Yes, that's a good workaround for our users in case we do screw up.Hi Geoffrey,
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.
Thanks for sharing :)
If it's changed to ${artifact.groupId}-${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.
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.
Best regards
Ansgar
[1] http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html
[2] http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#outputFileNameMapping
Am 19.11.2012 11:27, schrieb Geoffrey De Smet:
Hi Alexandre,
Some of your recent pom.xml changes might introduce a new issue.
What changes are an issue?
=================
The uberfire security api has:
<artifactId>security-api</artifactId>in https://github.com/droolsjbpm/uberfire/blob/master/uberfire-security/security-api/pom.xml
Why is that an issue?
=============
- 1) Hard for users to assert that uberfire's versions are in sync
- myproject.war // throws NoSuchMethodError in uberfire
- WEB-INF/lib
- ...
- security-api-0.3.jar // wrong version, should be 0.4
- ...
- spring-beans-3.0.0.jar
- spring-core-3.0.0.jar
- ...
- uberfire-core-0.4.jar
- uberfire-vfs-api-0.4.jar
- ...
- 2) Clashes/confuses with javax.security:security-api
- http://search.maven.org/#artifactdetails|javax.security|security-api|1.1-rev-1|jar
- myproject.war
- WEB-INF/lib
- ...
- security-api-0.4.jar // uberfire
- security-1.1-rev-1.jar // javax.security
How can you fix it?
============
Rename it to uberfire-*
<artifactId>uberfire-security-api</artifactId>Also check the other uberfire poms for the same problem (vfs-api, ...).
===
Can you take a look at fixing it?
(Let me know if you can't fix it in a timely manner.)
With kind regards,
Geoffrey
_______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev