[jira] (SCM-213) Broken with Cygwin
[ https://jira.codehaus.org/browse/SCM-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313506#comment-313506 ] Andreas Höhmann edited comment on SCM-213 at 11/14/12 1:36 AM: --- Who closed this bug as fixed? This problem still exists :-( (Maybe only in combination with the release plugin [3]?) [1] doesn't contains any special cygwin code, so the cygwin settings desribed in [2] doesn't work?! Maybe I put the svn-settings.xml in a wrong place ... I tried - D:\DEV\cygwin\home\USER\.scm - C:\Documents and Settings\USER\.scm true /cygwin [1] https://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.8/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svnexe/src/main/java/org/apache/maven/scm/provider/svn/svnexe/command/SvnCommandLineUtils.java [2] http://maven.apache.org/scm/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svn-commons/svn-settings.html [3] http://jira.codehaus.org/browse/MRELEASE-146 was (Author: ahoehma): Who closed this bug as fixed? This problem still exists :-( [1] doesn't contains any special cygwin code, so the cygwin settings desribed in [2] doesn't work?! Maybe I put the svn-settings.xml in a wrong place ... I tried - D:\DEV\cygwin\home\USER\.scm - C:\Documents and Settings\USER\.scm true /cygwin [1] https://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.8/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svnexe/src/main/java/org/apache/maven/scm/provider/svn/svnexe/command/SvnCommandLineUtils.java [2] http://maven.apache.org/scm/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svn-commons/svn-settings.html > Broken with Cygwin > -- > > Key: SCM-213 > URL: https://jira.codehaus.org/browse/SCM-213 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Affects Versions: 1.0-beta-3 > Environment: Cygwin under Windows, Maven release plugin version > 2.0-beta-4 >Reporter: Chas Douglass >Assignee: Emmanuel Venisse > Fix For: 1.0-rc1 > > > svn doesn't like absolute path for the files to commit when we run it under > cygwin with a windows svn and a cygwin svn. > svn --non-interactive commit --file c:\temp\maven-scm-945043858.commit > e:/newapps/JEC/pom.xml > Working directory: e:\newapps\JEC > doesn't works with the same error you have > svn --non-interactive commit --file c:\temp\maven-scm-945043858.commit pom.xml > Working directory: e:\newapps\JEC > works fine. -- 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-213) Broken with Cygwin
[ https://jira.codehaus.org/browse/SCM-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313506#comment-313506 ] Andreas Höhmann commented on SCM-213: - Who closed this bug as fixed? This problem still exists :-( [1] doesn't contains any special cygwin code, so the cygwin settings desribed in [2] doesn't work?! Maybe I put the svn-settings.xml in a wrong place ... I tried - D:\DEV\cygwin\home\USER\.scm - C:\Documents and Settings\USER\.scm [1] https://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.8/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svnexe/src/main/java/org/apache/maven/scm/provider/svn/svnexe/command/SvnCommandLineUtils.java [2] http://maven.apache.org/scm/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svn-commons/svn-settings.html > Broken with Cygwin > -- > > Key: SCM-213 > URL: https://jira.codehaus.org/browse/SCM-213 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Affects Versions: 1.0-beta-3 > Environment: Cygwin under Windows, Maven release plugin version > 2.0-beta-4 >Reporter: Chas Douglass >Assignee: Emmanuel Venisse > Fix For: 1.0-rc1 > > > svn doesn't like absolute path for the files to commit when we run it under > cygwin with a windows svn and a cygwin svn. > svn --non-interactive commit --file c:\temp\maven-scm-945043858.commit > e:/newapps/JEC/pom.xml > Working directory: e:\newapps\JEC > doesn't works with the same error you have > svn --non-interactive commit --file c:\temp\maven-scm-945043858.commit pom.xml > Working directory: e:\newapps\JEC > works fine. -- 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-213) Broken with Cygwin
[ https://jira.codehaus.org/browse/SCM-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313506#comment-313506 ] Andreas Höhmann edited comment on SCM-213 at 11/14/12 1:35 AM: --- Who closed this bug as fixed? This problem still exists :-( [1] doesn't contains any special cygwin code, so the cygwin settings desribed in [2] doesn't work?! Maybe I put the svn-settings.xml in a wrong place ... I tried - D:\DEV\cygwin\home\USER\.scm - C:\Documents and Settings\USER\.scm true /cygwin [1] https://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.8/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svnexe/src/main/java/org/apache/maven/scm/provider/svn/svnexe/command/SvnCommandLineUtils.java [2] http://maven.apache.org/scm/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svn-commons/svn-settings.html was (Author: ahoehma): Who closed this bug as fixed? This problem still exists :-( [1] doesn't contains any special cygwin code, so the cygwin settings desribed in [2] doesn't work?! Maybe I put the svn-settings.xml in a wrong place ... I tried - D:\DEV\cygwin\home\USER\.scm - C:\Documents and Settings\USER\.scm [1] https://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.8/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svnexe/src/main/java/org/apache/maven/scm/provider/svn/svnexe/command/SvnCommandLineUtils.java [2] http://maven.apache.org/scm/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svn-commons/svn-settings.html > Broken with Cygwin > -- > > Key: SCM-213 > URL: https://jira.codehaus.org/browse/SCM-213 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Affects Versions: 1.0-beta-3 > Environment: Cygwin under Windows, Maven release plugin version > 2.0-beta-4 >Reporter: Chas Douglass >Assignee: Emmanuel Venisse > Fix For: 1.0-rc1 > > > svn doesn't like absolute path for the files to commit when we run it under > cygwin with a windows svn and a cygwin svn. > svn --non-interactive commit --file c:\temp\maven-scm-945043858.commit > e:/newapps/JEC/pom.xml > Working directory: e:\newapps\JEC > doesn't works with the same error you have > svn --non-interactive commit --file c:\temp\maven-scm-945043858.commit pom.xml > Working directory: e:\newapps\JEC > works fine. -- 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-5124) mvn script should load .mavenrc files even in current folder
[ https://jira.codehaus.org/browse/MNG-5124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5124. -- Resolution: Won't Fix > mvn script should load .mavenrc files even in current folder > > > Key: MNG-5124 > URL: https://jira.codehaus.org/browse/MNG-5124 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Command Line >Affects Versions: 2.2.1 > Environment: linux >Reporter: Federico Fissore > Attachments: mvn.patch > > > By patching the mvn script, it's possible to add an ADDITIONAL_MAVEN_OPTS, so > that you can apply custom parameters such as memory, jvm flags, classpath, > evn vars > the rationale is that nowadays is more and more common to use external tools > such JRebel or AgentSmith, but every project could need custom settings -- 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-4354) DefaultArtifactResolver has problems when used with multiple repos
[ https://jira.codehaus.org/browse/MNG-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-4354. -- Resolution: Cannot Reproduce > DefaultArtifactResolver has problems when used with multiple repos > -- > > Key: MNG-4354 > URL: https://jira.codehaus.org/browse/MNG-4354 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.2.1 > Environment: N/A >Reporter: Hasan Ceylan >Priority: Blocker > Fix For: Issues to be reviewed for 3.x > > Attachments: maven.patch > > > DefaultArtifactResolver attaches the repositories to artifacts (AFAIK) to > optimize the repo look ups. > Here I have a case > 1) An artifact dependens on org.eclipse.equniox:app:1.2.0 > 2) org.eclipse.equinox:app depends on > org.eclipse.equinox:registry:[3.4.0,4.0.0) > 3) Both central repo and custom corporate repo has > org.eclipse.equinox:registry > 4) central repo has outdated versions > 3.2.1-R32x_v20060814 > 3.3.0-v20070522 > 5) DefaultArtifactResolver for optimization attaches central repo (last one > wins) > 6) Central repo neither satisfies the version range nor - even if it did - > has the latest version > 7) dependency is not satisfied > 8) Build halts > Attached patch is a dirty hack to disable signle repo downloand and checks > all the repositories. -- 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-3223) mvn.bat & mvn shell script use different variable names - should standardise them
[ https://jira.codehaus.org/browse/MNG-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3223. -- Resolution: Won't Fix > mvn.bat & mvn shell script use different variable names - should standardise > them > - > > Key: MNG-3223 > URL: https://jira.codehaus.org/browse/MNG-3223 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Bootstrap & Build >Affects Versions: 2.0.7 >Reporter: Kev Jackson >Priority: Minor > Fix For: Issues to be reviewed for 3.x > > Attachments: mvn.patch > > > Windows (mvn.bat): > MAVEN_CMD_LINE_ARGS > *nix (mvn): > QUOTED_ARGS > Replace QUOTED_ARGS with MAVEN_CMD_LINE_ARGS (more descriptive and uses same > name as windows batch file) > Also export MAVEN_CMD_LINE_ARGS so that these are available via > System.getProperty() for use in unit tests > See patch -- 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-5181) New resolution from local repository is very confusing
[
https://jira.codehaus.org/browse/MNG-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313500#comment-313500
]
Ondrej Zizka commented on MNG-5181:
---
How about instead of having G:A:V:R, the identity of the artifact would be
verified using a hash. Simply, G:A:V:H. Same G:A:V and hash => same artifact,
dependency satisfied, no matter what repo does it come from.
{code}
foo
bar
1.0
0c9ab296701a8
{code}
I guess this approach was considered, but I wonder why not chosen.
> New resolution from local repository is very confusing
> --
>
> Key: MNG-5181
> URL: https://jira.codehaus.org/browse/MNG-5181
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3
>Reporter: Arnaud Heritier
>Assignee: Jason van Zyl
>
> I just discover the change introduced in Maven 3.x to try to improve the
> resolution mechanism and to avoid to use a local artifact which may not be
> available in its remote repository :
> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
> Even if the feature is interesting it has several problems :
> # When an artifact isn't accessible from its remote repository it isn't used
> by maven which replies a classical "dependency not found error". It is really
> annoying for a user with some Maven 2 skills which will have a look at his
> local repo, will find the artifact and won't understand why Maven doesn't use
> it. At least the error reported by Maven should be clear that even if the
> dependency is available locally, it isn't used because it's remote repository
> isn't available.
> # This behavior cannot be configured to be only a warning for example. It is
> really annoying because it doesn't take care of some context and constraints
> we may have in a development team. Let's imagine that the remote artifact is
> really removed. Cool Maven broke the build to warn us. But it brakes the
> build of all the team whereas perhaps only one of them may try to solve the
> issue (and it can be a long resolution). Thus having the ability to configure
> if this control is blocker or warning may allow the team to configure it as
> blocker on the CI server and as warning on the development environment.
> # This behavior may introduce some bad practices for example when we are
> using a staging feature on a repository manager. In our case my teams have a
> dedicated profile to activate a staging repository when we are validating a
> release. I recommend to not have this profile always activated but to do it
> only on-demand to avoid them to DL staging stuffs they don't need. With this
> new feature they need for all builds they run to activate this staging
> profile while binaries are stored in it. When you have to do it 20 times per
> day minimum let's imagine what the developer does : It adds it as an
> alwaysActive profile and then forget to remove it when the release is ended.
> For all these reason I would like we improve this feature to make it more
> usable and before all bet understandable for ours users.
--
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-4568) maven-embedder 3.0-alpha-6 doesn't contain the MavenEmbedder class
[ https://jira.codehaus.org/browse/MNG-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-4568. -- Resolution: Won't Fix > maven-embedder 3.0-alpha-6 doesn't contain the MavenEmbedder class > -- > > Key: MNG-4568 > URL: https://jira.codehaus.org/browse/MNG-4568 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Embedding >Affects Versions: 3.0-alpha-6 >Reporter: Kohsuke Kawaguchi > Fix For: 3.2 > > > The jar has no class named MavenEmbedder. In fact the whole 'embed' package > used to be 3.0-alpha-2 is gone. -- 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-5353) version ranges: Ignore qualifiers in exclusive upper bound [lw,up)
[ https://jira.codehaus.org/browse/MNG-5353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313497#comment-313497 ] Herve Boutemy commented on MNG-5353: notice: "fixing" denotes a bug actual behaviour is not buggy, it has a perfect, strict, logic this issue is about a new feature (or a wish) to *implement*, which is supposed to be more natural given the way a lot of people seem to think at it > version ranges: Ignore qualifiers in exclusive upper bound [lw,up) > -- > > Key: MNG-5353 > URL: https://jira.codehaus.org/browse/MNG-5353 > Project: Maven 2 & 3 > Issue Type: Wish > Components: Dependencies >Affects Versions: 2.0.11, 2.2.1, 3.0.4 >Reporter: Jesse Long > Fix For: 3.1.0 > > > Please change the behaviour of exclusive upper bounds to the following: > In a version range, like [1.7.0,1.8.0), 1.8.0-alpha1 should not be included > in the range. 1.8.0* should not be included in the range. > This allows for us configure natural ranges for projects using semantic > versioning. > Please see: > http://markmail.org/message/4tubas4uok6ahbcp > http://markmail.org/message/s2ry2uru4ibub43q -- 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-5353) version ranges: Ignore qualifiers in exclusive upper bound [lw,up)
[ https://jira.codehaus.org/browse/MNG-5353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313496#comment-313496 ] Bruno Medeiros commented on MNG-5353: - It would be awesome to see ranges working like that! I Hope you can fix that in time to 3.1! > version ranges: Ignore qualifiers in exclusive upper bound [lw,up) > -- > > Key: MNG-5353 > URL: https://jira.codehaus.org/browse/MNG-5353 > Project: Maven 2 & 3 > Issue Type: Wish > Components: Dependencies >Affects Versions: 2.0.11, 2.2.1, 3.0.4 >Reporter: Jesse Long > Fix For: 3.1.0 > > > Please change the behaviour of exclusive upper bounds to the following: > In a version range, like [1.7.0,1.8.0), 1.8.0-alpha1 should not be included > in the range. 1.8.0* should not be included in the range. > This allows for us configure natural ranges for projects using semantic > versioning. > Please see: > http://markmail.org/message/4tubas4uok6ahbcp > http://markmail.org/message/s2ry2uru4ibub43q -- 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-5121) maven seems to lose transitive dependencies from the list of compilation dependencies
[ https://jira.codehaus.org/browse/MNG-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313495#comment-313495 ] Henning Schmiedehausen commented on MNG-5121: - This has been resolved with maven 3.0.4 > maven seems to lose transitive dependencies from the list of compilation > dependencies > - > > Key: MNG-5121 > URL: https://jira.codehaus.org/browse/MNG-5121 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.1, 3.0.2, 3.0.3 > Environment: Fedora Linux, Sun JDK 1.6.0_24, MacOS X 10.6.7, AppleJDK > 1.6.0_24 >Reporter: Henning Schmiedehausen >Assignee: Jason van Zyl >Priority: Blocker > Fix For: 3.0.4 > > Attachments: build_failed.log, build_successful.log, maven-pom.xml, > mng-5121.tgz > > > See the attached build logs "build_failed.log" and "build_succesful.log". > They were both created from using the attached POM. The only difference is > that in the successful build the dependency > > > com.google.inject > > guice > > 3.0 > > > is moved to the very top of the dependency list. When diffing the two build > logs, the most important difference is that in the failed log maven picks up > these dependencies: > [DEBUG]com.google.inject:guice:jar:3.0:compile > while in the successful build, the same dependency looks like this: > [DEBUG]com.google.inject:guice:jar:3.0:compile > > [DEBUG] javax.inject:javax.inject:jar:1:compile > > [DEBUG] aopalliance:aopalliance:jar:1.0: > This translates for the successful build into: > [DEBUG] Classpath: > [/Users/henning/private/source/services/thetargetproject/target/classes > > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > /Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar > > [...] > and for the failed build: > [DEBUG] Classpath: [...] > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > [...] > (note that even for the successful build, the aopalliance dependency still > got dropped). > This behaviour started with maven 3.x, all permutations of the dependencies > build fine with maven 2.2.1 > This problem can be reproduced in all maven 3.0.x versions (.1, .2 and .3). > In both cases, the transitive dependencies of guice 3.0 > (javax.inject:javax.inject and aopalliance:aopalliance) should always be > present. > The same behaviour occurs in the exec-maven-plugin which uses the runtime > dependency path to execute java code. -- 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-5121) maven seems to lose transitive dependencies from the list of compilation dependencies
[ https://jira.codehaus.org/browse/MNG-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed MNG-5121. --- Resolution: Fixed Fix Version/s: 3.0.4 > maven seems to lose transitive dependencies from the list of compilation > dependencies > - > > Key: MNG-5121 > URL: https://jira.codehaus.org/browse/MNG-5121 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.1, 3.0.2, 3.0.3 > Environment: Fedora Linux, Sun JDK 1.6.0_24, MacOS X 10.6.7, AppleJDK > 1.6.0_24 >Reporter: Henning Schmiedehausen >Assignee: Jason van Zyl >Priority: Blocker > Fix For: 3.0.4 > > Attachments: build_failed.log, build_successful.log, maven-pom.xml, > mng-5121.tgz > > > See the attached build logs "build_failed.log" and "build_succesful.log". > They were both created from using the attached POM. The only difference is > that in the successful build the dependency > > > com.google.inject > > guice > > 3.0 > > > is moved to the very top of the dependency list. When diffing the two build > logs, the most important difference is that in the failed log maven picks up > these dependencies: > [DEBUG]com.google.inject:guice:jar:3.0:compile > while in the successful build, the same dependency looks like this: > [DEBUG]com.google.inject:guice:jar:3.0:compile > > [DEBUG] javax.inject:javax.inject:jar:1:compile > > [DEBUG] aopalliance:aopalliance:jar:1.0: > This translates for the successful build into: > [DEBUG] Classpath: > [/Users/henning/private/source/services/thetargetproject/target/classes > > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > /Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar > > [...] > and for the failed build: > [DEBUG] Classpath: [...] > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > [...] > (note that even for the successful build, the aopalliance dependency still > got dropped). > This behaviour started with maven 3.x, all permutations of the dependencies > build fine with maven 2.2.1 > This problem can be reproduced in all maven 3.0.x versions (.1, .2 and .3). > In both cases, the transitive dependencies of guice 3.0 > (javax.inject:javax.inject and aopalliance:aopalliance) should always be > present. > The same behaviour occurs in the exec-maven-plugin which uses the runtime > dependency path to execute java code. -- 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-5353) version ranges: Ignore qualifiers in exclusive upper bound [lw,up)
[ https://jira.codehaus.org/browse/MNG-5353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5353: --- Fix Version/s: (was: 3.x / Backlog) 3.1.0 > version ranges: Ignore qualifiers in exclusive upper bound [lw,up) > -- > > Key: MNG-5353 > URL: https://jira.codehaus.org/browse/MNG-5353 > Project: Maven 2 & 3 > Issue Type: Wish > Components: Dependencies >Affects Versions: 2.0.11, 2.2.1, 3.0.4 >Reporter: Jesse Long > Fix For: 3.1.0 > > > Please change the behaviour of exclusive upper bounds to the following: > In a version range, like [1.7.0,1.8.0), 1.8.0-alpha1 should not be included > in the range. 1.8.0* should not be included in the range. > This allows for us configure natural ranges for projects using semantic > versioning. > Please see: > http://markmail.org/message/4tubas4uok6ahbcp > http://markmail.org/message/s2ry2uru4ibub43q -- 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-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3092: --- Fix Version/s: 3.1.0 > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson > Fix For: 3.1.0 > > Attachments: MNG-3092.patch > > > Contrary to the 2.0 design docs: > "Resolution of dependency ranges should not resolve to a snapshot > (development version) unless it is included as an explicit boundary." > -- from > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification > The following is equates to true: > VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new > DefaultArtifactVersion( "1.1-SNAPSHOT" ) ) > The attached patch only allows snapshot versions to be contained in a range > if they are equal to one of the boundaries. Note that this is a strict > equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- 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-5353) version ranges: Ignore qualifiers in exclusive upper bound [lw,up)
[ https://jira.codehaus.org/browse/MNG-5353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-5353: --- Fix Version/s: 3.x / Backlog > version ranges: Ignore qualifiers in exclusive upper bound [lw,up) > -- > > Key: MNG-5353 > URL: https://jira.codehaus.org/browse/MNG-5353 > Project: Maven 2 & 3 > Issue Type: Wish > Components: Dependencies >Affects Versions: 2.0.11, 2.2.1, 3.0.4 >Reporter: Jesse Long > Fix For: 3.x / Backlog > > > Please change the behaviour of exclusive upper bounds to the following: > In a version range, like [1.7.0,1.8.0), 1.8.0-alpha1 should not be included > in the range. 1.8.0* should not be included in the range. > This allows for us configure natural ranges for projects using semantic > versioning. > Please see: > http://markmail.org/message/4tubas4uok6ahbcp > http://markmail.org/message/s2ry2uru4ibub43q -- 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-4733) project.build.directory should be settable by default
[
https://jira.codehaus.org/browse/MNG-4733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-4733.
--
Resolution: Won't Fix
> project.build.directory should be settable by default
> -
>
> Key: MNG-4733
> URL: https://jira.codehaus.org/browse/MNG-4733
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: POM
>Affects Versions: 2.2.1
>Reporter: Joseph Walton
>Priority: Minor
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: target-dir.diff
>
>
> I'd like to be able to use a different target directory for projects without
> having to edit their poms directly. I can set project.build.directory in my
> parent pom but would also like to be able to make the change when building
> third-party projects.
> I have two use cases.
> 1. A temporary build that doesn't affect the target directories used by
> Eclipse
> e.g. mvn -Dtarget.dir=target.tmp test
> 2. A complete build outside the source tree of a multi-module project
> e.g. mvn -Dtarget.dir=/tmp/build/\${project.artifactId} test
> I attach a simple patch to the superpom that allows this.
--
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-671) implement a license clickthrough
[ https://jira.codehaus.org/browse/MNG-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-671. - Resolution: Won't Fix > implement a license clickthrough > > > Key: MNG-671 > URL: https://jira.codehaus.org/browse/MNG-671 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Dependencies >Reporter: Brett Porter > Fix For: Issues to be reviewed for 3.x > > Attachments: maven-artifact-manager-patch-2.txt, > maven-artifact-manager-patch.txt, maven-artifact-patch-2.txt, > maven-license-patches-3.zip, maven-settings-patch-2.txt, > maven-settings-patch.txt > > > we need some basic license acceptance policy for downloadable artifacts. For > now, this can just be a Y/N that is saved forever. -- 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-5240) Error building beacon package using maven
[ https://jira.codehaus.org/browse/MNG-5240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5240. -- Resolution: Cannot Reproduce > Error building beacon package using maven > - > > Key: MNG-5240 > URL: https://jira.codehaus.org/browse/MNG-5240 > Project: Maven 2 & 3 > Issue Type: Task > Components: Errors >Affects Versions: 3.0.4 > Environment: Ubuntu 11.04 natty running over intel x86. I am using > maven for building Beacon openflow controller. >Reporter: Muhammad Junaid >Priority: Critical > Attachments: log.txt > > > I have downloaded the openflowj and beacon controllers from git repositories. > The openflowj controller successfully builds using the mvn install > instruction specified at > https://openflow.stanford.edu/display/Beacon/Running+Beacon+with+Apache+Felix. > Now when I try to build beacon controller, I am getting error that is > attached in the file log.txt. -- 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-5239) Maven integration developers would like to be able to override the maven logging appender.
[ https://jira.codehaus.org/browse/MNG-5239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313493#comment-313493 ] Jason van Zyl commented on MNG-5239: What do you mean by integration developer? In that you're trying to embed Maven in a host system? > Maven integration developers would like to be able to override the maven > logging appender. > -- > > Key: MNG-5239 > URL: https://jira.codehaus.org/browse/MNG-5239 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Logging >Affects Versions: 2.2.1 >Reporter: Paul Ryan > > Integrations with maven logging right now have to be down with primitive > piping that loses context of the log. A greatly improved mechanism would be > by allowing integration developers to control where and how logs are output > and give an much improved integration capability. > This could be achieved by exposing the logging configuration to the maven > user (through a configuration file such as the log4j.xml). -- 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-5219) Regression from M2: Installing non-existing artifact is silently ignored
[
https://jira.codehaus.org/browse/MNG-5219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-5219:
---
Assignee: Jason van Zyl
> Regression from M2: Installing non-existing artifact is silently ignored
>
>
> Key: MNG-5219
> URL: https://jira.codehaus.org/browse/MNG-5219
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3, 3.0.4
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: /home/kozelka/opt/apache-maven-3.0.3
> Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: ANSI_X3.4-1968
> OS name: "linux", version: "2.6.38-13-generic", arch: "amd64", family: "unix"
>Reporter: Petr Kozelka
>Assignee: Jason van Zyl
> Attachments: MNG-fail-install-ifnotfound.patch, pom.xml
>
>
> Maven 2.2.1 used to fail during "install" phase when an attached artifact did
> not exist.
> This is no longer true with version 3.0.3.
> To reproduce the bug, store attached pom.xml into an empty directory and try:
> a) maven 2.2.1 - use command "mvn clean install -e" to see the stacktrace:
> {noformat}
> [INFO] [install:install {execution: default-install}]
> [INFO] Installing /TESTDIR/pom.xml to
> /LOCALREPO/test/mvn/install/test-mvn-install/1-SNAPSHOT/test-mvn-install-1-SNAPSHOT.pom
> [INFO] Installing /TESTDIR/target/nonexistent.nonsense to
> /LOCALREPO/test/mvn/install/test-mvn-install/1-SNAPSHOT/test-mvn-install-1-SNAPSHOT.nonsense
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error installing artifact: File /TESTDIR/target/nonexistent.nonsense
> does not exist
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error installing
> artifact: File /TESTDIR/target/nonexistent.nonsense does not exist
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> 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)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error installing
> artifact: File /TESTDIR/target/nonexistent.nonsense does not exist
> at
> org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:143)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: org.apache.maven.artifact.installer.ArtifactInstallationException:
> Error installing artifact: File /TESTDIR/target/nonexistent.nonsense does not
> exist
> at
> org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:119)
> at
> org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:133)
> ... 19 more
> Caused by: java.io.IOException: File /TESTDIR/target/nonexistent.nonsense
> does not exist
> at hidden.org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:1003)
> at
> org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstall
[jira] (MNG-5198) Error in starting maven - nullpointerexception
[ https://jira.codehaus.org/browse/MNG-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5198. -- Resolution: Cannot Reproduce > Error in starting maven - nullpointerexception > -- > > Key: MNG-5198 > URL: https://jira.codehaus.org/browse/MNG-5198 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Errors >Affects Versions: 2.2.1 > Environment: windows XP >Reporter: pgp skr > Attachments: maven_error.bmp > > > When I run mvn --version I am getting the following error. > java.lang.NullPointerException: key can't be null > at java.lang.System.checkKey(System.java:773) > at java.lang.System.getProperty(System.java:649) > at > org.codehaus.classworlds.Configurator.configure(Configurator.java:240 > ) > at org.codehaus.classworlds.Launcher.configure(Launcher.java:156) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:426) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > The following are the settings done for Maven > set JAVA_HOME=D:/java/jdk1.6.0_02 > set M2_HOME=D:/ReadNew/apache-maven-2.2.1 > set M2=%M2_HOME%/bin > After referring to the link > (http://maven.40175.n5.nabble.com/Created-MNG-4865-mvn-fails-because-of-null-property-td3211656.html) > I added the following entry in m2.conf > set MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=256m > But still the error persists. > Could someone help me in resolving the same. -- 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-5183) NPE in ComponentValueSetter
[
https://jira.codehaus.org/browse/MNG-5183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5183.
--
Resolution: Cannot Reproduce
> NPE in ComponentValueSetter
> ---
>
> Key: MNG-5183
> URL: https://jira.codehaus.org/browse/MNG-5183
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0.3
> Environment: $ uname -a
> Linux kslv221 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64
> x86_64 x86_64 GNU/Linux
> Environment settings:{code}MAVEN_HOME=/opt/apache-maven-3.0.3
> PATH=/bin:/usr/bin:/opt/apache-maven-3.0.3/bin{code}
>Reporter: Ernst de Haan
>
> Here's part of the log tail:{code}[DEBUG] Configuring mojo
> org.mortbay.jetty:jetty-maven-plugin:7.4.5.v20110725:run-war from plugin
> realm ClassRealm[plugin>org.mortbay.jetty:jetty-maven-plugin:7.4.5.v20110725,
> parent: sun.misc.Launcher$AppClassLoader@35a16869]
> [DEBUG] Configuring mojo
> 'org.mortbay.jetty:jetty-maven-plugin:7.4.5.v20110725:run-war' with basic
> configurator -->
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Pluto . SUCCESS [0.528s]
> [INFO] Pluto Types ... SUCCESS [4.730s]
> [INFO] Pluto CAPI SUCCESS [4.567s]
> [INFO] Pluto Server .. FAILURE [12.077s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 22.073s
> [INFO] Finished at: Tue Oct 18 11:42:41 CEST 2011
> [INFO] Final Memory: 41M/411M
> [INFO]
>
> [ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at
> org.apache.maven.lifecycle.internal.BuilderCommon.handleBuildError(BuilderCommon.java:128)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:95)
> 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:537)
> 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)
> Caused by: java.lang.NullPointerException
> at
> org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:331)
> at
> org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:151)
> at
> org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.fromConfiguration(ObjectWithFieldsConverter.java:89)
> at
> org.codehaus.plexus.component.configurator.converters.composite.ArrayConverter.fromChildren(ArrayConverter.java:129)
> at
> org.codehaus.plexus.component.configurator.converters.composite.ArrayConverter.fromConfiguration(ArrayConverter.java:91)
> at
> org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:331)
> at
> org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:151)
> at
> org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56)
> at
> org.apache.maven.plugin.internal.DefaultMavenPl
[jira] (MNG-5016) A mirror's layout setting should default to 'default' since thats' the only layout supported lay in maven 3
[ https://jira.codehaus.org/browse/MNG-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-5016: --- Fix Version/s: 3.1.0 > A mirror's layout setting should default to 'default' since thats' the only > layout supported lay in maven 3 > --- > > Key: MNG-5016 > URL: https://jira.codehaus.org/browse/MNG-5016 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Settings >Affects Versions: 3.0.2 >Reporter: Hiram Chirino > Fix For: 3.1.0 > > Attachments: MNG-5016.patch > > > A mirror's layout setting should default to 'default' since thats' the only > layout supported lay in maven 3 and maven 2 barfs if you add that element to > the settings.xml file. > So you want a default value which will work with you mirror. And since only > 'default' layout mirrors work maven 3, this is the best option. -- 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-5181) New resolution from local repository is very confusing
[ https://jira.codehaus.org/browse/MNG-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5181: --- Assignee: Jason van Zyl > New resolution from local repository is very confusing > -- > > Key: MNG-5181 > URL: https://jira.codehaus.org/browse/MNG-5181 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3 >Reporter: Arnaud Heritier >Assignee: Jason van Zyl > > I just discover the change introduced in Maven 3.x to try to improve the > resolution mechanism and to avoid to use a local artifact which may not be > available in its remote repository : > https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository > Even if the feature is interesting it has several problems : > # When an artifact isn't accessible from its remote repository it isn't used > by maven which replies a classical "dependency not found error". It is really > annoying for a user with some Maven 2 skills which will have a look at his > local repo, will find the artifact and won't understand why Maven doesn't use > it. At least the error reported by Maven should be clear that even if the > dependency is available locally, it isn't used because it's remote repository > isn't available. > # This behavior cannot be configured to be only a warning for example. It is > really annoying because it doesn't take care of some context and constraints > we may have in a development team. Let's imagine that the remote artifact is > really removed. Cool Maven broke the build to warn us. But it brakes the > build of all the team whereas perhaps only one of them may try to solve the > issue (and it can be a long resolution). Thus having the ability to configure > if this control is blocker or warning may allow the team to configure it as > blocker on the CI server and as warning on the development environment. > # This behavior may introduce some bad practices for example when we are > using a staging feature on a repository manager. In our case my teams have a > dedicated profile to activate a staging repository when we are validating a > release. I recommend to not have this profile always activated but to do it > only on-demand to avoid them to DL staging stuffs they don't need. With this > new feature they need for all builds they run to activate this staging > profile while binaries are stored in it. When you have to do it 20 times per > day minimum let's imagine what the developer does : It adds it as an > alwaysActive profile and then forget to remove it when the release is ended. > For all these reason I would like we improve this feature to make it more > usable and before all bet understandable for ours users. -- 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-5167) relative local repository settings
[ https://jira.codehaus.org/browse/MNG-5167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5167: --- Assignee: Jason van Zyl > relative local repository settings > -- > > Key: MNG-5167 > URL: https://jira.codehaus.org/browse/MNG-5167 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Settings >Affects Versions: 3.0.3, 3.0.4 >Reporter: Jason Pyeron >Assignee: Jason van Zyl > Attachments: MNG-5167.patch > > > see patch -- 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-5122) MavenCli com.google.inject.internal.util.ComputationException: java.lang.NoClassDefFoundError: org/apache/maven/plugin/descriptor/MojoDescriptor
[
https://jira.codehaus.org/browse/MNG-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5122.
--
Resolution: Cannot Reproduce
> MavenCli com.google.inject.internal.util.ComputationException:
> java.lang.NoClassDefFoundError:
> org/apache/maven/plugin/descriptor/MojoDescriptor
>
>
> Key: MNG-5122
> URL: https://jira.codehaus.org/browse/MNG-5122
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Class Loading, Embedding
>Affects Versions: 3.0.3
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_16
> Java home: C:\Programme\Java\jdk1.6.0_16\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "x86" Family: "windows"
>Reporter: Kati Golbang
> Attachments: build.log, components.xml, pom.xml
>
>
> I want to use MavenCli in order to use Maven programatically within an
> installer (IzPack).
> pom.xml (see attachment).
> I'm using
>
> org.apache.maven
> maven-embedder
> 3.0-beta-3
>
> Note that all dependencies are unzipped and part of the final installer jar
> (target/product-installer.jar). The components.xml contains all available
> components.xml files (merged by plexus-component-metadata plugin).
> how to build: mvn -X clean install > build.log
> At runtime (java -Xdebug
> -Xrunjdwp:transport=dt_socket,server=y,address="8000" -jar
> target/wigeoweb-installer.jar) following code is executed:
> MavenCli cli = new MavenCli();
> int result = cli.doMain(new String[]{"compile -X"},
> "C:/Develop/Experiments/webservercontext-maven-plugin", //Own plugin
> System.out, System.out);
> System.out.println("result: " + result);
> It terminates with exception while initializing plexus container (there's the
> place where the debugger exits):
> Exception:
> Listening for transport dt_socket at address: 8000
> [ERROR] Error executing Maven.
> [ERROR] com.google.inject.internal.util.ComputationException:
> java.lang.NoClassDefFoundError:
> org/apache/maven/plugin/descriptor/MojoDescriptor
> [ERROR] Caused by: java.lang.NoClassDefFoundError:
> org/apache/maven/plugin/descriptor/MojoDescriptor
> [ERROR] Caused by: org/apache/maven/plugin/descriptor/MojoDescriptor
> [ERROR] Caused by: org.apache.maven.plugin.descriptor.MojoDescriptor
> Source Code:
> private void container( CliRequest cliRequest )
> throws Exception
> {
> if ( cliRequest.classWorld == null )
> { cliRequest.classWorld = new ClassWorld( "plexus.core",
> Thread.currentThread().getContextClassLoader() ); }
> DefaultPlexusContainer container = this.container;
> if ( container == null )
> {
> ContainerConfiguration cc = new DefaultContainerConfiguration()
> .setClassWorld( cliRequest.classWorld )
> .setName( "maven" );
> *container = new DefaultPlexusContainer( cc ); //<<
> EXCEPTION THROWN*
> container.setLoggerManager( new MavenLoggerManager( logger ) );
> container.getLoggerManager().setThresholds(
> cliRequest.request.getLoggingLevel() );
> customizeContainer( container );
> if ( cliRequest.classWorld == classWorld )
> { this.container = container; }
> }
> maven = container.lookup( Maven.class );
> executionRequestPopulator = container.lookup(
> MavenExecutionRequestPopulator.class );
> modelProcessor = createModelProcessor( container );
> settingsBuilder = container.lookup( SettingsBuilder.class );
> dispatcher = (DefaultSecDispatcher) container.lookup( SecDispatcher.class,
> "maven" );
> }
> thank you
> K. Golbang
--
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-5121) maven seems to lose transitive dependencies from the list of compilation dependencies
[ https://jira.codehaus.org/browse/MNG-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5121: --- Assignee: Jason van Zyl > maven seems to lose transitive dependencies from the list of compilation > dependencies > - > > Key: MNG-5121 > URL: https://jira.codehaus.org/browse/MNG-5121 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.1, 3.0.2, 3.0.3 > Environment: Fedora Linux, Sun JDK 1.6.0_24, MacOS X 10.6.7, AppleJDK > 1.6.0_24 >Reporter: Henning Schmiedehausen >Assignee: Jason van Zyl >Priority: Blocker > Attachments: build_failed.log, build_successful.log, maven-pom.xml, > mng-5121.tgz > > > See the attached build logs "build_failed.log" and "build_succesful.log". > They were both created from using the attached POM. The only difference is > that in the successful build the dependency > > > com.google.inject > > guice > > 3.0 > > > is moved to the very top of the dependency list. When diffing the two build > logs, the most important difference is that in the failed log maven picks up > these dependencies: > [DEBUG]com.google.inject:guice:jar:3.0:compile > while in the successful build, the same dependency looks like this: > [DEBUG]com.google.inject:guice:jar:3.0:compile > > [DEBUG] javax.inject:javax.inject:jar:1:compile > > [DEBUG] aopalliance:aopalliance:jar:1.0: > This translates for the successful build into: > [DEBUG] Classpath: > [/Users/henning/private/source/services/thetargetproject/target/classes > > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > /Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar > > [...] > and for the failed build: > [DEBUG] Classpath: [...] > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > [...] > (note that even for the successful build, the aopalliance dependency still > got dropped). > This behaviour started with maven 3.x, all permutations of the dependencies > build fine with maven 2.2.1 > This problem can be reproduced in all maven 3.0.x versions (.1, .2 and .3). > In both cases, the transitive dependencies of guice 3.0 > (javax.inject:javax.inject and aopalliance:aopalliance) should always be > present. > The same behaviour occurs in the exec-maven-plugin which uses the runtime > dependency path to execute java code. -- 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-5120) Reg:How to build a project when building another project implicitely
[ https://jira.codehaus.org/browse/MNG-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5120. -- Resolution: Not A Bug > Reg:How to build a project when building another project implicitely > > > Key: MNG-5120 > URL: https://jira.codehaus.org/browse/MNG-5120 > Project: Maven 2 & 3 > Issue Type: New Feature >Reporter: krishna prasad vurapalli > > When we are building a project and that project contains dependency from > another project then we have to add the dependency explicitly . Instead of > doing like that is there is any way to build the dependent project while > building the main project implicitly that is we have to take the project name > from the command prompt and that will be dependent project name and that > project has to be build first and then that dependency will be added to our > main project -- 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-5105) disable/enable repositories in settings.xml does not work
[ https://jira.codehaus.org/browse/MNG-5105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5105: --- Assignee: Jason van Zyl > disable/enable repositories in settings.xml does not work > - > > Key: MNG-5105 > URL: https://jira.codehaus.org/browse/MNG-5105 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.3 >Reporter: Jeremy Nguyen Xuan >Assignee: Jason van Zyl > > With the following configuration, Maven will resolve SNAPSHOT dependencies > from the first repository: > > > public > http://artifacts/content/groups/public > > true > > > false > > > > allowed-snapshots > http://artifacts/content/groups/allowed-snapshots/ > > true > > > > The expected behavior would be Maven to resolve only release versions from > the first repository, and snapshots versions from the second one. -- 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-5094) If POM's parent is not availabe in local repository then DefaultProjectBuilder is unable to resolve this parent while POM build
[ https://jira.codehaus.org/browse/MNG-5094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5094. -- Resolution: Cannot Reproduce > If POM's parent is not availabe in local repository then > DefaultProjectBuilder is unable to resolve this parent while POM build > --- > > Key: MNG-5094 > URL: https://jira.codehaus.org/browse/MNG-5094 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.3 > Environment: Linux, Using maven 3.0.3 apis to build a MavenProject > from a POM file via DefaultProjectBuilder. >Reporter: amaresh mourya > > I created a maven project via "mvn archetype:generate" with selection item > no as 3. Project I created was abc:xyz:1.0:jar. > I am using build( File pomFile, ProjectBuildingRequest request ) method of > DefaultProjectBuilder which returns ProjectBuildingResult containing > MavenProject of POM file. > Here is parent section of POM > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > 4.0.0 > > com.cedarsoft > open > 4.0.2 > > abc > xyz > 1.0 > --- > > Problem: My local repository doesn't contain com.cedarsoft:open:4.0.2. So > while building with this build method I was expecting it to download parent > (com.cedarsoft:open:4.0.2) and move ahead with the building work, but it > didn't happen. This used to happen with maven 2.2.1 apis using > DefaultMavenProjectBuilder. > I debugged and found that while resolving parent (com.cedarsoft:open:4.0.2) > repositories list is empty whereas it should provide Central repository from > Super POM to resolve this parent artifact. This used to happen with maven > 2.2.1 apis > What I did to avoid this : Either I add central repository in my POM or add > Central repository in ProjectBuildingRequest. > So I think this is a bug of maven 3.0.3 where its unable to pass central > repository while resolving artifacts. -- 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-5085) Add a CLI option to ignore missing modules
[ https://jira.codehaus.org/browse/MNG-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5085. -- Resolution: Won't Fix > Add a CLI option to ignore missing modules > -- > > Key: MNG-5085 > URL: https://jira.codehaus.org/browse/MNG-5085 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Reactor and workspace >Reporter: Stephan Pauxberger > > Using SVN for a rather big project, we tend to use SVN sparse checkouts, i.e. > we do not checkout the whole project. Example: > Full Project (as in Repository): > Parent > pom.xml (contains A and B as modules) > --> A > pom.xml > --> B > pom.xml > Now, do a checkout (svn co xxx --depth children; svn update --set-depth > inifity A) > Working Copy: > Parent > pom.xml (contains A and B as modules) > --> A > pom.xml > --> B (no pom!!, since we only did a sparse checkout) > Now, this setup is not buildable, since maven complains (rightfully) about a > missing pom for B. > What I propose is an option to change this behaviour with a command-line > option (-imm, --ignore-missing-modules) that would simply ignore missing > modules during pom resolution. -- 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-5087) Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted
[
https://jira.codehaus.org/browse/MNG-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-5087:
---
Assignee: Jason van Zyl
> Maven 3 dependency resolution fails until maven-metadata-local.xml files
> (created by maven-invoker-plugin) are deleted
> --
>
> Key: MNG-5087
> URL: https://jira.codehaus.org/browse/MNG-5087
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies, Integration Tests
>Affects Versions: 3.0.2, 3.0.3
> Environment: Mac OS X 10.6.x, Java 1.6.0_24
>Reporter: Chas Emerick
>Assignee: Jason van Zyl
>
> In one of my Maven projects, dependency resolution will succeed once, then
> fail for later build attempts:
> {code}
> [WARNING] The POM for commons-logging:commons-logging:jar:1.1.1 is missing,
> no dependency information available
> [WARNING] The POM for commons-httpclient:commons-httpclient:jar:3.1 is
> missing, no dependency information available
> [WARNING] The POM for javax.mail:mail:jar:1.4.4 is missing, no dependency
> information available
> {code}
> ...and so on, until I delete the {{maven-metadata-local.xml}} files
> corresponding to the failing artifacts (e.g.
> {{~/.m2/repository/commons-logging/commons-logging/maven-metadata-local.xml}}),
> which appear to be created by maven-invoker-plugin:install. After those
> files are deleted, the next {{mvn}} invocation proceeds properly; the
> metadata files are restored by that invocation (presumably as part of the
> process of checking my upstream repositories/mirrors for updated artifacts),
> and I am again presented with the above errors until I again delete the
> metadata files.
> This is repeatable, even after starting with a completely fresh local
> repository. Note that Maven 2.2.1 does *NOT* exhibit this problem.
> FYI, I'm not using an integration-testing-only local repo
> [http://maven.apache.org/plugins/maven-invoker-plugin/install-mojo.html#localRepositoryPath|as
> described here], simply because doing so causes the re-downloading of all
> transitive dependencies
> ([http://maven.apache.org/plugins/maven-invoker-plugin/examples/fast-use.html|unless
> you want to maintain an integration-specific settings.xml file!!!]). I've
> used the invoker plugin with a variety of other projects in this way with
> good results ([http://github.com/clojure/tools.nrepl|example]) -- certainly
> never encountering a borked local repository in the process like this.
> Here's an affected project:
> [https://github.com/cemerick/rummage/tree/1.3.0-compat|the 1.3.0-compat
> branch of rummage]. To reproduce, just clone that repo, checkout
> {{1.3.0-compat}}, and:
> {code}
> > mvn clean test
> # no error -- can run this and other builds that don't involve
> maven-invoker-plugin all day w/o problems
> > mvn clean integration-test
> # FAIL: "Could not resolve dependencies", with warnings as noted above
> > mvn clean test
> # FAIL: "Could not resolve dependencies", with warnings as noted above
> {code}
> Once the local repository is broken (by the generation of the
> {{maven-metadata-local.xml}} files, AFAICT), no builds will get past the
> dependency resolution stage.
> Running mvn -X reveals lines like this for each artifact that is later
> apparently not found:
> {code}
> [DEBUG] Verifying availability of
> /Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar from []
> {code}
> Of course,
> {{/Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar}} et al.
> does exist, as does
> {{/Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.pom}}.
> I'm assuming this is a bug in Maven 3's core dependency resolution mechanisms
> (as opposed to maven-invoker-plugin) since Maven 2.2.1 doesn't exhibit the
> behaviour.
--
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-5084) Resolver for plugins failing
[ https://jira.codehaus.org/browse/MNG-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313492#comment-313492 ] Jason van Zyl commented on MNG-5084: Aether is now at 1.13.1. Seems this resolves your issue. > Resolver for plugins failing > > > Key: MNG-5084 > URL: https://jira.codehaus.org/browse/MNG-5084 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.3 > Environment: JDK 1.6.24, Mac OS X >Reporter: Richard Vowles >Priority: Critical > Attachments: Screen shot 2011-05-12 at 10.43.05 PM.png, > simple-plugin.tar > > > We are at a standstill with the easyb plugin for maven as we cannot get it to > resolve artefacts when doing its integration tests. Installing it without > them and then using it also fails with resolution problems. > I downloaded the source and did a remote debug, the resolution seems to > *require* that the artefact that is missing be deployed locally, even if > these artefacts are in central and are listed in the _maven.repositories file > as being from central. It seems to be looking for them as > groovy-all-1.7.10.jar>= (for example) even when there is a > groovy-all-1.7.10.jar>central= and it has previously just downloaded it from > central. > I have created a trivial sample, that builds nothing but has an integration > test (which also fails). To reproduce, you need to have *no* settings.xml and > clear your repository out (rename it to something else) so you have what > appears to be a bare repo. Then run a mvn clean verify (using 3.0.3) and it > builds, installs the plugin, runs the integration test and fails. If you edit > the integration test and specify the version and mvn clean verify again, it > still fails (so it has nothing to do with the invoker plugin). -- 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-5084) Resolver for plugins failing
[ https://jira.codehaus.org/browse/MNG-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5084. -- Resolution: Fixed > Resolver for plugins failing > > > Key: MNG-5084 > URL: https://jira.codehaus.org/browse/MNG-5084 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.3 > Environment: JDK 1.6.24, Mac OS X >Reporter: Richard Vowles >Priority: Critical > Attachments: Screen shot 2011-05-12 at 10.43.05 PM.png, > simple-plugin.tar > > > We are at a standstill with the easyb plugin for maven as we cannot get it to > resolve artefacts when doing its integration tests. Installing it without > them and then using it also fails with resolution problems. > I downloaded the source and did a remote debug, the resolution seems to > *require* that the artefact that is missing be deployed locally, even if > these artefacts are in central and are listed in the _maven.repositories file > as being from central. It seems to be looking for them as > groovy-all-1.7.10.jar>= (for example) even when there is a > groovy-all-1.7.10.jar>central= and it has previously just downloaded it from > central. > I have created a trivial sample, that builds nothing but has an integration > test (which also fails). To reproduce, you need to have *no* settings.xml and > clear your repository out (rename it to something else) so you have what > appears to be a bare repo. Then run a mvn clean verify (using 3.0.3) and it > builds, installs the plugin, runs the integration test and fails. If you edit > the integration test and specify the version and mvn clean verify again, it > still fails (so it has nothing to do with the invoker plugin). -- 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=313491#comment-313491
]
Olivier Lamy commented on WAGON-381:
must be fixed with
https://git-wip-us.apache.org/repos/asf/maven-wagon/repo?p=maven-wagon.git;a=commit;h=b8ca4254b1f5a828e7b1347c49b5f14bbb59e30b
You can try last maven 3.1 snapshot available here
https://builds.apache.org/view/M-R/view/Maven/job/maven-3.0.x/
@since build #365
> 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
> 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] (MNG-5080) revert separation of plugin and dependency repositories
[ https://jira.codehaus.org/browse/MNG-5080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5080: --- Assignee: Jason van Zyl > revert separation of plugin and dependency repositories > --- > > Key: MNG-5080 > URL: https://jira.codehaus.org/browse/MNG-5080 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.1, 3.0.2, 3.0.3 >Reporter: Mark Struberg >Assignee: Jason van Zyl > > I fear we need to rethink the changes done in MNG-4191. > While expressing my dislike about the strict classpath separation on IRC a > few times already since quite a few months, this now really turns out into > having a hugely negative kickback. > Basically every business project I saw being upgraded to maven3 compat got > all their sections dupped into . > This can't be it! > The reason for it is that _lots_ of plugins need dependencies to 'normal' > artifacts. > * hibernate-maven-plugin > * jboss-maven-plugin > * tomcat-maven-plugin > * openjpa-maven-plugin > * cargo > you name it ... > basically ALL plugins which serve as helper for any 3rd party libraries and > products. > In addition, this problem also hits all use cases where plugins get > 'resources' via dependencies, like: > * maven-checkstyle-plugin > * maven-pmd-plugin > * emma-maven-plugin > * maven-remote-resources-plugin > * etc > Have you ever had one project which uses _none_ of those plugins? Then you > are happy and don't need that. But for all other projects there is a good > chance that you will end up duplicating all your repository sections as > pluginRepository ... > In most of our Apache projects this just doesn't show off because > maven.central is by default defined as both and > . But once you hit a company situation, you will get this > problem > Jason already proposed to drop the section completely in > MNG-2750. > Maybe that's the way to go? -- 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-5059) --also-make-phase
[
https://jira.codehaus.org/browse/MNG-5059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-5059:
---
Assignee: Jason van Zyl
> --also-make-phase
> -
>
> Key: MNG-5059
> URL: https://jira.codehaus.org/browse/MNG-5059
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.0.3
>Reporter: Jesse Glick
>Assignee: Jason van Zyl
>
> Background:
> http://mail-archives.apache.org/mod_mbox/maven-dev/201104.mbox/%3Cincnbn$4kl$1...@dough.gmane.org%3E
> {{--also-make}} (with {{--projects}}) is useful, but suffers from the problem
> that dependent projects are always built to the same goal/phase as the
> selected project(s). That is fine for e.g. {{compile}} or {{install}}, but
> not for e.g. {{test}} where you would only want to build {{compile}} (or
> {{test-compile}}) for dependencies, not actually test them.
> Suggest a variant form of this parameter (say {{--also-make-phase}} /
> {{-amp}}) which would accept a goal or phase to run on dependencies in place
> of the regular arguments. For example, to run a unit test after making sure
> all its dependencies have been (re-)compiled:
> {noformat}
> mvn -amp test-compile -pl testedmod test -Dtest=OneTest
> {noformat}
> or to run an (unpacked) web application after (re-)compiling libraries it
> uses:
> {noformat}
> mvn -amp compile -pl webapp jetty:run
> {noformat}
> You might want to pass a goal rather than a phase, so the name could be
> misleading, but I think that would be a rarer use case. Ditto passing
> multiple goals/phases for the upstream projects.
--
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:all-tabpanel
]
Olivier Lamy closed WAGON-381.
--
Resolution: Fixed
Fix Version/s: 2.3
Assignee: Olivier Lamy
> 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] (MNG-5016) A mirror's layout setting should default to 'default' since thats' the only layout supported lay in maven 3
[ https://jira.codehaus.org/browse/MNG-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5016. -- Resolution: Fixed > A mirror's layout setting should default to 'default' since thats' the only > layout supported lay in maven 3 > --- > > Key: MNG-5016 > URL: https://jira.codehaus.org/browse/MNG-5016 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Settings >Affects Versions: 3.0.2 >Reporter: Hiram Chirino > Attachments: MNG-5016.patch > > > A mirror's layout setting should default to 'default' since thats' the only > layout supported lay in maven 3 and maven 2 barfs if you add that element to > the settings.xml file. > So you want a default value which will work with you mirror. And since only > 'default' layout mirrors work maven 3, this is the best option. -- 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-5016) A mirror's layout setting should default to 'default' since thats' the only layout supported lay in maven 3
[ https://jira.codehaus.org/browse/MNG-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313490#comment-313490 ] Jason van Zyl commented on MNG-5016: Patch applied. > A mirror's layout setting should default to 'default' since thats' the only > layout supported lay in maven 3 > --- > > Key: MNG-5016 > URL: https://jira.codehaus.org/browse/MNG-5016 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Settings >Affects Versions: 3.0.2 >Reporter: Hiram Chirino > Attachments: MNG-5016.patch > > > A mirror's layout setting should default to 'default' since thats' the only > layout supported lay in maven 3 and maven 2 barfs if you add that element to > the settings.xml file. > So you want a default value which will work with you mirror. And since only > 'default' layout mirrors work maven 3, this is the best option. -- 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-5053) Remove obsolete debugger arguments
[
https://jira.codehaus.org/browse/MNG-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313489#comment-313489
]
Jason van Zyl commented on MNG-5053:
Removed from launch scripts.
> Remove obsolete debugger arguments
> --
>
> Key: MNG-5053
> URL: https://jira.codehaus.org/browse/MNG-5053
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.0.3
>Reporter: Jesse Glick
>Priority: Minor
> Attachments: x.diff
>
>
> {{-Xnoagent -Djava.compiler=NONE}} are long obsolete options for debugging.
> See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4516835
--
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-5053) Remove obsolete debugger arguments
[
https://jira.codehaus.org/browse/MNG-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5053.
--
Resolution: Fixed
> Remove obsolete debugger arguments
> --
>
> Key: MNG-5053
> URL: https://jira.codehaus.org/browse/MNG-5053
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.0.3
>Reporter: Jesse Glick
>Priority: Minor
> Attachments: x.diff
>
>
> {{-Xnoagent -Djava.compiler=NONE}} are long obsolete options for debugging.
> See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4516835
--
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-5045) SnapshotTransformation class missing in maven 3.0.* series
[ https://jira.codehaus.org/browse/MNG-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5045: --- Assignee: Jason van Zyl > SnapshotTransformation class missing in maven 3.0.* series > -- > > Key: MNG-5045 > URL: https://jira.codehaus.org/browse/MNG-5045 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build, Class Loading, Dependencies, Errors >Affects Versions: 3.0.1, 3.0.2, 3.0.3 > Environment: Linux (Ubuntu) most likely all platforms >Reporter: bryan hunt >Assignee: Jason van Zyl >Priority: Blocker > > The class org/apache/maven/artifact/transform/SnapshotTransformation was > originally (apache-maven-2.2.1) bundled in maven-2.2.1-uber.jar > However this is now missing from maven 3.0.* releases. > As a result, one of the flex-mojo's sonatype project goals breaks when run > under maven 3.0.* series. > The bug report is here. > https://issues.sonatype.org/browse/FLEXMOJOS-397 > It's been marked as Fixed as the developer is adamant that API compatability > is supposed to be maintained between Maven 2 and 3 series but is very much > still active. > There are no more releases planned in that series but it is depended upon by > many developers. > Best Regards, > Bryan Hunt -- 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-4980) Shared local repository
[ https://jira.codehaus.org/browse/MNG-4980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-4980. -- Resolution: Won't Fix > Shared local repository > --- > > Key: MNG-4980 > URL: https://jira.codehaus.org/browse/MNG-4980 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Artifacts and Repositories >Affects Versions: 3.2 >Reporter: Markus KARG >Priority: Minor > > Execution speed of mvn is directly dependent to the fact that there are lots > of artifacts to get resolved via internet (or even slow LANs). To reduce the > impact of the internet's delay, one can use artifact managers like Nexus > serving as a cache to all LAN users. To reduce the impact of the LAN's delay, > mvn uses a local repository serving as a cache to all local users. > But that local cache (.m2/repository) is private to the user. While it makes > sense that there is a private repository for every user (e. g. so one user is > not able to install manually into other user's repository, or so one user > cannot see really private things of another user), it makes no sense that > there is no shared cache for all users. > My proposal would be that mvn splits the local repository into two parts. The > first part is a cache used by all users of that machine (which could be > hundreds in case of terminal servers or university class room machines) (on > Windows best located at %PROGRAMDATA%\.m2\repository). It gets filled solely > by downloading from a private or public repository, but one cannot install > into that to keep privacy and stability. The second part is the existing > repository (%USERPROFILE%\.m2\repository) and it gets filled only by manual > installing using mvn install. > Thanks to this splitting, chances are good that shared machines will have > latest dependencies stored locally already, reducing LAN delay. Builds run > faster then. Also, the user's own local repository is much cleaner then, > showing only his own manually installed projects, but not cached dependencies. -- 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:all-tabpanel
]
Olivier Lamy moved MNG-4977 to WAGON-381:
-
Complexity: (was: Intermediate)
Component/s: (was: Dependencies)
wagon-http
Affects Version/s: (was: 3.0.2)
2.2
Key: WAGON-381 (was: MNG-4977)
Project: Maven Wagon (was: Maven 2 & 3)
> 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
> 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] (MINVOKER-124) Reporting the reason for skipping an integration tests
[ https://jira.codehaus.org/browse/MINVOKER-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313485#comment-313485 ] Robert Scholte commented on MINVOKER-124: - Here's the fix for the commandline: [r1408974|http://svn.apache.org/viewvc?rev=1408974&view=rev] > Reporting the reason for skipping an integration tests > -- > > Key: MINVOKER-124 > URL: https://jira.codehaus.org/browse/MINVOKER-124 > Project: Maven 2.x Invoker Plugin > Issue Type: Improvement >Affects Versions: 1.5 >Reporter: Karl Heinz Marbaise >Priority: Minor > > If i have a selector-condition which defines to run a particular integration > test only for a particular Maven version it would be nice that in the report > which can be generated (report goal) a message will appear which says > "ignored, based on selector condition". This will also be true for the > summary output during run in command line. -- 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-5376) Account for changes between the Apple and Oracle JDKs on OSX
[ https://jira.codehaus.org/browse/MNG-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313484#comment-313484 ] Paul Benedict commented on MNG-5376: FWIW, I see the Eclipse IDE is working on the same problem: https://bugs.eclipse.org/bugs/show_bug.cgi?id=368483 > Account for changes between the Apple and Oracle JDKs on OSX > > > Key: MNG-5376 > URL: https://jira.codehaus.org/browse/MNG-5376 > Project: Maven 2 & 3 > Issue Type: Task >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 3.1.0 > > > With the arrival of Java 7 on OSX the directory locations and naming has > changed. Some changes need to be made in the launch scripts to account for > the changes. -- 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-2016) Document how to create a mirror of Ibiblio
[ https://jira.codehaus.org/browse/MNG-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313483#comment-313483 ] Jason van Zyl commented on MNG-2016: Ibiblio no longer allows rsyncs because of the load. > Document how to create a mirror of Ibiblio > -- > > Key: MNG-2016 > URL: https://jira.codehaus.org/browse/MNG-2016 > Project: Maven 2 & 3 > Issue Type: Task > Components: Artifacts and Repositories, Documentation: General >Reporter: Trygve Laugstol > Fix For: Documentation Deficit > > > Tips on what this document could include: > o Find a pointer to the list of Ibiblio mirrors > o Give an example command line for at least rsync, wget and curl where the > two last ones will use ftp > o Give an example cron expression and /etc/cron.d/ file that's useful for > making a mirrors including setting the correct permissions > o Give an example Apache configuration on how to configure Apache to serve > the mirror > This document should possibly be a part of > http://maven.apache.org/guides/mini/guide-mirror-settings.html -- 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-2016) Document how to create a mirror of Ibiblio
[ https://jira.codehaus.org/browse/MNG-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2016. -- Resolution: Not A Bug > Document how to create a mirror of Ibiblio > -- > > Key: MNG-2016 > URL: https://jira.codehaus.org/browse/MNG-2016 > Project: Maven 2 & 3 > Issue Type: Task > Components: Artifacts and Repositories, Documentation: General >Reporter: Trygve Laugstol > Fix For: Documentation Deficit > > > Tips on what this document could include: > o Find a pointer to the list of Ibiblio mirrors > o Give an example command line for at least rsync, wget and curl where the > two last ones will use ftp > o Give an example cron expression and /etc/cron.d/ file that's useful for > making a mirrors including setting the correct permissions > o Give an example Apache configuration on how to configure Apache to serve > the mirror > This document should possibly be a part of > http://maven.apache.org/guides/mini/guide-mirror-settings.html -- 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-1381) best practices: testing strategies
[ https://jira.codehaus.org/browse/MNG-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1381. -- Resolution: Duplicate > best practices: testing strategies > -- > > Key: MNG-1381 > URL: https://jira.codehaus.org/browse/MNG-1381 > Project: Maven 2 & 3 > Issue Type: Task > Components: Design, Patterns & Best Practices >Affects Versions: 2.0 >Reporter: Vincent Massol > Fix For: Documentation Deficit > > > The wiki page used to collect feedback is: > http://docs.codehaus.org/display/MAVEN/Testing+Strategies -- 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-4039) Allow plugins the chance to alter the project artifacts/dependencies during 'resolution phase'
[ https://jira.codehaus.org/browse/MNG-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-4039. -- Resolution: Won't Fix > Allow plugins the chance to alter the project artifacts/dependencies during > 'resolution phase' > -- > > Key: MNG-4039 > URL: https://jira.codehaus.org/browse/MNG-4039 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Dependencies, IDEs, Plugin API, Plugins and Lifecycle, > POM >Affects Versions: 3.0-alpha-2 > Environment: n/a >Reporter: Steve Ebersole >Assignee: Jason van Zyl > Fix For: 3.x / Backlog > > > The term 'resolution phase' was taken from an email on this subject : > http://www.nabble.com/Re%3A-Programmatically-adding-dependencies-to-a-MavenProject-p21668701.html > Basically, there are times when a plugin could add dependencies to the > project dependency tree in an effort to alleviate the project pom developer > from unnecessary ugliness. My particular use-case is very fitting imo. In > trying to write a plugin for antlr's gunit functionality. gUnit is a > mechanism for generating JUnit tests for testing antlr grammars; it uses an > antlr grammar itself to describe the tests. Typically, a project using > antlr3 is going to define a dependency on the org.antlr:antlr-runtime > artifact, since that artifact contains all the classes needed to utilize > antlr in the runtime as well as all that need to be exposed via transitive > dependencies. However, during build-time, a project using antlr is also > going to need access to the org.antlr:antlr artifact which defines all the > classes needed for grammar -> java-class transformations. As an > "anti-example", currently the antlr3 plugin handles this by defining a "hard > dependency" to a particular version of org.antlr:antlr in its pom even if > that version is a mismatch from the one used by the project. Wouldn't it be > great if the plugin were allowed to be smart enough to say "hey, the project > to which I am attached is using org.antlr:antlr-runtime:3.1.0 so i really > should be using org.antlr:antlr:3.1.0 for grammar transformation"? And in > the case of the antlr3 plugin it actually can do this already because it does > not need to muck with any of the project classpaths in order to do this. But > in the case of this gunit example, that is not the case. As I said, gunit > generates JUnit test classes which should then get picked up by the normal > surefire mechanism and executed. The issue is that these gunit-generated > JUnit classes have dependencies on gunit classes, so gunit must be available > on the test compilation classpath. Following along with the discussion > above, it would be fantastic if the plugin could handle all these details for > the project and prepare the classpath properly. > One possibility for implementing this is a new method on > org.apache.maven.plugin.Mojo. Another is a new optional mojo interface like > org.apache.maven.plugin.DependencyContributingMojo -- 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-5336) Descriptor Reference for settings.xml is incorrect
[ https://jira.codehaus.org/browse/MNG-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg reassigned MNG-5336: Assignee: Dennis Lundberg > Descriptor Reference for settings.xml is incorrect > -- > > Key: MNG-5336 > URL: https://jira.codehaus.org/browse/MNG-5336 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Settings >Affects Versions: 3.0.4 >Reporter: Jan Hänsli >Assignee: Dennis Lundberg > Fix For: 3.1.0 > > > The example settings.xml found here > (http://maven.apache.org/ref/3.0.4/maven-settings/settings.html) is not valid! > 65: > 66: value > 67: > bad line 67: > correct line 67: > Steps to reproduce: > - Copy & Paste the document into your IDE or XML editor. > - Start the xml validator and try to validate the document against > http://maven.apache.org/xsd/settings-1.1.0.xsd -- 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-5354) Integrate Eclipse Aether 0.0.9.M2
[ https://jira.codehaus.org/browse/MNG-5354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5354: --- Summary: Integrate Eclipse Aether 0.0.9.M2 (was: use Eclipse Aether) > Integrate Eclipse Aether 0.0.9.M2 > - > > Key: MNG-5354 > URL: https://jira.codehaus.org/browse/MNG-5354 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Artifacts and Repositories >Affects Versions: 3.0.4 >Reporter: Herve Boutemy >Assignee: Jason van Zyl > Fix For: 3.1.1 > > > Aether migrated from Sonatype (groupId org.sonatype.aether) to Eclipse > (groupId org.eclipse.aether) > this will cause an API incompatible change, since the Eclipse API is very > similar but in org.eclipse.aether.* java packages -- 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-5207) [Regression] Maven 3 fails to calculate proper build order
[ https://jira.codehaus.org/browse/MNG-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5207: --- Assignee: Kristian Rosenvold > [Regression] Maven 3 fails to calculate proper build order > -- > > Key: MNG-5207 > URL: https://jira.codehaus.org/browse/MNG-5207 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 3.0.3 >Reporter: Jörg Schaible >Assignee: Kristian Rosenvold >Priority: Critical > Fix For: 3.1.0 > > Attachments: mng5207-it.tgz, MNG-5207.tgz > > > Maven 3.0.3 and 3.0.4 RC1 fails to build the projects of the reactor in > proper order, if a transitive dependency (that is part of the reactor build) > is overruled in the dependencyManagement section with the current SNAPSHOT > version. Build order is perfectly calculated with Maven 2.2.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] (SUREFIRE-925) All includes and excludes to be read from files
[ https://jira.codehaus.org/browse/SUREFIRE-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313478#comment-313478 ] Jason Dillon commented on SUREFIRE-925: --- Pull updated with integration tests. > All includes and excludes to be read from files > --- > > Key: SUREFIRE-925 > URL: https://jira.codehaus.org/browse/SUREFIRE-925 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.12.4 >Reporter: Jason Dillon > > Allow includesFile and excludesFile configuration parameters on > surefire/failsafe test mojos. -- 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] (MINVOKER-145) Add option to set environment variables
[ https://jira.codehaus.org/browse/MINVOKER-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MINVOKER-145. --- Resolution: Fixed Assignee: Robert Scholte Fixed in [r1408853|http://svn.apache.org/viewvc?rev=1408853&view=rev] > Add option to set environment variables > --- > > Key: MINVOKER-145 > URL: https://jira.codehaus.org/browse/MINVOKER-145 > Project: Maven 2.x Invoker Plugin > Issue Type: New Feature >Affects Versions: 1.7 >Reporter: Robert Scholte >Assignee: Robert Scholte > -- 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-927) configFailurePolicy is not supported on Surefire plugin though it is supported on TestNG ant task
[ https://jira.codehaus.org/browse/SUREFIRE-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-927. --- Resolution: Fixed Fix Version/s: 2.13 Assignee: Kristian Rosenvold Fixed in fd26b2dd8fbce647d749e0a48e44aa6a20c09f69, thanks for the pull request! > configFailurePolicy is not supported on Surefire plugin though it is > supported on TestNG ant task > - > > Key: SUREFIRE-927 > URL: https://jira.codehaus.org/browse/SUREFIRE-927 > Project: Maven Surefire > Issue Type: Improvement > Components: TestNG support >Affects Versions: 2.12.4 >Reporter: Kobi Kisos >Assignee: Kristian Rosenvold > Fix For: 2.13 > > > configFailurePolicy is not supported on Surefire plugin though it is > supported on TestNG ant task > configFailurePolicy - Whether TestNG should continue to execute the remaining > tests in the suite or skip them if an @Before* method fails. -- 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-404) Goal archetype:integration-test fails with StringIndexOutOfBoundsException
[ https://jira.codehaus.org/browse/ARCHETYPE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313464#comment-313464 ] Patrizia Mottl commented on ARCHETYPE-404: -- are there any news on this issue. We ended up with the same problem and spent a long time to find out, that when we only include modules in the top level and one level below it works but if we add another sublevel it will fail with this StringIndexOutOfBoundxExepction in the plugin. > Goal archetype:integration-test fails with StringIndexOutOfBoundsException > -- > > Key: ARCHETYPE-404 > URL: https://jira.codehaus.org/browse/ARCHETYPE-404 > Project: Maven Archetype > Issue Type: Bug > Components: Generator >Affects Versions: 2.2 >Reporter: Roland Schaer > Attachments: ARCHETYPE-404.patch, debug.log > > > Under some circumstances the integration test fails with a > StringIndexOutOfBoundsException. -- 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] (MINVOKER-143) Update Maven Invoker to 2.1.1
[ https://jira.codehaus.org/browse/MINVOKER-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MINVOKER-143. --- Resolution: Fixed Fix Version/s: 1.8 Assignee: Robert Scholte Fixed in [r1408778|http://svn.apache.org/viewvc?rev=1408778&view=rev] > Update Maven Invoker to 2.1.1 > - > > Key: MINVOKER-143 > URL: https://jira.codehaus.org/browse/MINVOKER-143 > Project: Maven 2.x Invoker Plugin > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 1.8 > > -- 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] (MINVOKER-143) Update Maven Invoker to 2.1.1
[ https://jira.codehaus.org/browse/MINVOKER-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MINVOKER-143: Issue Type: Improvement (was: Bug) > Update Maven Invoker to 2.1.1 > - > > Key: MINVOKER-143 > URL: https://jira.codehaus.org/browse/MINVOKER-143 > Project: Maven 2.x Invoker Plugin > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Robert Scholte > -- 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] (MSHARED-261) DefaultInvoker does not set M2_HOME
Bernd Vogt created MSHARED-261:
--
Summary: DefaultInvoker does not set M2_HOME
Key: MSHARED-261
URL: https://jira.codehaus.org/browse/MSHARED-261
Project: Maven Shared Components
Issue Type: Bug
Components: maven-invoker
Environment: * Win7 x64
* JDK 6
Reporter: Bernd Vogt
Attachments: maven-invocation-its.zip
*Problem:*
Recently, some of our releases failed because the maven-release-plugin has not
re-used the Maven installation with which it was launched to perform the actual
release goals. It was noticeable that the release plugin has used the Maven
installation where the M2_HOME variable of the current machine has pointed to...
After some investigation, I figured out, that the DefaultInvoker doesn't
propagate the Maven home directory to the M2_HOME env var of invoked Maven
processes but uses the mvn.bat of those Maven. The problem ist, that mvn.bat at
first looks-up for M2_HOME to launch the Maven which is located there... So, if
M2_HOME is already set this takes effect and not the Maven where the invoked
mvn.bat is contained in...
*Workaround for release problem:*
Configure release plugin to use the Maven executor 'forked-path' instead of
'invoke'
*Workaround when using Invoker:*
{{request.addShellEnvironment("M2_HOME",
invoker.getMavenHome().getAbsolutePath());}}
*Steps to reproduce:*
# Download and unzip attached test project
# cd to unzipped folder and {{mvn clean verify}}
# Take a look at contained {{DefaultInvokerIT}}
--
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-4572) element in pom does not allow whitespace around version string
[
https://jira.codehaus.org/browse/MNG-4572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313457#comment-313457
]
Dimitri Alexeev commented on MNG-4572:
--
Is there any chance to fix this also in the 2.2.x branch?
> element in pom does not allow whitespace around version string
> -
>
> Key: MNG-4572
> URL: https://jira.codehaus.org/browse/MNG-4572
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.2.1
>Reporter: jonathan gold
>Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-3
>
> Attachments: pom.xml, t.txt
>
>
> I'm using 2.2.x and was surprised to find that, while valid XML, the
> following are not valid in a pom.xml:
> 4.0.0
> or
> 4.0.0
> I had expected that the maven xml parser would be normalizing the whitespace,
> but looked in
> maven-2.2.x/maven-project/src/main/java/org/apache/maven/project/DefaultMavenProjectBuilder.java
> and found this in readModel(), line 1609:
> if ( modelSource.indexOf( "" + MAVEN_MODEL_VERSION ) < 0 ) {
> throw new InvalidProjectModelException( projectId, pomLocation, "Not
> a v" + MAVEN_MODEL_VERSION + " 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] (SUREFIRE-927) configFailurePolicy is not supported on Surefire plugin though it is supported on TestNG ant task
[ https://jira.codehaus.org/browse/SUREFIRE-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313456#comment-313456 ] Kobi Kisos commented on SUREFIRE-927: - Opened pull request https://github.com/apache/maven-surefire/pull/9 > configFailurePolicy is not supported on Surefire plugin though it is > supported on TestNG ant task > - > > Key: SUREFIRE-927 > URL: https://jira.codehaus.org/browse/SUREFIRE-927 > Project: Maven Surefire > Issue Type: Improvement > Components: TestNG support >Affects Versions: 2.12.4 >Reporter: Kobi Kisos > > configFailurePolicy is not supported on Surefire plugin though it is > supported on TestNG ant task > configFailurePolicy - Whether TestNG should continue to execute the remaining > tests in the suite or skip them if an @Before* method fails. -- 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] (MSHARED-260) FileUtils.copyDirectory issue
[ https://jira.codehaus.org/browse/MSHARED-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313455#comment-313455 ] Karl Heinz Marbaise commented on MSHARED-260: - The title of the ticket should be updated to copyDirectory() instead of copyFile cause the thread is talking about copyDirectory(). > FileUtils.copyDirectory issue > - > > Key: MSHARED-260 > URL: https://jira.codehaus.org/browse/MSHARED-260 > Project: Maven Shared Components > Issue Type: Bug >Reporter: Kristian Rosenvold > > http://old.nabble.com/plexus-utils---maven-shared-utils---commons-io-to34671433.html -- 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] (MSHARED-260) FileUtils.copyDirectory issue
[ https://jira.codehaus.org/browse/MSHARED-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MSHARED-260: --- Summary: FileUtils.copyDirectory issue (was: FileUtils.copyFile issue) > FileUtils.copyDirectory issue > - > > Key: MSHARED-260 > URL: https://jira.codehaus.org/browse/MSHARED-260 > Project: Maven Shared Components > Issue Type: Bug >Reporter: Kristian Rosenvold > > http://old.nabble.com/plexus-utils---maven-shared-utils---commons-io-to34671433.html -- 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
