[jira] Commented: (MASSEMBLY-545) While loading multiple Filter files, already known filter values are not applied (see MSHARED-177)
[ http://jira.codehaus.org/browse/MASSEMBLY-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255012#action_255012 ] Daniel Mohni commented on MASSEMBLY-545: Another maven magic happend here. I can not reproduce the problem even with version 2.2 I tracked the problem and found out that it didn't work with beta-4. From beta-5 it is working, looks like there is workaround for my fix on maven-filtering somewhere else. Basicly the problem occured because the version was not specified in the pom, and maven 2.2.1 has beta-1 defined in the pluginManagment. Switching to maven3 would also solve the problem as it uses beta-5. > While loading multiple Filter files, already known filter values are not > applied (see MSHARED-177) > -- > > Key: MASSEMBLY-545 > URL: http://jira.codehaus.org/browse/MASSEMBLY-545 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Reporter: Daniel Mohni > Fix For: 2.2.1 > > > Fix has been submitted to maven-filtering project. > MASSEMBLY shoud update to new version as soon it is released -- 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: (SUREFIRE-616) surefire-report doesn't create target/site/css
[ http://jira.codehaus.org/browse/SUREFIRE-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255019#action_255019 ] Ravi Shriram Mundhe commented on SUREFIRE-616: -- try this add version "2.4.2" for "org.apache.maven.plugins" > surefire-report doesn't create target/site/css > -- > > Key: SUREFIRE-616 > URL: http://jira.codehaus.org/browse/SUREFIRE-616 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Report Plugin > Environment: Maven 2.2.1, Java 1.6.0_17, OS/X 10.6.3 >Reporter: Marco Brandizi > > I've just try " mvn surefire-report:report-only" and I get what said in the > subject. It creates site surefire-report.html, but not the css/*.css files > that are imported by such html. The result is quite ugly to see. -- 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: (MRELEASE-636) Flat Layout branching not correctly supported - CONTAINS PATCH FOR 2.1 version of plugin - please apply
[ http://jira.codehaus.org/browse/MRELEASE-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255029#action_255029 ] Andreas Gschwind commented on MRELEASE-636: --- We are facing the same problem and are looking forward for the path... Is there a plan, when a patch could be made available. Are we talking about days, weeks or months? > Flat Layout branching not correctly supported - CONTAINS PATCH FOR 2.1 > version of plugin - please apply > --- > > Key: MRELEASE-636 > URL: http://jira.codehaus.org/browse/MRELEASE-636 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: branch >Affects Versions: 2.1 > Environment: Maven 2.2.1, JDK6 >Reporter: Nico De Groote >Priority: Blocker > Attachments: release.patch > > > When trying to create a branch with the commitByProject=true value, it is not > taken into account. > So I created a patch on for the 2.1 version. > The attached patch consist of the following: > in the maven-release-manager > 1) the http://jira.codehaus.org/browse/MRELEASE-619 > 2) some extra logging concerning the use of commitByProject property in the > AbstractScmCommitPhase.java > in the maven-release-plugin > 1) I've put the commitByProject in the AbstractReleaseMojo, and used it in > both the BranchReleaseMojo and PrepareReleaseMojo in similar way. > Can you guys create a version 2.1.1 fix with this patch. There seem to be a > lot of people out there havinh troublwe releaseing a Flat Layout multimodule. > I do it in the following way... > /PARENT/pom.xml > /MODULE1/POM.XML > ... > and in the parent pom.xml > >../MODULE1/pom.xml... > > and in SVN > project/trunk/PARENT (0.0.10-SNAPSHOT) >/trunk/MODULE1 (0.0.10-SNAPSHOT) >/trunk/ (0.0.10-SNAPSHOT) > When releasing this application we perform the following commands > First checkout the application... and run the following command to release a > 0.0.10-SNAPSHOT version on the trunk. > Also make sure you did fill in the SCM information. > 1) release:clean release:branch with the following values set > -Dusername= -Dpassword= -DcommitByProject=true > -DautoVersionSubmodules=true -DreleaseVersion=0.0.10RC1 > -DdevelopmentVersion=0.0.11-SNAPSHOT -DupdateBranchVersions=true > -DbranchName=project-0.0.10_branch > This will update your trunk value to 0.0.11-SNAPSHOT and create a branch with > version 0.0.10RC1-SNAPSHOT > Svn will look like this > project/trunk/PARENT (0.0.11-SNAPSHOT) >/trunk/MODULE1 (0.0.11-SNAPSHOT) >/trunk/ >/branches/project-0.0.10_branch/PARENT (0.0.10RC1-SNAPSHOT) >/branches/project-0.0.10_branch/MODULE1 (0.0.10RC1-SNAPSHOT) >/branches/project-0.0.10_branch/... > Now, when this is done checkout this newly created branch > and perform the following > 2) release:clean release:prepare release:perform with the following values > -Dusername= -Dpassword= -DcommitByProject=true > -DautoVersionSubmodules=true > This will release your 0.0.10RC1-SNAPSHOT as 0.0.10RC1, creates a tag for it > and an upgrade the version number on the branch to 0.0.11RC2-SNAPSHOT > Svn will look like this > project/trunk/PARENT (0.0.11-SNAPSHOT) >/trunk/MODULE1 (0.0.11-SNAPSHOT) >/trunk/ >/branches/project-0.0.10_branch/PARENT (0.0.10RC2-SNAPSHOT) >/branches/project-0.0.10_branch/MODULE1 (0.0.10RC2-SNAPSHOT) >/branches/project-0.0.10_branch/... >/tags/project-0.0.10RC1/PARENT (0.0.10RC1) >/tags/project-0.0.10RC1/MODULE1 (0.0.10RC1) >/tags/project-0.0.10RC1/... > > Hope this helps... -- 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-646) release:prepare failed on parent's pom not localized in ../
release:prepare failed on parent's pom not localized in ../ --- Key: MRELEASE-646 URL: http://jira.codehaus.org/browse/MRELEASE-646 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.1 Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100) Java version: 1.6.0_23, vendor: Sun Microsystems Inc. OS name: "windows 2003", version: "5.2", arch: "x86", family: "windows" Reporter: amber Since Maven 3.x, the plugin failed during the prepare phase because of the "relativePath" error : Structure is : super-pom |__foo1 |__foo2 |__foo3 |__foo4 Foo1 is parent of foo3 but the plugin can't find it : [INFO] Not generating release POMs [INFO] Executing goals 'clean verify'... [WARNING] Maven will be executed in interactive mode, but no input stream has been configured for th is MavenInvoker instance. [INFO] [INFO] Scanning for projects... [INFO] [ERROR] The build could not read 1 project -> [Help 1] [INFO] [ERROR] [INFO] [ERROR] The project com.mycompany.testRelease.foo3:foo3:0.0.2 (C:\dev\test-rele aseplugin\foo3\pom.xml) has 1 error [INFO] [ERROR] Non-resolvable parent POM: Failure to find com.mycompany.testRelease: foo1:pom:0.0.2 in http://localhost:8081/nexus/content/groups/public was cached in the local reposito ry, resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced and 'parent.relativePath' points at wrong local POM @ line 4, column 10 -> [Help 2] [INFO] [ERROR] [INFO] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [INFO] [ERROR] Re-run Maven using the -X switch to enable full debug logging. [INFO] [ERROR] Here the foo3's pom : com.mycompany.testRelease foo1 0.0.2 This pom was working fine with Maven 2.2.1 ans a mvn install command with Maven 3.x (just a warning about parent.path but Maven find the artifact into the local referentiel) Now I have to put relativePath : com.mycompany.testRelease foo1 0.0.2 ../foo1/pom.xml and all works! it's not a real workaround because I use my project to generate an archetype, so I have to put the relativePath for the release plugin and remove it to create the archetype :( -- 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: (SCM-604) SCM API - Changelog fails if there are no changes in the specified range
SCM API - Changelog fails if there are no changes in the specified range
Key: SCM-604
URL: http://jira.codehaus.org/browse/SCM-604
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-perforce
Affects Versions: 1.4
Environment: Reproducible in ubuntu, windows xp
Reporter: Waikhom Ningsuhen
The issue was found while using maven changelog plugin. If there are no changes
in the range specified in changelog configuration, the plugin fails with error:-
{code}
[INFO] --- maven-changelog-plugin:2.2:changelog (generate-changelog) @ core ---
[INFO] Generating changed sets xml to:
/home/cquser/Workspace/core/target/changelog.xml
[INFO] No password found, proceeding without it.
[ERROR] CommandLineException Exit code: 1 - Usage: describe [-d -s -S]
[changelist#...]
Missing/wrong number of arguments.
Command line was:p4 -d /home/cquser/Workspace/core -p perforce:1980 describe -s
org.codehaus.plexus.util.cli.CommandLineException: Exit code: 1 - Usage:
describe [-d -s -S] [changelist#...]
Missing/wrong number of arguments.
Command line was:p4 -d /home/cquser/Workspace/core -p perforce:1980 describe -s
at
org.apache.maven.scm.provider.perforce.command.changelog.PerforceChangeLogCommand.executeChangeLogCommand(PerforceChangeLogCommand.java:151)
at
org.apache.maven.scm.provider.perforce.command.changelog.PerforceChangeLogCommand.executeChangeLogCommand(PerforceChangeLogCommand.java:74)
at
org.apache.maven.scm.command.changelog.AbstractChangeLogCommand.executeCommand(AbstractChangeLogCommand.java:102)
at
org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59)
at
org.apache.maven.scm.provider.perforce.PerforceScmProvider.changelog(PerforceScmProvider.java:159)
at
org.apache.maven.scm.provider.AbstractScmProvider.changeLog(AbstractScmProvider.java:248)
at
org.apache.maven.plugin.changelog.ChangeLogReport.generateChangeSetsFromSCM(ChangeLogReport.java:619)
at
org.apache.maven.plugin.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:535)
at
org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:448)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:135)
at
org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:87)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
{code}
After getting changesets, the command "p4 -d /home/cquser/Workspace/core -p
perforce:1980 describe -s [changeset#]" is executed but as there are no
changesets returned, the command is executed without the changeset number and
thereby failing.
There should be proper handling if no changesets are returned and no exception
should be thrown. Please check this issue.
--
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: h
[jira] Commented: (SUREFIRE-696) Improve the design of the class Classpath
[ http://jira.codehaus.org/browse/SUREFIRE-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255058#action_255058 ] Kristian Rosenvold commented on SUREFIRE-696: - LinkedHashSet is a jdk1.4 class and the booter is actually (believe it or not!) a java 1.3 module. I would also prefer using a private copy-constructor in the join method to retain immutability. Personally I see no point in using an interator when the code *also* has to maintain a counter, at least not when you can't use a linkedhashset ;) The other changes are nice, would you mind updating the patch? > Improve the design of the class Classpath > - > > Key: SUREFIRE-696 > URL: http://jira.codehaus.org/browse/SUREFIRE-696 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 2.7.2 >Reporter: Stefan Birkner >Priority: Minor > Attachments: SUREFIRE-Classpath.patch > > > This patch contains some improvements for the class Classpath: > * Only use a set for storing the elements. > * append(Classpath) has been changed to Classpath.join(Classpath, Classpath), > because the classpath doesn't get appended. Instead a new one is created. > * Renamed setForkProperties to writeToForkProperties. > * Renamed setAsSystemProperty to writeToSystemProperty. > * Moved getClassPathAsString() into writeToSystemProperty and only call > writeToSystemProperty from outside. > * Added readFromForkProperties in order to have serialization and > deseralization being part of the same class. > From my point of view these changes improve the readability of the Surefire > code and are another step on the way to clean code. -- 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-647) Error on SVN tagging in Maven release
Error on SVN tagging in Maven release -- Key: MRELEASE-647 URL: http://jira.codehaus.org/browse/MRELEASE-647 Project: Maven 2.x Release Plugin Issue Type: Bug Environment: Wiondows Server 2008, Tomcat 7, Jenkis 1.3.9.6 + Hudson Maven Release Plug-in Plug-in 0.6.1, Maven 3 Reporter: cforce Checking out from the scm (https://sid-repo.de/svn/e2etrace/trunk ) does work and "regular" svn tag from hdsuon also, only tagging via mave release plugin faults with following error. Tomcat is running on local user account not system account. The scm server is using a self signed certficate. Manual Svn (SlikSVN 1.6.12 is installed) update from cmd prompt console as local user in workspace does work without problems. [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 17.547s [INFO] Finished at: Tue Feb 08 14:49:11 CET 2011 [INFO] Final Memory: 14M/309M [INFO] mavenExecutionResult exceptions not empty org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.0:prepare (default-cli) on project e2etrace: Unable to tag SCM Provider message: The svn tag command failed. Command output: svn: Can't connect to host 'sid-repo.de': No connection could be made because the target machine actively refused it. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:314) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:151) at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239) at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:145) at hudson.maven.Maven3Builder.call(Maven3Builder.java:124) at hudson.maven.Maven3Builder.call(Maven3Builder.java:71) at hudson.remoting.UserRequest.perform(UserRequest.java:114) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:270) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: org.apache.maven.plugin.MojoFailureException: Unable to tag SCM Provider message: The svn tag command failed. Command output: svn: Can't connect to host 'sid-repo.de': No connection could be made because the target machine actively refused it. at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:219) at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:181) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) ... 27 more Caused by: org.apache.maven.shared.release.scm.ReleaseScmCommandException: Unable to tag SCM Provider message: The svn tag command failed. Command output: svn: Can't connect to host 'sid-repo.de': No connection could be made because the target machine actively refused it. at org.apache.maven.shared.release.phase.ScmTagPhase.execute(Sc
[jira] Created: (SUREFIRE-697) When the exception message is long or contains linefeeds, the summary display is not nice
When the exception message is long or contains linefeeds, the summary display
is not nice
-
Key: SUREFIRE-697
URL: http://jira.codehaus.org/browse/SUREFIRE-697
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Surefire Plugin
Affects Versions: 2.7.2
Reporter: Kristian Rosenvold
When the "message" of the exception is long (like Spring framework can do and
some backend systems) or contains some kind of multi-line text, the summary
display ("Failed tests"/"Tests with error") looks totally off. The message
shown in the display should probably be truncated to show only the first line
of the message text. I am not sure if it also should be truncated if it's very
long single-line, which should be considered when fixing this issue. This
problem was introduced with SUREFIRE-645 in 2.7.2
This is the display in question, but this testcase does not demonstrate the
long messages
Results :
Failed tests:
testiWithFail2(surefire613.Test2): We excpect this
testiWithFail4(surefire613.Test2): We excpect this
testiWithFail1(surefire613.Test2): We excpect this
testiWithFail3(surefire613.Test2): We excpect this
Tests in error:
testWithException8(surefire613.Test2): We expect this
testWithException7(surefire613.Test2): We expect this
testWithException6(surefire613.Test2): We expect this
testWithException5(surefire613.Test2): We expect this
testWithException4(surefire613.Test2): We expect this
testWithException3(surefire613.Test2): We expect this
testWithException2(surefire613.Test2): We expect this
testWithException1(surefire613.Test2): We expect this
--
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: (MRELEASE-647) Error on SVN tagging in Maven release
[ http://jira.codehaus.org/browse/MRELEASE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255060#action_255060 ] cforce commented on MRELEASE-647: - Tortoise checkout and copy from trunk to tags folder on server https://sid-repo.de/svn/e2etrace also works without porblems > Error on SVN tagging in Maven release > -- > > Key: MRELEASE-647 > URL: http://jira.codehaus.org/browse/MRELEASE-647 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Environment: Wiondows Server 2008, Tomcat 7, Jenkis 1.3.9.6 + Hudson > Maven Release Plug-in Plug-in 0.6.1, Maven 3 >Reporter: cforce > > Checking out from the scm (https://sid-repo.de/svn/e2etrace/trunk ) does work > and "regular" svn tag from hdsuon also, only tagging via mave release plugin > faults with following error. Tomcat is running on local user account not > system account. > The scm server is using a self signed certficate. > Manual Svn (SlikSVN 1.6.12 is installed) update from cmd prompt console as > local user in workspace does work without problems. > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 17.547s > [INFO] Finished at: Tue Feb 08 14:49:11 CET 2011 > [INFO] Final Memory: 14M/309M > [INFO] > > mavenExecutionResult exceptions not empty > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-release-plugin:2.0:prepare (default-cli) > on project e2etrace: Unable to tag SCM > Provider message: > The svn tag command failed. > Command output: > svn: Can't connect to host 'sid-repo.de': No connection could be made because > the target machine actively refused it. > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:314) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:151) > at > org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239) > at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:145) > at hudson.maven.Maven3Builder.call(Maven3Builder.java:124) > at hudson.maven.Maven3Builder.call(Maven3Builder.java:71) > at hudson.remoting.UserRequest.perform(UserRequest.java:114) > at hudson.remoting.UserRequest.perform(UserRequest.java:48) > at hudson.remoting.Request$2.run(Request.java:270) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:619) > Caused by: org.apache.maven.plugin.MojoFailureException: Unable to tag SCM > Provider message: > The svn tag command failed. > Command output: > svn: Can't connect to host 'sid-repo.de': No connection could be made because > the target machine actively refused it. > at > org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:219) > at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:181) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.jav
[jira] Created: (MNG-5006) M3 attempts to get released parent pom from snapshot repository when a dependency has range
M3 attempts to get released parent pom from snapshot repository when a dependency has range --- Key: MNG-5006 URL: http://jira.codehaus.org/browse/MNG-5006 Project: Maven 2 & 3 Issue Type: Bug Affects Versions: 3.0.2 Environment: WinXP SP3, Java 6u20 Reporter: Kristoffer Peterhäesel Attachments: mvn-verify-fixed-version.log, mvn-verify-range-version.log I have a bit of a strange issue. When running under Maven 3.0.2 I am getting build errors when I try to build one of our projects when one of their dependencies have a range version. But when setting it to a specific version it seems to work. The same project works without a hitch in Maven 2.2.1. As can be seen from the first included verbose trace (mvn-verify-range-version.log). Maven attempts to get the pom from our snapshot repository. That will, obviously, not work for a released artefact. Changing the dependency version from the [1,2) range to 1.0.1-SNAPSHOT seems to skip that step completely. Even though it resolves to the same version in the end. As seen in the other verbose trace (mvn-verify-fixed-version.log) -- 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-226) issueLinkTemplatePerSystem does not work
[
http://jira.codehaus.org/browse/MCHANGES-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255069#action_255069
]
Myron commented on MCHANGES-226:
Thanks for your patience - it was a clear layer8 problem.
It is working now with this sample, and i know what to do. (and what I've
should have done)
We recently switched to maven (2, then 3 shortly after) and i only checked the
page till the compatibility matrix.
All other reports i added worked "the old way", so it didn't come to my mind
that my setup was _that_ false for this plugin
lesson learned.
> issueLinkTemplatePerSystem does not work
>
>
> Key: MCHANGES-226
> URL: http://jira.codehaus.org/browse/MCHANGES-226
> Project: Maven 2.x Changes Plugin
> Issue Type: Bug
> Components: changes.xml
>Affects Versions: 2.4
>Reporter: Myron
>Assignee: Dennis Lundberg
>Priority: Minor
> Attachments: MCHANGES-226.zip, MCHANGES-226.zip
>
>
> Sorry, i don't get it.
> i try to add/config my own tracking system.
> {quote}
>
> testtesttest
> http://somehost.com/project/dashboard
>
> {quote}
> but i cant use the %URL%, i specify this absolute in the plugin section.
> {quote}
>
>
>
> http://somehost.com/items?query=%ISSUE%
>
>
> {quote}
> in my changes.xml, the system is also testtesttest.
> Tried everything, but i dont get links.
> if i use
> {quote}
> http://somehost.com/items?query=%ISSUE%
> {quote}
> and "default" in changes.xml i DO get links, but always with the default
> value (regardless whats specified)
> {quote}[DEBUG] (f) issueLinkTemplate =
> %URL%/ViewIssue.jspa?key=%ISSUE%{quote}
> if i specify f. ex. "SourceForge" in changes.xml, the links work
> out-of-the-box
> tried also old suggestions like MCHANGES-166 - no success.
--
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-5006) M3 attempts to get released parent pom from snapshot repository when a dependency has range
[ http://jira.codehaus.org/browse/MNG-5006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255075#action_255075 ] Kristoffer Peterhäesel commented on MNG-5006: - I forgot to mention one thing - since it is not obvious. But in this case it seems to be the parent of the dependency with the version range (coreapis in this case) that is being checked. Not the parent of the project we are running maven against. > M3 attempts to get released parent pom from snapshot repository when a > dependency has range > --- > > Key: MNG-5006 > URL: http://jira.codehaus.org/browse/MNG-5006 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.2 > Environment: WinXP SP3, Java 6u20 >Reporter: Kristoffer Peterhäesel > Attachments: mvn-verify-fixed-version.log, > mvn-verify-range-version.log > > > I have a bit of a strange issue. When running under Maven 3.0.2 I am getting > build errors when I try to build one of our projects when one of their > dependencies have a range version. But when setting it to a specific version > it seems to work. The same project works without a hitch in Maven 2.2.1. > As can be seen from the first included verbose trace > (mvn-verify-range-version.log). Maven attempts to get the pom from our > snapshot repository. That will, obviously, not work for a released artefact. > Changing the dependency version from the [1,2) range to 1.0.1-SNAPSHOT seems > to skip that step completely. Even though it resolves to the same version in > the end. As seen in the other verbose trace (mvn-verify-fixed-version.log) -- 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: (MANTRUN-86) Cannot handle multiple tasks elements
[
http://jira.codehaus.org/browse/MANTRUN-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255078#action_255078
]
Steffl commented on MANTRUN-86:
---
Pleas re-open this since it is really pain in the a*** to do all this
workarround just to decide which target should be executed. It costs me 3 hours
until now! And what I got is unreadable, crazy configurations. And I'am not the
only one. It could be so easy:
You mentioned, the reason why you won't fix is because you "believe the logic
for deciding which tasks to run doesn't belong in the antrun plugin". OK, but
there is already logic support for the "if" and "unless" attributes on a single
element. In my opinion, this is not consequently enough. Either you
drop support for these attributes completely or you support multimple target
elements (I would prefer).
Please re-think. Thanks a lot.
> Cannot handle multiple tasks elements
> -
>
> Key: MANTRUN-86
> URL: http://jira.codehaus.org/browse/MANTRUN-86
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Thomas Diesler
>Assignee: Paul Gier
>
> {code:xml}
>
> maven-antrun-plugin
>
>
> install
>
> run
>
>
>
>
>value="${jboss.local.repository}"/>
>
>
>
>
>
>
>
>
>
> {code}
> Always executes the last tasks element although 'jboss.local.repository' is
> set
> [INFO] [antrun:run {execution: default}]
> [INFO] Executing tasks
> [echo] Cannot install to
> jboss.local.repository=/home/tdiesler/svn/jboss.local.repository
> [INFO] Executed tasks
--
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-5006) M3 attempts to get released parent pom from snapshot repository when a dependency has range
[ http://jira.codehaus.org/browse/MNG-5006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristoffer Peterhäesel updated MNG-5006: Attachment: mvn-verify-offline.log Just tried to do the same with the -o option. And interestingly enough it appears to still try to validate the masterproject pom against the snapshot repository. And it still fails with the 'excuse' that is cannot resolve it. Hard to accept since it finds it just fine as the parent of the project of the pom maven is running against - or it would fail much sooner. > M3 attempts to get released parent pom from snapshot repository when a > dependency has range > --- > > Key: MNG-5006 > URL: http://jira.codehaus.org/browse/MNG-5006 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.2 > Environment: WinXP SP3, Java 6u20 >Reporter: Kristoffer Peterhäesel > Attachments: mvn-verify-fixed-version.log, mvn-verify-offline.log, > mvn-verify-range-version.log > > > I have a bit of a strange issue. When running under Maven 3.0.2 I am getting > build errors when I try to build one of our projects when one of their > dependencies have a range version. But when setting it to a specific version > it seems to work. The same project works without a hitch in Maven 2.2.1. > As can be seen from the first included verbose trace > (mvn-verify-range-version.log). Maven attempts to get the pom from our > snapshot repository. That will, obviously, not work for a released artefact. > Changing the dependency version from the [1,2) range to 1.0.1-SNAPSHOT seems > to skip that step completely. Even though it resolves to the same version in > the end. As seen in the other verbose trace (mvn-verify-fixed-version.log) -- 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: (MSHADE-92) Annotated Method Parameters Not Shaded
Annotated Method Parameters Not Shaded
--
Key: MSHADE-92
URL: http://jira.codehaus.org/browse/MSHADE-92
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.4
Environment: JDK 1.6.0r21
Reporter: Greg Wittel
When shading a function or constructor like
@JsonCreator
public MyClass(@JsonProperty("blah") String blah) {
}
The @JsonProperty annotation is not shaded. I decompiled the resulting .class
file and you see '@JsonCreator' is properly shaded, while @JsonProperty is not.
This is probably related to MSHADE-79.
--
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-4211) [regression] proxy access broken between maven version 2.0.10 and 2.1. Probably due to addition of wagon 1.0-beta-4+
[ http://jira.codehaus.org/browse/MNG-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255276#action_255276 ] Robert Glover Jr commented on MNG-4211: --- By good luck, an associate of mine seems to have located the specific reason why Maven firewall "broke" (for some of us) when Maven 2.1.0 was released. The problem can be seen if a debugging proxy is used to intercept and examine the request header that is sent outbound from Maven 2.1.0. In earlier versions the request header simply stated the java version. However the request header sent by Maven 2.1.0 says something to the effect of "Maven Apache.. etc.". If a debugging proxy is used to change the text of the request head back to what it was in Maven 2.0.9 and earlier, the problem with the firewall disappears and Maven 2.1.0 works again through a firewall. So, this sounds like it should be almost trivially simple for the Maven developers to "fix" so as to provide backwards compatibility in Maven 2.1.0 and above. I.e., add an option to send the same request header that Maven was sending in Maven 2.0.9 and earlier. I hope someone on the Maven developer team reads this and can implement a quick fix. It is so frustrating to be forced to use Maven 2.0.9 instead of all the goodness in Maven 2.1.0, not to mention Maven 3. > [regression] proxy access broken between maven version 2.0.10 and 2.1. > Probably due to addition of wagon 1.0-beta-4+ > - > > Key: MNG-4211 > URL: http://jira.codehaus.org/browse/MNG-4211 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.1.0, 2.2.0 > Environment: WinXP SP2 >Reporter: Robert Glover Jr >Priority: Blocker > Fix For: Issues to be reviewed for 3.x > > Attachments: jira_files_4_total.zip > > > At a large company, maven become impossible to use via proxy when maven > upgraded from 1.0.10 to 2.1. maven has always worked fine via proxy in 2.0.9 > and continues to work fine. however maven via proxy always fails in version > 2.1.0 and higher. > Attached is a zip file containing 1) log of GMAIL chat between the > creater of this JIRA and a maven developer. 2) two console outputs of > running maven 2.2. RC3 showing the proxy failure messages. 3) setting.xml > (with comments stripped out) -- 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-4211) [regression] proxy access broken between maven version 2.0.10 and 2.1. Probably due to addition of wagon 1.0-beta-4+
[
http://jira.codehaus.org/browse/MNG-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255284#action_255284
]
Benjamin Bentmann commented on MNG-4211:
Thanks for the info, the change in user agent is due to MNG-3652. You could try
the [advanced HTTP
config|http://maven.apache.org/guides/mini/guide-http-settings.html] to force
another agent or in Maven3 add {{-Daether.connector.userAgent=desired-agent}}
to your {{MAVEN_OPTS}}. But in the long run, you should probably talk to the
firewall maintainer to allow the Maven's requests to pass through, with their
original user agent info.
> [regression] proxy access broken between maven version 2.0.10 and 2.1.
> Probably due to addition of wagon 1.0-beta-4+
> -
>
> Key: MNG-4211
> URL: http://jira.codehaus.org/browse/MNG-4211
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.1.0, 2.2.0
> Environment: WinXP SP2
>Reporter: Robert Glover Jr
>Priority: Blocker
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: jira_files_4_total.zip
>
>
> At a large company, maven become impossible to use via proxy when maven
> upgraded from 1.0.10 to 2.1. maven has always worked fine via proxy in 2.0.9
> and continues to work fine. however maven via proxy always fails in version
> 2.1.0 and higher.
> Attached is a zip file containing 1) log of GMAIL chat between the
> creater of this JIRA and a maven developer. 2) two console outputs of
> running maven 2.2. RC3 showing the proxy failure messages. 3) setting.xml
> (with comments stripped out)
--
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: (MANTRUN-86) Cannot handle multiple tasks elements
[
http://jira.codehaus.org/browse/MANTRUN-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255286#action_255286
]
Paul Gier commented on MANTRUN-86:
--
Can you use multiple antrun executions? I would think this will accomplish the
same thing.
If that doesn't work for you, the best thing is probably to create a new jira
issue and attach a patch.
> Cannot handle multiple tasks elements
> -
>
> Key: MANTRUN-86
> URL: http://jira.codehaus.org/browse/MANTRUN-86
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Thomas Diesler
>Assignee: Paul Gier
>
> {code:xml}
>
> maven-antrun-plugin
>
>
> install
>
> run
>
>
>
>
>value="${jboss.local.repository}"/>
>
>
>
>
>
>
>
>
>
> {code}
> Always executes the last tasks element although 'jboss.local.repository' is
> set
> [INFO] [antrun:run {execution: default}]
> [INFO] Executing tasks
> [echo] Cannot install to
> jboss.local.repository=/home/tdiesler/svn/jboss.local.repository
> [INFO] Executed tasks
--
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-4211) [regression] proxy access broken between maven version 2.0.10 and 2.1. Probably due to addition of wagon 1.0-beta-4+
[ http://jira.codehaus.org/browse/MNG-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255293#action_255293 ] Robert Glover Jr commented on MNG-4211: --- I asked my associated to review the comment I made above, and he replied, "The biggest problem with your description is that you keep calling it "the request header". It is the user-agent header and you should make that clear." So please, when reading the comment above think "user-agent" whenever you see "request header". > [regression] proxy access broken between maven version 2.0.10 and 2.1. > Probably due to addition of wagon 1.0-beta-4+ > - > > Key: MNG-4211 > URL: http://jira.codehaus.org/browse/MNG-4211 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.1.0, 2.2.0 > Environment: WinXP SP2 >Reporter: Robert Glover Jr >Priority: Blocker > Fix For: Issues to be reviewed for 3.x > > Attachments: jira_files_4_total.zip > > > At a large company, maven become impossible to use via proxy when maven > upgraded from 1.0.10 to 2.1. maven has always worked fine via proxy in 2.0.9 > and continues to work fine. however maven via proxy always fails in version > 2.1.0 and higher. > Attached is a zip file containing 1) log of GMAIL chat between the > creater of this JIRA and a maven developer. 2) two console outputs of > running maven 2.2. RC3 showing the proxy failure messages. 3) setting.xml > (with comments stripped out) -- 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: (MANTRUN-160) maven-antrun-plugin 1.6 does not respect mvn --quiet option
[ http://jira.codehaus.org/browse/MANTRUN-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MANTRUN-160: -- Fix Version/s: 1.7 Assignee: Paul Gier > maven-antrun-plugin 1.6 does not respect mvn --quiet option > --- > > Key: MANTRUN-160 > URL: http://jira.codehaus.org/browse/MANTRUN-160 > Project: Maven 2.x Antrun Plugin > Issue Type: Bug >Affects Versions: 1.6 > Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 21:58:32+1100) > Java version: 1.6.0_22 > Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre > Default locale: en_AU, platform encoding: UTF-8 > OS name: "linux" version: "2.6.35-23-generic" arch: "amd64" Family: "unix" >Reporter: Ben Alex >Assignee: Paul Gier >Priority: Minor > Fix For: 1.7 > > Attachments: patch.diff > > > I use mvn -q to perform my builds, as it greatly reduces the verbosity of > output. At present maven-antrun-plugin v 1.6 does not respect the "mvn -q" > option. Here is an example of the output of an Antrun task that includes > directory deletion and file copying: >[delete] Deleting directory > /home/balex/projects/roo/annotations/src/main/java/org > [copy] Copying 19 files to > /home/balex/projects/roo/annotations/src/main/java > Attached is a patch that observes the mvn -q behavior. When in mvn -q, only > errors are emitted. The above informational output level messages are > therefore not display (the desired behavior). -- 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: (MANTRUN-160) maven-antrun-plugin 1.6 does not respect mvn --quiet option
[ http://jira.codehaus.org/browse/MANTRUN-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MANTRUN-160. - Resolution: Fixed Fixed in [r1068495|http://svn.apache.org/viewvc?view=revision&revision=1068495]. > maven-antrun-plugin 1.6 does not respect mvn --quiet option > --- > > Key: MANTRUN-160 > URL: http://jira.codehaus.org/browse/MANTRUN-160 > Project: Maven 2.x Antrun Plugin > Issue Type: Bug >Affects Versions: 1.6 > Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 21:58:32+1100) > Java version: 1.6.0_22 > Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre > Default locale: en_AU, platform encoding: UTF-8 > OS name: "linux" version: "2.6.35-23-generic" arch: "amd64" Family: "unix" >Reporter: Ben Alex >Assignee: Paul Gier >Priority: Minor > Fix For: 1.7 > > Attachments: patch.diff > > > I use mvn -q to perform my builds, as it greatly reduces the verbosity of > output. At present maven-antrun-plugin v 1.6 does not respect the "mvn -q" > option. Here is an example of the output of an Antrun task that includes > directory deletion and file copying: >[delete] Deleting directory > /home/balex/projects/roo/annotations/src/main/java/org > [copy] Copying 19 files to > /home/balex/projects/roo/annotations/src/main/java > Attached is a patch that observes the mvn -q behavior. When in mvn -q, only > errors are emitted. The above informational output level messages are > therefore not display (the desired behavior). -- 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-4211) [regression] proxy access broken between maven version 2.0.10 and 2.1. Probably due to addition of wagon 1.0-beta-4+
[ http://jira.codehaus.org/browse/MNG-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255304#action_255304 ] Robert Glover Jr commented on MNG-4211: --- Benjamin, my associate took a look at your response and especially the link you provided: http://maven.apache.org/guides/mini/guide-http-settings.html His reply indicates to me that it would be incredibly helpful if you could provide a a simple step-by-step explanation on how to change the user agent header-- ideally in your next comment here. (Hopeful, wistful smile). Here are my associates's 2 comments: First comment: Unfortunately it doesn't say anything about the user agent header. And the whole thing is pretty confusing. Second comment in a subsequent email: I re-read it and tried again to follow the instructions but was unsuccessful. The user agent doesn't change. > [regression] proxy access broken between maven version 2.0.10 and 2.1. > Probably due to addition of wagon 1.0-beta-4+ > - > > Key: MNG-4211 > URL: http://jira.codehaus.org/browse/MNG-4211 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.1.0, 2.2.0 > Environment: WinXP SP2 >Reporter: Robert Glover Jr >Priority: Blocker > Fix For: Issues to be reviewed for 3.x > > Attachments: jira_files_4_total.zip > > > At a large company, maven become impossible to use via proxy when maven > upgraded from 1.0.10 to 2.1. maven has always worked fine via proxy in 2.0.9 > and continues to work fine. however maven via proxy always fails in version > 2.1.0 and higher. > Attached is a zip file containing 1) log of GMAIL chat between the > creater of this JIRA and a maven developer. 2) two console outputs of > running maven 2.2. RC3 showing the proxy failure messages. 3) setting.xml > (with comments stripped out) -- 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: (MASSEMBLY-545) While loading multiple Filter files, already known filter values are not applied (see MSHARED-177)
[ http://jira.codehaus.org/browse/MASSEMBLY-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MASSEMBLY-545. - Resolution: Fixed Assignee: Dennis Lundberg > While loading multiple Filter files, already known filter values are not > applied (see MSHARED-177) > -- > > Key: MASSEMBLY-545 > URL: http://jira.codehaus.org/browse/MASSEMBLY-545 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Reporter: Daniel Mohni >Assignee: Dennis Lundberg > Fix For: 2.2.1 > > > Fix has been submitted to maven-filtering project. > MASSEMBLY shoud update to new version as soon it is released -- 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: (MANTTASKS-206) dependecies task overrides custom definition of 'central' repository
[ http://jira.codehaus.org/browse/MANTTASKS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MANTTASKS-206: Fix Version/s: 2.1.2 Assignee: Paul Gier > dependecies task overrides custom definition of 'central' repository > > > Key: MANTTASKS-206 > URL: http://jira.codehaus.org/browse/MANTTASKS-206 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Miroslaw Michalski >Assignee: Paul Gier > Fix For: 2.1.2 > > Attachments: patch2.txt > > > While using >cacheDependencyRefs="false" > pathId="maven.dependency.classpath" > useScope="test"> > > > with pom > > ... > > > central > https://custom/mvn/central > > true > > > true > > > > > the task is still trying to resolve my dependecies from > http://repo2.maven.org/maven2. > A patch resolving this issue is attached. -- 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-206) dependecies task overrides custom definition of 'central' repository
[ http://jira.codehaus.org/browse/MANTTASKS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MANTTASKS-206. --- Resolution: Fixed Patch applied in [r1068543|http://svn.apache.org/viewvc?view=revision&revision=1068543]. > dependecies task overrides custom definition of 'central' repository > > > Key: MANTTASKS-206 > URL: http://jira.codehaus.org/browse/MANTTASKS-206 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Miroslaw Michalski >Assignee: Paul Gier > Fix For: 2.1.2 > > Attachments: patch2.txt > > > While using >cacheDependencyRefs="false" > pathId="maven.dependency.classpath" > useScope="test"> > > > with pom > > ... > > > central > https://custom/mvn/central > > true > > > true > > > > > the task is still trying to resolve my dependecies from > http://repo2.maven.org/maven2. > A patch resolving this issue is attached. -- 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: (MANTTASKS-208) Change ant groupId to org.apache.ant
[ http://jira.codehaus.org/browse/MANTTASKS-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MANTTASKS-208: Priority: Minor (was: Major) Fix Version/s: 2.1.2 Assignee: Paul Gier > Change ant groupId to org.apache.ant > > > Key: MANTTASKS-208 > URL: http://jira.codehaus.org/browse/MANTTASKS-208 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Orion Poplawski >Assignee: Paul Gier >Priority: Minor > Fix For: 2.1.2 > > Attachments: maven-ant-tasks-2.1.1-ant-groupId.patch > > > The groupId for ant is org.apache.ant. The attached patch fixes. -- 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-208) Change ant groupId to org.apache.ant
[ http://jira.codehaus.org/browse/MANTTASKS-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MANTTASKS-208. --- Resolution: Won't Fix This particular IT requires Ant 1.6. Newer versions of Ant use the groupId "org.apache.ant", but Ant 1.6 and earlier use the groupId "ant". Applying the patch breaks the IT (mvn install -Prun-its) because the build can no longer find Ant 1.6. > Change ant groupId to org.apache.ant > > > Key: MANTTASKS-208 > URL: http://jira.codehaus.org/browse/MANTTASKS-208 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Orion Poplawski >Assignee: Paul Gier >Priority: Minor > Fix For: 2.1.2 > > Attachments: maven-ant-tasks-2.1.1-ant-groupId.patch > > > The groupId for ant is org.apache.ant. The attached patch fixes. -- 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-4211) [regression] proxy access broken between maven version 2.0.10 and 2.1. Probably due to addition of wagon 1.0-beta-4+
[ http://jira.codehaus.org/browse/MNG-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255331#action_255331 ] Robert Glover Jr commented on MNG-4211: --- Here are specific details for this problem, as forwarded by my associate a few minutes ago: Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400) Java version: 1.6.0_21 Default locale: en_US, platform encoding: Cp1252 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" Failing user agent: Apache-Maven/2.2 (Java 1.6.0_21; Windows XP 5.1) maven-artifact/2.2.1 Successful user agent: Java/1.6.0_21 > [regression] proxy access broken between maven version 2.0.10 and 2.1. > Probably due to addition of wagon 1.0-beta-4+ > - > > Key: MNG-4211 > URL: http://jira.codehaus.org/browse/MNG-4211 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.1.0, 2.2.0 > Environment: WinXP SP2 >Reporter: Robert Glover Jr >Priority: Blocker > Fix For: Issues to be reviewed for 3.x > > Attachments: jira_files_4_total.zip > > > At a large company, maven become impossible to use via proxy when maven > upgraded from 1.0.10 to 2.1. maven has always worked fine via proxy in 2.0.9 > and continues to work fine. however maven via proxy always fails in version > 2.1.0 and higher. > Attached is a zip file containing 1) log of GMAIL chat between the > creater of this JIRA and a maven developer. 2) two console outputs of > running maven 2.2. RC3 showing the proxy failure messages. 3) setting.xml > (with comments stripped out) -- 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-4211) [regression] proxy access broken between maven version 2.0.10 and 2.1. Probably due to addition of wagon 1.0-beta-4+
[ http://jira.codehaus.org/browse/MNG-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255332#action_255332 ] Robert Glover Jr commented on MNG-4211: --- My associate tells me that adding to the folowing to settings.xml fixes the problem. Hooray! nexus httpclient User-Agent Java/1.6.0_21 > [regression] proxy access broken between maven version 2.0.10 and 2.1. > Probably due to addition of wagon 1.0-beta-4+ > - > > Key: MNG-4211 > URL: http://jira.codehaus.org/browse/MNG-4211 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.1.0, 2.2.0 > Environment: WinXP SP2 >Reporter: Robert Glover Jr >Priority: Blocker > Fix For: Issues to be reviewed for 3.x > > Attachments: jira_files_4_total.zip > > > At a large company, maven become impossible to use via proxy when maven > upgraded from 1.0.10 to 2.1. maven has always worked fine via proxy in 2.0.9 > and continues to work fine. however maven via proxy always fails in version > 2.1.0 and higher. > Attached is a zip file containing 1) log of GMAIL chat between the > creater of this JIRA and a maven developer. 2) two console outputs of > running maven 2.2. RC3 showing the proxy failure messages. 3) setting.xml > (with comments stripped out) -- 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: (MWAR-248) Plugin warns about missing webxml attribute even if one exists
Plugin warns about missing webxml attribute even if one exists -- Key: MWAR-248 URL: http://jira.codehaus.org/browse/MWAR-248 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1.1 Reporter: Gili Attachments: debug.log I am attaching a debug log that clearly demonstrates how the WAR plugin warns about a missing webxml attribute which exists. I am attempting to let the plugin know that the web.xml file it is encountering is the same one specified by the webxml attribute. My pom file contains: org.apache.maven.plugins maven-war-plugin 2.1.1 true src/main/webapp/WEB-INF/web.xml -- 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-679) Test directories should not be exported to other projects/modules
Test directories should not be exported to other projects/modules - Key: MECLIPSE-679 URL: http://jira.codehaus.org/browse/MECLIPSE-679 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Reporter: Sean Flanigan For consistency with Maven dependency rules, the contents of src/test/java and src/test/resources should not be exported to the classpath of dependent projects. (This is handy for files like log4j.xml where a particularly verbose configuration might only make sense when testing the project itself.) In Eclipse, it's probably not possible to achieve this for a source folder like src/test/java (source folders are always exported), but at least src/test/resources could be added to the classpath as a class folder, rather than a source folder. It's probably best if this is optional, because you can't exclude **/*.java from a class folder, as you can for a source folder. It must be rare to put .java files in src/test/resources, but I'm sure they're out there! -- 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-679) Test directories should not be exported to other projects/modules
[
http://jira.codehaus.org/browse/MECLIPSE-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255359#action_255359
]
Sean Flanigan commented on MECLIPSE-679:
That should say "you can't exclude {{\*\*/\*.java}} from a class folder".
> Test directories should not be exported to other projects/modules
> -
>
> Key: MECLIPSE-679
> URL: http://jira.codehaus.org/browse/MECLIPSE-679
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
> (.classpath)
>Reporter: Sean Flanigan
>
> For consistency with Maven dependency rules, the contents of src/test/java
> and src/test/resources should not be exported to the classpath of dependent
> projects. (This is handy for files like log4j.xml where a particularly
> verbose configuration might only make sense when testing the project itself.)
> In Eclipse, it's probably not possible to achieve this for a source folder
> like src/test/java (source folders are always exported), but at least
> src/test/resources could be added to the classpath as a class folder, rather
> than a source folder.
> It's probably best if this is optional, because you can't exclude **/*.java
> from a class folder, as you can for a source folder. It must be rare to put
> .java files in src/test/resources, but I'm sure they're out there!
--
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: (MPOM-1) apache-release does unwanted things in the prepare goal
[ https://issues.apache.org/jira/browse/MPOM-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox reopened MPOM-1: -- This needs a different approach. If people don't want to use the profile by default, then lets put the profile argument into a property that can easily be overridden. It is very important though that we have proper release proceedures embodied by default in the ASF pom. People shouldn't have to customize sections of their poms to get proper releases. As it was done in the previous release, it "just works" > apache-release does unwanted things in the prepare goal > --- > > Key: MPOM-1 > URL: https://issues.apache.org/jira/browse/MPOM-1 > Project: Maven POM > Issue Type: Bug >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: ASF-9 > > > Release 7 of the org.apache:apache use -P to turn on an 'apache-release' > profile in the release plugin. By using -P, this profile is turned on in > prepare as well as perform. > This may turn into a contest of opinion, and you all may just tell me to jump > in a lake, but I think this is a bad idea. At prepare time, we're just > looking to get the versions setup and the tag made. Having to deal with gpg > signing, and source archiving seems out of place. > At very least, I'd request that this the element be left out of > the release plugin spec. If some project wants to use that particular > collection of functions, fine. For the rest of us, who just want to get > distribution management and other universals, you we wouldn't have to worry > about it. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-248) Plugin warns about missing webxml attribute even if one exists
[ http://jira.codehaus.org/browse/MWAR-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255366#action_255366 ] Gili commented on MWAR-248: --- It is worth noting that version 2.1 does not issue this warning message. This problem only occurs in version 2.1.1 and newer. > Plugin warns about missing webxml attribute even if one exists > -- > > Key: MWAR-248 > URL: http://jira.codehaus.org/browse/MWAR-248 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Gili > Attachments: debug.log > > > I am attaching a debug log that clearly demonstrates how the WAR plugin warns > about a missing webxml attribute which exists. I am attempting to let the > plugin know that the web.xml file it is encountering is the same one > specified by the webxml attribute. > My pom file contains: > > org.apache.maven.plugins > maven-war-plugin > 2.1.1 > > true > src/main/webapp/WEB-INF/web.xml > > -- 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-235) The web.xml file included twice into the result war
[ http://jira.codehaus.org/browse/MWAR-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255390#action_255390 ] Stephane Nicoll commented on MWAR-235: -- Dennis, can you have a look to MWAR-248? It sounds like a possible regression due to this change. > The web.xml file included twice into the result war > --- > > Key: MWAR-235 > URL: http://jira.codehaus.org/browse/MWAR-235 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: WinXP 32bit sp3, sun JDK .6.0.20, maven 2.2.1 >Reporter: Siarhei_Yarkavy >Assignee: Dennis Lundberg >Priority: Critical > Fix For: 2.1.1 > > Attachments: asmModule.zip, MWAR-235-test.patch, pom.xml, > screenshot.jpg, WarArchiver.java.patch > > > Please have a look to the attached demo project and screen-shot -- 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
