Nice work Alin ! I think the reproductibility of the download is really a *major* problem.
That's why when we release wrapped bundles in servicemix, we add some incremental counter for the osgi metadata itself, so that the artifact never changes: http://central.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.commons-io/ So we have the version of the original jar followed by '_' and the counter in case the metadata is fixed or enhanced. Until there's a way to have downloads reproducible, I strongly thing that can not be used in production. Another problem is that I fear people will start using those bundles and find some osgi related problems for libraries that don't really work well in OSGi, so it can be confusing. So I wonder if this should be limited to libraries for which a bnd instruction file has been provided and tested. On Thu, Jun 30, 2011 at 1:27 PM, Alin Dreghiciu <adreghi...@gmail.com>wrote: > Hi, > > Lets just start by saying that this is an experiment. Will see where it > goes. > > The jars are turned into bundles same way as Pax URL wrap does. It > uses a bnd recipe and asks bnd to do it's job. It there is an bnd > recipe (same name as jar but with an .osgi extension) it uses that > one. It there is no such recipe a default one is created and then the > bundle is generated. The jar/recipe/bundle are kept in sync meaning > that if jar/recipe changes bundle gets regenerated. > When bundle changes the p2/obr repositories gets updated. > > The advantage of this over "wrap:" is that it will result in same > bundle being able to be shared by all repository users as well as > being able to automatically generate obr/p2 repos that makes them > available. In plus will help in the future on additional features a > wanna add like being able (via UI/rest calls) to ask Nexus to resolve > a set of bundles that one needs and get back a provision file ready to > be used to provision pax runner/karaf or a eclipse target platform. Or > any other formats we may think of. > > Disadvantage over pax wrap is that you are less flexible. > > As you mention the main problem I also foreseen is the fact that a > released artifact (non SNAPSHOT) should not change as maven will not > re-download it but yet I did not come up with an easy to use solution > (suggestions are kindly welcome :). And there is not only the problem > of re-downloading it but also the fact that everyone will want that a > released (generated in this case) bundle to stay the same over time. > > Another issue raised is how we handle the signed jars, no solution yet > either. > > One important thing here is that should be just an helper towards > moving to OSGi where many dependencies apps have are not yet OSGi > bundles and I encourage everyone to not rely on this but make proper > bundles or use the newer versions if those are already having proper > OSGi manifests (if possible). > > > On Thu, Jun 30, 2011 at 9:48 AM, Guillaume Nodet <gno...@gmail.com> wrote: > > While I find the idea interesting, I'm a bit skeptical on the real > > usefulness of that. > > Could you share a bit more informations on how the jars are turned > > into bundles ? > > Given maven repositories are supposed to be immutable, what if I find > > some errors > > in the osgi metadata and want to fix it ? > > How is that different than using the wrap url handler ? It seems to > > me that at least, with > > the url handler, you are in control and don't hit the above problems. > > Thoughts? > > > > On Thu, Jun 2, 2011 at 15:36, Alin Dreghiciu <adreghi...@gmail.com> > wrote: > >> Hi, > >> > >> If anyone interested in OSGi version of any of Maven Central artifacts > >> (jars) you can now get them by using the > >> http://grid.sonatype.org:9000/nexus/content/repositories/central/ > >> repository. > >> The osgi bundles are created on demand, meaning that the jar will be > >> OSGi-fyed as soon as the first request for it. The generated OSGi > >> bundle will have the same Maven coordinates (group/artifact/version) > >> as the original non OSGI jar but it will have and "osgi" classifier. > >> > >> You can use the bundle in a Maven build as for example: > >> <dependency> > >> <groupId>commons-logging</groupId> > >> <artifactId>commons-logging</artifactId> > >> <version>1.1.1</version> > >> <classifier>osgi</classifier> > >> </dependency> > >> > >> If you want to directly download the bundle, the URL is similar to > >> original (non OSGi) version of jar with an additional "-osgi" added in > >> front of ".jar" extension as in the following example: > >> > >> Original jar URL: > >> > http://repo1.maven.org/maven2/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar > >> > >> OSGi bundle URL: > >> > http://repo1.maven.org/maven2/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1-osgi.jar > >> > >> If using Pax Maven URL (Pax runner, Karaf, ...) you can access the > bundle as: > >> mvn:commons-logging/commons-logging/1.1.1/jar/osgi or > >> mvn:commons-logging/commons-logging/1.1.1//osgi > >> > >> Of course that if the jar is already an OSGi bundle it will not be > transformed. > >> > >> All of this automatically transformed bundles and all existing bundles > >> accessed via the above mentioned repository are available also via OBR > >> at: > >> > >> > http://grid.sonatype.org:9000/nexus/content/shadows/central-obr/.meta/obr.xml > >> > >> Soon I will als make this bundles available as an P2 repository. > >> > >> Note that this is an "lab" project for now so things might change and > >> will have downtimes as I will upgrade them with latest builds of Nexus > >> plugins we develop for OSGi. > >> > >> Feel free to send me your feedback about it so I can improve/fix it if > >> needed. Also same features could be enabled for other Maven > >> repositories out there. > >> > >> -- > >> Alin Dreghiciu > >> Software Developer > >> My profile: http://www.linkedin.com/in/alindreghiciu > >> My blog: http://adreghiciu.wordpress.com > >> http://sonatype.com - Sonatype - The Maven Company > >> http://www.ops4j.org - New Energy for OSS Communities - Open > >> Participation Software. > >> > >> _______________________________________________ > >> general mailing list > >> general@lists.ops4j.org > >> http://lists.ops4j.org/mailman/listinfo/general > >> > > > > > > > > -- > > ------------------------ > > Guillaume Nodet > > ------------------------ > > Blog: http://gnodet.blogspot.com/ > > ------------------------ > > Open Source SOA > > http://fusesource.com > > > > _______________________________________________ > > general mailing list > > general@lists.ops4j.org > > http://lists.ops4j.org/mailman/listinfo/general > > > > > > -- > Alin Dreghiciu > Software Developer > My profile: http://www.linkedin.com/in/alindreghiciu > My blog: http://adreghiciu.wordpress.com > http://sonatype.com - Sonatype - The Maven Company > http://www.ops4j.org - New Energy for OSS Communities - Open > Participation Software. > > _______________________________________________ > general mailing list > general@lists.ops4j.org > http://lists.ops4j.org/mailman/listinfo/general > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
_______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
