I don't understand why the groupIds had to change - I assume it is to pick up the osgi-ified versions - but why do the names have to change so dramatically? (and I don't think it should break things - that seems a mistake).

On Mon, Jan 18, 2010 at 6:02 AM, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com <mailto:ge0ffrey.spam@gmail.com>> wrote: Hi guys, The OSGi ready commit on trunk of a couple of days ago, changed many pom.xml files, including the Drools core and Drools Planner pom.xml's. For example, something like this: <dependency> <groupId>commons-lang</groupId> <artifactId>commons-lang</artifactId> </dependency> Became: <dependency> <groupId>org.apache.commons</groupId> <artifactId>com.springsource.org.apache.commons.lang</artifactId> </dependency> See for example this pom.xml file: http://fisheye.jboss.org/browse/JBossRules/trunk/drools-planner/drools-pl... <http://fisheye.jboss.org/browse/JBossRules/trunk/drools-planner/drools-pl... This gives rise to 2 problems: 1) It uses different groupId:artifactId's! The ramifications of this are big & very backward incompatible: Lets say project X depends on drools: - X excludes commons-lang:commons-lang from the drools dependency, now he'll get it anyway, because org.apache.commons:com.springsource.org.apache.commons.lang is something else - X depends on commons-lang:commons-lang, now he'll get it twice - X depends on commons-lang:commons-lang in a different version, now he'll get it twice and maven will not get a change to do version conflict resolution (picking the highest), now he'll get it twice and drools might end up being run with a too low commons-lang version! Remember: most users don't use OSGi and don't like a "com.springsource" in their artifactId's. 2) Build problems too apparently: <nheron> Project ID: org.drools.planner:drools-planner-core <nheron> POM Location: /home/nheron/workspace-IntellJ-planner/drools-planner-core/pom.xml <nheron> Validation Messages: <nheron> [0] 'dependencies.dependency.version' is missing for org.apache.commons:com.springsource.org.apache.commons.lang <nheron> [1] 'dependencies.dependency.version' is missing for org.apache.commons:com.springsource.org.apache.commons.io <http://com.springsource.org.apache.commons.io> <nheron> [2] 'dependencies.dependency.version' is missing for com.thoughtworks.xstream:com.springsource.com.thoughtworks.xstream Because it is backward incompatible, I propose to shelve the OSGi ready changes till drools 6.0? -- With kind regards, Geoffrey De Smet _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/rules-dev -- Michael D Neale home: www.michaelneale.net <http://www.michaelneale.net> blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com> _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

hmm... I wonder if a script can automate that.

