[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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 -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-tabpanel&focusedCommentId=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 -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-tabpanel&focusedCommentId=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 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 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=274498#comment-274498
]
Benjamin Bentmann commented on MNG-5087:
The hotfix for this is to replace {{/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-tabpanel&focusedCommentId=274499#comment-274499 ] Benson Margulies commented on MSITE-600: I just checked one other aspect. If I remove the 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-tabpanel&focusedCommentId=274503#comment-274503 ] Lukas Theussl commented on MSITE-600: - bq. I have projects where the parent is released and deployed independently of the child. In fact, much of Maven itself works this way. All maven sub-project sites are deployed to scp://people.apache.org/www/maven.apache.org/ as far as I know. Even though I still question the use case, I agree there is a bug. If both parent and child declare a distMngmt url (note this always has to be absolute), then the child should use it's own unaltered. > 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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 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=revision&revision=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: > > maven-release-plugin > > ... > > package group:first-goal group:second-goal group:third-goal > site-deploy changes:announcement-generate > changes:announcement-mail > > > -- 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=1151935&view=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}org.ui.externaltools.ExternalToolBuilder{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}
> org.eclipse.ui.externaltools.ExternalToolBuilder
> {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=1151994&view=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 here.
> ...
> {noformat}
> Removing the hash fixes the problem:
> {noformat}
> ...
> You can download it from here.
> ...
> {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: static: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 , , , 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-tabpanel&focusedCommentId=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:
>
> static: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
> , , ,
>
> 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-tabpanel&focusedCommentId=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 @{project.version} (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-tabpanel&focusedCommentId=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.: scm: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: > > static: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 > , , , > > 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
