I usually had (in the recent year) 4.2.0 in mind. - some kind of implicit assumption that its what many OSGi related projects use. I think its even today the lowest common denominator across pax projects, so we should align them to that version.
Once a single project needs to go with 4.3.0 it can do so (for example for using the Hook AP e.g.). But, again, 4.2.0 looks like a good agreement. The next "useful" level of - speaking of getting a larger user base - would be supporting OSGi Spec 3.x.. which i don't see happening in the tooling space. Toni On Tue, Jan 24, 2012 at 7:42 PM, Harald Wellmann < [email protected]> wrote: > Which OSGi versions should we support in Pax? > > Which OSGi version should we use to compile Pax projects? > > The reason I'm asking is: There have been a few commits introducing > org.osgi.core:4.3.0 here and there and a few comments not so happy about > that move. > > I tend to agree, but changing the POMs back and forth is not a good idea, > so I'd like to discuss the issue and hopefully reach an agreement before > the next release train. > > According to [1], only OSGI 4.x is supported. > > Pax Exam and Pax Swissbox Framework definitely require 4.2.0 or higher > because of the FrameworkFactory. > > The Pax Swissbox Parent POM has org.osgi.core:4.0.1 in the last release > and 4.2.0 in current snapshots (changed by myself in December) - if this is > not desirable, there's no problem reverting to 4.0.1 in the parent and > using 4.2.0 for pax-swissbox-framework only. > > Regarding OSGi 4.3.0, there are significant API changes, not only new > classes and methods but also changed signatures due to generic type > arguments. While this is backward compatible (i.e. OSGi 4.3.0 runs bundles > compiled with 4.2.0), I'm not so sure about the opposite direction, and > even if there are no runtime conflicts, you get lots of ugly compiler > warnings when compiling current Pax code with raw types against OSGi 4.3.0 > with generics. > > So I think we should stick with (or revert to) 4.2.0 until further notice, > which does not rule out the possibility of individual subprojects upgrading > to 4.3.0 if they unavoidably require some of the new features (e.g. weaving > hooks). > > And we should clearly define which projects (if any) shall remain > compatible to 4.0.1 or 4.1.0 and put up a nice handy project/version matrix > in the Wiki. > > By the way, anybody voting for 4.1.0 support should be prepared to > contribute integration tests running on old framework versions :-P > > What do you think? > > [1] > http://team.ops4j.org/wiki/**display/ops4j/Pax<http://team.ops4j.org/wiki/display/ops4j/Pax> > > Cheers, > Harald > > ______________________________**_________________ > general mailing list > [email protected] > http://lists.ops4j.org/**mailman/listinfo/general<http://lists.ops4j.org/mailman/listinfo/general> > -- Toni Menzel Source <http://tonimenzel.com>
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
