[
http://jira.codehaus.org/browse/MEXEC-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=230033#action_230033
]
Glen Mazza commented on MEXEC-52:
---------------------------------
I'm not sure where the bug is--I'm using Maven 2.2.1 with JDK 6.0.18. To update
my bug report, here are the Maven pom files I am using:
http://www.jroller.com/gmazza/entry/web_service_tutorial#WFstep3
Only DoubleIt/pom.xml and DoubleIt/client/pom.xml are of importance here.
The two profiles are -PCXF and -PMetro (web service stacks), and the former (as
shown in the parent pom) has the activeByDefault setting.
When using mvn help:effective-pom as Joerg suggested from the client folder
with the -PMetro and -PCXF setting, I can see that Maven is dutifully switching
the dependencies between Metro and CXF and not combining the two. No setting
correctly gives the POM for the default CXF. -- i.e., everything working fine.
However running from the client folder mvn exec:exec -PMetro is causing the
default CXF libraries to load in addition to the Metro ones, (-PCXF or nothing
of course loads just the CXF libs.) If I switch the activeByDefault to Metro
in the parent POM, mvn exec:exec -PCXF causes the CXF libraries to load *in
addition to* the Metro ones. -PCXF should shut off the Metro jars and -PMetro
the CXF ones.
Using mvn exec:exec -PMetro -X (w/CXF default) as Robert suggested is showing,
however, the CXF JARs being loaded even though the mvn help:effective-pom is
showing that it shouldn't. So is this a Maven bug?
The way to also show this is just change the argument as I stated above on 18
July 2008, to get a quick listing of the classpath used. (Metro JARS are these,
BTW: webservices-rt-2.0.1.jar, webservices-api-2.0.1.jar, activation-1.1.jar;
CXF ones are very numerous and have "cxf" in them.)
> maven-exec-plugin <classpath/> not ignoring <activeByDefault/> when explicit
> profile given
> ------------------------------------------------------------------------------------------
>
> Key: MEXEC-52
> URL: http://jira.codehaus.org/browse/MEXEC-52
> Project: Maven 2.x Exec Plugin
> Issue Type: Bug
> Components: exec
> Affects Versions: 1.1
> Reporter: Glen Mazza
>
> When determining the list of dependencies for running a Java class, the
> maven-exec-plugin's <classpath/> setting is not ignoring the
> <activeByDefault/> setting (as it should) when an explicit -Pprofile setting
> is given on the command-line.
> mvn exec:exec -Pbcd
> <profile>
> <id>abc</id>
> <activation>
> <activeByDefault>true</activeByDefault>
> </activation>
> ....
> </profile>
> Should result in just bcd's dependencies getting listed into the classpath,
> not the sum of abc's and bcd's.
> As stated on the Maven profile page[1]: "[activeByDefault profiles] will
> automatically be active for all builds unless another profile in the same pom
> is activated using one of the previously described methods. All profiles that
> are active by default are automatically deactivated when a profile in the pom
> is activated on the command line or through its activation config."
> In my case, these three pom files[2] together allow for creating web service
> providers and clients using either Glassfish Metro or Apache CXF web service
> stack. In the trunk/pom.xml file, if I set activeByDefault for either Metro
> or CXF, the maven-exec-plugin <classpath/> setting always adds those
> dependencies in. If I explicitly set -PMetro or -PCXF command-line, it will
> add those dependencies on top of whatever is <activeByDefault/>. But in
> reality, an explicit profile setting is supposed to completely replace
> whatever dependencies would be listed in <activeByDefault/>.
> [1] http://maven.apache.org/guides/introduction/introduction-to-profiles.html
> [2] http://www.jroller.com/gmazza/date/20080417#WFstep3
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
