Re: maven / osgi / repositories
Jason van Zyl-5 wrote: > > > On 27-Jan-09, at 6:41 PM, Barrie Treloar wrote: > >>> repositories. They might become OBRs at some point when OSGi becomes >>> more "mainstream". >> >> One thing I have been toying with for a while is to auto-magically >> extend maven-jar-plugin to add the OSGi headers. >> > > I really don't think this is a great idea. I think for a bundle to be > useful someone needs to provide proper imports and exports. > >> I haven't given a lot of thought into what I need to do, but if I >> recall correctly, getting a simple OSGified jar isn't much work and if >> Maven did this out of the box then the maven repository would become >> OSGified over time as projects release their artifacts. >> > > We've toyed around with this idea, but if you want something useful I > think it's really hard to infer something useful. Making a manifest > that is workable with OSGi is not that hard and the author of a > package is probably the person to do it. I think what we can do is > give a brief guideline as to what's commonly expected and help people > create correct and useful bundles. Maven central is the biggest bundle > repository in waiting :-) > > I'm sure my views aren't unique, and I'm probably rehashing what someone else already said, but here goes: When you see that a dependency isn't OSGi-ified, first put yourself in the shoes of its authors, and consider the possible reasons: * "No one has requested OSGi-ification." This is pretty common. The author's don't even know that there is a demand because no one asked. Even if there is no time to wait on the authors and you have to custom-deploy a wrapped-version, at least file a bug to get the ball rolling. * "It's just a packaging concern, you can download a wrapped bundle from www.blah.." The Maven community has the most to lose from this approach to OSGi-ification. This wreaks havoc with the coordinate system. Sometimes the authors don't even know that others (1..*) have published wrapped versions of their jars. The dependency authors should be made aware that these workarounds do not serve the Maven+OSGi community well. * "We would add it, but how could we test it and maintain it?" This is very common too and I don't think there is an easy answer yet. Much of the testing infrastructure isn't even OSGi-ified yet. When filing requests for OSGi-ification, it would be nice if I could direct the dependency authors to a site/mailing-list where all their OSGi-ification/Maven-alignment questions could be answered. Does such a resource exist? I recently filed a request with Mockito, please take a look and let me know if I should have done anything differently: http://code.google.com/p/mockito/issues/detail?id=67 -- View this message in context: http://www.nabble.com/maven---osgi---repositories-tp21683632p22770424.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: RE : RE : RE : maven / osgi / repositories
Nope Christope, if you use the assembly plugin you'll usually get [artifactId]-[version]-[assemblyId].[assemblytype] e.g. distribution-1.0.0-SNAPSHOT-dist-binary.zip if I use dist-binary in src/assembly/dist-binary.xml in _addition_ to the normal build artifact. But keep up the good discussion about OSGi. What about the maven-osgi-plugin [1] or the even better the maven-bundle-plugin [2] the felix folks use? Has anyone experience with one of those yet? LieGrue, strub [1] http://mavenosgiplugin.berlios.de/ [2] http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html --- Deneux, Christophe schrieb am Fr, 30.1.2009: > Von: Deneux, Christophe > Betreff: RE : RE : RE : maven / osgi / repositories > An: "Maven Users List" , "Maven Users List" > > Datum: Freitag, 30. Januar 2009, 9:12 > Sorry, but I haven't a such POM. > > Moreover, I think that you should define different > profiles: one for the standard jar (without > maven-assembly-plugin), another for the OSGI jar (whith the > maven-assembly-plugin). It seems to me that when using the > maven-assembly-plugin with the goal "attach" only > the jar generated by the maven-assembly-plugin can be > deployed (through maven-deploy-plugin). So to be able to > deploy the both JARs you need two profiles. > > ___ > Christophe DENEUX / Capgemini Sud / Méditerranée > Integration Architect / OW2 PEtALS Comitter > Tel: + 33 4 93 95 55 92 / www.capgemini.com > <http://www.capgemini.com/> > Porte de l'Arénas - Entrée B / 455 Promenade des > Anglais / 06200 Nice / FRANCE > Join the Collaborative Business Experience > ___ > Please consider the environment and do not print this email > unless absolutely necessary. Capgemini encourages > environmental awareness. > > ____________ > > De: Henri Gomez [mailto:henri.go...@gmail.com] > Date: jeu. 29/01/2009 10:39 > À: Maven Users List > Objet : Re: RE : RE : maven / osgi / repositories > > > > Good idea. > > Did you have sample pom.xml for study ? > > Thanks Christophe > > 2009/1/29 Deneux, Christophe > : > > In your OSGI bundle project, you will use the > maven-assembly-plugin to generate your OSGI bundle artifact > (artifactId-version-classifier.jar) with: > > - configuration of the Manifest to specify specific > OSGI information: > > > > > maven-assembly-plugin > > > > [...] > > > > > > [...] > > > > > > > >[...] > > > >- a classifier set in the assembly id of the > assembly descriptor. > > > > > > To reference a dependence on a OSGI bundle, you should > use the dependencies mechanism: > > > > [...] > > > > > org.apache.ant > > > ant > >1.7.1 > > > osgi > > > > [...] > > > > > > So you have in your repository: an artifact usable as > simple library (the default artifact) and another one usable > as a OSGI bundle. > > I never try a such configuration, but I imagine that > it should work fine. > > > > > > > ___ > > Christophe DENEUX / Capgemini Sud / Méditerranée > > Integration Architect / OW2 PEtALS Comitter > > www.capgemini.com <http://www.capgemini.com/> > > Porte de l'Arénas - Entrée B / 455 Promenade des > Anglais / 06200 Nice / FRANCE > > Join the Collaborative Business Experience > > > ___ > > Please consider the environment and do not print this > email unless absolutely necessary. Capgemini encourages > environmental awareness. > > > > > > > > De: Henri Gomez [mailto:henri.go...@gmail.com] > > Date: mer. 28/01/2009 18:04 > > À: Maven Users List > > Objet : Re: RE : maven / osgi / repositories > > > > > > > > 2009/1/28 Deneux, Christophe > : > >> Isn't the role of the "classifier" > field ? > >> > >> instead of : > >> > >> org.apache.ant > >> ant > >> 1.7.1 > >> > >> we could use : > >> > >> org.apache.ant > >> ant > >&g
RE : RE : RE : maven / osgi / repositories
Sorry, but I haven't a such POM. Moreover, I think that you should define different profiles: one for the standard jar (without maven-assembly-plugin), another for the OSGI jar (whith the maven-assembly-plugin). It seems to me that when using the maven-assembly-plugin with the goal "attach" only the jar generated by the maven-assembly-plugin can be deployed (through maven-deploy-plugin). So to be able to deploy the both JARs you need two profiles. ___ Christophe DENEUX / Capgemini Sud / Méditerranée Integration Architect / OW2 PEtALS Comitter Tel: + 33 4 93 95 55 92 / www.capgemini.com <http://www.capgemini.com/> Porte de l'Arénas - Entrée B / 455 Promenade des Anglais / 06200 Nice / FRANCE Join the Collaborative Business Experience ___ Please consider the environment and do not print this email unless absolutely necessary. Capgemini encourages environmental awareness. De: Henri Gomez [mailto:henri.go...@gmail.com] Date: jeu. 29/01/2009 10:39 À: Maven Users List Objet : Re: RE : RE : maven / osgi / repositories Good idea. Did you have sample pom.xml for study ? Thanks Christophe 2009/1/29 Deneux, Christophe : > In your OSGI bundle project, you will use the maven-assembly-plugin to > generate your OSGI bundle artifact (artifactId-version-classifier.jar) with: > - configuration of the Manifest to specify specific OSGI information: > >maven-assembly-plugin > > [...] > > > [...] > > > >[...] > >- a classifier set in the assembly id of the assembly descriptor. > > > To reference a dependence on a OSGI bundle, you should use the dependencies > mechanism: > > [...] > >org.apache.ant >ant >1.7.1 >osgi > > [...] > > > So you have in your repository: an artifact usable as simple library (the > default artifact) and another one usable as a OSGI bundle. > I never try a such configuration, but I imagine that it should work fine. > > > ___ > Christophe DENEUX / Capgemini Sud / Méditerranée > Integration Architect / OW2 PEtALS Comitter > www.capgemini.com <http://www.capgemini.com/> > Porte de l'Arénas - Entrée B / 455 Promenade des Anglais / 06200 Nice / FRANCE > Join the Collaborative Business Experience > ___ > Please consider the environment and do not print this email unless absolutely > necessary. Capgemini encourages environmental awareness. > > > > De: Henri Gomez [mailto:henri.go...@gmail.com] > Date: mer. 28/01/2009 18:04 > À: Maven Users List > Objet : Re: RE : maven / osgi / repositories > > > > 2009/1/28 Deneux, Christophe : >> Isn't the role of the "classifier" field ? >> >> instead of : >> >> org.apache.ant >> ant >> 1.7.1 >> >> we could use : >> >> org.apache.ant >> ant >> 1.7.1 >> osgi > > Good but how do you specify such classifier in dependants projects ? > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > > > 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. > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org 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.
Re: maven / osgi / repositories
On Wed, Jan 28, 2009 at 2:13 PM, Jason van Zyl wrote: > > On 27-Jan-09, at 6:41 PM, Barrie Treloar wrote: > >>> repositories. They might become OBRs at some point when OSGi becomes >>> more "mainstream". >> >> One thing I have been toying with for a while is to auto-magically >> extend maven-jar-plugin to add the OSGi headers. >> > > I really don't think this is a great idea. I think for a bundle to be useful > someone needs to provide proper imports and exports. > >> I haven't given a lot of thought into what I need to do, but if I >> recall correctly, getting a simple OSGified jar isn't much work and if >> Maven did this out of the box then the maven repository would become >> OSGified over time as projects release their artifacts. >> > > We've toyed around with this idea, but if you want something useful I think > it's really hard to infer something useful. Making a manifest that is > workable with OSGi is not that hard and the author of a package is probably > the person to do it. I think what we can do is give a brief guideline as to > what's commonly expected and help people create correct and useful bundles. > Maven central is the biggest bundle repository in waiting :-) I agree it is sub-optimal. I think I would be suggesting a very broad approach. * OSGi bundle id matching group/artifactId combos. * exporting everything that is within the current artifact * wiring OSGi dependencies to match artifact dependencies probably without version ranges. Without thinking about it properly I think that would get people 80%-90% there with OSGi without having to re-wrap artifacts. I can't see how it will make things worse. This approach has some down sides * it exposes more than the author would expect * the dependencies may not yet be OSGified (but as they get released via maven that would get fixed) * OSGi headers may not be what the author would prefer (but they would be consistent with maven guidelines) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: maven / osgi / repositories
> I think what we can do is > give a brief guideline as to what's commonly expected and help people > create correct and useful bundles. Clearing up the version vs. classifier issue would be a good first step. From: Jason van Zyl [mailto:jvan...@sonatype.com] Sent: Tue 1/27/2009 10:43 PM To: Maven Users List Subject: Re: maven / osgi / repositories On 27-Jan-09, at 6:41 PM, Barrie Treloar wrote: >> repositories. They might become OBRs at some point when OSGi becomes >> more "mainstream". > > One thing I have been toying with for a while is to auto-magically > extend maven-jar-plugin to add the OSGi headers. > I really don't think this is a great idea. I think for a bundle to be useful someone needs to provide proper imports and exports. > I haven't given a lot of thought into what I need to do, but if I > recall correctly, getting a simple OSGified jar isn't much work and if > Maven did this out of the box then the maven repository would become > OSGified over time as projects release their artifacts. > We've toyed around with this idea, but if you want something useful I think it's really hard to infer something useful. Making a manifest that is workable with OSGi is not that hard and the author of a package is probably the person to do it. I think what we can do is give a brief guideline as to what's commonly expected and help people create correct and useful bundles. Maven central is the biggest bundle repository in waiting :-) > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven / osgi / repositories
>> One thing I have been toying with for a while is to auto-magically >> extend maven-jar-plugin to add the OSGi headers. > I really don't think this is a great idea. I think for a bundle to be useful > someone needs to provide proper imports and exports. Right, but it make took years ;( >> I haven't given a lot of thought into what I need to do, but if I >> recall correctly, getting a simple OSGified jar isn't much work and if >> Maven did this out of the box then the maven repository would become >> OSGified over time as projects release their artifacts. > We've toyed around with this idea, but if you want something useful I think > it's really hard to infer something useful. Making a manifest that is > workable with OSGi is not that hard and the author of a package is probably > the person to do it. I think what we can do is give a brief guideline as to > what's commonly expected and help people create correct and useful bundles. > Maven central is the biggest bundle repository in waiting :-) So you recommand education and lobbying. May be ASF should show the way, there is tons of projects today still not OSGIfied in ASF repo. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven / osgi / repositories
On 27-Jan-09, at 6:41 PM, Barrie Treloar wrote: repositories. They might become OBRs at some point when OSGi becomes more "mainstream". One thing I have been toying with for a while is to auto-magically extend maven-jar-plugin to add the OSGi headers. I really don't think this is a great idea. I think for a bundle to be useful someone needs to provide proper imports and exports. I haven't given a lot of thought into what I need to do, but if I recall correctly, getting a simple OSGified jar isn't much work and if Maven did this out of the box then the maven repository would become OSGified over time as projects release their artifacts. We've toyed around with this idea, but if you want something useful I think it's really hard to infer something useful. Making a manifest that is workable with OSGi is not that hard and the author of a package is probably the person to do it. I think what we can do is give a brief guideline as to what's commonly expected and help people create correct and useful bundles. Maven central is the biggest bundle repository in waiting :-) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: RE : RE : maven / osgi / repositories
Good idea. Did you have sample pom.xml for study ? Thanks Christophe 2009/1/29 Deneux, Christophe : > In your OSGI bundle project, you will use the maven-assembly-plugin to > generate your OSGI bundle artifact (artifactId-version-classifier.jar) with: > - configuration of the Manifest to specify specific OSGI information: > >maven-assembly-plugin > > [...] > > > [...] > > > >[...] > >- a classifier set in the assembly id of the assembly descriptor. > > > To reference a dependence on a OSGI bundle, you should use the dependencies > mechanism: > > [...] > >org.apache.ant >ant >1.7.1 >osgi > > [...] > > > So you have in your repository: an artifact usable as simple library (the > default artifact) and another one usable as a OSGI bundle. > I never try a such configuration, but I imagine that it should work fine. > > > ___ > Christophe DENEUX / Capgemini Sud / Méditerranée > Integration Architect / OW2 PEtALS Comitter > www.capgemini.com <http://www.capgemini.com/> > Porte de l'Arénas - Entrée B / 455 Promenade des Anglais / 06200 Nice / FRANCE > Join the Collaborative Business Experience > ___ > Please consider the environment and do not print this email unless absolutely > necessary. Capgemini encourages environmental awareness. > > ____________ > > De: Henri Gomez [mailto:henri.go...@gmail.com] > Date: mer. 28/01/2009 18:04 > À: Maven Users List > Objet : Re: RE : maven / osgi / repositories > > > > 2009/1/28 Deneux, Christophe : >> Isn't the role of the "classifier" field ? >> >> instead of : >> >> org.apache.ant >> ant >> 1.7.1 >> >> we could use : >> >> org.apache.ant >> ant >> 1.7.1 >> osgi > > Good but how do you specify such classifier in dependants projects ? > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > > > 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. > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE : RE : maven / osgi / repositories
In your OSGI bundle project, you will use the maven-assembly-plugin to generate your OSGI bundle artifact (artifactId-version-classifier.jar) with: - configuration of the Manifest to specify specific OSGI information: maven-assembly-plugin [...] [...] [...] - a classifier set in the assembly id of the assembly descriptor. To reference a dependence on a OSGI bundle, you should use the dependencies mechanism: [...] org.apache.ant ant 1.7.1 osgi [...] So you have in your repository: an artifact usable as simple library (the default artifact) and another one usable as a OSGI bundle. I never try a such configuration, but I imagine that it should work fine. ___ Christophe DENEUX / Capgemini Sud / Méditerranée Integration Architect / OW2 PEtALS Comitter www.capgemini.com <http://www.capgemini.com/> Porte de l'Arénas - Entrée B / 455 Promenade des Anglais / 06200 Nice / FRANCE Join the Collaborative Business Experience ___ Please consider the environment and do not print this email unless absolutely necessary. Capgemini encourages environmental awareness. De: Henri Gomez [mailto:henri.go...@gmail.com] Date: mer. 28/01/2009 18:04 À: Maven Users List Objet : Re: RE : maven / osgi / repositories 2009/1/28 Deneux, Christophe : > Isn't the role of the "classifier" field ? > > instead of : > > org.apache.ant > ant > 1.7.1 > > we could use : > > org.apache.ant > ant > 1.7.1 > osgi Good but how do you specify such classifier in dependants projects ? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org 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.
Re: RE : maven / osgi / repositories
2009/1/28 Deneux, Christophe : > Isn't the role of the "classifier" field ? > > instead of : > > org.apache.ant > ant > 1.7.1 > > we could use : > > org.apache.ant > ant > 1.7.1 > osgi Good but how do you specify such classifier in dependants projects ? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE : maven / osgi / repositories
Isn't the role of the "classifier" field ? instead of : org.apache.ant ant 1.7.1 we could use : org.apache.ant ant 1.7.1 osgi De: Henri Gomez [mailto:henri.go...@gmail.com] 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 : org.apache.ant ant 1.7.1 we could use : org.apache.ant ant 1.7.1-osgi > 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 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.
Re: maven / osgi / repositories
> repositories. They might become OBRs at some point when OSGi becomes > more "mainstream". One thing I have been toying with for a while is to auto-magically extend maven-jar-plugin to add the OSGi headers. I haven't given a lot of thought into what I need to do, but if I recall correctly, getting a simple OSGified jar isn't much work and if Maven did this out of the box then the maven repository would become OSGified over time as projects release their artifacts. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
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 : org.apache.ant ant 1.7.1 we could use : org.apache.ant ant 1.7.1-osgi > 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
Re: maven / osgi / repositories
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 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 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. >>> >>> -
Re: maven / osgi / repositories
> 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 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: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven / osgi / repositories
>> 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. > > ..with renamed group/artifactIds, which _completely_ destroys the entire > transitive dependency resolution. That's one of my concern. Different group/artifactid make a split between developpement and runtime ;( - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven / osgi / repositories
On Tue, 27 Jan 2009 22:53:10 +1100, Samuel Le Berrigaud wrote: > 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. ..with renamed group/artifactIds, which _completely_ destroys the entire transitive dependency resolution. -h - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven / osgi / repositories
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. 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. 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. 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. Archiva or Nexus would most probably satisfy your needs for maven repositories. They might become OBRs at some point when OSGi becomes more "mainstream". Hope this helps, SaM On Tue, Jan 27, 2009 at 10:24 PM, Henri Gomez 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: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
