hmm... I wonder if a script can automate that. On Mon, Jan 18, 2010 at 9:48 AM, Mark Proctor <[email protected]> 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 <[email protected] > > 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-planner-core/pom.xml?r1=30817&r2=31054 >> >> >> 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 >> <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 >> [email protected] >> https://lists.jboss.org/mailman/listinfo/rules-dev >> > > > > -- > Michael D Neale > home: www.michaelneale.net > blog: michaelneale.blogspot.com > > > _______________________________________________ > rules-dev mailing > [email protected]https://lists.jboss.org/mailman/listinfo/rules-dev > > > > _______________________________________________ > rules-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev > > -- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com
_______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
