I'm with Toni and you on this one. 4.2.0 as "general" version for all pax-projects; single subprojects can take 4.3.0 but only if they really use new features (although I'm not aware right now of any pax-project really needing it).
Also +1 to the version matrix. In addition I think an upgrade to 4.3.0 should go at least with a new minor release (better with a new major) and is something which might should be discussed first here on this list. Therefore I think we should also revert all upgrades to 4.3.0 before the next releases already done to various pax projects. Kind regards, Andreas On Tue, Jan 24, 2012 at 19:48, Toni Menzel <t...@okidokiteam.com> wrote: > 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 < > hwellmann...@googlemail.com> 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 >> general@lists.ops4j.org >> http://lists.ops4j.org/**mailman/listinfo/general<http://lists.ops4j.org/mailman/listinfo/general> >> > > > > -- > Toni Menzel Source <http://tonimenzel.com> > > > _______________________________________________ > general mailing list > general@lists.ops4j.org > http://lists.ops4j.org/mailman/listinfo/general > >
_______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
