-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[#528] remove runtime dependencies to xbase.lib #529
Conversation
val accessorsUtil = new AccessorsProcessor.Util(context) | ||
body = ''' | ||
«ToStringBuilder» b = new «ToStringBuilder»(this); | ||
«MoreObjects.ToStringHelper» b = «MoreObjects».toStringHelper(this); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alternatively we may add a copy of ToStringBuilder to our codebase
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alternatively we may add a copy of ToStringBuilder to our codebase
I would vouch for that. It would be a pity to lose the nicely formatted output provided by ToStringBuilder for deeply nested structures that are so common in LSP, both when debugging and in error logs. It seems that copying ToStringBuilder would add little if anything to maintenance costs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd do the same. Copy the ToStringBuilder as a package private class.
@@ -37,15 +38,15 @@ class HoverTypeAdapter { | |||
protected def readContents(JsonReader in) throws IOException { | |||
val nextToken = in.peek() | |||
if (nextToken == JsonToken.STRING) { | |||
val List<Either<String, MarkedString>> value = newArrayList(Either.forLeft(in.nextString)) | |||
val List<Either<String, MarkedString>> value = Lists.newArrayList(Either.forLeft(in.nextString)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
List.of
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is java 9+
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
when it comes to guava, less is better)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is java 9+
ah, i see. sorry then
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
de-guavaize would be a second step.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
did replace it with pure java
@@ -37,15 +38,17 @@ class HoverTypeAdapter { | |||
protected def readContents(JsonReader in) throws IOException { | |||
val nextToken = in.peek() | |||
if (nextToken == JsonToken.STRING) { | |||
val List<Either<String, MarkedString>> value = newArrayList(Either.forLeft(in.nextString)) | |||
val List<Either<String, MarkedString>> value = new ArrayList<Either<String, MarkedString>>() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
replaced it with a bit more verbose pure java
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If verbosity is a concern, you could remove the type arguments from the constructor invocation. They would be inferred. But I doubt it matters much.
if (purified !== null) { | ||
method.removeAnnotation(purified) | ||
} | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that also a part of this issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes it removes the pure annotation
bd3e73e
to
450204b
Compare
450204b
to
f97666e
Compare
f97666e
to
8a04deb
Compare
What is the state of this PR - is this something you are maintaining on the side for those that need it or does it need to get to completion one day? |
i dont know if it is properly working as expected as where else we use xbase.lib |
OK - me neither, and I don't know how to tell. I guess if it looks good we can release it and have a trial by fire on it. We are still an incubating project. |
Guess we have to Grep generated code where Xbase and Xtend lib still are used |
cc436c1
to
22ee77d
Compare
bda8bf0
to
b48f059
Compare
@pisv @szarnekow @jonahgraham
what do you think. maybe we can merge this shortly after the release https://ci.eclipse.org/lsp4j/job/lsp4j-multi-build/job/cd_issue528/lastSuccessfulBuild/artifact/build/maven-repository/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this.
should we also remove NoAnnotationTest or keep it? |
I don't think it does any harm but does not add any value either. |
Read: inconclusive :) |
Sounds like a good plan, lets just give it a few days in case we need to respin LSP4J for 2022-03 release. |
8826bbe
to
a8874df
Compare
fcf9674
to
ebce1f9
Compare
We plan to update to LSP4J 0.20.0 soon, and once that's done we'll probably be able to remove our dependence on xbase.lib as well. |
Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>
Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>
Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>
Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de>
@jonahgraham what do you think? ready to merge or wait another week? |
@cdietrich go ahead and merge. I now have the |
this pr is merged now. so using the nightly it should be possible to consume without guava, xtext and xtend |
When the dependency on xbase.lib was removed in #529 it put the implicit requirement that there is a class called ToStringBuilder in a sub-package of the xtend class called `util`. This change provides the ToStringBuilder in an util package in the org.eclipse.lsp4j.jsonrpc bundle so that consumers of LSP4J do not need to copy ToStringBuilder into their own source code. Fixes #742
When the dependency on xbase.lib was removed in eclipse-lsp4j#529 it put the implicit requirement that there is a class called ToStringBuilder in a sub-package of the xtend class called `util`. This change provides the ToStringBuilder in an util package in the org.eclipse.lsp4j.jsonrpc bundle so that consumers of LSP4J do not need to copy ToStringBuilder into their own source code. Fixes eclipse-lsp4j#742
When the dependency on xbase.lib was removed in #529 it put the implicit requirement that there is a class called ToStringBuilder in a sub-package of the xtend class called `util`. This change provides the ToStringBuilder in an util package in the org.eclipse.lsp4j.jsonrpc bundle so that consumers of LSP4J do not need to copy ToStringBuilder into their own source code. Fixes #742
When the dependency on xbase.lib was removed in #529 it put the implicit requirement that there is a class called ToStringBuilder in a sub-package of the xtend class called `util`. This change provides the ToStringBuilder in an util package in the org.eclipse.lsp4j.jsonrpc bundle so that consumers of LSP4J do not need to copy ToStringBuilder into their own source code. Fixes #742
[#528] remove some runtime dependencies to xbase.lib
Signed-off-by: Christian Dietrich christian.dietrich@itemis.de