Move or reuse third-party classes out of org.eclipse.embedcdt.core

[jonahgraham]

org.eclipse.embedcdt.core currently exports some classes/packages for use within embedcdt bundles. This can cause weird and terrible wiring errors. For example, if another bundle does Import-Package: org.json.simple they can get the one provided in the embedcdt which may not be expected, especially if that pulls in other stuff like CDT. No one has complained about it in 2020-12 milestones, so we are OK for now, but it should be fixed ASAP.

As a temporary workaround the exports are being marked as non-API for the 6.0.0 release.

[jonahgraham]

There are places which the API takes or returns these non-API classes. For now I am marking these methods as non-API until we can resolve this issue fully.

[ilg-ul]

Thank you for detecting this.

What would be possible solutions?

[jonahgraham]

Reuse and/or contribute the shared libraries to Orbit. I can help with that.

However for semver it is probably is best to rename the packages because it is a fork.

[ilg-ul]

Reuse and/or contribute the shared libraries to Orbit. I can help with that.

Sure.

for semver it is probably is best to rename the packages because it is a fork.

I guess we can do this, but this means there will probably never be more updates, since further merges will be impractical, almost impossible.

If you can explain me exactly what the problem is, perhaps I can figure out a solution. If the actual semver classes are not public, is it still a problem?

[jonahgraham]

for semver it is probably is best to rename the packages because it is a fork.

I guess we can do this, but this means there will probably never be more updates, since further merges will be impractical, almost impossible.

It seems strange to worry about further merges on code that has not had a commit upstream in >6 years.

Is Semver modified, I thought it was, but I see that liqp is also modified. If Semver is not modified, then adding it to orbit is a good solution.

If you can explain me exactly what the problem is, perhaps I can figure out a solution.

If one bundle exports a package, any other bundle (embedcdt or not) can import it. So there are a few issues:

• If the package you are exporting is not versioned and identical, then depending on how OSGi and p2 resolve stuff, simply having embedcdt installed can break other people.
• If multiple bundles export the same package (e.g. org.json.simple) then p2 can decide to use either one to resolve it. This means that embedcdt's presence can cause unexpected results for other packages
• for places where these types are used in API, it the consume of the API does not use the same loaded versions of these classes, then at runtime you can class exceptions that are very hard to track down

For all the above cases, the results are generally not deterministic, so depending on random other factors, such as version of Java, how many plug-ins are installed, etc you can run into a problem.

None of the above is urgent. However it is technical debt that can come back to bite us down the road. After having spent days resolving a similar issue in simrel I am trying to protect against that for the future.

If the actual semver classes are not public, is it still a problem?

If the packages are not exported it is not a problem. If they are exported, even if x-internal, then it is a problem. The modifier (public/private) on the class itself does not come into play.

[ilg-ul]

I understood only that we have a problem, but I don't get the details yet.

For semver, how about renaming all packages to org.eclipse.embedcdt.semver? I can do this relatively easily and have it fixed in 6.0.0.

As for Liqp, there were several small patches, we need to use the patched version. Any quick fix for it?

[jonahgraham]

Same quick fix for liqp, rename package to org.embedcdt namespace.

[ilg-ul]

Now semver and liqp are fixed, please check the separate commits.

Any other improvements?

[ilg-ul]

Especially please check the export definitions, I don't know how they should look like, I just fixed the details for the build to pass.

[jonahgraham]

aef3d92 makes sure none of liqp or semver is exposed as API.

If someone needs this as API it is easier to expose as API than to hide it later.

[jonahgraham]

Now semver and liqp are fixed, please check the separate commits.

org.jsoup is already available in Orbit with vetted IP, so no CQ needed for the dependency. But since it is in orbit it would be better to pull in that copy. Add cross-ref to #453

Any other improvements?

Just at some point the stuff in #453. But I wouldn't do that now right before the release. The API in regards to #453 is clean so I think this issues is done.

[ilg-ul]

org.jsoup is already available in Orbit with vetted IP, so no CQ needed for the dependency. But since it is in orbit it would be better to pull in that copy.

I got the org.jsoup_1.7.2.v201411291515.jar file from Orbit R20201130205003.

What else needs to be done?