Geir Magnusson Jr wrote: > Tim Ellison wrote: >> Sure, if you don't want the runtime effects of OSGi then you have >> flexibility to package the classes into any shape, including an rt.jar. >> However, if we want to support runtime modularity including component >> versioning etc. then we will have to have a number of discrete bundles. >> If OSGi has the ability to put multiple bundles into a single JAR ... > > I thnk you are missing my point. Sorry. What I'm saying/asking is > about OSGi being one [of many possible] delivery "packagings" of the > class libraries.
Can you think of any other runtime modularity systems that we should consider supporting? > So yes, I think that we definitely want to do OSGi as our default > packaging for our full implementation of J2SE, but that doesn't seem to > have to dictate on how we work with the code as class library > developers, does it? Life is easier if we layout the source code in modules too (rather than, say, mash it all together and make the modularity a package-time event) because we can get development time support from OSGi-aware tools like PDE that will 'smack' you for references outside the module definitions, compilation against the target directory, etc. > We have the circular dep issue to tangle with > (which seems to go away if we do a bootstrap uber-compile/uber-jar) and > we can also offer other packagings of the classlibrary to work with > systems that don't do OSGi support. Agreed. > And we don't know how 277 is going to turn out - we hope for OSGi-ish, > but one never knows... Makes it kinda difficult to support then ;-) I say we cross that bridge when we get to it. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
