<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">Op 19-11-12 14:37, Ansgar Konermann
schreef:<br>
</div>
<blockquote cite="mid:50AA362C.6030709@googlemail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Hi Geoffrey,<br>
<br>
Just as a technical side note: there's a property
<outputFileNameMapping> in the WAR plugin which can be
used to define the file name of libraries in the WEB-INF/lib
directory.<br>
</div>
</blockquote>
Yes, that's a good workaround for our users in case we do screw up.<br>
But I am hoping to avoid us screwing up,<br>
so our users aren't confronted with the pain of diagnosing the
problem and adding that workaround.<br>
<blockquote cite="mid:50AA362C.6030709@googlemail.com" type="cite">
<div class="moz-cite-prefix"> <br>
If it's changed to
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<b>${artifact.groupId}</b>-${artifact.artifactId}-${artifact.version}${dashClassifier?}.${artifact.extension},
you might isolate the higher level Drools POMs from naming
issues arising from similarly named dependencies (since the
group ID is now included in the JAR filename in WEB-INF/lib).
The clients are thereby relieved of the task of changing their
identity. Personally, I find it strange to impose a need to
rename modules to one of my dependencies, just because I / my
project happens to use them together with a similarly named
other library. The dependencies have a unique identity, but
artifactId is only part of it. If you put groupId plus
artifactId into the outputFileNameMapping, the full maven
identity of your dependencies is carried forward into the
WEB-INF/lib directory.<br>
<br>
My intention is just to make you aware of this (possible)
solution. It's of course up to you to decide which route to
follow.<br>
</div>
</blockquote>
Thanks for sharing :)<br>
<blockquote cite="mid:50AA362C.6030709@googlemail.com" type="cite">
<div class="moz-cite-prefix"> <br>
Best regards<br>
<br>
Ansgar<br>
<br>
[1]
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a moz-do-not-send="true"
href="http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html">http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html</a><br>
[2]
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a moz-do-not-send="true"
href="http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#outputFileNameMapping">http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#outputFileNameMapping</a><br>
<br>
<br>
Am 19.11.2012 11:27, schrieb Geoffrey De Smet:<br>
</div>
<blockquote cite="mid:50AA0982.1090403@gmail.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Hi Alexandre,<br>
<br>
Some of your recent pom.xml changes might introduce a new issue.<br>
<br>
What changes are an issue?<br>
=================<br>
<br>
The uberfire security api has:<br>
<pre><span class="nt"><artifactId></span>security-api<span class="nt"></artifactId></span></pre>
in <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://github.com/droolsjbpm/uberfire/blob/master/uberfire-security/security-api/pom.xml">https://github.com/droolsjbpm/uberfire/blob/master/uberfire-security/security-api/pom.xml</a><br>
<br>
Why is that an issue?<br>
=============<br>
<ul>
<li>1) Hard for users to assert that uberfire's versions are
in sync</li>
<ul>
<li> myproject.war // throws NoSuchMethodError in uberfire<br>
</li>
<ul>
<li>WEB-INF/lib</li>
<ul>
<li>...</li>
<li>security-api-0.3.jar // wrong version, should be 0.4</li>
<li>...</li>
<li>spring-beans-3.0.0.jar<br>
</li>
<li>spring-core-3.0.0.jar</li>
<li>...<br>
</li>
<li>uberfire-core-0.4.jar</li>
<li>uberfire-vfs-api-0.4.jar</li>
<li>...</li>
</ul>
</ul>
</ul>
<li>2) Clashes/confuses with javax.security:security-api<br>
</li>
<ul>
<li><a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://search.maven.org/#artifactdetails">http://search.maven.org/#artifactdetails</a>|javax.security|security-api|1.1-rev-1|jar</li>
<li> myproject.war<br>
</li>
<ul>
<li>WEB-INF/lib</li>
<ul>
<li>...</li>
<li>security-api-0.4.jar // uberfire</li>
<li>security-1.1-rev-1.jar // javax.security<br>
</li>
</ul>
</ul>
</ul>
</ul>
<br>
How can you fix it?<br>
============<br>
<br>
Rename it to uberfire-*<br>
<pre><span class="nt"><artifactId></span>uberfire-security-api<span class="nt"></artifactId></span></pre>
Also check the other uberfire poms for the same problem
(vfs-api, ...).<br>
<br>
===<br>
<br>
Can you take a look at fixing it?<br>
(Let me know if you can't fix it in a timely manner.)<br>
<br>
With kind regards,<br>
Geoffrey<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
rules-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>