Yes I view the spring style different artifactIds as a temporary thing as things make the transition to OSGi - that would be fair to say?
On Wed, Jan 20, 2010 at 8:09 AM, Geoffrey De Smet <[email protected]>wrote: > 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-sect-conflict.html > > 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-tycho-users-mailing-list/ > 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 <[email protected] > >> <mailto:[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] <mailto:[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 > >>> < > 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 > >>> <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 > >>> [email protected] <mailto:[email protected]> > >>> 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 > >>> [email protected] <mailto:[email protected]> > >>> https://lists.jboss.org/mailman/listinfo/rules-dev > >>> > >> > >> > >> _______________________________________________ > >> rules-dev mailing list > >> [email protected] <mailto:[email protected]> > >> 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 > >> [email protected] > >> https://lists.jboss.org/mailman/listinfo/rules-dev > >> > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > rules-dev mailing list > > [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
