[jira] [Comment Edited] (MWRAPPER-140) only-script Type does not honor MAVEN_USER_HOME
[
https://issues.apache.org/jira/browse/MWRAPPER-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847285#comment-17847285
]
Adrian Shum edited comment on MWRAPPER-140 at 5/17/24 1:25 PM:
---
{{Attached please find a quick fix I done myself.}}
I applied the same change of mvnw locally and seems working fine, but Windows
mvwn.cmd I have no way to test.
was (Author: adrianshum):
{{Following is a quick fix I done myself but I have just found that I am not
allowed to push changes and create pull requests.}}
I applied the same change of mvnw locally and seems working fine, but Windows
mvwn.cmd I have no way to test.
{{diff --git a/maven-wrapper-distribution/src/resources/only-mvnw
b/maven-wrapper-distribution/src/resources/only-mvnw}}
{{index b04e16b..dc12d6a 100755}}
{{--- a/maven-wrapper-distribution/src/resources/only-mvnw}}
{{+++ b/maven-wrapper-distribution/src/resources/only-mvnw}}
{{@@ -131,7 +131,8 @@ esac}}
{{ distributionUrlName="${distributionUrl##*/}"}}
{{ distributionUrlNameMain="${distributionUrlName%.*}"}}
{{ distributionUrlNameMain="${distributionUrlNameMain%-bin}"}}
{{-MAVEN_HOME="$HOME/.m2/wrapper/dists/${distributionUrlNameMain-}/$(hash_string
"$distributionUrl")"}}
{{+MAVEN_USER_HOME="${MAVEN_USER_HOME:-${HOME}/.m2}"}}
{{+MAVEN_HOME="${MAVEN_USER_HOME}/wrapper/dists/${distributionUrlNameMain-}/$(hash_string
"$distributionUrl")"}}
{{ }}
{{ exec_maven() {}}
{{ unset MVNW_VERBOSE MVNW_USERNAME MVNW_PASSWORD MVNW_REPOURL || :}}
{{diff --git a/maven-wrapper-distribution/src/resources/only-mvnw.cmd
b/maven-wrapper-distribution/src/resources/only-mvnw.cmd}}
{{index da5a302..d3e39f4 100644}}
{{--- a/maven-wrapper-distribution/src/resources/only-mvnw.cmd}}
{{+++ b/maven-wrapper-distribution/src/resources/only-mvnw.cmd}}
{{@@ -79,6 +79,9 @@ if ($env:MVNW_REPOURL) {}}
{{ $distributionUrlName = $distributionUrl -replace '^.*/',''}}
{{ $distributionUrlNameMain = $distributionUrlName -replace '\.[^.]*$',''
-replace '-bin$',''}}
{{ $MAVEN_HOME_PARENT = "$HOME/.m2/wrapper/dists/$distributionUrlNameMain"}}
{{+if ($env:MAVEN_USER_HOME) {}}
{{+ $MAVEN_HOME_PARENT =
"$env:MAVEN_USER_HOME/wrapper/dists/$distributionUrlNameMain"}}
{{+}}}
{{ $MAVEN_HOME_NAME =
([System.Security.Cryptography.MD5]::Create().ComputeHash([byte[]][char[]]$distributionUrl)
| ForEach-Object \{$_.ToString("x2")}) -join ''}}
{{ $MAVEN_HOME = "$MAVEN_HOME_PARENT/$MAVEN_HOME_NAME"}}
{{ }}
> only-script Type does not honor MAVEN_USER_HOME
> ---
>
> Key: MWRAPPER-140
> URL: https://issues.apache.org/jira/browse/MWRAPPER-140
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.3.1
>Reporter: Adrian Shum
>Priority: Major
> Attachments: patch
>
>
> As per described in [https://maven.apache.org/wrapper/index.html] we could
> set MAVEN_USER_HOME to define the location that Maven distro be downloaded to.
> For type=bin, it seems working as expected. However for type=script-only, it
> is trying to create director under ~/.m2 even I have MAVEN_USER_HOME set.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MWRAPPER-140) only-script Type does not honor MAVEN_USER_HOME
[ https://issues.apache.org/jira/browse/MWRAPPER-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Shum updated MWRAPPER-140: - Attachment: patch > only-script Type does not honor MAVEN_USER_HOME > --- > > Key: MWRAPPER-140 > URL: https://issues.apache.org/jira/browse/MWRAPPER-140 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.3.1 >Reporter: Adrian Shum >Priority: Major > Attachments: patch > > > As per described in [https://maven.apache.org/wrapper/index.html] we could > set MAVEN_USER_HOME to define the location that Maven distro be downloaded to. > For type=bin, it seems working as expected. However for type=script-only, it > is trying to create director under ~/.m2 even I have MAVEN_USER_HOME set. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MWRAPPER-140) only-script Type does not honor MAVEN_USER_HOME
[
https://issues.apache.org/jira/browse/MWRAPPER-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847285#comment-17847285
]
Adrian Shum commented on MWRAPPER-140:
--
{{Following is a quick fix I done myself but I have just found that I am not
allowed to push changes and create pull requests.}}
I applied the same change of mvnw locally and seems working fine, but Windows
mvwn.cmd I have no way to test.
{{diff --git a/maven-wrapper-distribution/src/resources/only-mvnw
b/maven-wrapper-distribution/src/resources/only-mvnw}}
{{index b04e16b..dc12d6a 100755}}
{{--- a/maven-wrapper-distribution/src/resources/only-mvnw}}
{{+++ b/maven-wrapper-distribution/src/resources/only-mvnw}}
{{@@ -131,7 +131,8 @@ esac}}
{{ distributionUrlName="${distributionUrl##*/}"}}
{{ distributionUrlNameMain="${distributionUrlName%.*}"}}
{{ distributionUrlNameMain="${distributionUrlNameMain%-bin}"}}
{{-MAVEN_HOME="$HOME/.m2/wrapper/dists/${distributionUrlNameMain-}/$(hash_string
"$distributionUrl")"}}
{{+MAVEN_USER_HOME="${MAVEN_USER_HOME:-${HOME}/.m2}"}}
{{+MAVEN_HOME="${MAVEN_USER_HOME}/wrapper/dists/${distributionUrlNameMain-}/$(hash_string
"$distributionUrl")"}}
{{ }}
{{ exec_maven() {}}
{{ unset MVNW_VERBOSE MVNW_USERNAME MVNW_PASSWORD MVNW_REPOURL || :}}
{{diff --git a/maven-wrapper-distribution/src/resources/only-mvnw.cmd
b/maven-wrapper-distribution/src/resources/only-mvnw.cmd}}
{{index da5a302..d3e39f4 100644}}
{{--- a/maven-wrapper-distribution/src/resources/only-mvnw.cmd}}
{{+++ b/maven-wrapper-distribution/src/resources/only-mvnw.cmd}}
{{@@ -79,6 +79,9 @@ if ($env:MVNW_REPOURL) {}}
{{ $distributionUrlName = $distributionUrl -replace '^.*/',''}}
{{ $distributionUrlNameMain = $distributionUrlName -replace '\.[^.]*$',''
-replace '-bin$',''}}
{{ $MAVEN_HOME_PARENT = "$HOME/.m2/wrapper/dists/$distributionUrlNameMain"}}
{{+if ($env:MAVEN_USER_HOME) {}}
{{+ $MAVEN_HOME_PARENT =
"$env:MAVEN_USER_HOME/wrapper/dists/$distributionUrlNameMain"}}
{{+}}}
{{ $MAVEN_HOME_NAME =
([System.Security.Cryptography.MD5]::Create().ComputeHash([byte[]][char[]]$distributionUrl)
| ForEach-Object \{$_.ToString("x2")}) -join ''}}
{{ $MAVEN_HOME = "$MAVEN_HOME_PARENT/$MAVEN_HOME_NAME"}}
{{ }}
> only-script Type does not honor MAVEN_USER_HOME
> ---
>
> Key: MWRAPPER-140
> URL: https://issues.apache.org/jira/browse/MWRAPPER-140
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.3.1
>Reporter: Adrian Shum
>Priority: Major
>
> As per described in [https://maven.apache.org/wrapper/index.html] we could
> set MAVEN_USER_HOME to define the location that Maven distro be downloaded to.
> For type=bin, it seems working as expected. However for type=script-only, it
> is trying to create director under ~/.m2 even I have MAVEN_USER_HOME set.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MWRAPPER-140) only-script Type does not honor MAVEN_USER_HOME
[ https://issues.apache.org/jira/browse/MWRAPPER-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Shum updated MWRAPPER-140: - Component/s: Maven Wrapper Scripts > only-script Type does not honor MAVEN_USER_HOME > --- > > Key: MWRAPPER-140 > URL: https://issues.apache.org/jira/browse/MWRAPPER-140 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.3.1 >Reporter: Adrian Shum >Priority: Major > > As per described in [https://maven.apache.org/wrapper/index.html] we could > set MAVEN_USER_HOME to define the location that Maven distro be downloaded to. > For type=bin, it seems working as expected. However for type=script-only, it > is trying to create director under ~/.m2 even I have MAVEN_USER_HOME set. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MWRAPPER-140) only-script Type does not honor MAVEN_USER_HOME
Adrian Shum created MWRAPPER-140: Summary: only-script Type does not honor MAVEN_USER_HOME Key: MWRAPPER-140 URL: https://issues.apache.org/jira/browse/MWRAPPER-140 Project: Maven Wrapper Issue Type: Bug Reporter: Adrian Shum As per described in [https://maven.apache.org/wrapper/index.html] we could set MAVEN_USER_HOME to define the location that Maven distro be downloaded to. For type=bin, it seems working as expected. However for type=script-only, it is trying to create director under ~/.m2 even I have MAVEN_USER_HOME set. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MWRAPPER-140) only-script Type does not honor MAVEN_USER_HOME
[ https://issues.apache.org/jira/browse/MWRAPPER-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Shum updated MWRAPPER-140: - Affects Version/s: 3.3.1 > only-script Type does not honor MAVEN_USER_HOME > --- > > Key: MWRAPPER-140 > URL: https://issues.apache.org/jira/browse/MWRAPPER-140 > Project: Maven Wrapper > Issue Type: Bug >Affects Versions: 3.3.1 >Reporter: Adrian Shum >Priority: Major > > As per described in [https://maven.apache.org/wrapper/index.html] we could > set MAVEN_USER_HOME to define the location that Maven distro be downloaded to. > For type=bin, it seems working as expected. However for type=script-only, it > is trying to create director under ~/.m2 even I have MAVEN_USER_HOME set. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-624) automatic parent versioning
[
https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=336980#comment-336980
]
Adrian Shum edited comment on MNG-624 at 12/9/13 3:44 AM:
--
For all suggestion/workaround proposed here using a property for parent
version, they all suffer from one issue: This will work for build, but will
fail on using the result as dependency.
Assuming I have a very simple structure like this:
{code}
foo-parent
foo-lib
{code}
assume the POm of foo-lib contains
{code}
foo
foo-parent
${foo.version}
../foo-parent/pom.xml
{code}
(foo.version can be provided by any means, by command line or by property
defined in parent etc)
Because Maven is deploying/installing the POM as-is. That means, if I put
foo-lib in the repository, when people is using it as dependency, the POM is
containing only
{code}${foo.version} {code}
string literal as the parent version. There is no way that it can resolve the
correct parent POM to refer to.
May I suggests, instead of deploying the POM as-is, we are creating an
"effective" POM to use to deploy? In the "effective" POM, we have all necessary
properties replaced and use that for install/deploy.
was (Author: adrianshum):
For all suggestion/workaround proposed here using a property for parent
version, they all suffer from one issue: This will work for build, but will
fail on using the result as dependency.
Assuming I have a very simple structure like this:
{code}
foo-parent
foo-lib
{code}
assume the POm of foo-lib contains
{code}
foo
foo-parent
${foo.version}
../foo-parent/pom.xml
{code}
(foo.version can be provided by any means, by command line or by property
defined in parent etc)
Because Maven is deploying/installing the POM as-is. That means, if I put
foo-lib in the repository, when people is using it as dependency, the POM is
containing only ${foo.version} string literal as the parent version. There is
no way that it can resolve the correct parent POM to refer to.
May I suggests, instead of deploying the POM as-is, we are creating an
"effective" POM to use to deploy? In the "effective" POM, we have all necessary
properties replaced and use that for install/deploy.
> automatic parent versioning
> ---
>
> Key: MNG-624
> URL: https://jira.codehaus.org/browse/MNG-624
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Reporter: Brett Porter
>Assignee: Ralph Goers
>Priority: Blocker
> Fix For: 3.2
>
> Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see
> MNG-521)
> currently, you have to specify the parent version when extending which makes
> a project stand alone very easily, but has the drawback of being a
> maintainance problem when you start development on a new version. Tools can
> help, but it would be nice not to have to rely on them.
> One alternative is to allow the parent version to be omitted, and when it is
> it is assumed you want the latest. The parent is used from the reactor or the
> universal source directory. IT may also be read from a LATEST in the
> repository though this is contentious - it may be better to simply fail in
> that environment and require builds be in a known checkout structure for
> building individual projects.
> This also introduces the need for tool support to populate the version on
> release and deployment for reproducibility.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-624) automatic parent versioning
[
https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=336980#comment-336980
]
Adrian Shum commented on MNG-624:
-
For all suggestion/workaround proposed here using a property for parent
version, they all suffer from one issue: This will work for build, but will
fail on using the result as dependency.
Assuming I have a very simple structure like this:
{code}
foo-parent
foo-lib
{code}
assume the POm of foo-lib contains
{code}
foo
foo-parent
${foo.version}
../foo-parent/pom.xml
{code}
(foo.version can be provided by any means, by command line or by property
defined in parent etc)
Because Maven is deploying/installing the POM as-is. That means, if I put
foo-lib in the repository, when people is using it as dependency, the POM is
containing only ${foo.version} string literal as the parent version. There is
no way that it can resolve the correct parent POM to refer to.
May I suggests, instead of deploying the POM as-is, we are creating an
"effective" POM to use to deploy? In the "effective" POM, we have all necessary
properties replaced and use that for install/deploy.
> automatic parent versioning
> ---
>
> Key: MNG-624
> URL: https://jira.codehaus.org/browse/MNG-624
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Reporter: Brett Porter
>Assignee: Ralph Goers
>Priority: Blocker
> Fix For: 3.2
>
> Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see
> MNG-521)
> currently, you have to specify the parent version when extending which makes
> a project stand alone very easily, but has the drawback of being a
> maintainance problem when you start development on a new version. Tools can
> help, but it would be nice not to have to rely on them.
> One alternative is to allow the parent version to be omitted, and when it is
> it is assumed you want the latest. The parent is used from the reactor or the
> universal source directory. IT may also be read from a LATEST in the
> repository though this is contentious - it may be better to simply fail in
> that environment and require builds be in a known checkout structure for
> building individual projects.
> This also introduces the need for tool support to populate the version on
> release and deployment for reproducibility.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5316) Build Extension not resolved from reactor
[ https://jira.codehaus.org/browse/MNG-5316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308966#comment-308966 ] Adrian Shum commented on MNG-5316: -- Any comments or update on this issue? I am a bit worried that this issue tracker is not actually in use, is it? > Build Extension not resolved from reactor > - > > Key: MNG-5316 > URL: https://jira.codehaus.org/browse/MNG-5316 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.4 > Environment: Windows XP, JDK 1.6.0_30 >Reporter: Adrian Shum > Attachments: exttest.zip > > > This seems to be what described in another bug MNG-1323. > I encountered this issue when I am trying out what described in FindBugs > multi-module configuration: > http://mojo.codehaus.org/findbugs-maven-plugin/examples/multi-module-config.html > Attached please find a sample project which I skimmed from my existing > project. > exttest is a multi-module project > exttest-qa module is the module aimed to be included as extension. This > module is not having any dependency, and it is intentionally not inheriting > from exttest-parent to avoid cyclic dependency > exttest-parent is the parent POM for the whole project, and it add exttest-qa > as a build extension. > exttest-main did nothing in this test. I put it in just to make the whole > project looks more reasonable :) > Simply mvn clean will shows the error of : > [ERROR] Unresolveable build extension: Plugin > com.foo:exttest-qa:1.0-SNAPSHOT or one of its dependencies could not be > resolved: Failure to find com.foo:exttest-qa:jar:1.0-SNAPSHOT in > However I expect exttest-qa should be resolved from the reactor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5316) Build Extension not resolved from reactor
Adrian Shum created MNG-5316: Summary: Build Extension not resolved from reactor Key: MNG-5316 URL: https://jira.codehaus.org/browse/MNG-5316 Project: Maven 2 & 3 Issue Type: Bug Affects Versions: 3.0.4 Environment: Windows XP, JDK 1.6.0_30 Reporter: Adrian Shum Attachments: exttest.zip This seems to be what described in another bug MNG-1323. I encountered this issue when I am trying out what described in FindBugs multi-module configuration: http://mojo.codehaus.org/findbugs-maven-plugin/examples/multi-module-config.html Attached please find a sample project which I skimmed from my existing project. exttest is a multi-module project exttest-qa module is the module aimed to be included as extension. This module is not having any dependency, and it is intentionally not inheriting from exttest-parent to avoid cyclic dependency exttest-parent is the parent POM for the whole project, and it add exttest-qa as a build extension. exttest-main did nothing in this test. I put it in just to make the whole project looks more reasonable :) Simply mvn clean will shows the error of : [ERROR] Unresolveable build extension: Plugin com.foo:exttest-qa:1.0-SNAPSHOT or one of its dependencies could not be resolved: Failure to find com.foo:exttest-qa:jar:1.0-SNAPSHOT in However I expect exttest-qa should be resolved from the reactor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5316) Build Extension not resolved from reactor
[ https://jira.codehaus.org/browse/MNG-5316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Shum updated MNG-5316: - Attachment: exttest.zip > Build Extension not resolved from reactor > - > > Key: MNG-5316 > URL: https://jira.codehaus.org/browse/MNG-5316 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.4 > Environment: Windows XP, JDK 1.6.0_30 >Reporter: Adrian Shum > Attachments: exttest.zip > > > This seems to be what described in another bug MNG-1323. > I encountered this issue when I am trying out what described in FindBugs > multi-module configuration: > http://mojo.codehaus.org/findbugs-maven-plugin/examples/multi-module-config.html > Attached please find a sample project which I skimmed from my existing > project. > exttest is a multi-module project > exttest-qa module is the module aimed to be included as extension. This > module is not having any dependency, and it is intentionally not inheriting > from exttest-parent to avoid cyclic dependency > exttest-parent is the parent POM for the whole project, and it add exttest-qa > as a build extension. > exttest-main did nothing in this test. I put it in just to make the whole > project looks more reasonable :) > Simply mvn clean will shows the error of : > [ERROR] Unresolveable build extension: Plugin > com.foo:exttest-qa:1.0-SNAPSHOT or one of its dependencies could not be > resolved: Failure to find com.foo:exttest-qa:jar:1.0-SNAPSHOT in > However I expect exttest-qa should be resolved from the reactor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5182) Abnormal behavior for plugin POM download when missing plugin version
Abnormal behavior for plugin POM download when missing plugin version - Key: MNG-5182 URL: https://jira.codehaus.org/browse/MNG-5182 Project: Maven 2 & 3 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.2.1 Environment: JDK 1.6.0_23 (64 bit) , Nexus 1.8 for repository, Windows 7 64 bit Reporter: Adrian Shum Attachments: pom.xml In our company repository (using Nexus), it provide several repository groups. PUBLIC is proxy to public repository. EXT contains 3rd party artifacts that is not available on public repo. My settings.xml contains NO mirrors declaration, and in which defined a activeProfile that contains several repositories and plugin repositories, which put EXT and PUBLIC (EXT comes before PUBLIC). I have did a minor change in a 3rd party plugin, org.codehaus.mojo:native2ascii-maven-plugin:1.0-alpha-1, and I put the modified version in EXT repo, with version changed to 1.0-alpha-1.1 A project is declared to use the plugin org.codehaus.mojo:native2ascii-maven-plugin, with no version provided. Local repository should be purged before building the project. By building the project, and inspects the local repository, it can be found that only JAR of the plugin is downloaded, but not the POM. By adding -X option when building with Maven, it can be found that Maven is downloading JAR of org.codehaus.mojo:native2ascii-maven-plugin:1.0-alpha-1.1 from EXT, but then trying to get the POM from central. As there is no such artifact in central repository, Maven treated that as no POM available. However, if plugin version is added in the project POM, everything will be fine. Plugin POM is correctly downloaded. Although it is my fault that plugin version is missed in the project, it does not seems that reasonable for the behavior for Maven: It downloaded the plugin JAR from the first plugin repository (I bet it simply get the latest version), and then trying to get the plugin POM from a totally unrelated location (central repo in such case). Attached please find the testing project as part of the test case. However, as the test needs quite a lot of setup in the environment, I cannot provide the full test case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MENFORCER-42) Maven-Enforcer-Plugin fails in multimodule project when artifacts not in repository
[
http://jira.codehaus.org/browse/MENFORCER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234533#action_234533
]
Adrian Shum commented on MENFORCER-42:
--
I am encountering the same problem. In a multimodule project, child1 depends
on child2. Enforcer plugin failed when it runs on child1, complaining that it
cannot resolve child2. I am using Enforcer 1.0-beta1, with Maven 2.2.1.
Is there any workaround for this?
> Maven-Enforcer-Plugin fails in multimodule project when artifacts not in
> repository
> ---
>
> Key: MENFORCER-42
> URL: http://jira.codehaus.org/browse/MENFORCER-42
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 1.0-alpha-3, 1.0
> Environment: Tested with Maven 2.0.7 and 2.0.8 on Linux with Java 1.5
>Reporter: Martin Höller
>Assignee: Brian Fox
> Attachments: enforcer-test.tar.gz
>
>
> Create a new simple multimodule-project and call {{mvn validate}} at the
> toplevel. This leads to a build failure if none of the multimodule-artifacts
> are in your local repository.
> Attached is a simple test project for reproducing this bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-584) Skip checking SCM setting for update-versions
Skip checking SCM setting for update-versions - Key: MRELEASE-584 URL: http://jira.codehaus.org/browse/MRELEASE-584 Project: Maven 2.x Release Plugin Issue Type: Improvement Reporter: Adrian Shum As update-versions goal involves only local changes, it is not necessary to check for existence of tags -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-441) manifest is incorrectly 'overwritten' when using jar-with-dependencies
manifest is incorrectly 'overwritten' when using jar-with-dependencies -- Key: MASSEMBLY-441 URL: http://jira.codehaus.org/browse/MASSEMBLY-441 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-4 Environment: Maven 2.1 JDK 1.5 Reporter: Adrian Shum maven-assembly-plugin jar-with-dependencies my.fullly.qualified.MainClass make-assembly package directory I used the plugin config above and tried to create a 'all-in-one executable jar'. However, I found the MANIFEST.MF is not really what I declared. It seems that MANIFEST.MF of certain dependencies JARs is put there instead (In my case, Oracle's JDBC driver JAR's MANIFEST.MF is presented) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
