[jira] Created: (MANTRUN-95) Plugin classpath problem in multi module maven project
Plugin classpath problem in multi module maven project -- Key: MANTRUN-95 URL: http://jira.codehaus.org/browse/MANTRUN-95 Project: Maven 2.x Antrun Plugin Issue Type: Bug Environment: WindowsXP Pro jdk1.5.0_11 MAVEN 2.0.9 Reporter: Alexandre GIGLEUX Attachments: ProblemMavenPluginClasspath.zip We have a pom.xml with : ./Module1 ./Module2 In Module1 we use the define . In Module2 we also define for maven-antrun-plugin with other . Problem when we display , in Module2 we have the classpath of the Module1. The only workaround is to add specific of Module2, in Module1 (for the maven-antrun-plugin plugin). It looks like the plugin classpath is not updated for each Module. -- 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
[jira] Commented: (MANTTASKS-115) Plugin classpath problem in multi module maven project
[ http://jira.codehaus.org/browse/MANTTASKS-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143697#action_143697 ] Alexandre GIGLEUX commented on MANTTASKS-115: - A new JIRA has been opened in Maven 2.x Antrun Plugin (MANTRUN): http://jira.codehaus.org/browse/MANTRUN-95 > Plugin classpath problem in multi module maven project > -- > > Key: MANTTASKS-115 > URL: http://jira.codehaus.org/browse/MANTTASKS-115 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.9 > Environment: WindowsXP Pro > jdk1.5.0_11 >Reporter: Alexandre GIGLEUX >Priority: Minor > Attachments: ProblemMavenPluginClasspath.zip > > > We have a pom.xml with : > > ./Module1 > ./Module2 > > In Module1 we use the define . > In Module2 we also define for maven-antrun-plugin with other > . > Problem when we display , in Module2 we have the classpath of the Module1. > The only workaround is to add specific of Module2, in Module1 > (for the maven-antrun-plugin plugin). > It looks like the plugin classpath is not updated for each Module. -- 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
[jira] Closed: (MANTTASKS-115) Plugin classpath problem in multi module maven project
[ http://jira.codehaus.org/browse/MANTTASKS-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre GIGLEUX closed MANTTASKS-115. --- Resolution: Won't Fix Not in the correct JIRA project. > Plugin classpath problem in multi module maven project > -- > > Key: MANTTASKS-115 > URL: http://jira.codehaus.org/browse/MANTTASKS-115 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.9 > Environment: WindowsXP Pro > jdk1.5.0_11 >Reporter: Alexandre GIGLEUX >Priority: Minor > Attachments: ProblemMavenPluginClasspath.zip > > > We have a pom.xml with : > > ./Module1 > ./Module2 > > In Module1 we use the define . > In Module2 we also define for maven-antrun-plugin with other > . > Problem when we display , in Module2 we have the classpath of the Module1. > The only workaround is to add specific of Module2, in Module1 > (for the maven-antrun-plugin plugin). > It looks like the plugin classpath is not updated for each Module. -- 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
[jira] Created: (MAVENUPLOAD-2162) Please upload simple-jndi-0.11.4
Please upload simple-jndi-0.11.4 Key: MAVENUPLOAD-2162 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2162 Project: Maven Upload Requests Issue Type: Wish Reporter: Henri Yandell Bugfix release. -- 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
[jira] Updated: (WAGON-231) PathUtils.toRelative() throws SIOOBE if supplied arguments specify the same directory
[
http://jira.codehaus.org/browse/WAGON-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated WAGON-231:
---
Fix Version/s: 1.0-beta-5
> PathUtils.toRelative() throws SIOOBE if supplied arguments specify the same
> directory
> -
>
> Key: WAGON-231
> URL: http://jira.codehaus.org/browse/WAGON-231
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-provider-api
>Affects Versions: 1.0-beta-3
>Reporter: Benjamin Bentmann
> Fix For: 1.0-beta-5
>
> Attachments: to-relative.patch
>
>
> i.e. {{PathUtils.toRelative( new File( "foo" ).getAbsoluteFile(), new File(
> "foo" ).getAbsolutePath() )}} fails.
--
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
[jira] Created: (WAGON-233) Isolate unit tests
Isolate unit tests
--
Key: WAGON-233
URL: http://jira.codehaus.org/browse/WAGON-233
Project: Maven Wagon
Issue Type: Task
Reporter: Benjamin Bentmann
Attachments:
org.apache.maven.wagon.providers.http.LightweightHttpsWagonTest.txt
Running the unit tests for Wagon produced the attached Surefire report.
Symptomatic is that the first test fails while all following raise errors. The
Surefire report shows that this is due to
{noformat}
BindException: Address already in use: JVM_Bind
{noformat}
and indeed, I couldn't spot a call to {{tearDownWagonTestingFixtures()}} in
case the test method was completed abnormally, so the previously started Jetty
server is still hanging around when the next test tries to run.
What about moving the {{tearDown*()}} methods into the usual {{tearDown()}}
method invoked by JUnit? The alternative of using try/finally blocks everywhere
might be cumbersome. Additionally, tear down should be fail-safe, e.g. a call
like {{server.stop()}} would need to be guarded against {{server}} being
{{null}}.
--
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
[jira] Commented: (MWAR-82) setting archiveClasses to true create the jar in WEB-INF/lib but does not remove WEB-INF/classes
[
http://jira.codehaus.org/browse/MWAR-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143711#action_143711
]
Zecas commented on MWAR-82:
---
Hi,
I came across this issue, and I'm having the same problem.
My pom.xml settings:
WebContent/WEB-INF/classes
org.apache.maven.plugins
maven-war-plugin
2.0.1
explode
true
**/resources/*.*
${basedir}/WebContent
It creates a jar file inside the WEB-INF\lib folder, but doesn't remove classes
from WEB-INF\classes folder.
Any workaround?
> setting archiveClasses to true create the jar in WEB-INF/lib but does not
> remove WEB-INF/classes
>
>
> Key: MWAR-82
> URL: http://jira.codehaus.org/browse/MWAR-82
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Reporter: Sebastien Brunot
>Assignee: Stephane Nicoll
>
> This bug has been explained on the maven users mailing list:
> Hi Sebastien
> It seems to be a bug.
> In the code [1] we have :
> if ( archiveClasses )
> {
> createJarArchive( libDirectory );
> }
> else
> {
> copyDirectoryStructureIfModified( classesDirectory,
> webappClassesDirectory );
> }
> The content of the classes directory is never removed (neither in
> createJarArchive nor somewhere else).
> Can you create an issue please ?
> Thx
> Arnaud
> [1]
> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java?revision=471624
> Sebastien Brunot wrote:
> >
> > Hi all,
> >
> > i've got a war project which pom build section contains the following
> > statements:
> >
> >
> >
> > org.apache.maven.plugins
> > maven-war-plugin
> >
> >
> >
> >war
> >
> >
> >true
> >
> >
> >
> >
> >
> > As a result, all the classes and resources from my war project are
> > packaged in a jar that is copied in the WEB-INF/lib directory of the
> > war artifact.
> >
> > But i don't understand why the war artifact still contains copy of the
> > classes and resources under WEB-INF/classes... Does anybody think that
> > i've misconfigured the war plugin ?
> >
> > Thanks for your help,
> >
> > Sebastien
> >
> >
> --
> View this message in context:
> http://www.nabble.com/Configuring-war-plugin-for-using-a-jar-instead-of-WEB-INF-classes-tf2589199s177.html#a7219855
> Sent from the Maven - Users mailing list archive at Nabble.com.
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
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
[jira] Issue Comment Edited: (MWAR-82) setting archiveClasses to true create the jar in WEB-INF/lib but does not remove WEB-INF/classes
[ http://jira.codehaus.org/browse/MWAR-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143711#action_143711 ] zecas edited comment on MWAR-82 at 7/31/08 4:02 AM: Hi, I came across this issue, and I'm having the same problem. My pom.xml settings:It creates a jar file inside the WEB-INF\lib folder, but doesn't remove classes from WEB-INF\classes folder. Any workaround? was (Author: zecas): Hi, I came across this issue, and I'm having the same problem. My pom.xml settings: WebContent/WEB-INF/classes org.apache.maven.plugins maven-war-plugin 2.0.1 explode true **/resources/*.* ${basedir}/WebContent It creates a jar file inside the WEB-INF\lib folder, but doesn't remove classes from WEB-INF\classes folder. Any workaround? > setting archiveClasses to true create the jar in WEB-INF/lib but does not > remove WEB-INF/classes > > > Key: MWAR-82 > URL: http://jira.codehaus.org/browse/MWAR-82 > Project: Maven 2.x War Plugin > Issue Type: Bug >Reporter: Sebastien Brunot >Assignee: Stephane Nicoll > > This bug has been explained on the maven users mailing list: > Hi Sebastien > It seems to be a bug. > In the code [1] we have : > if ( archiveClasses ) > { > createJarArchive( libDirectory ); > } > else > { > copyDirectoryStructureIfModified( classesDirectory, > webappClassesDirectory ); > } > The content of the classes directory is never removed (neither in > createJarArchive nor somewhere else). > Can you create an issue please ? > Thx > Arnaud > [1] > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java?revision=471624 > Sebastien Brunot wrote: > > > > Hi all, > > > > i've got a war project which pom build section contains the following > > statements: > > > > > > > > org.apache.maven.plugins > > maven-war-plugin > > > > > > > >war > > > > > >true > > > > > > > > > > > > As a result, all the classes and resources from my war project are > > packaged in a jar that is copied in the WEB-INF/lib directory of the > > war artifact. > > > WebContent/WEB-INF/classes org.apache.maven.plugins maven-war-plugin 2.0.1 explode true **/resources/*.* ${basedir}/WebContent
[jira] Issue Comment Edited: (MWAR-82) setting archiveClasses to true create the jar in WEB-INF/lib but does not remove WEB-INF/classes
[ http://jira.codehaus.org/browse/MWAR-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143711#action_143711 ] zecas edited comment on MWAR-82 at 7/31/08 4:03 AM: Hi, I came across this issue, and I'm having the same problem. My pom.xml settings:It creates a jar file inside the WEB-INF\lib folder, but doesn't remove classes from WEB-INF\classes folder. I've tried a clean build: mvn clean and then to be sure: mvn clean package Any workaround? was (Author: zecas): Hi, I came across this issue, and I'm having the same problem. My pom.xml settings: WebContent/WEB-INF/classes org.apache.maven.plugins maven-war-plugin 2.0.1 explode true **/resources/*.* ${basedir}/WebContent It creates a jar file inside the WEB-INF\lib folder, but doesn't remove classes from WEB-INF\classes folder. Any workaround? > setting archiveClasses to true create the jar in WEB-INF/lib but does not > remove WEB-INF/classes > > > Key: MWAR-82 > URL: http://jira.codehaus.org/browse/MWAR-82 > Project: Maven 2.x War Plugin > Issue Type: Bug >Reporter: Sebastien Brunot >Assignee: Stephane Nicoll > > This bug has been explained on the maven users mailing list: > Hi Sebastien > It seems to be a bug. > In the code [1] we have : > if ( archiveClasses ) > { > createJarArchive( libDirectory ); > } > else > { > copyDirectoryStructureIfModified( classesDirectory, > webappClassesDirectory ); > } > The content of the classes directory is never removed (neither in > createJarArchive nor somewhere else). > Can you create an issue please ? > Thx > Arnaud > [1] > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java?revision=471624 > Sebastien Brunot wrote WebContent/WEB-INF/classes org.apache.maven.plugins maven-war-plugin 2.0.1 explode true **/resources/*.* ${basedir}/WebContent
[jira] Created: (MEAR-89) Problem, the ear can be buildt with two artifact in same version if a classifier is specified
Problem, the ear can be buildt with two artifact in same version if a classifier is specified - Key: MEAR-89 URL: http://jira.codehaus.org/browse/MEAR-89 Project: Maven 2.x Ear Plugin Issue Type: Bug Reporter: Nicolas Mercereau For example : I have an ear with 2 dependencies EAR_EXAMPLE : -> lib1.jar:alpha -> lib2.jar:beta I use the bundleFinalName to rename the lib1.jar and lib2.jar in order not to have the version in the name of the jar in the ear buildt (eg : not to have lib1-alpha.jar). So i have an ear wich contains lib1.jar and lib2.jar. lib2 has a dependency to lib1 lib2 :beta -> lib1:alpha And now i deploy the lib1 in version alpha with a new classifier "obf" (the repository has two jars, the one normal : lib1-alpha.jar and the one obfuscated : lib1-aplha-obf.jar). And i want to build an EAR with the classifier "obf" for lib1 and lib2 (without classifier for lib2). EAR_EXAMPLE : -> lib1.jar:alpha:classifier=obf -> lib2.jar:beta The problem is that in the EAR, i obtains : - lib1.jar (which is in fact : lib1-aplha-obf.jar) - lib2.jar - and lib1-alpha.jar (which i does not want) The file lib1-alpha.jar is get by the transitive dependencies of lib2. I think it is a bug because the EAR should not take the lib1-alpha.jar, because it has already include the lib1-aplha-obf.jar which corresponds to the same artifact in the same version. -- 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
[jira] Created: (MECLIPSE-473) Allow removing common part of groupId for project name
Allow removing common part of groupId for project name -- Key: MECLIPSE-473 URL: http://jira.codehaus.org/browse/MECLIPSE-473 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Components: Core : Multi-projects Affects Versions: 2.5.1 Reporter: Moshe Bergman Same problem as previous JIRA's. Having multiple projects with the same artifactId in different groupId's. However, using addGroupNameToProjectName creates a long project name, since our projects have this format for grouId: com.aaa.bbb.ccc.Category. Would it be possible to add excludeGroupName option. So I can specify "com.aaa.bbb.ccc" as excluded? -- 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
[jira] Commented: (MECLIPSE-473) Allow removing common part of groupId for project name
[ http://jira.codehaus.org/browse/MECLIPSE-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143723#action_143723 ] Moshe Bergman commented on MECLIPSE-473: Just to clarify, this would result in the project names: Category. For example, if I have artifactId "Client" in: 1) com.aaa.bbb.ccc.Category1 and 2) com.aaa.bbb.ccc.Category2, The result would be: 1) Category1.Client 2) Category2.Client > Allow removing common part of groupId for project name > -- > > Key: MECLIPSE-473 > URL: http://jira.codehaus.org/browse/MECLIPSE-473 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: Core : Multi-projects >Affects Versions: 2.5.1 >Reporter: Moshe Bergman > > Same problem as previous JIRA's. Having multiple projects with the same > artifactId in different groupId's. > However, using addGroupNameToProjectName creates a long project name, since > our projects have this format for grouId: com.aaa.bbb.ccc.Category. > Would it be possible to add excludeGroupName option. So I can specify > "com.aaa.bbb.ccc" as excluded? -- 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
[jira] Reopened: (MCHANGES-47) Add support for multiple and tags in changes.xml
[ http://jira.codehaus.org/browse/MCHANGES-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg reopened MCHANGES-47: - The applied patch for this is *not* compatible with Maven 1, which was the whole purpose of this issue. Check the documentation for the Maven 1 plugin to see this should work: http://maven.apache.org/maven-1.x/plugins/changes/ > Add support for multiple and tags in changes.xml > - > > Key: MCHANGES-47 > URL: http://jira.codehaus.org/browse/MCHANGES-47 > Project: Maven 2.x Changes Plugin > Issue Type: New Feature > Components: changes-report >Affects Versions: 2.0-beta-2, 2.0-beta-3, 2.0 >Reporter: Dennis Lundberg >Assignee: Olivier Lamy > Fix For: 2.1 > > Attachments: maven-change-multiple-issue.patch, > MCHANGES-47-maven-changes-plugin.patch > > > This is to improve the compatibility with changes.xml files used by the Maven > 1 version of the plugin. See MPCHANGES-15 and MPCHANGES-16 for more info. -- 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
[jira] Created: (MNG-3691) When a snapshot is deployed with uniqueVersion=false, it's SNAPSHOT dependencies must be forced to timestamp
When a snapshot is deployed with uniqueVersion=false, it's SNAPSHOT dependencies must be forced to timestamp Key: MNG-3691 URL: http://jira.codehaus.org/browse/MNG-3691 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.9 Reporter: nicolas de loof use case : using the release plugin as a SNAPSHOT timestamped version to ensure reproductibility. When an incompatible SNAPSHOT of the release-manager is deployed, the plugin doesn't work anymore : it updated it's SNAPSHOT dependencies. -> uniqueVersion=false was useless to ensure reproductibility. The isse is that the plugin POM has a SNAPSHOT dependency. As part of the deploy process, the SNAPSHOT version SHOULD be forced to current timestamped version to follow the uniqueVersion expectation. -- 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
RE: maven-test-plugin-1.8.2/plugin.jelly:46:72: : cannot find the path to add to specified by 'id': maven.test.compile.src.set
I am getting the following internal exception in maven test plugin 1.8.2 working inside maven 1.1. Where is this property (maven.test.compile.src.set) supposed to be set initially? Errors stack : >> Unable to obtain goal [all:rebuildWithoutTest] >> File.. file:/C:/p4/tcw/TCW_S_Dev/fo_tcw_fip/TCW/maven.xml >> Element... m:reactor >> Line.. 24 >> Column 45 >> Unable to obtain goal [tcw:buildWithoutTest] >> cannot find the path to add to specified by 'id': maven.test.compile.src.set >> File.. file:/c:/temp/.maven/cache/maven-test-plugin-1.8.2/plugin.jelly >> Element... maven:addPath >> Line.. 46 >> Column 72 Exception stack traces : org.apache.maven.werkz.UnattainableGoalException: Unable to obtain goal [all:rebuildWithoutTest] at org.apache.maven.werkz.Goal.fire(Goal.java:698) at org.apache.maven.werkz.Goal.attain(Goal.java:623) at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:526) at org.apache.maven.werkz.Goal.attain(Goal.java:621) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:712 ) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:265) at org.apache.maven.cli.App.doMain(App.java:307) at org.apache.maven.cli.App.main(App.java:217) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Caused by: org.apache.commons.jelly.JellyTagException: file:/C:/p4/tcw/TCW_S_Dev/fo_tcw_fip/TCW/maven.xml:24:45: Reactor subproje ct failure occurred at org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:380) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.j ava:83) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAc tion(MavenGoalTag.java:116) at org.apache.maven.werkz.Goal.fire(Goal.java:691) at org.apache.maven.werkz.Goal.attain(Goal.java:623) at org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:209) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGo alTag.java:115) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.j ava:83) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAc tion(MavenGoalTag.java:116) at org.apache.maven.werkz.Goal.fire(Goal.java:691) ... 13 more Caused by: org.apache.maven.werkz.UnattainableGoalException: Unable to obtain goal [tcw:buildWithoutTest] at org.apache.maven.werkz.Goal.fire(Goal.java:698) at org.apache.maven.werkz.Goal.attain(Goal.java:623) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:712 ) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:265) at org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:370) ... 26 more Caused by: org.apache.commons.jelly.JellyTagException: file:/c:/temp/.maven/cache/maven-test-plugin-1.8.2/plugin.jelly:46:72: cannot find the path to add to specified by 'id': maven.test.compile.src.set at org.apache.maven.jelly.tags.maven.AddPathTag.doTag(AddPathTag.java:67) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.j ava:83) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAc tion(MavenGoalTag.java:116) at org.apache.maven.werkz.Goal.fire(Goal.java:691) at org.apache.maven.werkz.Goal.attain(Goal.java:623) at org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:209) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGo alTag.java:115) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.j ava:83) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAc tion(MavenGoalTag.java:116) at org.apache.maven.werkz.Goal.fire(Goal.java:691) at or
maven-test-plugin-1.8.2/plugin.jelly:46:72: : cannot find the path to add to specified by 'id': maven.test.compile.src.set
I am getting the following internal exception in maven test plugin 1.8.2 working inside maven 1.1. Where is this property (maven.test.compile.src.set) supposed to be set initially? Errors stack : >> Unable to obtain goal [all:rebuildWithoutTest] >> File.. file:/C:/p4/tcw/TCW_S_Dev/fo_tcw_fip/TCW/maven.xml >> Element... m:reactor >> Line.. 24 >> Column 45 >> Unable to obtain goal [tcw:buildWithoutTest] >> cannot find the path to add to specified by 'id': maven.test.compile.src.set >> File.. file:/c:/temp/.maven/cache/maven-test-plugin-1.8.2/plugin.jelly >> Element... maven:addPath >> Line.. 46 >> Column 72 Exception stack traces : org.apache.maven.werkz.UnattainableGoalException: Unable to obtain goal [all:rebuildWithoutTest] at org.apache.maven.werkz.Goal.fire(Goal.java:698) at org.apache.maven.werkz.Goal.attain(Goal.java:623) at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:526) at org.apache.maven.werkz.Goal.attain(Goal.java:621) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:712 ) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:265) at org.apache.maven.cli.App.doMain(App.java:307) at org.apache.maven.cli.App.main(App.java:217) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Caused by: org.apache.commons.jelly.JellyTagException: file:/C:/p4/tcw/TCW_S_Dev/fo_tcw_fip/TCW/maven.xml:24:45: Reactor subproje ct failure occurred at org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:380) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.j ava:83) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAc tion(MavenGoalTag.java:116) at org.apache.maven.werkz.Goal.fire(Goal.java:691) at org.apache.maven.werkz.Goal.attain(Goal.java:623) at org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:209) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGo alTag.java:115) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.j ava:83) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAc tion(MavenGoalTag.java:116) at org.apache.maven.werkz.Goal.fire(Goal.java:691) ... 13 more Caused by: org.apache.maven.werkz.UnattainableGoalException: Unable to obtain goal [tcw:buildWithoutTest] at org.apache.maven.werkz.Goal.fire(Goal.java:698) at org.apache.maven.werkz.Goal.attain(Goal.java:623) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:712 ) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:265) at org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:370) ... 26 more Caused by: org.apache.commons.jelly.JellyTagException: file:/c:/temp/.maven/cache/maven-test-plugin-1.8.2/plugin.jelly:46:72: cannot find the path to add to specified by 'id': maven.test.compile.src.set at org.apache.maven.jelly.tags.maven.AddPathTag.doTag(AddPathTag.java:67) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.j ava:83) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAc tion(MavenGoalTag.java:116) at org.apache.maven.werkz.Goal.fire(Goal.java:691) at org.apache.maven.werkz.Goal.attain(Goal.java:623) at org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:209) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGo alTag.java:115) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.j ava:83) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAc tion(MavenGoalTag.java:116) at org.apache.maven.werkz.Goal.fire(Goal.java:691) at or
[jira] Created: (MNG-3692) War plugin version 2.1-alpha-1 re-processes files
War plugin version 2.1-alpha-1 re-processes files
-
Key: MNG-3692
URL: http://jira.codehaus.org/browse/MNG-3692
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.1-alpha-1
Environment: Windows/jdk 151/maven 2.0.9
Reporter: EJ Ciramella
We have a version.html file that has a ${label} token inside (as listed
below). When I run with maven 2.0.9, using "mvn install", I can see
that version.html is copied into the target location twice, once via
process-resources (and it's expanded at this point) and then a second
time when the war plugin says:
[INFO] Assembling webapp[pdtApp] in
[E:\work\up-svcs\lty\rel\LTY-R66.0\programData\pdt-web\target\pdtApp-66.
0-SNAPSHOT]
[INFO] Processing war project<-
[INFO] Webapp assembled in[2530 msecs]
This is a change since mvn 2.0.5.
I've NOT defined a war plugin, I'm only telling maven that the
is war. Is it looking at all the defined and
copying them over?
To reproduce this, set up a resource (such as version.html) with a token in it
that lives in the webapp directory under source. Run a mvn package or mvn
install and you'll see that the token first is expanded during the
process-resources goal, then during package, the war plugin copies over (and
overwrites) that same file.
--
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
[jira] Updated: (MRELEASE-236) ArrayindexoutofBoundsException rewriting the Poms for release
[ http://jira.codehaus.org/browse/MRELEASE-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MRELEASE-236: --- Fix Version/s: (was: 2.0) 2.0-beta-7 > ArrayindexoutofBoundsException rewriting the Poms for release > - > > Key: MRELEASE-236 > URL: http://jira.codehaus.org/browse/MRELEASE-236 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: William Ferguson >Assignee: Carlos Sanchez >Priority: Blocker > Fix For: 2.0-beta-7 > > Attachments: MRELEASE-236-patch.txt, pom.xml, Stacktrace.txt > > > Just testing out maven-release-plugin-2.0-beta-6 prior to release and noticed > that it always fails on release:prepare when it is rewriting the Poms. > Looking at the source code, the while loop at lines 249:252 of > RewritePomsForReleasePhase class will always iterate past the end of the char > arrays. > I'm not sure, but I suspect the appropriate soltuion is to check to ensure > that i < tagPathChars.length and i < trunkPathChars.length within the loop > and if so to break. -- 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
[jira] Commented: (MNG-3690) inheriting properties doesn't work if name of property is too long
[ http://jira.codehaus.org/browse/MNG-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143765#action_143765 ] Joseph Marques commented on MNG-3690: - hmm...investigating more into this it appears it might have to do with weird caching. if i just change the value of some property at some parent-parent pom.xml, the new value does not trickle down if i try to execute "mvn" from the child level. i need to path up to the ancestor, build "mvn -N install" from there, and then go back down to the child. this makes using properties set at parent levels rather clunky. i want to be able to change the property at a parent level, and have that take immediate effect if i execute from any child module. is there a way to enable this? > inheriting properties doesn't work if name of property is too long > -- > > Key: MNG-3690 > URL: http://jira.codehaus.org/browse/MNG-3690 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.9 >Reporter: Joseph Marques > > when i used a property that was 30 characters long, it wasn't propagated. > when i shortened it to only be 20, it worked. i don't know what the limit > is, but this was a very sly bug. -- 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
[jira] Commented: (MNG-3690) inheriting properties doesn't work if name of property is too long
[
http://jira.codehaus.org/browse/MNG-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143767#action_143767
]
Benjamin Bentmann commented on MNG-3690:
bq. i want to be able to change the property at a parent level, and have that
take immediate effect if i execute from any child module. is there a way to
enable this?
In principal it should be possible: Maven tries to look up parent POMs from the
local filesystem by following the module's
[{{}}|http://maven.apache.org/ref/2.0.8/maven-model/maven.html#class_parent]
element (of course, the version of the parent POM found at this location must
match the version specified in the child or Maven continues the search in the
repos).
Can you provide a test project that demonstrates your issues?
> inheriting properties doesn't work if name of property is too long
> --
>
> Key: MNG-3690
> URL: http://jira.codehaus.org/browse/MNG-3690
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.9
>Reporter: Joseph Marques
>
> when i used a property that was 30 characters long, it wasn't propagated.
> when i shortened it to only be 20, it worked. i don't know what the limit
> is, but this was a very sly bug.
--
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
[jira] Commented: (MEAR-89) Problem, the ear can be buildt with two artifact in same version if a classifier is specified
[ http://jira.codehaus.org/browse/MEAR-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143771#action_143771 ] Nicolas Mercereau commented on MEAR-89: --- I propose a patch on the EARMojo.java file : patch_EAR_plugin_MEAR-89.txt I have tested the modifications with this patch and it works. It would be great to integrate it in the next release 2.3.2 (we can yet improve the modification i proposed). > Problem, the ear can be buildt with two artifact in same version if a > classifier is specified > - > > Key: MEAR-89 > URL: http://jira.codehaus.org/browse/MEAR-89 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Reporter: Nicolas Mercereau > > For example : > I have an ear with 2 dependencies > EAR_EXAMPLE : > -> lib1.jar:alpha > -> lib2.jar:beta > I use the bundleFinalName to rename the lib1.jar and lib2.jar in order not to > have the version in the name of the jar in the ear buildt (eg : not to have > lib1-alpha.jar). So i have an ear wich contains lib1.jar and lib2.jar. > lib2 has a dependency to lib1 > lib2 :beta > -> lib1:alpha > And now i deploy the lib1 in version alpha with a new classifier "obf" (the > repository has two jars, the one normal : lib1-alpha.jar and the one > obfuscated : lib1-aplha-obf.jar). > And i want to build an EAR with the classifier "obf" for lib1 and lib2 > (without classifier for lib2). > EAR_EXAMPLE : > -> lib1.jar:alpha:classifier=obf > -> lib2.jar:beta > The problem is that in the EAR, i obtains : > - lib1.jar (which is in fact : lib1-aplha-obf.jar) > - lib2.jar > - and lib1-alpha.jar (which i does not want) > The file lib1-alpha.jar is get by the transitive dependencies of lib2. > I think it is a bug because the EAR should not take the lib1-alpha.jar, > because it has already include the lib1-aplha-obf.jar which corresponds to > the same artifact in the same version. -- 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
[jira] Updated: (MEAR-89) Problem, the ear can be buildt with two artifact in same version if a classifier is specified
[ http://jira.codehaus.org/browse/MEAR-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Mercereau updated MEAR-89: -- Attachment: patch_EAR_plugin_MEAR-89.txt the patch of correction > Problem, the ear can be buildt with two artifact in same version if a > classifier is specified > - > > Key: MEAR-89 > URL: http://jira.codehaus.org/browse/MEAR-89 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Reporter: Nicolas Mercereau > Attachments: patch_EAR_plugin_MEAR-89.txt > > > For example : > I have an ear with 2 dependencies > EAR_EXAMPLE : > -> lib1.jar:alpha > -> lib2.jar:beta > I use the bundleFinalName to rename the lib1.jar and lib2.jar in order not to > have the version in the name of the jar in the ear buildt (eg : not to have > lib1-alpha.jar). So i have an ear wich contains lib1.jar and lib2.jar. > lib2 has a dependency to lib1 > lib2 :beta > -> lib1:alpha > And now i deploy the lib1 in version alpha with a new classifier "obf" (the > repository has two jars, the one normal : lib1-alpha.jar and the one > obfuscated : lib1-aplha-obf.jar). > And i want to build an EAR with the classifier "obf" for lib1 and lib2 > (without classifier for lib2). > EAR_EXAMPLE : > -> lib1.jar:alpha:classifier=obf > -> lib2.jar:beta > The problem is that in the EAR, i obtains : > - lib1.jar (which is in fact : lib1-aplha-obf.jar) > - lib2.jar > - and lib1-alpha.jar (which i does not want) > The file lib1-alpha.jar is get by the transitive dependencies of lib2. > I think it is a bug because the EAR should not take the lib1-alpha.jar, > because it has already include the lib1-aplha-obf.jar which corresponds to > the same artifact in the same version. -- 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
[jira] Updated: (WAGON-234) deprecated proxyInfo parameter for Wagon.connect(..) doesn't work in 1.0-beta-4
[ http://jira.codehaus.org/browse/WAGON-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated WAGON-234: - Fix Version/s: 1.0-beta-5 > deprecated proxyInfo parameter for Wagon.connect(..) doesn't work in > 1.0-beta-4 > --- > > Key: WAGON-234 > URL: http://jira.codehaus.org/browse/WAGON-234 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-provider-api >Affects Versions: 1.0-beta-4 >Reporter: John Casey > Fix For: 1.0-beta-5 > > > proxyInfo parameter passed into some connect(..) methods is set on the > AbstractWagon instance, but is never used. This will probably cause problems > for users of older versions of wagon, as it did with DefaultWagonManager in > maven-artifact-manager 2.0.10-RC4 snapshot, until I traced it back and > learned that I had to provide a ProxyInfoProvider instance instead to get > proxies working. -- 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
[jira] Created: (WAGON-234) deprecated proxyInfo parameter for Wagon.connect(..) doesn't work in 1.0-beta-4
deprecated proxyInfo parameter for Wagon.connect(..) doesn't work in 1.0-beta-4 --- Key: WAGON-234 URL: http://jira.codehaus.org/browse/WAGON-234 Project: Maven Wagon Issue Type: Bug Components: wagon-provider-api Affects Versions: 1.0-beta-4 Reporter: John Casey Fix For: 1.0-beta-5 proxyInfo parameter passed into some connect(..) methods is set on the AbstractWagon instance, but is never used. This will probably cause problems for users of older versions of wagon, as it did with DefaultWagonManager in maven-artifact-manager 2.0.10-RC4 snapshot, until I traced it back and learned that I had to provide a ProxyInfoProvider instance instead to get proxies working. -- 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
[jira] Commented: (MCHANGES-47) Add support for multiple and tags in changes.xml
[ http://jira.codehaus.org/browse/MCHANGES-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143778#action_143778 ] Olivier Lamy commented on MCHANGES-47: -- Thanks for the link Dennis :-) Never seen it before. > Add support for multiple and tags in changes.xml > - > > Key: MCHANGES-47 > URL: http://jira.codehaus.org/browse/MCHANGES-47 > Project: Maven 2.x Changes Plugin > Issue Type: New Feature > Components: changes-report >Affects Versions: 2.0-beta-2, 2.0-beta-3, 2.0 >Reporter: Dennis Lundberg >Assignee: Olivier Lamy > Fix For: 2.1 > > Attachments: maven-change-multiple-issue.patch, > MCHANGES-47-maven-changes-plugin.patch > > > This is to improve the compatibility with changes.xml files used by the Maven > 1 version of the plugin. See MPCHANGES-15 and MPCHANGES-16 for more info. -- 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
[jira] Commented: (WAGON-234) deprecated proxyInfo parameter for Wagon.connect(..) doesn't work in 1.0-beta-4
[ http://jira.codehaus.org/browse/WAGON-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143782#action_143782 ] Brett Porter commented on WAGON-234: can you elaborate on the circumstances that caused this? it is set, and is intended to be used as a fallback, but perhaps one particular sequence doesn't do this > deprecated proxyInfo parameter for Wagon.connect(..) doesn't work in > 1.0-beta-4 > --- > > Key: WAGON-234 > URL: http://jira.codehaus.org/browse/WAGON-234 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-provider-api >Affects Versions: 1.0-beta-4 >Reporter: John Casey > Fix For: 1.0-beta-5 > > > proxyInfo parameter passed into some connect(..) methods is set on the > AbstractWagon instance, but is never used. This will probably cause problems > for users of older versions of wagon, as it did with DefaultWagonManager in > maven-artifact-manager 2.0.10-RC4 snapshot, until I traced it back and > learned that I had to provide a ProxyInfoProvider instance instead to get > proxies working. -- 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
[jira] Created: (MAVENUPLOAD-2163) Maven GWT plugin 1.0
Maven GWT plugin 1.0 Key: MAVENUPLOAD-2163 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2163 Project: Maven Upload Requests Issue Type: Wish Reporter: Maxim Gordienko "net.sf.mgp","[EMAIL PROTECTED]:/home/groups/m/mg/mgp/htdocs/releases","rsync_ssh","Maxim Gordienko","[EMAIL PROTECTED]",, -- 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
[jira] Created: (MSITE-346) Allow site.xml to be optional
Allow site.xml to be optional - Key: MSITE-346 URL: http://jira.codehaus.org/browse/MSITE-346 Project: Maven 2.x Site Plugin Issue Type: Improvement Reporter: Paul Benedict I want to use the Maven Site Plugin to produce, package, and deploy a typical Apache-hosted website. I do not need any content generation or skinning. Everything that I need would reside in /src/main/resources. -- 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
[jira] Commented: (WAGON-234) deprecated proxyInfo parameter for Wagon.connect(..) doesn't work in 1.0-beta-4
[ http://jira.codehaus.org/browse/WAGON-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143792#action_143792 ] John Casey commented on WAGON-234: -- When I rolled the beta-4 version of wagon back into the 2.0.10-RC build, DefaultWagonManager was still using connect(.., ProxyInfo) instead of the ProxyInfoProvider method. The result was the IT for MNG-3599 would not pass. When I looked into the code (maven-artifact-manager and wagon-provider-api), I found that, yes, the proxyInfo variable, which is deprecated, was set. However, I had all of the wagon projects loaded and open in my Eclipse workspace, and a reference search for that field didn't turn up anything at all except for that assignment. I can't see that this deprecated field is used anywhere at all. If I'm incorrect, that's great, but the IT magically started working when I replaced the connect(..) calls in DefaultWagonManager with the version that passed in ProxyInfoProvider instances. No other changes to the IT at all. > deprecated proxyInfo parameter for Wagon.connect(..) doesn't work in > 1.0-beta-4 > --- > > Key: WAGON-234 > URL: http://jira.codehaus.org/browse/WAGON-234 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-provider-api >Affects Versions: 1.0-beta-4 >Reporter: John Casey > Fix For: 1.0-beta-5 > > > proxyInfo parameter passed into some connect(..) methods is set on the > AbstractWagon instance, but is never used. This will probably cause problems > for users of older versions of wagon, as it did with DefaultWagonManager in > maven-artifact-manager 2.0.10-RC4 snapshot, until I traced it back and > learned that I had to provide a ProxyInfoProvider instance instead to get > proxies working. -- 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
[jira] Commented: (MSITE-346) Allow site.xml to be optional
[ http://jira.codehaus.org/browse/MSITE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143793#action_143793 ] Dennis Lundberg commented on MSITE-346: --- What kind of problems are you running into trying to do this? > Allow site.xml to be optional > - > > Key: MSITE-346 > URL: http://jira.codehaus.org/browse/MSITE-346 > Project: Maven 2.x Site Plugin > Issue Type: Improvement >Reporter: Paul Benedict > > I want to use the Maven Site Plugin to produce, package, and deploy a typical > Apache-hosted website. I do not need any content generation or skinning. > Everything that I need would reside in /src/main/resources. -- 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
[jira] Updated: (MNG-3599) webdav does not set http-proxy correctly
[ http://jira.codehaus.org/browse/MNG-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3599: -- Fix Version/s: (was: 2.0.11) 2.0.10 > webdav does not set http-proxy correctly > > > Key: MNG-3599 > URL: http://jira.codehaus.org/browse/MNG-3599 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.0.10, 2.1-alpha-1 > > Attachments: MNG-3599.patch > > > patch is attached to WAGON-82 > (0001-Make-the-artifact-manager-using-wagons-ProxyInfoProv.patch), utilising > the new APIs in beta-3 -- 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
[jira] Commented: (WAGON-234) deprecated proxyInfo parameter for Wagon.connect(..) doesn't work in 1.0-beta-4
[ http://jira.codehaus.org/browse/WAGON-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143794#action_143794 ] Brett Porter commented on WAGON-234: I'll take a look - Wagon itself now uses the provider, and a default one using the proxyInfo is constructed in that constructor. The old field is there for anyone using it since it was a protected variable. I'm quite sure the ITs worked with the old constructor - but good that it is working now. > deprecated proxyInfo parameter for Wagon.connect(..) doesn't work in > 1.0-beta-4 > --- > > Key: WAGON-234 > URL: http://jira.codehaus.org/browse/WAGON-234 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-provider-api >Affects Versions: 1.0-beta-4 >Reporter: John Casey > Fix For: 1.0-beta-5 > > > proxyInfo parameter passed into some connect(..) methods is set on the > AbstractWagon instance, but is never used. This will probably cause problems > for users of older versions of wagon, as it did with DefaultWagonManager in > maven-artifact-manager 2.0.10-RC4 snapshot, until I traced it back and > learned that I had to provide a ProxyInfoProvider instance instead to get > proxies working. -- 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
[jira] Commented: (MSITE-346) Allow site.xml to be optional
[ http://jira.codehaus.org/browse/MSITE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143796#action_143796 ] Wendy Smoak commented on MSITE-346: --- Seems to be related to this thread: http://www.nabble.com/Site-Plugin%3A-Only-static-content---is-it-possible--ts18747971.html I had no problems removing site.xml. Is that really the problem here? What I did find is that I needed to configure the maven-project-info-reports plugin to not generate any reports, and possibly create a new site skin that doesn't have any css or images. > Allow site.xml to be optional > - > > Key: MSITE-346 > URL: http://jira.codehaus.org/browse/MSITE-346 > Project: Maven 2.x Site Plugin > Issue Type: Improvement >Reporter: Paul Benedict > > I want to use the Maven Site Plugin to produce, package, and deploy a typical > Apache-hosted website. I do not need any content generation or skinning. > Everything that I need would reside in /src/main/resources. -- 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
[jira] Commented: (MWAR-116) The outputFileNameMapping config creates bad dependency files in WEB-INF/lib
[
http://jira.codehaus.org/browse/MWAR-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143798#action_143798
]
Dave Sinclair commented on MWAR-116:
I have 2.1-alpha-2-SNAPSHOT and am still seeing this problem. Here is the
section from my pom. Any ideas?
org.apache.maven.plugins
maven-war-plugin
2.1-alpha-2-SNAPSHOT
true
${artifact.artifactId}.${artifact.extension}
src/main/filters/${wile.filter.properties}
${basedir}/src/main/webapp/WEB-INF
beans.xml
web.xml
WEB-INF
true
> The outputFileNameMapping config creates bad dependency files in WEB-INF/lib
>
>
> Key: MWAR-116
> URL: http://jira.codehaus.org/browse/MWAR-116
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.1-alpha-1
>Reporter: Chris Moesel
>Assignee: Olivier Lamy
> Fix For: 2.1-alpha-2
>
> Attachments: mwar_93_webapp.zip
>
>
> I've tried using the new outputFileNameMapping feature (MWAR-93) by adding
> the following to my POM:
>
> org.apache.maven.plugins
> maven-war-plugin
> 2.1-alpha-1-SNAPSHOT
>
> ${artifactId}.${extension}
>
>
> This results in really oddly named files in my web-inf/lib now. A typical
> example:
> org.springframework-mywebapp.null
> So, the resulting files are really mapped more like: ${groupId of the
> dependency}-${artifactId of my war module}.null
> I've attached an example Maven 2 project that demonstrates this. Just run
> "mvn package" and look at the result in target.
--
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
[jira] Created: (MJAVADOC-210) Unit tests fail on OS X
Unit tests fail on OS X --- Key: MJAVADOC-210 URL: http://jira.codehaus.org/browse/MJAVADOC-210 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.5 Environment: Betelgeuse:maven-javadoc-plugin jdcasey$ mvn -v JDK 1.4 2.0.9 --> Command was: /Users/jdcasey/apps/maven/apache-maven-2.0.9/bin/mvn -v Maven version: 2.0.9 Java version: 1.4.2_16 OS name: "mac os x" version: "10.5.4" arch: "i386" Family: "unix" Java Home: /System/Library/Frameworks/JavaVM.framework/Versions/1.4/Home Reporter: John Casey Priority: Critical Attachments: build.log, org.apache.maven.plugin.javadoc.JavadocReportTest.txt I'm attaching the build console output and surefire output file for the failing unit test. -- 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
[jira] Closed: (MIDEA-102) Module filepath is generated incorrectly for sibling parent
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MIDEA-102. - Resolution: Fixed OK, I'm closing this as fixed now. I got one response in private that it works. > Module filepath is generated incorrectly for sibling parent > --- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102-2.patch, > maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- 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
[jira] Updated: (MJAVADOC-210) Unit tests fail on OS X
[
http://jira.codehaus.org/browse/MJAVADOC-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MJAVADOC-210:
---
Attachment: MJAVADOC-210.patch
IIRC, Mac has no {{tools.jar}} but a similar thing named {{classes.jar}} which
is already part of the bootstrap class path I believe. So I coded up this
patch. I have no Mac box to test it, so it's all up to you John. If it works, I
leave it to Vincent to do a final review and maybe apply.
> Unit tests fail on OS X
> ---
>
> Key: MJAVADOC-210
> URL: http://jira.codehaus.org/browse/MJAVADOC-210
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.5
> Environment: Betelgeuse:maven-javadoc-plugin jdcasey$ mvn -v
> JDK 1.4
> 2.0.9
> --> Command was: /Users/jdcasey/apps/maven/apache-maven-2.0.9/bin/mvn -v
> Maven version: 2.0.9
> Java version: 1.4.2_16
> OS name: "mac os x" version: "10.5.4" arch: "i386" Family: "unix"
> Java Home: /System/Library/Frameworks/JavaVM.framework/Versions/1.4/Home
>Reporter: John Casey
>Priority: Critical
> Attachments: build.log, MJAVADOC-210.patch,
> org.apache.maven.plugin.javadoc.JavadocReportTest.txt
>
>
> I'm attaching the build console output and surefire output file for the
> failing unit test.
--
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
[jira] Commented: (MJAVADOC-210) Unit tests fail on OS X
[ http://jira.codehaus.org/browse/MJAVADOC-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143807#action_143807 ] Vincent Siveton commented on MJAVADOC-210: -- According [1], I am not sure if it is classes.jar. John? [1] https://svn.codehaus.org/plexus/plexus-components/trunk/plexus-compiler/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavacCompiler.java > Unit tests fail on OS X > --- > > Key: MJAVADOC-210 > URL: http://jira.codehaus.org/browse/MJAVADOC-210 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.5 > Environment: Betelgeuse:maven-javadoc-plugin jdcasey$ mvn -v > JDK 1.4 > 2.0.9 > --> Command was: /Users/jdcasey/apps/maven/apache-maven-2.0.9/bin/mvn -v > Maven version: 2.0.9 > Java version: 1.4.2_16 > OS name: "mac os x" version: "10.5.4" arch: "i386" Family: "unix" > Java Home: /System/Library/Frameworks/JavaVM.framework/Versions/1.4/Home >Reporter: John Casey >Priority: Critical > Attachments: build.log, MJAVADOC-210.patch, > org.apache.maven.plugin.javadoc.JavadocReportTest.txt > > > I'm attaching the build console output and surefire output file for the > failing unit test. -- 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
[jira] Commented: (MJAVADOC-210) Unit tests fail on OS X
[ http://jira.codehaus.org/browse/MJAVADOC-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143808#action_143808 ] Vincent Siveton commented on MJAVADOC-210: -- John, could you zip your target dir? > Unit tests fail on OS X > --- > > Key: MJAVADOC-210 > URL: http://jira.codehaus.org/browse/MJAVADOC-210 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.5 > Environment: Betelgeuse:maven-javadoc-plugin jdcasey$ mvn -v > JDK 1.4 > 2.0.9 > --> Command was: /Users/jdcasey/apps/maven/apache-maven-2.0.9/bin/mvn -v > Maven version: 2.0.9 > Java version: 1.4.2_16 > OS name: "mac os x" version: "10.5.4" arch: "i386" Family: "unix" > Java Home: /System/Library/Frameworks/JavaVM.framework/Versions/1.4/Home >Reporter: John Casey >Priority: Critical > Attachments: build.log, MJAVADOC-210.patch, > org.apache.maven.plugin.javadoc.JavadocReportTest.txt > > > I'm attaching the build console output and surefire output file for the > failing unit test. -- 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
[jira] Created: (MCHECKSTYLE-99) should use default test sources xref output dir: ${project.reporting.outputDirectory}/xref-test
should use default test sources xref output dir:
${project.reporting.outputDirectory}/xref-test
Key: MCHECKSTYLE-99
URL: http://jira.codehaus.org/browse/MCHECKSTYLE-99
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: Linux (but I assume it happens in all environs)
Reporter: Dan Rollo
Attachments: pom.xml
The xref link to the Source pages in the checkstyle report page is
broken. The source xref link for Unit Test Source files is not using the
default value of the destDir for jxr test sources. From the jxr plugin docs
for jxr:test-jxr:
destDir
Folder where the Xref files will be copied to.
* Type: java.lang.String
* Required: No
* Expression: ${project.reporting.outputDirectory}/xref-test
I think the checkstyle plugin should:
- assume the default dir for jxr:test-jxr
- provide it's own additional override setting (similar to xrefLocation,
but for test sources). like: testXrefLocation.
A pom file exhibiting this problem is attached.
Dan Rollo
--
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
[jira] Created: (MCHECKSTYLE-100) Using element truncates xref link to "production" (non-test) classes
Using element truncates xref link to "production" (non-test) classes - Key: MCHECKSTYLE-100 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-100 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.2 Environment: Linux (assume the same issue exists in all environs) maven 2.0.9 Reporter: Dan Rollo Attachments: pom.xml When I include the element, the source xref link for "production" (non-test) classes has a mangled URL: the first letter of the top level package is ommitted in the link: Links to production source should be: file:///.../jdbc4olap/target/site/xref/org/jdbc4olap/xmla/XmlaProperties.html#10 But the actual link created is: file:///.../jdbc4olap/target/site/xref/rg/jdbc4olap/xmla/XmlaProperties.html#10 ^ If I remove the element, the xref links to production sources are fine. [BTW, there is a LICENSE.txt file at the root of my project (in case anyone thought a missing default header file would affect this), and the checkstyle report properly flags missing headers.] pom.xml showing the problem is attached. (Maybe related to MCHECKSTYLE-99 ?) Dan Rollo -- 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
[jira] Reopened: (MRELEASE-3) release:prepare should not require multimodule artifacts to be in the local repository
[ http://jira.codehaus.org/browse/MRELEASE-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran reopened MRELEASE-3: - Dont think it is fixed, my maven is 2.0.9 using release plugin that binds with the maven version. > release:prepare should not require multimodule artifacts to be in the local > repository > -- > > Key: MRELEASE-3 > URL: http://jira.codehaus.org/browse/MRELEASE-3 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Reporter: John Casey >Assignee: Emmanuel Venisse > Fix For: 2.0-beta-5 > > > Currently, if you try to run release:prepare on a multimodule project after > removing any of that build's artifacts from the local repository, it will > fail. Investigate why release:prepare needs the multimodule artifacts > installed in the local repository before it can succeed. > To reproduce, comment the following line in it2002/test.sh: > mvn clean install > NOTE: This may have to do with the version resolution code, which is used to > resolve SNAPSHOT versions. -- 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
[jira] Created: (MRELEASE-368) release:prepare doesn't recognise deleted files
release:prepare doesn't recognise deleted files --- Key: MRELEASE-368 URL: http://jira.codehaus.org/browse/MRELEASE-368 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Affects Versions: 2.0-beta-7 Environment: Windows XP, CVSNT 2.5.03 (build 2382), Maven 2.0.9 Reporter: David Barri Priority: Critical If I check a project out, delete a file and then run mvn release:prepare (using native cvs impl) then the following happens: * In the first phase I see Unknown file status: 'R'. * It then changes the version in the pom to the release version and commits it. * However before tagging it checks again, see’s that a file is missing and aborts. It should stop in the verify phase at the beginning. -- 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
[jira] Updated: (MRELEASE-368) release:prepare doesn't recognise deleted files
[ http://jira.codehaus.org/browse/MRELEASE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Barri updated MRELEASE-368: - Attachment: MRELEASE-368 output.txt mvn output > release:prepare doesn't recognise deleted files > --- > > Key: MRELEASE-368 > URL: http://jira.codehaus.org/browse/MRELEASE-368 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.0-beta-7 > Environment: Windows XP, CVSNT 2.5.03 (build 2382), Maven 2.0.9 >Reporter: David Barri >Priority: Critical > Attachments: MRELEASE-368 output.txt > > > If I check a project out, delete a file and then run mvn release:prepare > (using native cvs impl) then the following happens: > * In the first phase I see Unknown file status: 'R'. > * It then changes the version in the pom to the release version and commits > it. > * However before tagging it checks again, see’s that a file is missing > and aborts. > It should stop in the verify phase at the beginning. -- 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
