Yeah, you're right. In fact this is the only option I have to make this work cleanly.
pax-wicket-api is (have to be independent) from the wicket version pax-wicket-impl14 is compatible from 1.4.0 to their next internal API change (e.g. 1.4.12). In this case I'll have to limit the wicket package imports to [1.4.0,1.4.12) and create pax-wicket-impl1412... Yeah but it seams that this is the only road to a clear semantic versioning... Thanks for the pointer and kind regards, Andreas On Tue, Jul 5, 2011 at 4:45 PM, Niclas Hedhman <nic...@hedhman.org> wrote: > On Tue, Jul 5, 2011 at 1:59 PM, Andreas Pieber <anpie...@gmail.com> wrote: > >> @1. IMHO it will create too much hassle to create a new project for >> each minor wicket release > > I actually look at this as the primary one. Your pax-wicket-api is > separated from pax-wicket-impl14 which is one variant of, > pax-wicket-impl15 being another, and the user need to match the > dependencies on their own choice. > > But welcome to versioning hell, and the fact that after >30 years of > software 'sharing' we have not been able to solve this problem at a > fundamental level, like Just because Mr Pieber now has evolved and > understand more things (and forgottten some other) doesn't impact most > "users"... > > > Cheers > -- > Niclas Hedhman, Software Developer > http://www.qi4j.org - New Energy for Java > > I live here; http://tinyurl.com/3xugrbk > I work here; http://tinyurl.com/24svnvk > I relax here; http://tinyurl.com/2cgsug > > _______________________________________________ > 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
