Do not embedd lemminx

[laeubi]

I just faced an issue that I wanted to test a new lemminx snapshot build, and this was more complex than I thought.

1. https://github.com/eclipse-wildwebdeveloper/wildwebdeveloper/blob/master/TIPS_and_FAQ.md didn't mentioned anything
2. I needed to debug the code to find out it has lemminx embedded and find the magic path (that will change depending on each deployment)
3. Then replace the jar by a manual copy to that location

What I thought about would it be not more convenient if lemminx would be not embedded in the jar itself? My idea would be to have the following adjustments:

1. make the lemminx-uber-jar a bundle that just exports all lemminx packages
2. let WWD require-bundle that one with a version range (e.g. excluding the next minor version)
3. the WWD can find out the JAR of the bundle and the just use that

This has the advantage that at least it is possible to update lemminx independent from WWD, the WWD bundle itself gets a lot "slimmer" (currently ~10 MB!) and possibly others can reuse that (e.g. extensions).

On the long run, one could even think about not using the uber-jar and simply collect lemminx and all its OSGi dependencies but thats a different topic.

[mickaelistria]

I tried it initially to make Wild Web Developer+LemMinX more OSGi-friendly and there are some challenges with it:

• In Maven world, there are not so fine-grain modularity so what works in the uber-jar (because Maven resolved and tested those dependencies) may fail in other deployments because of undocumented dependency ranges. In the current state, LemMinX is totally unable to support such "exotic" deployments.
• LemMinX uses ServiceLocator with classpath extensions to detect extension, and that is harder to support with OSGi
• Some LemMinX deps are/were not OSGi-ready

make the lemminx-uber-jar a bundle that just exports all lemminx packages

That might be good; however I'm still unsure about how to enable extensibility there. If you can demonstrate extensibility can be made to work with such approach, then it is probably a very good step forward.

[laeubi]

I have now created a draft PR at lemminx:

• Add an uber-bundle artifact eclipse-lemminx/lemminx#1701

[mickaelistria]

Couldn't most of the change just take place in the .target of m2e?

[laeubi]

Couldn't most of the change just take place in the .target of m2e?

This then wont allow an independent update of a lemminx build (so not much different from what it is today).

[mickaelistria]

The difference is that we wouldn't need to bump the version org org.eclipse.wildwebdeveloper.xml when trying to use a newer lemminx. That would already be a benefit.
But then, if you want lemminx to be "externally updatable", what would be the source p2 repo where new versions of lemminx come from?

[laeubi]

I think there are different cases

1. I build a local version / have lemminx in the workspace, this is/was the primary driver about my initial request as it was a bit tricky to find out how to get this working
2. there is a new lemminx release and I want to update it as a user independent from WWD, in such case e.g lemminx could provide a (maven based) update site

[laeubi]

@mickaelistria I have now created a PR here (needs approval from a maintainer):

• Consume lemminx as a bundle from the OSGi runtime #1741