Hi, Am 07.06.2012 um 15:45 schrieb Luc Maisonobe:
> Hi, > > Le 06/06/2012 18:27, James Carman a écrit : >> Agreed. I'm in OSGi-land these days (ServiceMix, Camel, ActiveMQ, etc.), >> so I'm all for it! :) >> >> >> On Wed, Jun 6, 2012 at 12:21 PM, Christian Grobmeier >> <grobme...@gmail.com>wrote: >> >>> No objections here. >>> If there is a spec we can follow, we should do it. >>> In commons we build components - osgi is very natural for these kind >>> of stuff. If it helps the OSGi people and we have only little effort - >>> why not? > > Doest this mean we would enforce users to use OSGi too ? This is > something I would like to avoid, as not everybody uses this (even if > OSGi is a very good thing and should be used). This is about enabling the OSGi users (adding sensible package export versions) and not about forcing non-OSGi users (they don't care for the extra entries in the manifest. Regards Felix > > If adopting these conventions is better for OSGi users and does not harm > other users, then this would be an improvement. > > Luc > >>> >>> Cheers >>> >>> On Wed, Jun 6, 2012 at 2:00 PM, Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>>> Opening <CanOfWorms>... >>>> >>>> Should Commons adopt OSGi Semantic Versioning [1] instead of defining our >>>> own [2] (even though they might in effect be the same)? >>>> >>>> Should Commons layer its semantic version details on top of OSGi? >>>> >>>> [1] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf >>>> [2] http://commons.apache.org/releases/versioning.html >>>> >>>> Gary >>>> -- >>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 >>>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK >>>> Blog: http://garygregory.wordpress.com >>>> Home: http://garygregory.com/ >>>> Tweet! http://twitter.com/GaryGregory >>> >>> >>> >>> -- >>> http://www.grobmeier.de >>> https://www.timeandbill.de >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
