Skip to content
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

Merged
merged 4 commits into from
Mar 1, 2023
Merged

Conversation

cdietrich
Copy link
Contributor

[#528] remove some runtime dependencies to xbase.lib
Signed-off-by: Christian Dietrich christian.dietrich@itemis.de

val accessorsUtil = new AccessorsProcessor.Util(context)
body = '''
«ToStringBuilder» b = new «ToStringBuilder»(this);
«MoreObjects.ToStringHelper» b = «MoreObjects».toStringHelper(this);
Copy link
Contributor Author

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

Copy link
Contributor

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.

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.

@cdietrich cdietrich marked this pull request as draft March 26, 2021 08:13
@@ -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))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

List.of?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is java 9+

Copy link
Contributor

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)

Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor Author

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>>()
Copy link
Contributor Author

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

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)
}
]
Copy link
Contributor

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?

Copy link
Contributor Author

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

@jonahgraham
Copy link
Contributor

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?

@cdietrich
Copy link
Contributor Author

i dont know if it is properly working as expected as where else we use xbase.lib

@jonahgraham
Copy link
Contributor

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.

@cdietrich
Copy link
Contributor Author

Guess we have to Grep generated code where Xbase and Xtend lib still are used

@cdietrich cdietrich force-pushed the cd_issue528 branch 2 times, most recently from cc436c1 to 22ee77d Compare August 5, 2022 04:13
@cdietrich cdietrich marked this pull request as ready for review August 5, 2022 04:32
@cdietrich cdietrich force-pushed the cd_issue528 branch 2 times, most recently from bda8bf0 to b48f059 Compare September 22, 2022 09:27
@cdietrich
Copy link
Contributor Author

cdietrich commented Feb 14, 2023

@pisv @szarnekow @jonahgraham
i have updated this pr by

  • also remove the annotation for the adapters TypeAdapterImpl annotation
  • add copies of ToStringBuilder so we are compatible and dont need guava dependency
  • moved generator dependency to compileOnly (so no longer maven dependency to it)
  • added ArchUnit tests to make sure we no longer depend on xbase.lib, xtend.lib, guava and lsp4j.generator at runtime.

what do you think. maybe we can merge this shortly after the release
cc @rgrunber this might be of interest for you on jdt.ls side

https://ci.eclipse.org/lsp4j/job/lsp4j-multi-build/job/cd_issue528/lastSuccessfulBuild/artifact/build/maven-repository/
https://ci.eclipse.org/lsp4j/job/lsp4j-multi-build/job/cd_issue528/lastSuccessfulBuild/artifact/build/p2-repository/

@cdietrich cdietrich changed the title [#528] remove some runtime dependencies to xbase.lib [#528] remove runtime dependencies to xbase.lib Feb 14, 2023
Copy link

@szarnekow szarnekow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this.

@cdietrich
Copy link
Contributor Author

should we also remove NoAnnotationTest or keep it?

@szarnekow
Copy link

should we also remove NoAnnotationTest or keep it?

I don't think it does any harm but does not add any value either.

@szarnekow
Copy link

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 :)

@jonahgraham
Copy link
Contributor

what do you think. maybe we can merge this shortly after the release

Sounds like a good plan, lets just give it a few days in case we need to respin LSP4J for 2022-03 release.

@cdietrich cdietrich force-pushed the cd_issue528 branch 2 times, most recently from 8826bbe to a8874df Compare February 17, 2023 12:57
@cdietrich cdietrich force-pushed the cd_issue528 branch 2 times, most recently from fcf9674 to ebce1f9 Compare February 22, 2023 17:56
@rgrunber
Copy link

what do you think. maybe we can merge this shortly after the release cc @rgrunber this might be of interest for you on jdt.ls side

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>
@cdietrich
Copy link
Contributor Author

cdietrich commented Mar 1, 2023

@jonahgraham what do you think? ready to merge or wait another week?
didnt follow if you built the patch from master or a dedicate maintenance branch

@jonahgraham
Copy link
Contributor

@cdietrich go ahead and merge. I now have the release_0.20 branch if I need to do any further respins for 2023-03

@cdietrich cdietrich merged commit 4bad511 into main Mar 1, 2023
@cdietrich cdietrich deleted the cd_issue528 branch March 1, 2023 14:17
@cdietrich
Copy link
Contributor Author

this pr is merged now. so using the nightly it should be possible to consume without guava, xtext and xtend
cc @rgrunber @mickaelistria

@jonahgraham jonahgraham added this to the 0.21.0 milestone May 17, 2023
jonahgraham added a commit that referenced this pull request Feb 12, 2024
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
jonahgraham added a commit to jonahgraham/lsp4j that referenced this pull request Feb 13, 2024
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
jonahgraham added a commit that referenced this pull request Feb 13, 2024
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
jonahgraham added a commit that referenced this pull request Feb 13, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove dependency on xtext's @Pure and ToStringBuilder
7 participants