Re: [VOTE] Retire Maven OSGi
Hi, just for the record: There is a replacement for most of the classes in bnd: https://github.com/bndtools/bnd/blob/9a4d7bcc04c2377641911b517ca8b1915f763a9a/biz.aQute.bndlib/src/aQute/bnd/version/MavenVersion.java I just replaced the code using maven-osgi with bndlib in Apache Sling : https://issues.apache.org/jira/browse/SLING-8656. Konrad On 2019/08/23 17:43:53, Tibor Digana wrote: > Hi Dirk, > > This project is not worth a plugin, it is a pure converter of single class. > In this case it is legal to adopt this code according to the license. > Anyway the Maven is not the OSGi. The OSGi is not our key API we deliver to > our customers. > We have to save our energy on what makes Maven The Maven. > > Cheers > Tibor17 > > On Fri, Aug 23, 2019 at 5:21 PM Dirk Mahler > wrote: > > > Hi, > > > > I'm not using it but just for curiosity I checked on Maven Central if > > some artifacts have been pushed there recently that declare a dependency > > to this artifact (maven-osgi): > > > > "0.2.0" "org.glassfish.hk2:consolidatedbundle-maven-plugin:pom:2.6.0" > > "2019-07-31T22:22:29Z" > > "0.2.0" "org.glassfish.hk2:osgiversion-maven-plugin:pom:2.6.0" > > "2019-07-31T22:21:55Z" > > "0.2.0" "org.apache.sling:slingstart-maven-plugin:pom:1.8.4" > > "2019-06-13T11:29:18Z" > > "0.2.0" "org.apache.sling:slingfeature-maven-plugin:pom:1.0.4" > > "2019-06-13T09:52:03Z" > > ... > > > > Hope it helps for voting. > > > > Cheers > > > > Dirk > > > > -- Originalnachricht -- > > Von: "Robert Scholte" > > An: "Apache Maven Dev" > > Cc: "Apache Maven Users" > > Gesendet: 23.08.2019 15:17:23 > > Betreff: [VOTE] Retire Maven OSGi > > > > >Hi, > > > > > >The Apache Maven project consist of about 90 (sub)projects. Due to the > > small number of volunteers and the huge amount of code to maintain we're > > missing enough space to make real progress on all these projects, > > including our ambitious ideas for the next major version(s) of Maven > > itself. > > >To be able to gain more focus we need to criticize the current > > subprojects and decide if it is worth maintaining. > > > > > >https://maven.apache.org/shared/maven-osgi/ describes the main purpose > > in one line: Library for Maven-OSGi integration. > > >There have been only 2 releases: 0.1.0 in July 2007 and 0.2.0 in > > December 2007 and just one open issue by Stuart McCulloch regarding an > > unclosed jar. > > >It is unclear to me if this library is still used. The library is based > > on just 3 files: interface, default implementation and dedicated exception. > > >Either the library is complete or never used anymore. In both cases I > > see no real reason to maintain it. > > > > > >I therefore propose that we retire the maven-osgi library. > > > > > >I don't think it makes sense to do a final release. Instead we should > > update the documentation and freeze the codebase. > > > > > >The process for retiring a plugin is described here: > > >https://maven.apache.org/developers/retirement-plan-plugins.html [ > > https://maven.apache.org/developers/retirement-plan-plugins.html] > > > > > >The vote is open for 72 hours. > > >[ ] +1 Yes, it's about time > > >[ ] -1 No, because... > > > > > >- > > >To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > >For additional commands, e-mail: dev-h...@maven.apache.org > > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[RESULT] [VOTE] Retire Maven OSGi
Hi, The vote has passed with the following result: +1: Tamás Cservenák, Anders Hammar, Tibor Digana, Karl Heinz Marbaise, Michael Osipov, Arnaud Héritier, Enrico Olivelli, Stephane Nicoll, Francois Papon, Hervé BOUTEMY PMC quorum: reached Special thanks to Dirk Mahler for collecting a list of projects still using the library. I considered doing a final release anyway because of the provided information, but after having a view on the list of commits on the project and concluded it is still not worth it. I will continue with the steps required to retire this library. On Fri, 23 Aug 2019 15:17:23 +0200, Robert Scholte wrote: Hi, The Apache Maven project consist of about 90 (sub)projects. Due to the small number of volunteers and the huge amount of code to maintain we're missing enough space to make real progress on all these projects, including our ambitious ideas for the next major version(s) of Maven itself. To be able to gain more focus we need to criticize the current subprojects and decide if it is worth maintaining. https://maven.apache.org/shared/maven-osgi/ describes the main purpose in one line: Library for Maven-OSGi integration. There have been only 2 releases: 0.1.0 in July 2007 and 0.2.0 in December 2007 and just one open issue by Stuart McCulloch regarding an unclosed jar. It is unclear to me if this library is still used. The library is based on just 3 files: interface, default implementation and dedicated exception. Either the library is complete or never used anymore. In both cases I see no real reason to maintain it. I therefore propose that we retire the maven-osgi library. I don't think it makes sense to do a final release. Instead we should update the documentation and freeze the codebase. The process for retiring a plugin is described here: https://maven.apache.org/developers/retirement-plan-plugins.html [https://maven.apache.org/developers/retirement-plan-plugins.html] The vote is open for 72 hours. [ ] +1 Yes, it's about time [ ] -1 No, because... - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [VOTE] Retire Maven OSGi
Yes, the maven-bundle-plugin from Apache Felix do the job :) +1 (non-binding) Thanks! regards, François fpa...@apache.org Le 23/08/2019 à 15:17, Robert Scholte a écrit : > Hi, > > The Apache Maven project consist of about 90 (sub)projects. Due to the > small number of volunteers and the huge amount of code to maintain > we're missing enough space to make real progress on all these > projects, including our ambitious ideas for the next major version(s) > of Maven itself. > To be able to gain more focus we need to criticize the current > subprojects and decide if it is worth maintaining. > > https://maven.apache.org/shared/maven-osgi/ describes the main purpose > in one line: Library for Maven-OSGi integration. > There have been only 2 releases: 0.1.0 in July 2007 and 0.2.0 in > December 2007 and just one open issue by Stuart McCulloch regarding an > unclosed jar. > It is unclear to me if this library is still used. The library is > based on just 3 files: interface, default implementation and dedicated > exception. > Either the library is complete or never used anymore. In both cases I > see no real reason to maintain it. > > I therefore propose that we retire the maven-osgi library. > > I don't think it makes sense to do a final release. Instead we should > update the documentation and freeze the codebase. > > The process for retiring a plugin is described here: > https://maven.apache.org/developers/retirement-plan-plugins.html > [https://maven.apache.org/developers/retirement-plan-plugins.html] > > The vote is open for 72 hours. > [ ] +1 Yes, it's about time > [ ] -1 No, because... > > - > 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: [VOTE] Retire Maven OSGi
+1 Thank you Dirk for checking Enrico Il giorno ven 23 ago 2019 alle ore 20:48 Arnaud Héritier < aherit...@gmail.com> ha scritto: > +1 > > Le ven. 23 août 2019 à 15:17, Robert Scholte a > écrit : > > > Hi, > > > > The Apache Maven project consist of about 90 (sub)projects. Due to the > > small number of volunteers and the huge amount of code to maintain we're > > missing enough space to make real progress on all these projects, > > including our ambitious ideas for the next major version(s) of Maven > > itself. > > To be able to gain more focus we need to criticize the current > > subprojects > > and decide if it is worth maintaining. > > > > https://maven.apache.org/shared/maven-osgi/ describes the main purpose > > in > > one line: Library for Maven-OSGi integration. > > There have been only 2 releases: 0.1.0 in July 2007 and 0.2.0 in December > > 2007 and just one open issue by Stuart McCulloch regarding an unclosed > jar. > > It is unclear to me if this library is still used. The library is based > > on > > just 3 files: interface, default implementation and dedicated exception. > > Either the library is complete or never used anymore. In both cases I see > > no real reason to maintain it. > > > > I therefore propose that we retire the maven-osgi library. > > > > I don't think it makes sense to do a final release. Instead we should > > update the documentation and freeze the codebase. > > > > The process for retiring a plugin is described here: > > https://maven.apache.org/developers/retirement-plan-plugins.html > > [https://maven.apache.org/developers/retirement-plan-plugins.html] > > > > The vote is open for 72 hours. > > [ ] +1 Yes, it's about time > > [ ] -1 No, because... > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > -- > - > Arnaud Héritier > http://aheritier.net > Mail/GTalk: aheritier AT gmail DOT com > Twitter/Skype : aheritier >
Re: [VOTE] Retire Maven OSGi
+1 Le ven. 23 août 2019 à 15:17, Robert Scholte a écrit : > Hi, > > The Apache Maven project consist of about 90 (sub)projects. Due to the > small number of volunteers and the huge amount of code to maintain we're > missing enough space to make real progress on all these projects, > including our ambitious ideas for the next major version(s) of Maven > itself. > To be able to gain more focus we need to criticize the current > subprojects > and decide if it is worth maintaining. > > https://maven.apache.org/shared/maven-osgi/ describes the main purpose > in > one line: Library for Maven-OSGi integration. > There have been only 2 releases: 0.1.0 in July 2007 and 0.2.0 in December > 2007 and just one open issue by Stuart McCulloch regarding an unclosed jar. > It is unclear to me if this library is still used. The library is based > on > just 3 files: interface, default implementation and dedicated exception. > Either the library is complete or never used anymore. In both cases I see > no real reason to maintain it. > > I therefore propose that we retire the maven-osgi library. > > I don't think it makes sense to do a final release. Instead we should > update the documentation and freeze the codebase. > > The process for retiring a plugin is described here: > https://maven.apache.org/developers/retirement-plan-plugins.html > [https://maven.apache.org/developers/retirement-plan-plugins.html] > > The vote is open for 72 hours. > [ ] +1 Yes, it's about time > [ ] -1 No, because... > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
Re: [VOTE] Retire Maven OSGi
Hi Dirk, This project is not worth a plugin, it is a pure converter of single class. In this case it is legal to adopt this code according to the license. Anyway the Maven is not the OSGi. The OSGi is not our key API we deliver to our customers. We have to save our energy on what makes Maven The Maven. Cheers Tibor17 On Fri, Aug 23, 2019 at 5:21 PM Dirk Mahler wrote: > Hi, > > I'm not using it but just for curiosity I checked on Maven Central if > some artifacts have been pushed there recently that declare a dependency > to this artifact (maven-osgi): > > "0.2.0" "org.glassfish.hk2:consolidatedbundle-maven-plugin:pom:2.6.0" > "2019-07-31T22:22:29Z" > "0.2.0" "org.glassfish.hk2:osgiversion-maven-plugin:pom:2.6.0" > "2019-07-31T22:21:55Z" > "0.2.0" "org.apache.sling:slingstart-maven-plugin:pom:1.8.4" > "2019-06-13T11:29:18Z" > "0.2.0" "org.apache.sling:slingfeature-maven-plugin:pom:1.0.4" > "2019-06-13T09:52:03Z" > ... > > Hope it helps for voting. > > Cheers > > Dirk > > -- Originalnachricht -- > Von: "Robert Scholte" > An: "Apache Maven Dev" > Cc: "Apache Maven Users" > Gesendet: 23.08.2019 15:17:23 > Betreff: [VOTE] Retire Maven OSGi > > >Hi, > > > >The Apache Maven project consist of about 90 (sub)projects. Due to the > small number of volunteers and the huge amount of code to maintain we're > missing enough space to make real progress on all these projects, > including our ambitious ideas for the next major version(s) of Maven > itself. > >To be able to gain more focus we need to criticize the current > subprojects and decide if it is worth maintaining. > > > >https://maven.apache.org/shared/maven-osgi/ describes the main purpose > in one line: Library for Maven-OSGi integration. > >There have been only 2 releases: 0.1.0 in July 2007 and 0.2.0 in > December 2007 and just one open issue by Stuart McCulloch regarding an > unclosed jar. > >It is unclear to me if this library is still used. The library is based > on just 3 files: interface, default implementation and dedicated exception. > >Either the library is complete or never used anymore. In both cases I > see no real reason to maintain it. > > > >I therefore propose that we retire the maven-osgi library. > > > >I don't think it makes sense to do a final release. Instead we should > update the documentation and freeze the codebase. > > > >The process for retiring a plugin is described here: > >https://maven.apache.org/developers/retirement-plan-plugins.html [ > https://maven.apache.org/developers/retirement-plan-plugins.html] > > > >The vote is open for 72 hours. > >[ ] +1 Yes, it's about time > >[ ] -1 No, because... > > > >- > >To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Retire Maven OSGi
Hi, +1 from me. Kind regards Karl Heinz Marbaise On 23.08.19 15:17, Robert Scholte wrote: Hi, The Apache Maven project consist of about 90 (sub)projects. Due to the small number of volunteers and the huge amount of code to maintain we're missing enough space to make real progress on all these projects, including our ambitious ideas for the next major version(s) of Maven itself. To be able to gain more focus we need to criticize the current subprojects and decide if it is worth maintaining. https://maven.apache.org/shared/maven-osgi/ describes the main purpose in one line: Library for Maven-OSGi integration. There have been only 2 releases: 0.1.0 in July 2007 and 0.2.0 in December 2007 and just one open issue by Stuart McCulloch regarding an unclosed jar. It is unclear to me if this library is still used. The library is based on just 3 files: interface, default implementation and dedicated exception. Either the library is complete or never used anymore. In both cases I see no real reason to maintain it. I therefore propose that we retire the maven-osgi library. I don't think it makes sense to do a final release. Instead we should update the documentation and freeze the codebase. The process for retiring a plugin is described here: https://maven.apache.org/developers/retirement-plan-plugins.html [https://maven.apache.org/developers/retirement-plan-plugins.html] The vote is open for 72 hours. [ ] +1 Yes, it's about time [ ] -1 No, because... - 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: [VOTE] Retire Maven OSGi
There's very good BND plugin org.apache.felix:maven-bundle-plugin. +1 to retire and delete old https://maven.apache.org/shared/maven-osgi/ Cheers Tibor17 On Fri, Aug 23, 2019 at 3:17 PM Robert Scholte wrote: > Hi, > > The Apache Maven project consist of about 90 (sub)projects. Due to the > small number of volunteers and the huge amount of code to maintain we're > missing enough space to make real progress on all these projects, > including our ambitious ideas for the next major version(s) of Maven > itself. > To be able to gain more focus we need to criticize the current > subprojects > and decide if it is worth maintaining. > > https://maven.apache.org/shared/maven-osgi/ describes the main purpose > in > one line: Library for Maven-OSGi integration. > There have been only 2 releases: 0.1.0 in July 2007 and 0.2.0 in December > 2007 and just one open issue by Stuart McCulloch regarding an unclosed jar. > It is unclear to me if this library is still used. The library is based > on > just 3 files: interface, default implementation and dedicated exception. > Either the library is complete or never used anymore. In both cases I see > no real reason to maintain it. > > I therefore propose that we retire the maven-osgi library. > > I don't think it makes sense to do a final release. Instead we should > update the documentation and freeze the codebase. > > The process for retiring a plugin is described here: > https://maven.apache.org/developers/retirement-plan-plugins.html > [https://maven.apache.org/developers/retirement-plan-plugins.html] > > The vote is open for 72 hours. > [ ] +1 Yes, it's about time > [ ] -1 No, because... > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Retire Maven OSGi
+1 On Fri, Aug 23, 2019 at 3:17 PM Robert Scholte wrote: > Hi, > > The Apache Maven project consist of about 90 (sub)projects. Due to the > small number of volunteers and the huge amount of code to maintain we're > missing enough space to make real progress on all these projects, > including our ambitious ideas for the next major version(s) of Maven > itself. > To be able to gain more focus we need to criticize the current > subprojects > and decide if it is worth maintaining. > > https://maven.apache.org/shared/maven-osgi/ describes the main purpose > in > one line: Library for Maven-OSGi integration. > There have been only 2 releases: 0.1.0 in July 2007 and 0.2.0 in December > 2007 and just one open issue by Stuart McCulloch regarding an unclosed jar. > It is unclear to me if this library is still used. The library is based > on > just 3 files: interface, default implementation and dedicated exception. > Either the library is complete or never used anymore. In both cases I see > no real reason to maintain it. > > I therefore propose that we retire the maven-osgi library. > > I don't think it makes sense to do a final release. Instead we should > update the documentation and freeze the codebase. > > The process for retiring a plugin is described here: > https://maven.apache.org/developers/retirement-plan-plugins.html > [https://maven.apache.org/developers/retirement-plan-plugins.html] > > The vote is open for 72 hours. > [ ] +1 Yes, it's about time > [ ] -1 No, because... > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
[VOTE] Retire Maven OSGi
Hi, The Apache Maven project consist of about 90 (sub)projects. Due to the small number of volunteers and the huge amount of code to maintain we're missing enough space to make real progress on all these projects, including our ambitious ideas for the next major version(s) of Maven itself. To be able to gain more focus we need to criticize the current subprojects and decide if it is worth maintaining. https://maven.apache.org/shared/maven-osgi/ describes the main purpose in one line: Library for Maven-OSGi integration. There have been only 2 releases: 0.1.0 in July 2007 and 0.2.0 in December 2007 and just one open issue by Stuart McCulloch regarding an unclosed jar. It is unclear to me if this library is still used. The library is based on just 3 files: interface, default implementation and dedicated exception. Either the library is complete or never used anymore. In both cases I see no real reason to maintain it. I therefore propose that we retire the maven-osgi library. I don't think it makes sense to do a final release. Instead we should update the documentation and freeze the codebase. The process for retiring a plugin is described here: https://maven.apache.org/developers/retirement-plan-plugins.html [https://maven.apache.org/developers/retirement-plan-plugins.html] The vote is open for 72 hours. [ ] +1 Yes, it's about time [ ] -1 No, because... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven-OSGI and Spring
Is it possible to create a maven-osgi project which uses spring libraries? I have a web dynamic project which has rest services with spring framework and the persistence is done by a JPA project. When these are normal projects, these work fine.. But when I create Maven-OSGI project with JPA and web project and add spring libraries into it this doesn't work
Recall: Maven-OSGI and Spring
CHOUBEY, PRIYAL would like to recall the message, Maven-OSGI and Spring. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven-OSGI and Spring
What do you mean this doesn't work? A little detail might get you some help. Ron On 22/05/2012 7:24 AM, CHOUBEY, PRIYAL wrote: Is it possible to create a maven-osgi project which uses spring libraries? I have a web dynamic project which has rest services with spring framework and the persistence is done by a JPA project. When these are normal projects, these work fine.. But when I create Maven-OSGI project with JPA and web project and add spring libraries into it this doesn't work -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
resolve dependencies for maven osgi project
I have a working project. it has some dependencies,. i am using pax plugin in to run it. i am using eclipse, and right clicking the project i am choosing maven intall, and then i am using the wrap plugin to make the dependencies as bundles as well.Then i am starting the pax plugin from a command line interface to eliminate eclipse, and installing the project, i have to manually install the dependencies one by one for it to work, but then it works fine. Has anyone used this before? and instruct me on what i am doing wrong? i am sure that there is a different way and not to install the dependencies manually. please help. -- View this message in context: http://maven.40175.n5.nabble.com/resolve-dependencies-for-maven-osgi-project-tp5459677p5459677.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
Re: Maven + OSGI
2009/6/15 Peter Horlock peter.horl...@googlemail.com Hello Stuart, thanks for your reply. Could you please send me your assembly plugin settings? Hi Peter, Unfortunately I don't have an assembly configuration I can share at the moment - I use Pax-Runner to deploy my apps. If you're still stuck perhaps you could send a note to gene...@ops4j.org as there are a lot of OSGi users on that list. -- Cheers, Stuart Thanks in advance, Peter
Re: Maven + OSGI
Thanks Stuart, I'll try to get help on that list. Peter
Re: Maven + OSGI
Could anyone please share his/her assembly plugin settings and assembly file for OSGI? Thanks in advance, Peter
Re: Maven + OSGI
No one here using OSGI + Maven? What about the plugin I found: http://mvn-dp-plugin.sourceforge.net/site/plugin-info.html Could that do the trick? Thanks, Peter
Re: Maven + OSGI
2009/6/15 Peter Horlock peter.horl...@googlemail.com No one here using OSGI + Maven? I'm sure there are several people here using OSGi + Maven (me for one) however, this doesn't sound like a general OSGi issue as such, because OSGi doesn't actually mandate a specific layout of bundles - instead your layout is specific to Equinox, the OSGi framework used by Eclipse (and therefore BIRT which is an Eclipse project) you could perhaps look into using the headless Eclipse/PDE build, but this can be painful to use - IMHO the best (and simplest) option is just use the assembly plugin to arrange everything What about the plugin I found: http://mvn-dp-plugin.sourceforge.net/site/plugin-info.html Could that do the trick? well that plugin generates standard OSGi deployment packages: http://www.osgi.org/javadoc/r4v41/org/osgi/service/deploymentadmin/DeploymentPackage.html which are a way to atomically install and update a collection of bundles, managed by the deployment admin bundle (so you need this installed) - while you can use this to deploy apps onto a framework it won't help you do the initial bootstrapping, so you'd still need to mimic some of the Equinox layout another option might be to use pax-runner to generate the Equinox layout: http://issues.ops4j.org/browse/PAXRUNNER-177 http://paxrunner.ops4j.org/space/Pax+Runner but I still think using the assembly plugin would be simplest approach initially Thanks, Peter -- Cheers, Stuart
Re: Maven + OSGI
Hello Stuart, thanks for your reply. Could you please send me your assembly plugin settings? Thanks in advance, Peter
Maven + OSGI
Hi, I have a question regarding Maven dependency management and the OSGi-based BIRT Report Engine (RE). The RE, in order to be available at runtime in the tomcat environment, must conform to a specific directory structure: 'top-level' JARs in WEB-INF/lib, config.ini in WEB-INF/platform/configuration and dozens of further JARs with horribly detailed filenames in WEB-INF/platform/plugins and sub-directories. How do I combine MVN storage of the RE JARs (and other files - config.ini, MANIFEST.MF, ...) with the strict directory structure requirements at deployment time? Ideally, I'd also like to automatically upload the RE to the Maven repo initially. I've found a hopeful plugin under http://mvn-dp-plugin.sourceforge.net/site/plugin-info.html, but the documentation is scanty and I do not know if it will do what I need... Thanks in advance, Peter
Re: Maven + OSGI
How do I combine MVN storage of the RE JARs (and other files - config.ini, MANIFEST.MF, ...) with the strict directory structure requirements at deployment time? Ideally, I'd also like to automatically upload the RE to the Maven repo initially. The assembly plugin would work with the proper configuration, I'd assume. But it does sound painful. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
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
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 christophe.den...@capgemini.com: 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: plugin artifactIdmaven-assembly-plugin/artifactId configuration [...] archive manifest [...] /manifest /archive /configuration [...] /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: dependencies [...] dependency groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.7.1/version classifierosgi/classifier /dependency [...] /dependencies 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 christophe.den...@capgemini.com: Isn't the role of the classifier field ? instead of : groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.7.1/version we could use : groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.7.1/version classifierosgi/classifier 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.
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 iddist-binary/id 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 christophe.den...@capgemini.com schrieb am Fr, 30.1.2009: Von: Deneux, Christophe christophe.den...@capgemini.com Betreff: RE : RE : RE : maven / osgi / repositories An: Maven Users List users@maven.apache.org, Maven Users List users@maven.apache.org 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 christophe.den...@capgemini.com: 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: plugin artifactIdmaven-assembly-plugin/artifactId configuration [...] archive manifest [...] /manifest /archive /configuration [...] /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: dependencies [...] dependency groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.7.1/version classifierosgi/classifier /dependency [...] /dependencies 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 christophe.den...@capgemini.com: Isn't the role of the classifier field ? instead of : groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.7.1/version we could use : groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.7.1/version classifierosgi/classifier 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
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: plugin artifactIdmaven-assembly-plugin/artifactId configuration [...] archive manifest [...] /manifest /archive /configuration [...] /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: dependencies [...] dependency groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.7.1/version classifierosgi/classifier /dependency [...] /dependencies 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 christophe.den...@capgemini.com: Isn't the role of the classifier field ? instead of : groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.7.1/version we could use : groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.7.1/version classifierosgi/classifier 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 : RE : maven / osgi / repositories
Good idea. Did you have sample pom.xml for study ? Thanks Christophe 2009/1/29 Deneux, Christophe christophe.den...@capgemini.com: 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: plugin artifactIdmaven-assembly-plugin/artifactId configuration [...] archive manifest [...] /manifest /archive /configuration [...] /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: dependencies [...] dependency groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.7.1/version classifierosgi/classifier /dependency [...] /dependencies 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 christophe.den...@capgemini.com: Isn't the role of the classifier field ? instead of : groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.7.1/version we could use : groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.7.1/version classifierosgi/classifier 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: 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
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
On Wed, Jan 28, 2009 at 2:13 PM, Jason van Zyl jvan...@sonatype.com 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
Isn't the role of the classifier field ? instead of : groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.7.1/version we could use : groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.7.1/version classifierosgi/classifier 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 : groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.7.1/version we could use : groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.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 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 christophe.den...@capgemini.com: Isn't the role of the classifier field ? instead of : groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.7.1/version we could use : groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.7.1/version classifierosgi/classifier 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
maven / osgi / repositories
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
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 henri.go...@gmail.com 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
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
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
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 henri.go...@gmail.com 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
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 henri.go...@gmail.com 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 henri.go...@gmail.com 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:
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 : groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.7.1/version we could use : groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.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
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: [m2] maven-osgi-plugin
There has been talk, buit AFAIK nobody has writen one for any version of Maven. If you know of one, please let us know the URL. - Brett On 7/20/05, Bennett, Timothy (JIS/Applications) [EMAIL PROTECTED] wrote: Is the maven-osgi-plugin available for maven2 yet? - 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]
RE: [m2] maven-osgi-plugin
-Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 19, 2005 3:32 PM To: Maven Users List Subject: Re: [m2] maven-osgi-plugin There has been talk, buit AFAIK nobody has writen one for any version of Maven. If you know of one, please let us know the URL. http://mavenosgiplugin.berlios.de/ Just found it... Don't know anything about it... (yet) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] maven-osgi-plugin
added: http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Matrix On 7/20/05, Bennett, Timothy (JIS/Applications) [EMAIL PROTECTED] wrote: -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 19, 2005 3:32 PM To: Maven Users List Subject: Re: [m2] maven-osgi-plugin There has been talk, buit AFAIK nobody has writen one for any version of Maven. If you know of one, please let us know the URL. http://mavenosgiplugin.berlios.de/ Just found it... Don't know anything about it... (yet) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
