[jira] (MNG-5424) Direction invocation goal can be invoked in a pom
[ https://jira.codehaus.org/browse/MNG-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tony Chemit updated MNG-5424: - Component/s: (was: Plugin Requests) Plugins and Lifecycle > Direction invocation goal can be invoked in a pom > - > > Key: MNG-5424 > URL: https://jira.codehaus.org/browse/MNG-5424 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.4 >Reporter: Tony Chemit > Attachments: MNG-5424.zip > > > Since maven 3 (at least 3.0.4 and 3.1.0) > A mojo annotated as directionInvocation to true can be invoked in a pom. > the plugin.ml is well generated but at runtime no error occurs if goal is > executed form a pom. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5424) Direction invocation goal can be invoked in a pom
[ https://jira.codehaus.org/browse/MNG-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317460#comment-317460 ] Tony Chemit edited comment on MNG-5424 at 1/17/13 1:23 AM: --- Little project with 2 its (one using maven 2.2.1 and one using maven 3). Under maven 2.2.1, it is ok (fails at end), but not when using maven 3. was (Author: tchemit): Little project with tow its (one using maven 2.2.1 and one using maven 3). Under maven 2.2.1, it is ok (fails at end), but not when using maven 3. > Direction invocation goal can be invoked in a pom > - > > Key: MNG-5424 > URL: https://jira.codehaus.org/browse/MNG-5424 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.4 >Reporter: Tony Chemit > Attachments: MNG-5424.zip > > > Since maven 3 (at least 3.0.4 and 3.1.0) > A mojo annotated as directionInvocation to true can be invoked in a pom. > the plugin.ml is well generated but at runtime no error occurs if goal is > executed form a pom. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5424) Direction invocation goal can be invoked in a pom
[ https://jira.codehaus.org/browse/MNG-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tony Chemit updated MNG-5424: - Attachment: MNG-5424.zip Little project with tow its (one using maven 2.2.1 and one using maven 3). Under maven 2.2.1, it is ok (fails at end), but not when using maven 3. > Direction invocation goal can be invoked in a pom > - > > Key: MNG-5424 > URL: https://jira.codehaus.org/browse/MNG-5424 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.4 >Reporter: Tony Chemit > Attachments: MNG-5424.zip > > > Since maven 3 (at least 3.0.4 and 3.1.0) > A mojo annotated as directionInvocation to true can be invoked in a pom. > the plugin.ml is well generated but at runtime no error occurs if goal is > executed form a pom. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5424) Direction invocation goal can be invoked in a pom
Tony Chemit created MNG-5424: Summary: Direction invocation goal can be invoked in a pom Key: MNG-5424 URL: https://jira.codehaus.org/browse/MNG-5424 Project: Maven 2 & 3 Issue Type: Bug Components: Plugin Requests Affects Versions: 3.0.4 Reporter: Tony Chemit Since maven 3 (at least 3.0.4 and 3.1.0) A mojo annotated as directionInvocation to true can be invoked in a pom. the plugin.ml is well generated but at runtime no error occurs if goal is executed form a pom. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[ https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317454#comment-317454 ] Andrei Pozolotin commented on MRELEASE-812: --- Robert: thank you for looking into this; here is a test case: 1) repo to clone https://github.com/barchart/barchart-bugs 2) project with v 2.3.2, which works https://github.com/barchart/barchart-bugs/tree/master/barchart-bugs-MRELEASE-812/build-tester/barchart-bugs-MRELEASE-812-case-01 and maven log https://raw.github.com/barchart/barchart-bugs/master/barchart-bugs-MRELEASE-812/build-tester/barchart-bugs-MRELEASE-812-case-01/doc/mvn.log.txt run from eclipse: https://github.com/barchart/barchart-bugs/blob/master/barchart-bugs-MRELEASE-812/build-tester/barchart-bugs-MRELEASE-812-case-01/build/maven-release.ant 3) project with v 2.4, which is broken https://github.com/barchart/barchart-bugs/tree/master/barchart-bugs-MRELEASE-812/build-tester/barchart-bugs-MRELEASE-812-case-02 and maven log https://raw.github.com/barchart/barchart-bugs/master/barchart-bugs-MRELEASE-812/build-tester/barchart-bugs-MRELEASE-812-case-02/doc/mvn.log.txt run from eclipse: https://github.com/barchart/barchart-bugs/blob/master/barchart-bugs-MRELEASE-812/build-tester/barchart-bugs-MRELEASE-812-case-02/build/maven-release.ant thank you. Andrei. > "prepare" does not commit before tagging and therefore deploys snapshot > instead of release > -- > > Key: MRELEASE-812 > URL: https://jira.codehaus.org/browse/MRELEASE-812 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: Git >Affects Versions: 2.4 >Reporter: Andrei Pozolotin >Priority: Critical > Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt > > > thank you very much for new release! > http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E > it seems we need an emergency fix: > attached are 2 logs: > 1) mvn-2.3.2.txt invocation that works fine with 2.3.2 > 2) mvn-2.4.0.txt invocation that fails with 2.4 > problem: > "perform" does not commit tags, deploys snapshot instead of release > here is project parent: > http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom > build is invoked both times with this: > mvn --define resume=false release:prepare > mvn --define resume=false release:perform -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-552) No such command 'add' using Clearcase adaptor when performing release:prepare-with-pom
[
https://jira.codehaus.org/browse/SCM-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317445#comment-317445
]
Robert Scholte commented on SCM-552:
{quote}And ideally, I do not want maven to automatically check in the generated
files{quote}
In that case you should run the release-plugin with the {{prepare}}-goal.
> No such command 'add' using Clearcase adaptor when performing
> release:prepare-with-pom
> --
>
> Key: SCM-552
> URL: https://jira.codehaus.org/browse/SCM-552
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-clearcase
> Environment: Windows XP, running Clearcase 7, Java 1.6.
>Reporter: Jason Lee
>
> When preparing the release using {{release:prepare-with-pom}}, the process
> can not be completed as it seems to try to add the generated
> {{release-pom.xml}} into clearcase, but received an error 'No such command
> 'add' '
> From the SCM matrix, it appears that this operation is valid. And ideally, I
> do not want maven to automatically check in the generated files.
> Below is the generated trace:
> {noformat}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Cannot add release POM to SCM: No such command 'add'.
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Cannot add release
> POM t
> o SCM: No such command 'add'.
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone
> Goal(DefaultLifecycleExecutor.java:569)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
> ltLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
> dleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
> ts(DefaultLifecycleExecutor.java:284)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
> fecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:6
> 0)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Cannot add release
> PO
> M to SCM: No such command 'add'.
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(Pr
> epareReleaseMojo.java:215)
> at
> org.apache.maven.plugins.release.PrepareWithPomReleaseMojo.execute(Pr
> epareWithPomReleaseMojo.java:48)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Cannot
> add
> release POM to SCM: No such command 'add'.
> at
> org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.addRel
> easePomsToScm(GenerateReleasePomsPhase.java:199)
> at
> org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.genera
> teReleasePoms(GenerateReleasePomsPhase.java:132)
> at
> org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.execut
> e(GenerateReleasePomsPhase.java:105)
> at
> org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.execut
> e(GenerateReleasePomsPhase.java:92)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
> ReleaseManager.java:203)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
> ReleaseManager.java:140)
>
[jira] (SCM-552) No such command 'add' using Clearcase adaptor when performing release:prepare-with-pom
[
https://jira.codehaus.org/browse/SCM-552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-552:
---
Component/s: (was: maven-plugin)
maven-scm-provider-clearcase
Description:
When preparing the release using {{release:prepare-with-pom}}, the process can
not be completed as it seems to try to add the generated {{release-pom.xml}}
into clearcase, but received an error 'No such command 'add' '
>From the SCM matrix, it appears that this operation is valid. And ideally, I
>do not want maven to automatically check in the generated files.
Below is the generated trace:
{noformat}
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Cannot add release POM to SCM: No such command 'add'.
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Cannot add release POM t
o SCM: No such command 'add'.
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:719)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone
Goal(DefaultLifecycleExecutor.java:569)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:539)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:284)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:6
0)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Cannot add release PO
M to SCM: No such command 'add'.
at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(Pr
epareReleaseMojo.java:215)
at org.apache.maven.plugins.release.PrepareWithPomReleaseMojo.execute(Pr
epareWithPomReleaseMojo.java:48)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:694)
... 17 more
Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Cannot add
release POM to SCM: No such command 'add'.
at org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.addRel
easePomsToScm(GenerateReleasePomsPhase.java:199)
at org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.genera
teReleasePoms(GenerateReleasePomsPhase.java:132)
at org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.execut
e(GenerateReleasePomsPhase.java:105)
at org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.execut
e(GenerateReleasePomsPhase.java:92)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:203)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:140)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:103)
at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(Pr
epareReleaseMojo.java:211)
... 20 more
Caused by: org.apache.maven.scm.NoSuchCommandScmException: No such command 'add'
.
at org.apache.maven.scm.provider.AbstractScmProvider.add(AbstractScmProv
ider.java:147)
at org.apache.maven.scm.provider.AbstractScmProvider.add(AbstractScmProv
ider.java:141)
at org.apache.maven.scm.provider.AbstractScmProvider.add(AbstractScmProv
ider.java:124)
at org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.addRel
easePomsToScm(GenerateReleasePomsPhase.java:190)
... 27 more
{noformat}
Can anyone make sense of it?
was:
When preparing the r
[jira] (SCM-557) ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently)
[
https://jira.codehaus.org/browse/SCM-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-557:
---
Description:
Trying to run the release plugin for a git project
http://xircles.codehaus.org/projects/paranamer/repo/git/repo (branch real_asm).
In the prepare phase it barfs like so :
{noformat}
[INFO] [INFO]
[INFO] [INFO] BUILD SUCCESSFUL
[INFO] [INFO]
[INFO] [INFO] Total time: 11 seconds
[INFO] [INFO] Finished at: Thu Jun 10 05:21:23 CDT 2010
[INFO] [INFO] Final Memory: 39M/81M
[INFO] [INFO]
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git add --
pom.xml
[INFO] Working directory: /scm/oss/paranamer-git/paranamer
[INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git status
[INFO] Working directory: /scm/oss/paranamer-git/paranamer
[DEBUG] # On branch real_asm
[DEBUG] # Changes to be committed:
[DEBUG] # (use "git reset HEAD ..." to unstage)
[DEBUG] #
[DEBUG] # modified: pom.xml
[DEBUG] #
[DEBUG] # Untracked files:
[DEBUG] # (use "git add ..." to include in what will be committed)
[DEBUG] #
[DEBUG] # pom.xml.releaseBackup
[DEBUG] # release.properties
[INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git commit
--verbose -F
/var/folders/qb/qbAjORvlEIKOmBNFQArSsTI/-Tmp-/maven-scm-964404670.commit
pom.xml
[INFO] Working directory: /scm/oss/paranamer-git/paranamer
[INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git
symbolic-ref HEAD
[INFO] Working directory: /scm/oss/paranamer-git/paranamer
[INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git push
ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm
[INFO] Working directory: /scm/oss/paranamer-git/paranamer
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to commit files
Provider message:
The git-push command failed.
Command output:
##
Unauthorized access to this system (codehaus01) is forbidden and will
be prosecuted by law. By accessing this system, you agree that your
actions may be monitored if unauthorized usage is suspected.
##
ERROR:gitosis.serve.main:Arguments to command look dangerous
fatal: The remote end hung up unexpectedly
[INFO]
[DEBUG] Trace
org.apache.maven.BuildFailureException: Unable to commit files
Provider message:
The git-push command failed.
Command output:
##
Unauthorized access to this system (codehaus01) is forbidden and will
be prosecuted by law. By accessing this system, you agree that your
actions may be monitored if unauthorized usage is suspected.
##
ERROR:gitosis.serve.main:Arguments to command look dangerous
fatal: The remote end hung up unexpectedly
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
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.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430
[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
[
https://jira.codehaus.org/browse/MENFORCER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317443#comment-317443
]
Ben Noland edited comment on MENFORCER-146 at 1/16/13 3:21 PM:
---
I don't know that the relationship between B and C matters. X could be guava, B
could be an internal project, C could be an external library.
If A calls a method of B that uses a method that's new in X version 2.5, you're
going to get an error.
I do agree that the useManagedVersions param seems like a good solution, I just
don't know that false is the best default, other than to ease people into the
new behavior.
was (Author: bennoland):
I don't know that the relationship between B and C matters. X could be
guava, B could be an internal project, C could be an external library.
If A calls a method of B that uses a method that's new in X version 2.5, you're
going to get an error.
I do agree that the useManagedVersions param seems like a good solution, I just
don't know that true is the best default, other than to ease people into the
new behavior.
> requireUpperBoundDeps inneffective when DependencyManagement is used
>
>
> Key: MENFORCER-146
> URL: https://jira.codehaus.org/browse/MENFORCER-146
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Reporter: Ben Noland
> Attachments: RequireUpperBoundDepsVisitor.diff
>
>
> Consider the following dependency tree:
> {noformat}
> A
> +- B
> | \-X (1.1)
> +- C
>\-X (2.1)
> {noformat}
> I can use the requireUpperBoundDeps to find these types of issues (I want to
> use D 2.1 rather than 1.1).
> To fix the issue I use dependencyManagement to set the version of X to 2.1.
> As I understand it, using dependencyManagement effectively changes the tree
> to look like this:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 1.1, but managed to 2.1)
> +- C
>\-X (2.1)
> {noformat}
> Now, if B is upgraded to depend on X 2.5, I will never know:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
> +- C
>\-X (2.1)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
[
https://jira.codehaus.org/browse/MENFORCER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317443#comment-317443
]
Ben Noland edited comment on MENFORCER-146 at 1/16/13 3:22 PM:
---
I don't know that the relationship between B and C matters. X could be guava, B
could be an internal project, C could be an external library.
If A calls a method of B that uses a method that's new in X version 2.5, you're
going to get an error.
I do agree that the useManagedVersions param seems like a good solution.
was (Author: bennoland):
I don't know that the relationship between B and C matters. X could be
guava, B could be an internal project, C could be an external library.
If A calls a method of B that uses a method that's new in X version 2.5, you're
going to get an error.
I do agree that the useManagedVersions param seems like a good solution, I just
don't know that false is the best default, other than to ease people into the
new behavior.
> requireUpperBoundDeps inneffective when DependencyManagement is used
>
>
> Key: MENFORCER-146
> URL: https://jira.codehaus.org/browse/MENFORCER-146
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Reporter: Ben Noland
> Attachments: RequireUpperBoundDepsVisitor.diff
>
>
> Consider the following dependency tree:
> {noformat}
> A
> +- B
> | \-X (1.1)
> +- C
>\-X (2.1)
> {noformat}
> I can use the requireUpperBoundDeps to find these types of issues (I want to
> use D 2.1 rather than 1.1).
> To fix the issue I use dependencyManagement to set the version of X to 2.1.
> As I understand it, using dependencyManagement effectively changes the tree
> to look like this:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 1.1, but managed to 2.1)
> +- C
>\-X (2.1)
> {noformat}
> Now, if B is upgraded to depend on X 2.5, I will never know:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
> +- C
>\-X (2.1)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
[
https://jira.codehaus.org/browse/MENFORCER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317443#comment-317443
]
Ben Noland commented on MENFORCER-146:
--
I don't know that the relationship between B and C matters. X could be guava, B
could be an internal project, C could be an external library.
If A calls a method of B that uses a method that's new in X version 2.5, you're
going to get an error.
I do agree that the useManagedVersions param seems like a good solution, I just
don't know that true is the best default, other than to ease people into the
new behavior.
> requireUpperBoundDeps inneffective when DependencyManagement is used
>
>
> Key: MENFORCER-146
> URL: https://jira.codehaus.org/browse/MENFORCER-146
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Reporter: Ben Noland
> Attachments: RequireUpperBoundDepsVisitor.diff
>
>
> Consider the following dependency tree:
> {noformat}
> A
> +- B
> | \-X (1.1)
> +- C
>\-X (2.1)
> {noformat}
> I can use the requireUpperBoundDeps to find these types of issues (I want to
> use D 2.1 rather than 1.1).
> To fix the issue I use dependencyManagement to set the version of X to 2.1.
> As I understand it, using dependencyManagement effectively changes the tree
> to look like this:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 1.1, but managed to 2.1)
> +- C
>\-X (2.1)
> {noformat}
> Now, if B is upgraded to depend on X 2.5, I will never know:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
> +- C
>\-X (2.1)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-762) Add support for test compile and test runtime separation
[ https://jira.codehaus.org/browse/SUREFIRE-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated SUREFIRE-762: --- Attachment: SUREFIRE-762 Git Commit: https://github.com/aslakknutsen/maven-surefire/commit/e914da14c12f96b042bad92f703d57e64f59276c Adds the 'additionalProfiles' configuration option. The additional profile ids are used to activated the profile to re calculate the TestClasspath and open up for runtime only dependencies. Used in cases where you e.g. only want API on classpath but test against a specific impl. Individual Surefire Executions can be configured to run against different API impls. > Add support for test compile and test runtime separation > > > Key: SUREFIRE-762 > URL: https://jira.codehaus.org/browse/SUREFIRE-762 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Affects Versions: 2.9 >Reporter: Aslak Knutsen > Attachments: SUREFIRE-762 > > > In some cases it is interesting to bind surefire to multiple execution > targets but have it operate on different classpaths. > e.g: > - Have the same test suite run against multiple JPA providers; EclipseLink > and Hibernate > - Arquillian test suite run against Tomcat and Jetty > In these cases you would have the TestCompile scope defined in your normal > dependency chain scoped as "test", while you can tell surefire to activate > another profile during test. > TestCompile = JPA API > TestRuntime = Hibernate | EclipseLink > Example: > https://gist.github.com/1155271 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
[
https://jira.codehaus.org/browse/MENFORCER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317435#comment-317435
]
Robert Scholte commented on MENFORCER-146:
--
IMO as long as B and C aren't related, it shouldn't be an issue. But I can
imagine the situation. So {{useManagedVersions}} should be a {{boolean}},
default to {{false}}. A test to prevent regression would be welcome as well.
> requireUpperBoundDeps inneffective when DependencyManagement is used
>
>
> Key: MENFORCER-146
> URL: https://jira.codehaus.org/browse/MENFORCER-146
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Reporter: Ben Noland
> Attachments: RequireUpperBoundDepsVisitor.diff
>
>
> Consider the following dependency tree:
> {noformat}
> A
> +- B
> | \-X (1.1)
> +- C
>\-X (2.1)
> {noformat}
> I can use the requireUpperBoundDeps to find these types of issues (I want to
> use D 2.1 rather than 1.1).
> To fix the issue I use dependencyManagement to set the version of X to 2.1.
> As I understand it, using dependencyManagement effectively changes the tree
> to look like this:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 1.1, but managed to 2.1)
> +- C
>\-X (2.1)
> {noformat}
> Now, if B is upgraded to depend on X 2.5, I will never know:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
> +- C
>\-X (2.1)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-424) Conditionally include or exclude a fileSet from an archetype when project is generated
Adrian created ARCHETYPE-424:
Summary: Conditionally include or exclude a fileSet from an
archetype when project is generated
Key: ARCHETYPE-424
URL: https://jira.codehaus.org/browse/ARCHETYPE-424
Project: Maven Archetype
Issue Type: New Feature
Reporter: Adrian
I'm creating a project generating code samples for accessing Oracle and
Mainframe.
I want to conditionnaly generate the samples based on user input
Define value for groupId: : com.example
Define value for artifactId: : myproject
Define value for package: com.example: :
Define value for SGBD Sample : : Y
Define value for Mainframe Sample : : N
Could it be possible to add this functionnality ?
i.e. This could be done by adding an attribute into fileSet element which would
indicate if the fileSet directive needs to be taken into account :
{code:xml}
src/main/java
mainframe/*.java
{code}
Some links :
*
[http://stackoverflow.com/questions/1919704/how-do-i-conditionally-include-or-exclude-a-file-from-an-archetype-when-project]
* [ARCHETYPE-58|http://jira.codehaus.org/browse/ARCHETYPE-58] (this one didn't
adressed this issue)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-381) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
https://jira.codehaus.org/browse/WAGON-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317433#comment-317433
]
Ben Douglas commented on WAGON-381:
---
I just attempted the 3.1 snapshot (build 320) and my download stalled again and
gave me a bad md5 warning:
{noformat}
bdouglas@gambit templates$ /opt/apache-maven-3.1-SNAPSHOT/bin/mvn --version
Apache Maven 3.1-SNAPSHOT (rNON-CANONICAL_2012-12-01_03-31_jenkins; 2012-11-30
22:31:54-0500)
Maven home: /opt/apache-maven-3.1-SNAPSHOT
Java version: 1.6.0_33, vendor: Sun Microsystems Inc.
Java home: /opt/jdk1.6.0_33/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.6.11-1.fc17.x86_64", arch: "amd64", family: "unix"
bdouglas@gambit templates$
{noformat}
The checksum failing is when the artifact is only the Integer.MAX_VALUE size
{noformat}
[INFO] Configured Artifact: org.centos:CentOS-6.3-x86_64-bin-DVD1:1.0:iso
[DEBUG] Using connector WagonRepositoryConnector with priority 0 for
http://x.com/artifactory/libs-release
Downloading:
http://x.com/artifactory/libs-release/org/centos/CentOS-6.3-x86_64-bin-DVD1/1.0/CentOS-6.3-x86_64-bin-DVD1-1.0.iso
[WARNING] Checksum validation failed, expected
eaa52f3d1ccf2df3b03e064fb0fa6168be28a4d4 but is
249cf446611db34ad8006bbdb99397c2a4bc201a for
http://x.com/artifactory/libs-release/org/centos/CentOS-6.3-x86_64-bin-DVD1/1.0/CentOS-6.3-x86_64-bin-DVD1-1.0.iso
{noformat}
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: WAGON-381
> URL: https://jira.codehaus.org/browse/WAGON-381
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 2.2
>Reporter: Evgeny Goldin
>Assignee: Olivier Lamy
> Fix For: 2.3
>
> Attachments: 1.png, 2.png
>
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-557) ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently)
[ https://jira.codehaus.org/browse/SCM-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317431#comment-317431 ] Darryl L. Miles edited comment on SCM-557 at 1/16/13 9:22 AM: -- The message you see is coming from the server ? It is dangerous since you are not being explicit and the systems at one or both ends need to do some guess work. This guess can be wrong and therefore for a production system it is dangerous. A Maven module should not be ambiguously pushing... Related to SCM-705 ? ## What maven is currently doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm ## What maven should be doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:refs/heads/real_asm was (Author: dlmiles): The message you see is coming from the server ? It is dangerous since you are not being explicit and the systems at one or both ends need to do some guess work. This guess can be wrong and therefore for a production system it is dangerous. A Maven module should not be ambiguously pushing... Related to SCM-705 ? # What maven is currently doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm # What maven should be doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:refs/heads/real_asm > ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently) > - > > Key: SCM-557 > URL: https://jira.codehaus.org/browse/SCM-557 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.3 >Reporter: Paul Hammant > > Trying to run the release plugin for a git project > http://xircles.codehaus.org/projects/paranamer/repo/git/repo (branch > real_asm). In the prepare phase it barfs like so : > [INFO] [INFO] > > [INFO] [INFO] BUILD SUCCESSFUL > [INFO] [INFO] > > [INFO] [INFO] Total time: 11 seconds > [INFO] [INFO] Finished at: Thu Jun 10 05:21:23 CDT 2010 > [INFO] [INFO] Final Memory: 39M/81M > [INFO] [INFO] > > [INFO] Checking in modified POMs... > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git add > -- pom.xml > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git status > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [DEBUG] # On branch real_asm > [DEBUG] # Changes to be committed: > [DEBUG] # (use "git reset HEAD ..." to unstage) > [DEBUG] # > [DEBUG] # modified: pom.xml > [DEBUG] # > [DEBUG] # Untracked files: > [DEBUG] # (use "git add ..." to include in what will be committed) > [DEBUG] # > [DEBUG] # pom.xml.releaseBackup > [DEBUG] # release.properties > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git > commit --verbose -F > /var/folders/qb/qbAjORvlEIKOmBNFQArSsTI/-Tmp-/maven-scm-964404670.commit > pom.xml > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git > symbolic-ref HEAD > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git push > ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Unable to commit files > Provider message: > The git-push command failed. > Command output: > ## > Unauthorized access to this system (codehaus01) is forbidden and will > be prosecuted by law. By accessing this system, you agree that your > actions may be monitored if unauthorized usage is suspected. > ## > ERROR:gitosis.serve.main:Arguments to command look dangerous > fatal: The remote end hung up unexpectedly > [INFO] > > [DEBUG] Trace > org.apache.maven.BuildFailureException: Unable to commit files > Provider message: > The git-push command failed. > Command output: > ## > Unauthorized access to this system (codehaus01) is forbidden and will > be prosecuted by law. By accessing thi
[jira] (SCM-557) ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently)
[ https://jira.codehaus.org/browse/SCM-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317431#comment-317431 ] Darryl L. Miles edited comment on SCM-557 at 1/16/13 9:22 AM: -- The message you see is coming from the server ? It is dangerous since you are not being explicit and the systems at one or both ends need to do some guess work. This guess can be wrong and therefore for a production system it is dangerous. A Maven module should not be ambiguously pushing... Related to SCM-705 ? What maven is currently doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm What maven should be doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:refs/heads/real_asm was (Author: dlmiles): The message you see is coming from the server ? It is dangerous since you are not being explicit and the systems at one or both ends need to do some guess work. This guess can be wrong and therefore for a production system it is dangerous. A Maven module should not be ambiguously pushing... Related to SCM-705 ? ## What maven is currently doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm ## What maven should be doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:refs/heads/real_asm > ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently) > - > > Key: SCM-557 > URL: https://jira.codehaus.org/browse/SCM-557 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.3 >Reporter: Paul Hammant > > Trying to run the release plugin for a git project > http://xircles.codehaus.org/projects/paranamer/repo/git/repo (branch > real_asm). In the prepare phase it barfs like so : > [INFO] [INFO] > > [INFO] [INFO] BUILD SUCCESSFUL > [INFO] [INFO] > > [INFO] [INFO] Total time: 11 seconds > [INFO] [INFO] Finished at: Thu Jun 10 05:21:23 CDT 2010 > [INFO] [INFO] Final Memory: 39M/81M > [INFO] [INFO] > > [INFO] Checking in modified POMs... > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git add > -- pom.xml > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git status > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [DEBUG] # On branch real_asm > [DEBUG] # Changes to be committed: > [DEBUG] # (use "git reset HEAD ..." to unstage) > [DEBUG] # > [DEBUG] # modified: pom.xml > [DEBUG] # > [DEBUG] # Untracked files: > [DEBUG] # (use "git add ..." to include in what will be committed) > [DEBUG] # > [DEBUG] # pom.xml.releaseBackup > [DEBUG] # release.properties > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git > commit --verbose -F > /var/folders/qb/qbAjORvlEIKOmBNFQArSsTI/-Tmp-/maven-scm-964404670.commit > pom.xml > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git > symbolic-ref HEAD > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git push > ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Unable to commit files > Provider message: > The git-push command failed. > Command output: > ## > Unauthorized access to this system (codehaus01) is forbidden and will > be prosecuted by law. By accessing this system, you agree that your > actions may be monitored if unauthorized usage is suspected. > ## > ERROR:gitosis.serve.main:Arguments to command look dangerous > fatal: The remote end hung up unexpectedly > [INFO] > > [DEBUG] Trace > org.apache.maven.BuildFailureException: Unable to commit files > Provider message: > The git-push command failed. > Command output: > ## > Unauthorized access to this system (codehaus01) is forbidden and will > be prosecuted by law. By accessing this sy
[jira] (SCM-557) ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently)
[ https://jira.codehaus.org/browse/SCM-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317431#comment-317431 ] Darryl L. Miles commented on SCM-557: - The message you see is coming from the server ? It is dangerous since you are not being explicit and the systems at one or both ends need to do some guess work. This guess can be wrong and therefore for a production system it is dangerous. A Maven module should not be ambiguously pushing... Related to SCM-705 ? # What maven is currently doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm # What maven should be doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:refs/heads/real_asm > ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently) > - > > Key: SCM-557 > URL: https://jira.codehaus.org/browse/SCM-557 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.3 >Reporter: Paul Hammant > > Trying to run the release plugin for a git project > http://xircles.codehaus.org/projects/paranamer/repo/git/repo (branch > real_asm). In the prepare phase it barfs like so : > [INFO] [INFO] > > [INFO] [INFO] BUILD SUCCESSFUL > [INFO] [INFO] > > [INFO] [INFO] Total time: 11 seconds > [INFO] [INFO] Finished at: Thu Jun 10 05:21:23 CDT 2010 > [INFO] [INFO] Final Memory: 39M/81M > [INFO] [INFO] > > [INFO] Checking in modified POMs... > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git add > -- pom.xml > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git status > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [DEBUG] # On branch real_asm > [DEBUG] # Changes to be committed: > [DEBUG] # (use "git reset HEAD ..." to unstage) > [DEBUG] # > [DEBUG] # modified: pom.xml > [DEBUG] # > [DEBUG] # Untracked files: > [DEBUG] # (use "git add ..." to include in what will be committed) > [DEBUG] # > [DEBUG] # pom.xml.releaseBackup > [DEBUG] # release.properties > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git > commit --verbose -F > /var/folders/qb/qbAjORvlEIKOmBNFQArSsTI/-Tmp-/maven-scm-964404670.commit > pom.xml > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git > symbolic-ref HEAD > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git push > ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Unable to commit files > Provider message: > The git-push command failed. > Command output: > ## > Unauthorized access to this system (codehaus01) is forbidden and will > be prosecuted by law. By accessing this system, you agree that your > actions may be monitored if unauthorized usage is suspected. > ## > ERROR:gitosis.serve.main:Arguments to command look dangerous > fatal: The remote end hung up unexpectedly > [INFO] > > [DEBUG] Trace > org.apache.maven.BuildFailureException: Unable to commit files > Provider message: > The git-push command failed. > Command output: > ## > Unauthorized access to this system (codehaus01) is forbidden and will > be prosecuted by law. By accessing this system, you agree that your > actions may be monitored if unauthorized usage is suspected. > ## > ERROR:gitosis.serve.main:Arguments to command look dangerous > fatal: The remote end hung up unexpectedly > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifec
[jira] (SCM-557) ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently)
[ https://jira.codehaus.org/browse/SCM-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317431#comment-317431 ] Darryl L. Miles edited comment on SCM-557 at 1/16/13 9:20 AM: -- The message you see is coming from the server ? It is dangerous since you are not being explicit and the systems at one or both ends need to do some guess work. This guess can be wrong and therefore for a production system it is dangerous. A Maven module should not be ambiguously pushing... Related to SCM-705 ? # What maven is currently doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm # What maven should be doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:refs/heads/real_asm was (Author: dlmiles): The message you see is coming from the server ? It is dangerous since you are not being explicit and the systems at one or both ends need to do some guess work. This guess can be wrong and therefore for a production system it is dangerous. A Maven module should not be ambiguously pushing... Related to SCM-705 ? # What maven is currently doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm # What maven should be doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:refs/heads/real_asm > ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently) > - > > Key: SCM-557 > URL: https://jira.codehaus.org/browse/SCM-557 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.3 >Reporter: Paul Hammant > > Trying to run the release plugin for a git project > http://xircles.codehaus.org/projects/paranamer/repo/git/repo (branch > real_asm). In the prepare phase it barfs like so : > [INFO] [INFO] > > [INFO] [INFO] BUILD SUCCESSFUL > [INFO] [INFO] > > [INFO] [INFO] Total time: 11 seconds > [INFO] [INFO] Finished at: Thu Jun 10 05:21:23 CDT 2010 > [INFO] [INFO] Final Memory: 39M/81M > [INFO] [INFO] > > [INFO] Checking in modified POMs... > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git add > -- pom.xml > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git status > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [DEBUG] # On branch real_asm > [DEBUG] # Changes to be committed: > [DEBUG] # (use "git reset HEAD ..." to unstage) > [DEBUG] # > [DEBUG] # modified: pom.xml > [DEBUG] # > [DEBUG] # Untracked files: > [DEBUG] # (use "git add ..." to include in what will be committed) > [DEBUG] # > [DEBUG] # pom.xml.releaseBackup > [DEBUG] # release.properties > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git > commit --verbose -F > /var/folders/qb/qbAjORvlEIKOmBNFQArSsTI/-Tmp-/maven-scm-964404670.commit > pom.xml > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git > symbolic-ref HEAD > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git push > ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Unable to commit files > Provider message: > The git-push command failed. > Command output: > ## > Unauthorized access to this system (codehaus01) is forbidden and will > be prosecuted by law. By accessing this system, you agree that your > actions may be monitored if unauthorized usage is suspected. > ## > ERROR:gitosis.serve.main:Arguments to command look dangerous > fatal: The remote end hung up unexpectedly > [INFO] > > [DEBUG] Trace > org.apache.maven.BuildFailureException: Unable to commit files > Provider message: > The git-push command failed. > Command output: > ## > Unauthorized access to this system (codehaus01) is forbidden and will > be prosecuted by law. By accessing this system, you agr
[jira] (SCM-557) ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently)
[ https://jira.codehaus.org/browse/SCM-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317431#comment-317431 ] Darryl L. Miles edited comment on SCM-557 at 1/16/13 9:20 AM: -- The message you see is coming from the server ? It is dangerous since you are not being explicit and the systems at one or both ends need to do some guess work. This guess can be wrong and therefore for a production system it is dangerous. A Maven module should not be ambiguously pushing... Related to SCM-705 ? # What maven is currently doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm # What maven should be doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:refs/heads/real_asm was (Author: dlmiles): The message you see is coming from the server ? It is dangerous since you are not being explicit and the systems at one or both ends need to do some guess work. This guess can be wrong and therefore for a production system it is dangerous. A Maven module should not be ambiguously pushing... Related to SCM-705 ? # What maven is currently doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm # What maven should be doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:refs/heads/real_asm > ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently) > - > > Key: SCM-557 > URL: https://jira.codehaus.org/browse/SCM-557 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.3 >Reporter: Paul Hammant > > Trying to run the release plugin for a git project > http://xircles.codehaus.org/projects/paranamer/repo/git/repo (branch > real_asm). In the prepare phase it barfs like so : > [INFO] [INFO] > > [INFO] [INFO] BUILD SUCCESSFUL > [INFO] [INFO] > > [INFO] [INFO] Total time: 11 seconds > [INFO] [INFO] Finished at: Thu Jun 10 05:21:23 CDT 2010 > [INFO] [INFO] Final Memory: 39M/81M > [INFO] [INFO] > > [INFO] Checking in modified POMs... > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git add > -- pom.xml > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git status > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [DEBUG] # On branch real_asm > [DEBUG] # Changes to be committed: > [DEBUG] # (use "git reset HEAD ..." to unstage) > [DEBUG] # > [DEBUG] # modified: pom.xml > [DEBUG] # > [DEBUG] # Untracked files: > [DEBUG] # (use "git add ..." to include in what will be committed) > [DEBUG] # > [DEBUG] # pom.xml.releaseBackup > [DEBUG] # release.properties > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git > commit --verbose -F > /var/folders/qb/qbAjORvlEIKOmBNFQArSsTI/-Tmp-/maven-scm-964404670.commit > pom.xml > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git > symbolic-ref HEAD > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer && git push > ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm > [INFO] Working directory: /scm/oss/paranamer-git/paranamer > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Unable to commit files > Provider message: > The git-push command failed. > Command output: > ## > Unauthorized access to this system (codehaus01) is forbidden and will > be prosecuted by law. By accessing this system, you agree that your > actions may be monitored if unauthorized usage is suspected. > ## > ERROR:gitosis.serve.main:Arguments to command look dangerous > fatal: The remote end hung up unexpectedly > [INFO] > > [DEBUG] Trace > org.apache.maven.BuildFailureException: Unable to commit files > Provider message: > The git-push command failed. > Command output: > ## > Unauthorized access to this system (codehaus01) is forbidden and will > be prosecuted by law. By accessing this system, you agree that your > ac
[jira] (MSHADE-136) Shade dependency reduced pom uses timestamp in artifact names instead of -SNAPSHOT
[ https://jira.codehaus.org/browse/MSHADE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Dahanne updated MSHADE-136: --- Attachment: MSHADE-136_integration-test1.patch integration test patch for the new parameter useBaseVersion > Shade dependency reduced pom uses timestamp in artifact names instead of > -SNAPSHOT > -- > > Key: MSHADE-136 > URL: https://jira.codehaus.org/browse/MSHADE-136 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Hung Huynh > Attachments: MSHADE-136_code2.patch, > MSHADE-136_integration-test1.patch > > > The major problem that we run into is that Maven would download that exact > timestamp artifact instead of using the latest. > Instead of this > > org.mycom > management-core > 1.1.0-20130115.201411-23 > compile > > should have been this > > org.mycom > management-core > 1.1.0-SNAPSHOT > compile > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-136) Shade dependency reduced pom uses timestamp in artifact names instead of -SNAPSHOT
[ https://jira.codehaus.org/browse/MSHADE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Dahanne updated MSHADE-136: --- Attachment: MSHADE-136_code2.patch Patch to provide a new parameter : useBaseVersion > Shade dependency reduced pom uses timestamp in artifact names instead of > -SNAPSHOT > -- > > Key: MSHADE-136 > URL: https://jira.codehaus.org/browse/MSHADE-136 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Hung Huynh > Attachments: MSHADE-136_code2.patch > > > The major problem that we run into is that Maven would download that exact > timestamp artifact instead of using the latest. > Instead of this > > org.mycom > management-core > 1.1.0-20130115.201411-23 > compile > > should have been this > > org.mycom > management-core > 1.1.0-SNAPSHOT > compile > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-711) request for scm:info goal
[
https://jira.codehaus.org/browse/SCM-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317426#comment-317426
]
Olivier Lamy commented on SCM-711:
--
not well documented but buildnumber:create support git and mercurial too. (see
http://mojo.codehaus.org/buildnumber-maven-plugin/index.html)
> request for scm:info goal
> -
>
> Key: SCM-711
> URL: https://jira.codehaus.org/browse/SCM-711
> Project: Maven SCM
> Issue Type: Wish
> Components: maven-scm-api
>Reporter: Karl Pietrzak
>Priority: Minor
>
> h4. What
> I would like to request the addition of a {{scm:info}} goal.
> h4. Why
> I would like to use the properties of {{scm:info}} in the rest of my Maven
> build process, especially put SVN info properties into my manifest.
> h4. How
> Most (all?) of the providers have some kind of {{info}} method already, so it
> shouldn't be a big deal.
> I can submit a patch, if this sounds OK to folks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-489) Failure to locate component descriptors in another project
[
https://jira.codehaus.org/browse/MASSEMBLY-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317424#comment-317424
]
Toni Menzel commented on MASSEMBLY-489:
---
Whats the deal with this issue? We also experience problems actually using
componentDescriptors in conjunction with DescriptorRefs.
Our descriptors are referenced via classpath (descriptorRef) but they need to
be able to also consume components from classpath.
> Failure to locate component descriptors in another project
> --
>
> Key: MASSEMBLY-489
> URL: https://jira.codehaus.org/browse/MASSEMBLY-489
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Components: component descriptor
>Affects Versions: 2.2-beta-5
> Environment: Apache Maven 3.0-beta-1 (r935667; 2010-04-19
> 19:00:39+0200)
> Java version: 1.6.0_20
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.20/jre
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "linux" version: "2.6.31-22-generic" arch: "i386" Family: "unix"
>Reporter: Andreas Sewe
> Attachments: aggregator.tar.gz
>
>
> The {{maven-assembly-plugin}} seems to search for component descriptors in
> the current project instead of in the one containing the assembly descriptors
> which do the referring. This behavior is probably a bug and makes it quite
> impossible to use such a modularized assembly descriptor from a different
> project.
> The attached multi-module project exemplifies this; just run "mvn install"
> from the aggregator project and you will get the following stack trace:
> {quote}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single
> (default) on project problematic-module: Error reading assemblies: Failed to
> locate component descriptor: src/main/resources/assemblies/component.xml
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:141)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:77)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:69)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:82)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:54)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.singleThreadedBuild(DefaultLifecycleExecutor.java:218)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:190)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:246)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:95)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:430)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:160)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:124)
> 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)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error reading
> assemblies: Failed to locate component descriptor:
> src/main/resources/assemblies/component.xml
> at
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:356)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:133)
> ... 19 more
> Caused by: org.apache.maven.plugin.assembly.io.AssemblyReadException: Failed
> to locate component descriptor: src/main/resources/assemblies/component.xml
> at
> org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.mergeComponentsWithMainAssembly(DefaultAssemblyReader.java:452)
> at
> org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssembly(DefaultAssemblyReader.java:366)
> at
> org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.addAssemblyForDescriptorReference(DefaultAssemblyReader.java:257)
> at
> org.apache.maven.plugin.assembly.io.DefaultAssemblyReade
[jira] (MDEP-230) Performance is really bad for large artifacts
[ https://jira.codehaus.org/browse/MDEP-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MDEP-230. - Resolution: Won't Fix Assignee: Olivier Lamy already fixed with recent version. > Performance is really bad for large artifacts > - > > Key: MDEP-230 > URL: https://jira.codehaus.org/browse/MDEP-230 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: unpack >Affects Versions: 2.1 > Environment: linux >Reporter: Jason Chaffee >Assignee: Olivier Lamy > > I have a 300mb tar.gz file that I need to unpack for one of my builds. I > takes over 10 minutes to unpack with the unpack goal. If I do it on the > cmd-line it takes less than 1 minute. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-158) Relative file name doesn't work when specifying ruleset
[
https://jira.codehaus.org/browse/MPMD-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Pushyk updated MPMD-158:
--
Attachment: MPMD-158-With-Child-Module.zip
Sorry for late response. Now I noticed that issue appears whenever there is
Maven child project and PMD plugin tries to resolve ruleset file relative to
child project location. I've modified you exemplary project to let you
reproduce the issue.
> Relative file name doesn't work when specifying ruleset
> ---
>
> Key: MPMD-158
> URL: https://jira.codehaus.org/browse/MPMD-158
> Project: Maven 2.x PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 2.7.1
> Environment: Windows 7
>Reporter: Taras Pushyk
> Attachments: MPMD-158-With-Child-Module.zip, MPMD-158.zip
>
>
> When ruleset specified as follows:
> {code}
>
> org.apache.maven.plugins
> maven-pmd-plugin
> 2.7.1
>
> false 100 1.5
>
>../config/basic.xml
>
>
>
> {code}
> File is not resolved. Also following message appears on console:
> [DEBUG] The resource '../config/basic.xml' was not found with resourceLoader
> org.codehaus.plexus.resource.loader.FileResourceLoader.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
