> 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.
Good idea. instead of : <groupId>org.apache.ant</groupId> <artifactId>ant</artifactId> <version>1.7.1</version> we could use : <groupId>org.apache.ant</groupId> <artifactId>ant</artifactId> <version>1.7.1-osgi</version> > 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. That's a huge task and may be a duplicate works from what is done by SpringSource and Eclipse ;( BTW, I'll be happy to see a sample pom.xml for such task, if you have one, it's more than welcome --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