On Mon, Jan 18, 2010 at 9:48 AM, Mark Proctor <mproctor(a)codehaus.org <mailto:mproctor@codehaus.org>> wrote: On 17/01/2010 21:57, Michael Neale wrote: > I don't understand why the groupIds had to change - I assume it > is to pick up the osgi-ified versions - but why do the names have > to change so dramatically? (and I don't think it should break > things - that seems a mistake). I can revert trunk back to the origianl deps, and maintain a module by hand that has all the osgi versions. We just need to remember to keep them in sync. Mark > > On Mon, Jan 18, 2010 at 6:02 AM, Geoffrey De Smet > <ge0ffrey.spam(a)gmail.com <mailto:ge0ffrey.spam@gmail.com>> wrote: > > Hi guys, > > The OSGi ready commit on trunk of a couple of days ago, > changed many > pom.xml files, including the Drools core and Drools Planner > pom.xml's. > > For example, something like this: > > <dependency> > <groupId>commons-lang</groupId> > <artifactId>commons-lang</artifactId> > </dependency> > > Became: > > <dependency> > <groupId>org.apache.commons</groupId> > <artifactId>com.springsource.org.apache.commons.lang</artifactId> > </dependency> > > > See for example this pom.xml file: > http://fisheye.jboss.org/browse/JBossRules/trunk/drools-planner/drools-pl... > <http://fisheye.jboss.org/browse/JBossRules/trunk/drools-planner/drools-pl... > > > This gives rise to 2 problems: > > 1) It uses different groupId:artifactId's! > The ramifications of this are big & very backward incompatible: > Lets say project X depends on drools: > - X excludes commons-lang:commons-lang from the drools > dependency, now > he'll get it anyway, because > org.apache.commons:com.springsource.org.apache.commons.lang > is something > else > - X depends on commons-lang:commons-lang, now he'll get it twice > - X depends on commons-lang:commons-lang in a different > version, now > he'll get it twice and maven will not get a change to do version > conflict resolution (picking the highest), now he'll get it twice > and drools might end up being run with a too low commons-lang > version! > > Remember: most users don't use OSGi and don't like a > "com.springsource" > in their artifactId's. > > 2) Build problems too apparently: > > <nheron> Project ID: org.drools.planner:drools-planner-core > <nheron> POM Location: > /home/nheron/workspace-IntellJ-planner/drools-planner-core/pom.xml > <nheron> Validation Messages: > <nheron> [0] 'dependencies.dependency.version' is > missing for > org.apache.commons:com.springsource.org.apache.commons.lang > <nheron> [1] 'dependencies.dependency.version' is > missing for > org.apache.commons:com.springsource.org.apache.commons.io > <http://com.springsource.org.apache.commons.io> > <nheron> [2] 'dependencies.dependency.version' is > missing for > com.thoughtworks.xstream:com.springsource.com.thoughtworks.xstream > > > > Because it is backward incompatible, I propose to shelve the > OSGi ready > changes till drools 6.0? > > -- > With kind regards, > Geoffrey De Smet > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-dev > > > > > -- > Michael D Neale > home: www.michaelneale.net <http://www.michaelneale.net> > blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com> > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/rules-dev -- Michael D Neale home: www.michaelneale.net <http://www.michaelneale.net> blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com> _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Hi guys, From the Maven book: "when groupId or artifactId are different, Maven will consider this to be two different libraries" "The groupId or artifactId of the artifact has changed, where the current project requires an alternately named version from a dependency's version - resulting in 2 copies of the same project in the classpath. Normally Maven would capture this conflict and use a single version of the project, but when groupId or artifactId are different, Maven will consider this to be two different libraries." from http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sec... I've seen the classifierId for osgi dependencies of mule etc. The maven guys are definitely taking the OSGi story serious: http://www.sonatype.com/people/2009/03/the-future-of-maven-osgi-join-the-... and surely there must be a better way then duplicating everything under a different groupId-artifactId like SpringSource's workaround for now? With kind regards, Geoffrey De Smet Mark Proctor schreef: > On 17/01/2010 22:53, Michael Neale wrote: >> hmm... I wonder if a script can automate that. > it can yes. Actually you could make a script to automate the re-packing > of all our depencies, without having to point to springsource ones. The > main thing to remember is the main jar you are wrapping must be > unzipped, but just look at the jxls, smooks and mvel examples I did to > see what i mean. PaxConstruct attempts to help with this automation: > http://wiki.ops4j.org/display/paxconstruct/Pax+Construct > > Geoffrey feels we should differentiate the repackaged bundles by a > classifier and not by an artifactid prefix. > > Mark >> >> On Mon, Jan 18, 2010 at 9:48 AM, Mark Proctor <mproctor(a)codehaus.org >> <mailto:mproctor@codehaus.org>> wrote: >> >> On 17/01/2010 21:57, Michael Neale wrote: >>> I don't understand why the groupIds had to change - I assume it >>> is to pick up the osgi-ified versions - but why do the names have >>> to change so dramatically? (and I don't think it should break >>> things - that seems a mistake). >> I can revert trunk back to the origianl deps, and maintain a >> module by hand that has all the osgi versions. We just need to >> remember to keep them in sync. >> >> Mark >> >>> >>> On Mon, Jan 18, 2010 at 6:02 AM, Geoffrey De Smet >>> <ge0ffrey.spam(a)gmail.com <mailto:ge0ffrey.spam@gmail.com>> wrote: >>> >>> Hi guys, >>> >>> The OSGi ready commit on trunk of a couple of days ago, >>> changed many >>> pom.xml files, including the Drools core and Drools Planner >>> pom.xml's. >>> >>> For example, something like this: >>> >>> <dependency> >>> <groupId>commons-lang</groupId> >>> <artifactId>commons-lang</artifactId> >>> </dependency> >>> >>> Became: >>> >>> <dependency> >>> <groupId>org.apache.commons</groupId> >>> >>> <artifactId>com.springsource.org.apache.commons.lang</artifactId> >>> </dependency> >>> >>> >>> See for example this pom.xml file: >>> http://fisheye.jboss.org/browse/JBossRules/trunk/drools-planner/drools-pl... >>> < http://fisheye.jboss.org/browse/JBossRules/trunk/drools-planner/drools-pl... > >>> >>> >>> This gives rise to 2 problems: >>> >>> 1) It uses different groupId:artifactId's! >>> The ramifications of this are big & very backward incompatible: >>> Lets say project X depends on drools: >>> - X excludes commons-lang:commons-lang from the drools >>> dependency, now >>> he'll get it anyway, because >>> org.apache.commons:com.springsource.org.apache.commons.lang >>> is something >>> else >>> - X depends on commons-lang:commons-lang, now he'll get it twice >>> - X depends on commons-lang:commons-lang in a different >>> version, now >>> he'll get it twice and maven will not get a change to do version >>> conflict resolution (picking the highest), now he'll get it twice >>> and drools might end up being run with a too low commons-lang >>> version! >>> >>> Remember: most users don't use OSGi and don't like a >>> "com.springsource" >>> in their artifactId's. >>> >>> 2) Build problems too apparently: >>> >>> <nheron> Project ID: org.drools.planner:drools-planner-core >>> <nheron> POM Location: >>> /home/nheron/workspace-IntellJ-planner/drools-planner-core/pom.xml >>> <nheron> Validation Messages: >>> <nheron> [0] 'dependencies.dependency.version' is >>> missing for >>> org.apache.commons:com.springsource.org.apache.commons.lang >>> <nheron> [1] 'dependencies.dependency.version' is >>> missing for >>> org.apache.commons:com.springsource.org.apache.commons.io >>> <http://com.springsource.org.apache.commons.io> >>> <nheron> [2] 'dependencies.dependency.version' is >>> missing for >>> com.thoughtworks.xstream:com.springsource.com.thoughtworks.xstream >>> >>> >>> >>> Because it is backward incompatible, I propose to shelve the >>> OSGi ready >>> changes till drools 6.0? >>> >>> -- >>> With kind regards, >>> Geoffrey De Smet >>> >>> _______________________________________________ >>> rules-dev mailing list >>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >>> >>> >>> >>> -- >>> Michael D Neale >>> home: www.michaelneale.net <http://www.michaelneale.net> >>> blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com> >>> >>> >>> _______________________________________________ >>> rules-dev mailing list >>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> >> >> >> -- >> Michael D Neale >> home: www.michaelneale.net <http://www.michaelneale.net> >> blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com> >> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev