[#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.
alternatively we may add a copy of ToStringBuilder to our codebase
There was a problem hiding this comment.
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.
I'd do the same. Copy the ToStringBuilder as a package private class.
| 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.
when it comes to guava, less is better)
There was a problem hiding this comment.
is java 9+
ah, i see. sorry then
There was a problem hiding this comment.
de-guavaize would be a second step.
There was a problem hiding this comment.
did replace it with pure java
| 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.
replaced it with a bit more verbose pure java
There was a problem hiding this comment.
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.
Is that also a part of this issue?
There was a problem hiding this comment.
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/ |
|
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