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
