Switch to plain Maven artifacts (no Tycho)

[mickaelistria]

Here is a proposal to simplify releng for LSP4J: now that it's much easier to include libraries from Maven into a .target, it doesn't seem necessary for LSP4J which is first an API and not an Eclipse plugin, to publish a p2 repository. LSP4E can simply include the latest LSP4J from Maven repo (Central or repo.eclipse.org) as long as it has proper OSGi metadata. So if this seems profitable for LSP4J, let's remove creation and publication of a p2 repo.

[cdietrich]

lsp4j is pure maven artifacts already. i dont know if all clients would be fine consuming it non p2 repo way

[mickaelistria]

lsp4j is pure maven artifacts already.

Indeed, I've retitled the issue to better capture the proposal.

i dont know if all clients would be fine consuming it non p2 repo way

LSP4E, JDT-LS and LemMinX could totally live without a p2 repo for LSP4J and would be fine consuming it from Maven.

[cdietrich]

how does contributing pure maven artifacts to simrel work?

[mickaelistria]

Should LSP4J be contributed directly to SimRel? LSP4E would contain the version of LSP4J it depends on in its p2 repo, SimRel could pick LSP4J from LSP4E repo.

[cdietrich]

the question is what is about 3rd party users. right now they can install from simrel

[mickaelistria]

the question is what is about 3rd party users

Well, it's more or less your call here; I'm suggesting that there are some build steps and integration that could probably be skipped; if you're willing to keep doing this work anyway, feel free. But what we've learned in many projects lately is that breaking 3rd-party users is actually the best way to get them contributing more. ie if some people need a p2 repo and you stop producing them, either they'll find a solution on their end, or they'll come and take care of this work, ie you've gained some contributors and ultimately have less work to do personally for the same value produced.

right now they can install from simrel

No-one installs LSP4J as it because it's not a functional bit of the IDE, it's an API, it's best to include it in a .target, and it's .target has capacity to load Maven artifacts directly.

[cdietrich]

cc @rubenporras @szarnekow

[cdietrich]

my experience shows that projects might be on older eclipse versions where the m2e p2 thing is not available ootb, old tycho versions are used, just try out without extra setup etc.

[mickaelistria]

Let's close. It looks like producing p2 repo is profitable enough for someone to actively care about providing such support. I had an apparently incorrect guess that such removal of duty would be perceived as an improvement for the maintainer community.

[szarnekow]

Well, it's more or less your call here; I'm suggesting that there are some build steps and integration that could probably be skipped; if you're willing to keep doing this work anyway, feel free.

Are you saying removing build steps from a script will attract new contributors? Sorry for being a little blunt here, but wouldn't their contribution be to put these steps back into the build script?

[szarnekow]

Ok, that was a race-condition.

[mickaelistria]

but wouldn't their contribution be to put these steps back into the build script?

Yes, and then to take ownership of those. For the same result, you get 1 more person involved in the project, that's a win. There is always a risk that the contributor community gets "enslaved" by the consumers; by not doing for free work that the contributor community doesn't need, then the consumers have to start investing and contribute to the project one way or the other (manpower, money...) which ultimately makes the project more sustainable. Being too kind with consumers is actually a disservice in many cases. But here, it seems like @cdietrich is OK with the current status; and I wrongly assumed producing p2 repo was "free work that the contributor community doesn't need".

[cdietrich]

i cannot judge. but the current build script creates it ootb @jonahgraham is there any extra effort on your side i dont see?

[rubenporras]

@mickaelistria , I see that we have closed the ticket without implementing it, but out of curiosity, since we use .target files everywhere, and you mention that it is easier that before to "include libraries from Maven into a .target", where can I read about that?

[mickaelistria]

you can find some bits of explanation here and there, but the big picture is AFAIK best explained at https://läubisoft.gmbh/en/articles/using-maven-artifacts-in-pde-rcp-and-tycho-builds/

[jonahgraham]

My instinct is to not remove the p2, it is already in place, works and is fully automated.

However if it stops working at some point, or needs some refactoring, it may then be more profitable to remove it than maintain it.

---

If someone is looking to add some value to releng it would be to add GitHub actions for PRs (however GitHub actions on the "main" Eclipse org at github tends to have ridiculously long latency, so doing the GHAs would probably mean asking EF staff to move lsp4j to its own org).

We also have "approval" from the community to change to Java 11 (not 17!) - https://github.com/eclipse/lsp4j/issues/547 - but no one has desired to invest the time to do that work yet.

[mickaelistria]

See #706 and #707