[jira] Commented: (MDEP-106) Unpacking primary artifact from sibling module uses repository rather than reactor
[
https://jira.codehaus.org/browse/MDEP-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=273301#comment-273301
]
Matt Ryall commented on MDEP-106:
-
Thanks for the update, Stephen.
Unpacking primary artifact from sibling module uses repository rather than
reactor
--
Key: MDEP-106
URL: https://jira.codehaus.org/browse/MDEP-106
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack
Affects Versions: 2.0-alpha-4
Reporter: Matt Ryall
Assignee: Brian Fox
Fix For: 2.3
Running dependency:unpack referencing a project in the reactor has the
following output which shows it is scanning for repository artifacts rather
than the artifact in the reactor:
{quote}
[INFO] [dependency:unpack \{execution: unpack-tests}]
[INFO] Configured Artifact:
com.example.app:app-acceptance-test:2.6-SNAPSHOT:jar
[INFO] snapshot com.example.app:app-acceptance-test:2.6-SNAPSHOT: checking
for updates from snapshots
[INFO] snapshot com.example.app:app-acceptance-test:2.6-SNAPSHOT: checking
for updates from m1-repo
Downloading:
http://m2proxy:8081/artifactory/repo/com/example/app/app-acceptance-test/2.6-SNAPSHOT/app-acceptance-test-2.6-20070829.025709-409.jar
9125K downloaded
[INFO] Expanding:
/Users/mryall/.m2/repository/com/example/app/app-acceptance-test/2.6-SNAPSHOT/app-acceptance-test-2.6-SNAPSHOT.jar
into /Users/mryall/src/example/app/app-webapp/target/it-classes
{quote}
To explain the scenario: to build reusable acceptance tests, I have the
following sub-modules of my project:
- app-core (jar)
- app-acceptance-tests (jar)
- app-webapp (war)
The acceptance tests are packaged this way for further use in testing, and
also run against the webapp in the integration-test phase. This is where the
problem arises.
Running 'mvn clean integration-test' does the following relevant tasks:
- in the app-acceptance-test module, compiles and packages a JAR of tests
- in the app-webapp module, uses the dependency:unpack goal to extract the
tests into target/it-classes in the pre-integration-test phase, and test:test
to run them in the integration test phase.
I don't think this is caused by the snapshot version, because the release
plugin also fails because it is unable to find the 2.6 version when it runs
'mvn clean verify'. There, it scans all the repositories for the acceptance
test artifact before failing with the usual error:
{quote}
[INFO] Failed to resolve artifact.
GroupId: com.example.app
ArtifactId: app-acceptance-test
Version: 2.6
Reason: Unable to download the artifact from any repository
{quote}
Maven details:
{noformat}
$ mvn -version
Maven version: 2.0.7
Java version: 1.4.2_12
OS name: mac os x version: 10.4.10 arch: i386
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3361) Deploying from Leopard, with Svn 1.4.4 has error on automated Svn commit
[ http://jira.codehaus.org/browse/MNG-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126772 ] Matt Ryall commented on MNG-3361: - This is actually a Leopard issue, but there is a bug in Subversion for tracking it here: http://subversion.tigris.org/issues/show_bug.cgi?id=3059 Deploying from Leopard, with Svn 1.4.4 has error on automated Svn commit Key: MNG-3361 URL: http://jira.codehaus.org/browse/MNG-3361 Project: Maven 2 Issue Type: Bug Components: Deployment Affects Versions: 2.0.8 Reporter: Paul Hammant [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 3 minutes 25 seconds [INFO] Finished at: Fri Jan 11 08:49:42 PST 2008 [INFO] Final Memory: 14M/29M [INFO] [INFO] Checking in modified POMs... [INFO] Executing: svn --non-interactive commit --file /tmp/maven-scm-1359802395.commit --targets /tmp/maven-scm-28211-targets [INFO] Working directory: /scm/oss/jremoting/root/trunk [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to commit files Provider message: The svn command failed. Command output: svn: Commit failed (details follow): svn: MKACTIVITY of '/jremoting/!svn/act/c136e17a-8ec7-44c4-a326-b2611ec72ffc': authorization failed (https://svn.codehaus.org) -- 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] Commented: (MRELEASE-260) Profiles given on command-line not added to exec.additionalArguments
[
http://jira.codehaus.org/browse/MRELEASE-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106340
]
Matt Ryall commented on MRELEASE-260:
-
A simpler workaround is to use the -Darguments system property for the
release:perform step like so:
{noformat}
mvn release:perform -Darguments=-Pprivate
{noformat}
Profiles given on command-line not added to exec.additionalArguments
Key: MRELEASE-260
URL: http://jira.codehaus.org/browse/MRELEASE-260
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-6
Reporter: Matt Ryall
In my POM, I have two distribution management sections, each in a separate
profile:
{code:xml}
...
profiles
profile
idprivate/id
distributionManagement
repository
idprivate-repository/id
urlscp://repository.example.com/opt/mvn/private/url
/repository
/distributionManagement
/profile
profile
idpublic/id
distributionManagement
repository
idpublic-repository/id
urlscp://repository.example.com/opt/mvn/public/url
/repository
/distributionManagement
/profile
/profiles
{code}
Running {{mvn release:prepare -Ppublic}} puts the following line in
release.properties:
{{exec.additionalArguments=-P default-profile,default-profile}}
(The profile default-profile is the profile in my settings.xml which is
active by default.)
If the release plugin was working correctly, this line would be:
{{exec.additionalArguments=-P default-profile,public}}
In earlier betas, I believe this worked correctly. The workaround I'm using
is to run {{mvn release:prepare}}, then {{mvn release:perform}}. The second
command fails, and I go to {{target/checkout}}, and run {{mvn deploy
-Ppublic}} manually.
Changing {{release.properties}} doesn't work, either. It seems like
{{release:perform}} uses its own list of profiles, not the ones in the
properties file.
--
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: (MDEP-106) Unpacking primary artifact from sibling module uses repository rather than reactor
Unpacking primary artifact from sibling module uses repository rather than
reactor
--
Key: MDEP-106
URL: http://jira.codehaus.org/browse/MDEP-106
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack
Affects Versions: 2.0-alpha-4
Reporter: Matt Ryall
Assignee: Brian Fox
Running dependency:unpack referencing a project in the reactor has the
following output which shows it is scanning for repository artifacts rather
than the artifact in the reactor:
{quote}
[INFO] [dependency:unpack \{execution: unpack-tests}]
[INFO] Configured Artifact: com.example.app:app-acceptance-test:2.6-SNAPSHOT:jar
[INFO] snapshot com.example.app:app-acceptance-test:2.6-SNAPSHOT: checking for
updates from snapshots
[INFO] snapshot com.example.app:app-acceptance-test:2.6-SNAPSHOT: checking for
updates from m1-repo
Downloading:
http://m2proxy:8081/artifactory/repo/com/example/app/app-acceptance-test/2.6-SNAPSHOT/app-acceptance-test-2.6-20070829.025709-409.jar
9125K downloaded
[INFO] Expanding:
/Users/mryall/.m2/repository/com/example/app/app-acceptance-test/2.6-SNAPSHOT/app-acceptance-test-2.6-SNAPSHOT.jar
into /Users/mryall/src/example/app/app-webapp/target/it-classes
{quote}
To explain the scenario: to build reusable acceptance tests, I have the
following sub-modules of my project:
- app-core (jar)
- app-acceptance-tests (jar)
- app-webapp (war)
The acceptance tests are packaged this way for further use in testing, and also
run against the webapp in the integration-test phase. This is where the problem
arises.
Running 'mvn clean integration-test' does the following relevant tasks:
- in the app-acceptance-test module, compiles and packages a JAR of tests
- in the app-webapp module, uses the dependency:unpack goal to extract the
tests into target/it-classes in the pre-integration-test phase, and test:test
to run them in the integration test phase.
I don't think this is caused by the snapshot version, because the release
plugin also fails because it is unable to find the 2.6 version when it runs
'mvn clean verify'. There, it scans all the repositories for the acceptance
test artifact before failing with the usual error:
{quote}
[INFO] Failed to resolve artifact.
GroupId: com.example.app
ArtifactId: app-acceptance-test
Version: 2.6
Reason: Unable to download the artifact from any repository
{quote}
Maven details:
{noformat}
$ mvn -version
Maven version: 2.0.7
Java version: 1.4.2_12
OS name: mac os x version: 10.4.10 arch: i386
{noformat}
--
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-260) Profiles given on command-line not added to exec.additionalArguments
Profiles given on command-line not added to exec.additionalArguments
Key: MRELEASE-260
URL: http://jira.codehaus.org/browse/MRELEASE-260
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-6
Reporter: Matt Ryall
In my POM, I have two distribution management sections, each in a separate
profile:
{code:xml}
...
profiles
profile
idprivate/id
distributionManagement
repository
idprivate-repository/id
urlscp://repository.example.com/opt/mvn/private/url
/repository
/distributionManagement
/profile
profile
idpublic/id
distributionManagement
repository
idpublic-repository/id
urlscp://repository.example.com/opt/mvn/public/url
/repository
/distributionManagement
/profile
/profiles
{code}
Running {{mvn release:prepare -Ppublic}} puts the following line in
release.properties:
{{exec.additionalArguments=-P default-profile,default-profile}}
(The profile default-profile is the profile in my settings.xml which is
active by default.)
If the release plugin was working correctly, this line would be:
{{exec.additionalArguments=-P default-profile,public}}
In earlier betas, I believe this worked correctly. The workaround I'm using is
to run {{mvn release:prepare}}, then {{mvn release:perform}}. The second
command fails, and I go to {{target/checkout}}, and run {{mvn deploy -Ppublic}}
manually.
Changing {{release.properties}} doesn't work, either. It seems like
{{release:perform}} uses its own list of profiles, not the ones in the
properties file.
--
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: (MNG-2999) Receiving a 403 response from a mirror server should attempt other mirrors
Receiving a 403 response from a mirror server should attempt other mirrors -- Key: MNG-2999 URL: http://jira.codehaus.org/browse/MNG-2999 Project: Maven 2 Issue Type: Improvement Affects Versions: 2.0.4 Reporter: Matt Ryall Priority: Minor Trying to download asm:asm:3.0:jar from several of the central mirrors fails with a 403, but it would work if it attempted download from the main site. I'm not sure whether this is an issue caused by the fact that the mirrors aren't true mirrors, or that Maven should attempt other mirrors if one of them fails with a 403 (or perhaps also 404) error. -- 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
