Hi, as you point it out there is definitely an issue with the renaming of groupId /artifactId as it will 'break' maven dependency management. However I don't think that anyone but the project owner(s) should be allowed to deploy a jar with their groupId/artifactId (to the public repo). I believe this is why the springsource guys renamed theirs.
I feel like the issue with non-OSGi jars is very similar to what happened when first moving all libraries from the maven1 repository to the maven2 repository. This is even more complicated as this time the "metadata" in inside the jar. Until all projects make the effort of having a correct OSGi compatible MANIFEST in their jars we'll have to deal with it ourselves. The only way that I can think of it working is to have your own repository with OSGi-ified versions of the libraries you need. The most sensible thing to do is probably changing the version so that it identifies the jar as being OSGi. This will let you use maven's dependency management to some extent. You will have to use the "dependencyManagement" section of your POMs though to enforce OSGi versions of the libraries. I don't think those jars can go to the public repo though. Practically I would consider creating maven projects on your side of things using the shade plugin to create an OSGi version of the library you want, just overriding/merging the MANIFEST and changing the version. This would simply be a pom.xml and a MANIFEST file. Another thing is definitely to create issues and provide patches to those project so that they can start make their jars OSGi compatible. SaM On Wed, Jan 28, 2009 at 12:18 AM, Henri Gomez <[email protected]> wrote: >> Hi Henri, >> >> it seems to me that OSGi jars are not meant to be anything else that >> traditional jars with extra information in their MANIFEST. I would >> definitely recomment deploying them as standard jar as you would do >> for any normal maven project. > > Simple jar with MANIFEST, but today very few maven artifact are > OSGIfied, so so should geth OSGIfied jars elsewhere or with a > different group/artifact id ;( > >> One thing that could/would differentiate your OSGi jars is that if you >> use the maven bundle plugin >> [http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html] >> then the pom deployed along side your jar will have the packaging set >> to "bundle". To me it seems like enough information. > > For inhouse projects, it's not a problem and we allready do that from > our RCP projects, but the problem is still here for external projects, > ie ant, jaxws... > >> Another point of reference you might consider is how the springsource >> guys make OSGi-ified version of many java libraries in their bundle >> repository [http://www.springsource.com/repository/]. This acts pretty >> much as a simple maven repository delivering jars. > > I see that but the group/artifact is not the same that the one used in > developpement, hard after that to get a clean trace from developpment > to runtime :( > >> Also I know that the Felix guys have an initiative around an OSGi >> Bundle Repository (OBR) >> [http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html]. >> This is meant to be a repository that is more OSGi specific. I could >> help with dependency resolution -- just as maven does -- by >> introspecting jars MANIFESTs. > > A good idea, it will be nice to get it as maven central. > > And in the long term, get all 'maven' artifact converted to > osgi-bundle (very long term). > > Or may by specializing maven request, ie I need ant-1.7.2 jar, > ant-1.7.2 osgi-bundle. > So we could have simple jar and bundle at the same location in maven repo. > >> Archiva or Nexus would most probably satisfy your needs for maven >> repositories. They might become OBRs at some point when OSGi becomes >> more "mainstream". > > I think there is plan for this in Nexus. > >> Hope this helps, >> SaM > > Thanks for your time Sam, it was helpfull :) > >> On Tue, Jan 27, 2009 at 10:24 PM, Henri Gomez <[email protected]> wrote: >>> Hi to all, >>> >>> We're using maven to build all our company projects for about 6 months >>> and are very happy with it. >>> Some of our projects, mainly Eclipse RCP plugins, are also mavenized. >>> >>> We know think about OSGIfing more of our projects (server side) and >>> track ASF projects Felix of course core but also ServiceMix Kernel. >>> >>> BTW, we wonder if there is a consensus or strategy about OSGIfied >>> artifacts and their location in external repositories. >>> >>> - Should we repackage our current projects to produce both jar and plugins ? >>> >>> - How and where to store these artifacts to make sure Felix could get >>> it (did a Nexus repository could do the job). >>> >>> - How to 'mark' artifacts to indicate the difference between strict >>> jar and OSIG jars (bundles). Eclipse prefix then with org.eclipse, SS >>> with com.springsource ? >>> >>> >>> Advices and experience are more than welcome. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
