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