I wholeheartedly agree that if you're going to be in the OSGi runtime the shared lib approach doesn't make sense. You would be denying yourself all the benefits that OSGi brings in terms of classloading and flexibility.
I just wanted to be clear that at a high level in 3.0 OSGi is not only a capability but also a requirement. Default conversions may work fine for some, but it might not work so well in practice if you have a large number of jars, in which case you (application developers) may have to bite the bullet and do the bundlization yourself. So this was really a question of transition/migration cost. The shared lib use case is/was useful when you have multiple wars that share a fair amount of jars. The wars themselves tend to be fairly small and lend themselves easily to automatic bundlization. What would be interesting is bundlizing the portion that was sitting in the shared lib. If the number of jars is significant, bundlizing each jar may prove to be quite time consuming (and not very automatic)... I suppose one possible idea to ease the transition is to make the shared lib optionally available via something like extra packages, but I admit that approach is neither clean nor desirable in the long term. Thanks, Sangjin On Wed, Mar 24, 2010 at 2:30 PM, David Jencks <david_jen...@yahoo.com>wrote: > > On Mar 24, 2010, at 2:10 PM, Kevan Miller wrote: > > > > > On Mar 24, 2010, at 4:57 PM, David Jencks wrote: > > > >> > >> On Mar 24, 2010, at 12:58 PM, Sangjin Lee wrote: > >> > >>> Thanks. So it sounds like it will be pretty much a *requirement* that > applications on 3.0 need to be fully OSGi bundles, > >> > >> Well, the idea is that the geronimo deployment process will turn your > javaee app into one or more bundles. We set up defaults for the osgi > manifest headers but you can modify them in your geronimo plans. > > > > Right. So traditional EE apps need not change. You can continue to deploy > EE defined artifacts (e.g. WAR/EAR/JAR). Users don't need to turn them into > bundles. Applications that used Geronimo deployment plan dependencies are > likely to require some changes... > > > >> > >>> and if you were using the shared lib as part of your classloading > scheme you will have to convert them all to OSGi bundles. > >> > >> Jars that aren't part of a javaee application need to be converted to > bundles before installing them. I guess we could provide a default > conversion but usually this doesn't seem to be adequate in practice. Do you > think this is going to be a problem for users? > > > > David never really liked shared-lib, to begin with... ;-) > > > > If you have compelling use cases, now is definitely a good time to speak > up... There's certainly a set of users that have found shared lib to be > convenient. > > While I always thought shared lib was a bad idea, at least pre-osgi the > concept of a classloader that you could just toss things in made sense. I > don't think it makes any sense in osgi. There is no dynamic-export header > so whatever implementation you came up with would have to know exactly what > packages to export... making the idea of adding more stuff to it useless. > If you just make sure your jar is bundleized so the packages you want to > use are exported, and install the bundle in the osgi framework, the osgi > wiring mechanism will take care of making it available to your app, in a > simpler, uniform way that is much more flexible than shared lib was. > > In other words, plain vanilla osgi all by itself does what shared lib was > for much much better. The only inconvenience is that you have to make your > libraries into bundles somehow. We can certainly talk about how to help > people do that, but that will be generally useful and/or impossible to do > well. > > thanks > david jencks > > > > > --kevan > >
