[rules-dev] OSGi ready commit gives problems
Michael Neale
michael.neale at gmail.com
Tue Jan 19 21:03:42 EST 2010
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
<ge0ffrey.spam at gmail.com>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 <mproctor at codehaus.org
> >> <mailto:mproctor at 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 at gmail.com <mailto:ge0ffrey.spam at 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-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
> >>> rules-dev at lists.jboss.org <mailto:rules-dev at 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 at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> >>> https://lists.jboss.org/mailman/listinfo/rules-dev
> >>>
> >>
> >>
> >> _______________________________________________
> >> rules-dev mailing list
> >> rules-dev at lists.jboss.org <mailto:rules-dev at 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-dev
> >>
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20100120/969fb1b5/attachment-0001.html
More information about the rules-dev
mailing list