[jira] Commented: (MSITE-600) site plugin 2.4 does not permit a child to fully override parent site deployment URL
[ https://jira.codehaus.org/browse/MSITE-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274473#comment-274473 ] Lukas Theussl commented on MSITE-600: - Is this a realistic use case? Why would you want to deploy the child to a different host? I think that currently it is assumed that related sites (modules, parent) are deployed to the same host, otherwise e.g. relative links between components will not work. site plugin 2.4 does not permit a child to fully override parent site deployment URL Key: MSITE-600 URL: https://jira.codehaus.org/browse/MSITE-600 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 2.4 Reporter: Benson Margulies Attachments: muddle.tar The test cases here has a parent with a a distributionManagement/site/url, and then a child which overrides it with an absolute URL. Except that the override does not work ... or, at least, looks quite peculiar. the parent is file:///tmp/bloop the child is scp://localhost:/tmp/blop and the result is [INFO] Error uploading site Embedded error: Could not make directory '/tmp/bloop/../../Users/benson/asf/mvn/site-interp-muddle/child/scp:/localhost:/tmp/blop'. [INFO] --- -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5135) Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging
[ https://jira.codehaus.org/browse/MNG-5135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274482#comment-274482 ] Christian Pesch commented on MNG-5135: -- Interesting question. I've found a post from April: http://maven.40175.n5.nabble.com/3-0-4-release-td4311795.html Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging - Key: MNG-5135 URL: https://jira.codehaus.org/browse/MNG-5135 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0.3 Environment: Maven 3.0.3 Reporter: Evgeny Mandrikov Assignee: Benjamin Bentmann Fix For: 3.0.4 As described in SONAR-2626 : aggregator mojo, which requires dependency resolution (like sonar:sonar or javadoc:aggregate-jar) is unable to resolve dependencies, when executed from command-line and build extension with custom packaging declared in sub-module, but not in parent. Declaration of extension in parent allows to workaround problem as well as downgrade to Maven 2.2.1 and execution of mvn validate sonar:sonar. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5136) Not all dependency are included in WAR
[ https://jira.codehaus.org/browse/MNG-5136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274484#comment-274484 ] luca preziati commented on MNG-5136: Fixed with lib update for all windows system. Not all dependency are included in WAR -- Key: MNG-5136 URL: https://jira.codehaus.org/browse/MNG-5136 Project: Maven 2 3 Issue Type: Bug Components: General Affects Versions: 3.0.3 Environment: Windows Vista 32 Bit, apache maven 3.0.3, java version 1.6.0_21 Java(TM) SE Runtime Environment (build 1.6.0_21-b07) Java HotSpot(TM) Client VM (build 17.0-b17, mixed mode, sharing) Reporter: luca preziati Priority: Blocker Attachments: build-MAVEN-3.0.3.log, build-MAVEN-3.0-SNAPSHOT, Lib dir.txt, list.txt, tree.TXT When I launch mvn dependency:tree i found logback-core, when I build War the lib isn't include. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (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:comment-tabpanelfocusedCommentId=274485#comment-274485
]
David Matejcek commented on MNG-5087:
-
I have the same problem, deployed SNAPSHOT version from one machine to the
repository server yesterday, but today another machine does not update the
artifact, even with -U.
When I deleted maven-metadata-local.xml of the artifact, the dependency was
updated (even without -U).
There wasn't any problems with Maven2.
Maven 3.0.3, Kubuntu 10.04 - 2.6.32-32-generic, Sun JDK 1.6.0.24.
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
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (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:comment-tabpanelfocusedCommentId=274486#comment-274486
]
David Matejcek commented on MNG-5087:
-
I have an idea - I switched between Maven2 and Maven3. Maybe if the artifact is
downloaded by Maven2, Maven3 skips updating due to some incompatibility?
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
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-624) Performing a release with localCheckout fail on Windows
[
https://jira.codehaus.org/browse/MRELEASE-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thorsten Gawantka updated MRELEASE-624:
---
Attachment: GitScmProviderRepository.patch
Hi, the problem is not realy in the release plugin.
The issue comes from URL-Parsing in the maven-scm-provider for git.
I have created a patch for this issue, can anyone review this patch and apply
it? Thank you.
Performing a release with localCheckout fail on Windows
---
Key: MRELEASE-624
URL: https://jira.codehaus.org/browse/MRELEASE-624
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.1
Environment: Windows Vista, msysgit, Maven 3.0.0
Reporter: Daniel Spilker
Priority: Minor
Attachments: GitScmProviderRepository.patch
When trying to perform a release on a Windows machine with localCheckout set
to true, I get the following error message. The path
'C:\Users\daspilker\workspaces\myproject' is a git repository.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.1:perform (default-cli) on
project warp:
Unable to checkout from SCM
[ERROR] Provider message:
[ERROR] The git-clone command failed.
[ERROR] Command output:
[ERROR] fatal: 'C\Users\daspilker\workspaces\myproject' does not appear to be
a git repository
[ERROR] fatal: The remote end hung up unexpectedly
[ERROR] - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR] mvn goals -rf :myproject
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRELEASE-624) Performing a release with localCheckout fail on Windows
[
https://jira.codehaus.org/browse/MRELEASE-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274495#comment-274495
]
Thorsten Gawantka edited comment on MRELEASE-624 at 7/28/11 4:58 AM:
-
Hi, the problem is not really in the release plugin.
The issue is related with URL-Parsing in the maven-scm-provider for git.
I have created a patch for this issue, can anyone review this patch and apply
it? Thank you.
was (Author: thgaw):
Hi, the problem is not realy in the release plugin.
The issue comes from URL-Parsing in the maven-scm-provider for git.
I have created a patch for this issue, can anyone review this patch and apply
it? Thank you.
Performing a release with localCheckout fail on Windows
---
Key: MRELEASE-624
URL: https://jira.codehaus.org/browse/MRELEASE-624
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.1
Environment: Windows Vista, msysgit, Maven 3.0.0
Reporter: Daniel Spilker
Priority: Minor
Attachments: GitScmProviderRepository.patch
When trying to perform a release on a Windows machine with localCheckout set
to true, I get the following error message. The path
'C:\Users\daspilker\workspaces\myproject' is a git repository.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.1:perform (default-cli) on
project warp:
Unable to checkout from SCM
[ERROR] Provider message:
[ERROR] The git-clone command failed.
[ERROR] Command output:
[ERROR] fatal: 'C\Users\daspilker\workspaces\myproject' does not appear to be
a git repository
[ERROR] fatal: The remote end hung up unexpectedly
[ERROR] - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR] mvn goals -rf :myproject
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-600) site plugin 2.4 does not permit a child to fully override parent site deployment URL
[ https://jira.codehaus.org/browse/MSITE-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274496#comment-274496 ] Benson Margulies commented on MSITE-600: I have projects where the parent is released and deployed independently of the child. In fact, much of Maven itself works this way. There is still a relativePath for use in SNAPSHOT development when everything in the tree happens to be hanging out together. This is a regression from 2.2 (2.3 has other problems in this area), where it works fine. It seems to me that the code should ask, 'is the resolved child url absolute', and, if it is, don't change it; checking to see if the protocols are different couldn't hurt either. In general, if I wanted inheritance, I'd leave the url spec out of the child. If I write a spec in a child, it has to override the parent. site plugin 2.4 does not permit a child to fully override parent site deployment URL Key: MSITE-600 URL: https://jira.codehaus.org/browse/MSITE-600 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 2.4 Reporter: Benson Margulies Attachments: muddle.tar The test cases here has a parent with a a distributionManagement/site/url, and then a child which overrides it with an absolute URL. Except that the override does not work ... or, at least, looks quite peculiar. the parent is file:///tmp/bloop the child is scp://localhost:/tmp/blop and the result is [INFO] Error uploading site Embedded error: Could not make directory '/tmp/bloop/../../Users/benson/asf/mvn/site-interp-muddle/child/scp:/localhost:/tmp/blop'. [INFO] --- -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-600) site plugin 2.4 does not permit a child to fully override parent site deployment URL
[ https://jira.codehaus.org/browse/MSITE-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274497#comment-274497 ] Benson Margulies commented on MSITE-600: How about adding an attribute to url to control this inheritance if absolute pathname checks don't make sense? site plugin 2.4 does not permit a child to fully override parent site deployment URL Key: MSITE-600 URL: https://jira.codehaus.org/browse/MSITE-600 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 2.4 Reporter: Benson Margulies Attachments: muddle.tar The test cases here has a parent with a a distributionManagement/site/url, and then a child which overrides it with an absolute URL. Except that the override does not work ... or, at least, looks quite peculiar. the parent is file:///tmp/bloop the child is scp://localhost:/tmp/blop and the result is [INFO] Error uploading site Embedded error: Could not make directory '/tmp/bloop/../../Users/benson/asf/mvn/site-interp-muddle/child/scp:/localhost:/tmp/blop'. [INFO] --- -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (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:comment-tabpanelfocusedCommentId=274498#comment-274498
]
Benjamin Bentmann commented on MNG-5087:
The hotfix for this is to replace {{maven-home/lib/aether-\*-1.11.jar}}'s
with their 1.12 equivalents.
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
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-600) site plugin 2.4 does not permit a child to fully override parent site deployment URL
[ https://jira.codehaus.org/browse/MSITE-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274499#comment-274499 ] Benson Margulies commented on MSITE-600: I just checked one other aspect. If I remove the relativePath from the child, it still exhibits this behavior. This really seems chaotic to me due to its effect on independently released, poms. Consider the global ASF POM. No one wants to be building site URLs that assume any relationship to its site; it should have a site that documents it that is disconnected from any sites of projects that use it as a parent. site plugin 2.4 does not permit a child to fully override parent site deployment URL Key: MSITE-600 URL: https://jira.codehaus.org/browse/MSITE-600 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 2.4 Reporter: Benson Margulies Attachments: muddle.tar The test cases here has a parent with a a distributionManagement/site/url, and then a child which overrides it with an absolute URL. Except that the override does not work ... or, at least, looks quite peculiar. the parent is file:///tmp/bloop the child is scp://localhost:/tmp/blop and the result is [INFO] Error uploading site Embedded error: Could not make directory '/tmp/bloop/../../Users/benson/asf/mvn/site-interp-muddle/child/scp:/localhost:/tmp/blop'. [INFO] --- -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-600) site plugin 2.4 does not permit a child to fully override parent site deployment URL
[ https://jira.codehaus.org/browse/MSITE-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274504#comment-274504 ] Benson Margulies commented on MSITE-600: Thanks. Just to make you feel better about the existence of the use case, I want to call out https://svn.apache.org/repos/asf/maven/pom/trunk/asf/pom.xml. This is used as a parent throughout the ASF. At my day job, we have used this structure extensively. We publish a corporate parent POM. It can live far away in http-space from the sites of the projects that use it. site plugin 2.4 does not permit a child to fully override parent site deployment URL Key: MSITE-600 URL: https://jira.codehaus.org/browse/MSITE-600 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 2.4 Reporter: Benson Margulies Attachments: muddle.tar The test cases here has a parent with a a distributionManagement/site/url, and then a child which overrides it with an absolute URL. Except that the override does not work ... or, at least, looks quite peculiar. the parent is file:///tmp/bloop the child is scp://localhost:/tmp/blop and the result is [INFO] Error uploading site Embedded error: Could not make directory '/tmp/bloop/../../Users/benson/asf/mvn/site-interp-muddle/child/scp:/localhost:/tmp/blop'. [INFO] --- -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-600) site plugin 2.4 does not permit a child to fully override parent site deployment URL
[ https://jira.codehaus.org/browse/MSITE-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274506#comment-274506 ] Lukas Theussl commented on MSITE-600: - bq. This is used as a parent throughout the ASF. I don't see the relevance, the ASF pom does not define a distributionManagement.site.url. The maven pom https://svn.apache.org/repos/asf/maven/pom/trunk/maven/pom.xml OTOH does define one, but as I said, that's where all the maven sites go. site plugin 2.4 does not permit a child to fully override parent site deployment URL Key: MSITE-600 URL: https://jira.codehaus.org/browse/MSITE-600 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 2.4 Reporter: Benson Margulies Attachments: muddle.tar The test cases here has a parent with a a distributionManagement/site/url, and then a child which overrides it with an absolute URL. Except that the override does not work ... or, at least, looks quite peculiar. the parent is file:///tmp/bloop the child is scp://localhost:/tmp/blop and the result is [INFO] Error uploading site Embedded error: Could not make directory '/tmp/bloop/../../Users/benson/asf/mvn/site-interp-muddle/child/scp:/localhost:/tmp/blop'. [INFO] --- -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-600) site plugin 2.4 does not permit a child to fully override parent site deployment URL
[ https://jira.codehaus.org/browse/MSITE-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274507#comment-274507 ] Benson Margulies commented on MSITE-600: it doesn't define it because of this set of problems. People keep asking us to make a site for that pom, but we keep not doing it. I admit that I am now arguing in something of a circle. I'll stick to the statement of principle: a parent with no modules used as a global resource cries out for a documentation site, and fixing this issue will make that possible without messing up the documentation sites. site plugin 2.4 does not permit a child to fully override parent site deployment URL Key: MSITE-600 URL: https://jira.codehaus.org/browse/MSITE-600 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 2.4 Reporter: Benson Margulies Attachments: muddle.tar The test cases here has a parent with a a distributionManagement/site/url, and then a child which overrides it with an absolute URL. Except that the override does not work ... or, at least, looks quite peculiar. the parent is file:///tmp/bloop the child is scp://localhost:/tmp/blop and the result is [INFO] Error uploading site Embedded error: Could not make directory '/tmp/bloop/../../Users/benson/asf/mvn/site-interp-muddle/child/scp:/localhost:/tmp/blop'. [INFO] --- -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-698) Inconsistent documentation for 'generate release pom'
Inconsistent documentation for 'generate release pom' - Key: MRELEASE-698 URL: https://jira.codehaus.org/browse/MRELEASE-698 Project: Maven 2.x Release Plugin Issue Type: Bug Components: documentation Affects Versions: 2.2 Reporter: Benson Margulies http://maven.apache.org/plugins/maven-release-plugin/examples/generate-release-poms.html disagrees with http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#generateReleasePoms, which describes the former technique as deprecated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5141) Make MojoExecutor.ensureDependenciesAreResolved public
Make MojoExecutor.ensureDependenciesAreResolved public -- Key: MNG-5141 URL: https://jira.codehaus.org/browse/MNG-5141 Project: Maven 2 3 Issue Type: Improvement Components: Embedding Affects Versions: 3.0.2 Reporter: Igor Fedorenko Priority: Trivial In order to be able to honour @requiresDependencyResolution when executing mojos inside m2e jvm (during workspace build, for example) m2e needs access to MojoExecutor.ensureDependenciesAreResolved -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-5141) Make MojoExecutor.ensureDependenciesAreResolved public
[ https://jira.codehaus.org/browse/MNG-5141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5141. --- Resolution: Fixed Fix Version/s: 3.0.4 Assignee: Igor Fedorenko done. http://svn.apache.org/viewvc?view=revisionrevision=1151851 forgot to mention, original m2e bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=353312 Make MojoExecutor.ensureDependenciesAreResolved public -- Key: MNG-5141 URL: https://jira.codehaus.org/browse/MNG-5141 Project: Maven 2 3 Issue Type: Improvement Components: Embedding Affects Versions: 3.0.2 Reporter: Igor Fedorenko Assignee: Igor Fedorenko Priority: Trivial Fix For: 3.0.4 In order to be able to honour @requiresDependencyResolution when executing mojos inside m2e jvm (during workspace build, for example) m2e needs access to MojoExecutor.ensureDependenciesAreResolved -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-697) version 2.2 includes SNAPSHOT in default tag name
[
https://jira.codehaus.org/browse/MRELEASE-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed MRELEASE-697.
-
Resolution: Fixed
Fix Version/s: 2.3
Assignee: Stephen Connolly
r1151860
version 2.2 includes SNAPSHOT in default tag name
-
Key: MRELEASE-697
URL: https://jira.codehaus.org/browse/MRELEASE-697
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.2
Reporter: Benson Margulies
Assignee: Stephen Connolly
Fix For: 2.3
There's a test case here:
https://svn.apache.org/repos/asf/maven/sandbox/bimargulies/mrp-snap-tc/trunk
2.1 does the expected thing (no -SNAPSHOT in the proposed tag name).
/Users/benson/asf/mvn/mrp-snap-tc /opt/apache-maven-2.2.1/bin/mvn
-DdryRun=true release:prepare
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'release'.
[INFO]
[INFO] Building test case for strange behavior
[INFO]task-segment: [release:prepare] (aggregator-style)
[INFO]
[INFO] [release:prepare {execution: default-cli}]
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: pom.xml.next, release.properties,
pom.xml.releaseBackup, pom.xml.backup, pom.xml.branch, pom.xml.tag
[INFO] Executing: /bin/sh -c cd /Users/benson/asf/mvn/mrp-snap-tc svn
status
[INFO] Working directory: /Users/benson/asf/mvn/mrp-snap-tc
[INFO] Checking dependencies and plugins for snapshots ...
What is the release version for test case for strange behavior?
(org.apache.maven:mrp-snap-tag-tc) 1: :
What is SCM release tag or label for test case for strange behavior?
(org.apache.maven:mrp-snap-tag-tc) mrp-snap-tag-tc-1-SNAPSHOT: :
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-571) When collecting active profiles, the active profiles from parent poms are not considered
[ https://jira.codehaus.org/browse/MRELEASE-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MRELEASE-571: -- Fix Version/s: (was: 2.3) 2.2.1 When collecting active profiles, the active profiles from parent poms are not considered Key: MRELEASE-571 URL: https://jira.codehaus.org/browse/MRELEASE-571 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform, prepare Affects Versions: 2.0 Reporter: Lars Corneliussen Fix For: 2.2.1 Attachments: 89d9799a56d46d7435d08c94ca538845d7145c9b[1].patch, MRELEASE-571-collect-profiles.patch, profile-ignored-with-module.zip MavenProject.getActiveProfiles() does not return all profiles that are currently run, but instead only those that are run AND defined on the current project. This leads to preparation-builds of modules without the specified active profiles derived from their parents. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-499) Add to FAQ: prepare fails because of inheriting parent scm
[
https://jira.codehaus.org/browse/MRELEASE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MRELEASE-499:
--
Fix Version/s: (was: 2.3)
2.2.1
Add to FAQ: prepare fails because of inheriting parent scm
--
Key: MRELEASE-499
URL: https://jira.codehaus.org/browse/MRELEASE-499
Project: Maven 2.x Release Plugin
Issue Type: Improvement
Components: documentation, prepare
Reporter: Robert Scholte
Assignee: Stephen Connolly
Fix For: 2.2.1
If the pom.xml has no scm-section but his parent does, the prepare will fail
when trying to tag.
The message will be something like:
{quote}svn: Path
'https://svn.codehaus.org/mojo/tags/mojo-parent-22/my-maven-plugin' does not
exist in revision 12345{quote}
To fix it, add the scm-section to the pom, restore the version (-SNAPSHOT)
and execute {{mvn release:clean}}
Than we're ready to run another {{mvn:prepare}}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-571) When collecting active profiles, the active profiles from parent poms are not considered
[ https://jira.codehaus.org/browse/MRELEASE-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MRELEASE-571: -- Fix Version/s: (was: 2.2.1) 2.3 When collecting active profiles, the active profiles from parent poms are not considered Key: MRELEASE-571 URL: https://jira.codehaus.org/browse/MRELEASE-571 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform, prepare Affects Versions: 2.0 Reporter: Lars Corneliussen Fix For: 2.3 Attachments: 89d9799a56d46d7435d08c94ca538845d7145c9b[1].patch, MRELEASE-571-collect-profiles.patch, profile-ignored-with-module.zip MavenProject.getActiveProfiles() does not return all profiles that are currently run, but instead only those that are run AND defined on the current project. This leads to preparation-builds of modules without the specified active profiles derived from their parents. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-697) version 2.2 includes SNAPSHOT in default tag name
[
https://jira.codehaus.org/browse/MRELEASE-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MRELEASE-697:
--
Fix Version/s: (was: 2.3)
2.2.1
version 2.2 includes SNAPSHOT in default tag name
-
Key: MRELEASE-697
URL: https://jira.codehaus.org/browse/MRELEASE-697
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.2
Reporter: Benson Margulies
Assignee: Stephen Connolly
Fix For: 2.2.1
There's a test case here:
https://svn.apache.org/repos/asf/maven/sandbox/bimargulies/mrp-snap-tc/trunk
2.1 does the expected thing (no -SNAPSHOT in the proposed tag name).
/Users/benson/asf/mvn/mrp-snap-tc /opt/apache-maven-2.2.1/bin/mvn
-DdryRun=true release:prepare
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'release'.
[INFO]
[INFO] Building test case for strange behavior
[INFO]task-segment: [release:prepare] (aggregator-style)
[INFO]
[INFO] [release:prepare {execution: default-cli}]
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: pom.xml.next, release.properties,
pom.xml.releaseBackup, pom.xml.backup, pom.xml.branch, pom.xml.tag
[INFO] Executing: /bin/sh -c cd /Users/benson/asf/mvn/mrp-snap-tc svn
status
[INFO] Working directory: /Users/benson/asf/mvn/mrp-snap-tc
[INFO] Checking dependencies and plugins for snapshots ...
What is the release version for test case for strange behavior?
(org.apache.maven:mrp-snap-tag-tc) 1: :
What is SCM release tag or label for test case for strange behavior?
(org.apache.maven:mrp-snap-tag-tc) mrp-snap-tag-tc-1-SNAPSHOT: :
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-239) release:perform and release:prepare should accept multi-line goals/preparationGoals configurations
[ https://jira.codehaus.org/browse/MRELEASE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MRELEASE-239: -- Fix Version/s: (was: 2.3) 2.2.1 release:perform and release:prepare should accept multi-line goals/preparationGoals configurations -- Key: MRELEASE-239 URL: https://jira.codehaus.org/browse/MRELEASE-239 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Affects Versions: 2.0-beta-6 Reporter: Steve Rowe Assignee: Stephen Connolly Priority: Minor Fix For: 2.2.1 Attachments: ForkedMavenExecutor.patch When I specify a list of goals in my POM that span multiple lines (see an example below), only those goals before the newline are executed when I run mvn release:perform. I have only noticed this for release:perform, but given what the code looks like, I assume it's an issue for release:prepare too. This is a minor problem, but an irritating one, because release:peform claims to successfully complete without actually executing all specified goals. I attach a patch to ForkedMavenExecutor.java that splits the goals list on newlines and carriage returns, in addition to the comma and space split characters that were there already. Here's an example configuration that will trigger the problem: plugin artifactIdmaven-release-plugin/artifactId configuration ... goals package group:first-goal group:second-goal group:third-goal site-deploy changes:announcement-generate changes:announcement-mail /goals /configuration /plugin -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-627) Wrong classname used in documentation at additionalBuildcommands
[
https://jira.codehaus.org/browse/MECLIPSE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MECLIPSE-627.
---
Resolution: Fixed
Fix Version/s: 2.9
Assignee: Robert Scholte
Fix in [rev. 1151935|http://svn.apache.org/viewvc?rev=1151935view=rev]
Wrong classname used in documentation at additionalBuildcommands
-
Key: MECLIPSE-627
URL: https://jira.codehaus.org/browse/MECLIPSE-627
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Plugin Documentation
Reporter: Dennis Müller
Assignee: Robert Scholte
Priority: Minor
Fix For: 2.9
If using
{code:xml}nameorg.ui.externaltools.ExternalToolBuilder/name{code} as
shown in the documentation at [Maven documentation for
eclipse:eclipse|http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html#additionalBuildcommands],
after executing *eclipse:eclipse* the maven builders configured in eclipse
for the project will not run automatically.
While this can be fixed manually with a few clicks, it's quite annoying - and
can easily be fixed by usind the correct name (which is _not_ mentioned in
the documentation, but set by eclipse when fixed manually):
{code:xml}
nameorg.eclipse.ui.externaltools.ExternalToolBuilder/name
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-434) WTP 2.0 Documentation
[ https://jira.codehaus.org/browse/MECLIPSE-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MECLIPSE-434. --- Resolution: Fixed Already fixed in rev. 1006168 WTP 2.0 Documentation - Key: MECLIPSE-434 URL: https://jira.codehaus.org/browse/MECLIPSE-434 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Plugin Documentation Affects Versions: 2.5.1 Reporter: Shelley Baker Assignee: fabrizio giustina Priority: Minor Fix For: 2.9 Attachments: maven.eclipse.plugin-site.wtp.fix.patch The maven-eclipse-plugin mojo documentation should be updated to mention WTP 2.0 support. Currently, the wtpversion parameter description states that the only supported versions are R7, 1.0 and 1.5. http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html#wtpversion -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-599) Broken link to j2ee-simple.tar.gz on multi-module-projects.html
[
https://jira.codehaus.org/browse/MECLIPSE-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MECLIPSE-599.
---
Resolution: Fixed
Fix Version/s: 2.9
Assignee: Robert Scholte
Fixed in [rev. 1151994|http://svn.apache.org/viewvc?rev=1151994view=rev]
Broken link to j2ee-simple.tar.gz on multi-module-projects.html
---
Key: MECLIPSE-599
URL: https://jira.codehaus.org/browse/MECLIPSE-599
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Plugin Documentation
Reporter: Clemens Fuchslocher
Assignee: Robert Scholte
Fix For: 2.9
On [Using maven-eclipse-plugin in multi-module projects with
WTP|http://maven.apache.org/plugins/maven-eclipse-plugin/examples/multi-module-projects.html]
is a broken link to the project archive j2ee-simple.tar.gz.
The archive is wrongly referenced as an anchor:
{noformat}
...
You can download it from a href=#j2ee-simple.tar.gzhere/a.
...
{noformat}
Removing the hash fixes the problem:
{noformat}
...
You can download it from a href=j2ee-simple.tar.gzhere/a.
...
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5142) allow static URLSs which don't change in derived submodules
allow static URLSs which don't change in derived submodules --- Key: MNG-5142 URL: https://jira.codehaus.org/browse/MNG-5142 Project: Maven 2 3 Issue Type: Bug Components: Inheritance and Interpolation Affects Versions: 3.0.3, 2.2.1 Reporter: Mark Struberg In sub-modules, URLs in the MavenModel will automatically get expanded by adding the artifactId of the very sub-module. This is fine for e.g. a SVN scm URL but breaks other SCMs like git or hg. Proposal: We should introduce a 'static:' prefix for URLs which must not get automatically expanded in submodules. An example: scm developerConnectionstatic:scm:git:https://myserver.com/gitrepo/... The 'static:' info will get removed while parsing the pom. Compat notes: I've tried that such scm URLs with mvn-3.0.3 and mvn-2.2.1 in scmconnection, developerConnection, url, distributionManagementsiteurl and got no error building my project. Of course, if you use the 'static:' prefix then you cannot release or do other site and scm tasks with an old maven version anymore. But that part is considered to be broken anyway at the moment ;) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5142) allow static URLSs which don't change in derived submodules
[
https://jira.codehaus.org/browse/MNG-5142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274559#comment-274559
]
Robert Scholte commented on MNG-5142:
-
{{static:}} sounds a bit confusing, because what would {{dynamic:}} mean?
I'd prefer the usage of {{relative:}} and {{absolute:}} where relative would be
the default.
These are well-known terms and immediately clear for everyone.
allow static URLSs which don't change in derived submodules
---
Key: MNG-5142
URL: https://jira.codehaus.org/browse/MNG-5142
Project: Maven 2 3
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.2.1, 3.0.3
Reporter: Mark Struberg
In sub-modules, URLs in the MavenModel will automatically get expanded by
adding the artifactId of the very sub-module.
This is fine for e.g. a SVN scm URL but breaks other SCMs like git or hg.
Proposal:
We should introduce a 'static:' prefix for URLs which must not get
automatically expanded in submodules.
An example:
scm
developerConnectionstatic:scm:git:https://myserver.com/gitrepo/...
The 'static:' info will get removed while parsing the pom.
Compat notes:
I've tried that such scm URLs with mvn-3.0.3 and mvn-2.2.1 in
scmconnection, developerConnection, url,
distributionManagementsiteurl
and got no error building my project. Of course, if you use the 'static:'
prefix then you cannot release or do other site and scm tasks with an old
maven version anymore. But that part is considered to be broken anyway at the
moment ;)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-691) tagNameFormat property interpolation does not use the release values but the project ones
[
https://jira.codehaus.org/browse/MRELEASE-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274560#comment-274560
]
Idcmp commented on MRELEASE-691:
This seems to trick the M2 Release Plugin into creating tags like
my-proj-1.2-SNAPSHOT if you're not careful which feels like the opposite of
what you'd want this feature to do. Maybe we could get a 2.2.1 with this fixed?
tagNameFormat property interpolation does not use the release values but the
project ones
-
Key: MRELEASE-691
URL: https://jira.codehaus.org/browse/MRELEASE-691
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare, scm
Affects Versions: 2.2
Reporter: Julien Nicoulaud
Priority: Minor
Attachments: maven-release-plugin-tagNameFormat.log
The property interpolation in the [tagNameFormat
option|http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#tagNameFormat]
is counterintuitive, one would expect it to use the release value for the
project version, but instead the project SNAPSHOT version is used.
For example, with tagNameFormat@{project.version}/tagNameFormat (see
attached log):
{noformat}
What is the release version for flexlib?
(com.google.code.flexlib:flexlib-parent) 2.6: 2.6-M2
What is SCM release tag or label for flexlib?
(com.google.code.flexlib:flexlib-parent) 2.6-SNAPSHOT:
{noformat}
= The version should be 2.6-M2 I just entered here, not the project SNAPSHOT
one.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5142) allow static URLSs which don't change in derived submodules
[ https://jira.codehaus.org/browse/MNG-5142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274561#comment-274561 ] Mark Struberg commented on MNG-5142: another good idea came up. The maven pom XSD does not prevent us from using attributes. So we could just add an 'absolute' attribute to the various url tags. E.g.: scmdeveloperConnection absolute=truescm:git:https://... allow static URLSs which don't change in derived submodules --- Key: MNG-5142 URL: https://jira.codehaus.org/browse/MNG-5142 Project: Maven 2 3 Issue Type: Bug Components: Inheritance and Interpolation Affects Versions: 2.2.1, 3.0.3 Reporter: Mark Struberg In sub-modules, URLs in the MavenModel will automatically get expanded by adding the artifactId of the very sub-module. This is fine for e.g. a SVN scm URL but breaks other SCMs like git or hg. Proposal: We should introduce a 'static:' prefix for URLs which must not get automatically expanded in submodules. An example: scm developerConnectionstatic:scm:git:https://myserver.com/gitrepo/... The 'static:' info will get removed while parsing the pom. Compat notes: I've tried that such scm URLs with mvn-3.0.3 and mvn-2.2.1 in scmconnection, developerConnection, url, distributionManagementsiteurl and got no error building my project. Of course, if you use the 'static:' prefix then you cannot release or do other site and scm tasks with an old maven version anymore. But that part is considered to be broken anyway at the moment ;) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
