| [ve-dev] Changes being proposed for JEM bundle structure ... |
|
As I hope you know, the JEE Tools project took
over stewardship of JEM a couple of years ago. We've had a bug/feature request to un-nest some embedded jars, so that people can compile against the binary version of those bundles and jars and not have to have the complete source tree present. This is, sort of, a well known PDE limitation, where it works a little differently that what a pure OSGi runtime would allow. I think it is feasible to un-nest these jars, given OSGi, compared to the original Eclipse Plugin model, which was used when this JEM code was first designed and developed. That is, we'd refactor the nested jars out of the current bundle, and make them bundles too. That makes PDE happy, and the bundles can still be used as ordinary jars (and the OSGi directives ignored). If this works, it will be nothing but good news for projects that pre-req all of WTP anyway (not sure what VE does) but for projects who "pick and choose" exactly which bundles to get for their feature or products, then they will have to be aware of the fact that they need to get two additional bundles from JEM. Their code should not have to change at all ... the bundles just have to be present (they used to be present by virtue of being nested inside of other jars, which they no longer will be). You can follow along in this bug, if you are interested. https://bugs.eclipse.org/bugs/show_bug.cgi?id=256441 The "rub" is that we would like to provide this new structure in our Ganymede SR2 release. Normally, restructuring should be avoided for a maintenance release, but since there's no real change of code or dependencies, I think it is reasonable to propose. Let us know if you object, or if are overjoyed because it will make VE easier to build :) Comments in the bugs are fine, and once it's ready, if any of you can give it an early test, that would be very helpful. Thanks, |