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,
|