On Thursday 17 April 2008, Alan D. Cabrera wrote: > On Apr 17, 2008, at 7:19 AM, Guillaume Nodet wrote: > > I've thought about this. The main problem is that you end up having > > two different > > jars for the spec, one being a plain jar and another one being an > > OSGi bundle. > > Both would not be compatible if the bundle embeds the spec jar, > > because non osgi > > environment would not be able to load the jar inside the bundle. > > Imho, creating two different jars would confuse the users and be > > more error prone. > > Non OSGi environments use the vanilla jar as they currently do. OSGi > environments load the spec bundle. Doesn't seem confusing to me.
Well, it IS confusing when you have projects that are required to work in both OSGi and non-OSGi environments. Suddenly, they have to ship two versions of the same jar so downloads are bigger. They have to document when they can use one versus the other. You have to deal with users that don't read the docs and try to do something with the wrong one, etc... Not fun. There are also issues with maven and dependencies (must depend on the non-osgi for compiling, but the non-osgi for testing/shipping?), but that's a completely different issue. Dan > > > On Thu, Apr 17, 2008 at 4:10 PM, Alan D. Cabrera > > > > <[EMAIL PROTECTED]> wrote: > >> On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote: > >>> In the past months, I've been working on making the specs jars > >>> from > >> > >> Geronimo working in an OSGi environment. > >> > >>> All these jars have been published and work great :-) > >>> However, lots of these spec jars define factories (stax, saaj for > >>> example) > >> > >> that use the META-INF/services/ discovery mechanism to find an > >> implementation of the spec and load it. This mechanism does not > >> fit well in > >> OSGi (really, it does not), mainly because usually, the classloader > >> containing the spec jar will not contain the implementation. > >> > >>> I'd like to work on these spec jars so that they will contain an > >>> OSGi > >> > >> BundleActivator that would change the behavior of these factories > >> when > >> deployed in an OSGi environment (without changing the behavior in > >> other > >> case). The idea is that the activator would scan OSGi bundles when > >> they are > >> started to find META-INF/services and populate a map that would be > >> used by > >> the factory when creating an object before using the standard > >> mechanism. > >> > >>> The only real difference compared to what we currently have would > >>> be the > >> > >> addition of a package named org.apache.geronimo.specs.stax (for > >> example) > >> that would contain the needed classes (i suppose two classes), and > >> the > >> modification of the factories to delegate to one of these class > >> before using > >> the standard behavior (the class would do nothing if not deployed > >> in an OSGi > >> environment). > >> > >>> Has anyone any objection with such an enhancement in the specs jar > >>> ? > >> > >> I would prefer to have a virgin spec jar wrapped inside an OSGi > >> bundle. > >> Here the virgin factories would be overshadowed by the OSGi > >> specific factories. > >> > >> I feel strongly about this but am willing to discuss it. > >> > >> > >> Regards, > >> Alan > > > > -- > > Cheers, > > Guillaume Nodet > > ------------------------ > > Blog: http://gnodet.blogspot.com/ -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
