Isn't the role of the "classifier" field ? 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</version> <classifier>osgi</classifier> ________________________________ De: Henri Gomez [mailto:[email protected]] Date: mar. 27/01/2009 23:00 À: Maven Users List Objet : Re: maven / osgi / repositories > 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: [email protected] For additional commands, e-mail: [email protected] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
