Revist the transitive dependencies of org.apache.commons.jxpath

[merks]

Unfortunately I overlooked the fact that not only jxpath is being removed, but also any transitive dependencies that are also no longer required by the Platform itself.

eclipse-platform/eclipse.platform.releng.aggregator#2814

Specifically the following which also lead to aggregation failure:

Sorry I did not consider this in advance. 😢

[ewillink]

Please be clear about what more MoDisco needs to redistribute

• both commons-beanutils and commons-collections as suggested by the pom snippet
• org.apache.commons.beanutils as suggested by the failure

Since these removals break existing functionality prresumably way beyond MoDisco, surely the removals should be reverted to preserve compatibility? Whether the platform uses them is irrelevant.

[ewillink]

Strange.

On 2024-12, the Plugin Dependencies View shows that org.apache.commons.jxpath 1.3.0.v200911051830 has no dependencies.

The org.apache.commons.jxpath MANIFEST.MF shows no dependencies.

[ewillink]

If org.apache.commons.beanutils is needed by MoDisco, why didn't the SimRel build fail forcing the deficient contribution to be remedied?

[merks]

Maybe you, or some tool, is overlooking package requirements...

These are the problematic missing dependencies (package requirements) in the MANIFEST.MF

Of course it's a transitive problem so I believe you will need org.apache.commons.commons-beanutils which needs org.apache.commons.collections.

Please also keep in mind that the maven coordinates and jar names are often quite different from the bundle symbolic name.

This table has links back to maven central so that might be useful:

https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/table.html

From that table we see org.apache.commons.commons-beanutils comes from:

https://repo1.maven.org/maven2/commons-beanutils/commons-beanutils/1.10.0/

---

No project is obligated to provide 3rd party dependencies to downstream projects that it does not itself require. Unfortunately it's hard to test the extent to which your repository is complete so it's easy to rely on the dependencies being in SimRel and then innocently overlook the fact that some other project is contributing to SimRel the 3rd party dependency that your project needs. This already happened with tracecompass as well when ECF reduces the content of its p2 repository:

eclipse-tracecompass/org.eclipse.tracecompass#206

[ewillink]

The eclipse-orbit/orbit-simrel#46 fix enables me to see

This suggests that commons-collections may be the next problem.

[merks]

If WTP ever stops contributing it, that will become a problem:

[ewillink]

Thanks. Might as wll do org.apache.commons.collections too.

org.apache.commons.logging seems safe enough since it is needed by org.apache.ant that is needed by Platform, EMF, UML, ...