[jira] (SCM-530) Add support for git submodules to git SCM provider
[ https://jira.codehaus.org/browse/SCM-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=332261#comment-332261 ] sital anadkat commented on SCM-530: --- Hi , I supplied a patch to use git submodules, please see the following link http://jira.codehaus.org/browse/MRELEASE-726#comment-324432 Add support for git submodules to git SCM provider -- Key: SCM-530 URL: https://jira.codehaus.org/browse/SCM-530 Project: Maven SCM Issue Type: New Feature Components: maven-scm-provider-git Affects Versions: 1.3 Reporter: Chas Emerick Pretty self-explanatory. Example fallout of this issue: release:perform on a project that refers to other git repos as submodules cannot succeed. -- 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-5315) Artifact resolution sporadically fails in parallel builds
[
https://jira.codehaus.org/browse/MNG-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=332278#comment-332278
]
Sami Salonen commented on MNG-5315:
---
Thanks a lot Sandy for your solution.
We used to suffer from this very same problem on a daily basis. I applied your
patch to both maven 3.0.5 and 3.1.0. Now, after one month and about 3000 builds
later, not a single build has failed for this problem anymore. Perfect.
Artifact resolution sporadically fails in parallel builds
-
Key: MNG-5315
URL: https://jira.codehaus.org/browse/MNG-5315
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.0.4
Reporter: Ivan S. Dubrov
Assignee: Jason van Zyl
Priority: Minor
Artifact resolution can fail during the parallel build if it was downloaded
during the same session.
Scenario:
1) Delete the whole Maven local repository.
2) Run build mvn compile -T1.5C
3) Build fails (see log extracts below)
4) If I run build again, it succeeds.
It seems like the problem is due to two thread trying to resolve same
artifact concurrently. This problem never happens once I have all
dependencies cached in the local repository.
Extracts from the log output:
{noformat}Downloading:
http://nexus/content/repositories/thirdparty/com/googlecode/guava-osgi/guava-osgi/11.0.0/guava-osgi-11.0.0.jar
12444/13937 KB ...
...
[DEBUG] Skipped remote update check for commons-cli:commons-cli:jar:1.2,
already updated during this session.
[DEBUG] Skipped remote update check for
com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, already updated during this
session.
[DEBUG] Skipped remote update check for org.slf4j:slf4j-api:jar:1.6.4,
already updated during this session.
[DEBUG] Skipped remote update check for org.slf4j:slf4j-jdk14:jar:1.6.4,
already updated during this session.
...
[ERROR] Failed to execute goal on project util: Could not resolve
dependencies for project com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The
following artifacts could not be resolved: commons-cli:commons-cli:jar:1.2,
com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
find commons-cli:commons-cli:jar:1.2 in
http://nexus/content/repositories/thirdparty was cached in the local
repository, resolution will not be reattempted until the update interval of
gw.thirdparty has elapsed or updates are forced - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal on project util: Could not resolve dependencies for project
com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The following artifacts could not
be resolved: commons-cli:commons-cli:jar:1.2,
com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
find commons-cli:commons-cli:jar:1.2 in
http://nexus/content/repositories/thirdparty was cached in the local
repository, resolution will not be reattempted until the update interval of
gw.thirdparty has elapsed or updates are forced
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
at
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused
[jira] (MRESOURCES-31) Dependency resolution for resource filtering
[
https://jira.codehaus.org/browse/MRESOURCES-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=332282#comment-332282
]
Emeric MARTINEAU commented on MRESOURCES-31:
Hi,
you can't use :
{code}
${project.dependencies[0].artifactId}
${project.dependencies[org.mvel:mvel].version}
{code}
Why ?
Two things.
You must make difference between, filtering (in file) and replace in pom.
In pom file, $\{project.dependencies[0].artifactId} work (exemple below)
because, is use class called
org.apache.maven.plugin.PluginParameterExpressionEvaluator that use
org.codehaus.plexus.util.introspection.ReflectionValueExtractor that support
index properties
{code:xml}
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasegenerate-sources/phase
configuration
tasks
echo${project.dependencies[0].artifactId}/echo
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
/plugin
{code}
when your are in filtering, is use class
org.codehaus.plexus.interpolation.PrefixedObjectValueSource that use
org.codehaus.plexus.interpolation.ObjectBasedValueSource that
org.codehaus.plexus.interpolation.reflection.ReflectionValueExtractor that not
support index properties.
You can see that exemple :
{code}
project.dependencies=${project.dependencies}
give :
project.dependencies=[Dependency {groupId=org.apache.maven,
artifactId=maven-plugin-api, version=2.0.6, type=jar}, Dependency
{groupId=org.apache.maven, artifactId=maven-model, version=3.0.5, type=jar}]
project.dependencies[0].artifactId=${project.dependencies[0].artifactId}
give :
project.dependencies[0].artifactId=${project.dependencies[0].artifactId}
{code}
to change this way, org.apache.maven.shared.filtering.DefaultMavenFileFilter
(method getReader) must be change.
I don't know if easy to change that (what are side effect ?).
Maybe someone of maven team may provide his point of view ?
Dependency resolution for resource filtering
Key: MRESOURCES-31
URL: https://jira.codehaus.org/browse/MRESOURCES-31
Project: Maven Resources Plugin
Issue Type: Wish
Affects Versions: 2.2
Reporter: Daniel Holmen
Priority: Minor
I've been trying to use the project.compileClasspathElements property in a
filtered resource, but discovered that Resources plugin isn't set up to
require dependency resolution. The result of this is that i cannot use any of
the classpath properties in my filtered resources.
The solution is quite simple, just add a @requiresDependencyResolution
annotation to ResourcesMojo. I have no idea if this causes any bad
side-effects - but it seemed to work properly when I tested it locally.
--
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-5237) Cannot download maven dependencies through NTLM proxy
[
https://jira.codehaus.org/browse/MNG-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=332304#comment-332304
]
Kristian Rosenvold edited comment on MNG-5237 at 9/3/13 2:02 PM:
-
We just had a fix in Wagon (d6a6c6f6e133365ff6a68d06de3ab1bfc0a0484c) that
might resolve this issue also of wagon-http.
I just started a build on CI and an updated snapshot should be available on
https://repository.apache.org/content/groups/snapshots/org/apache/maven/wagon/wagon-http/2.5-SNAPSHOT/
soonish (check timestamp on file!). Copy the http-wagon jar file to the lib
installation directory of their maven installation (dont forget to remove the
old one)
was (Author: krosenvold):
We just had a fix in Wagon (d6a6c6f6e133365ff6a68d06de3ab1bfc0a0484c) that
might resolve this issue also of wagon-http.
An updated version does not seem to be available at
https://repository.apache.org/content/groups/snapshots/org/apache/maven/wagon/wagon-http/2.5-SNAPSHOT/
yet, but people interested in testing this can build wagon from source
(https://github.com/apache/maven-wagon.git ) and copy the http-wagon jar file
to the lib installation directory of their maven installation (dont forget to
remove the old one)
Cannot download maven dependencies through NTLM proxy
-
Key: MNG-5237
URL: https://jira.codehaus.org/browse/MNG-5237
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.0.4
Environment: windows xp64 using cygwin
Reporter: Niels Mordt-Ostergaard
Assignee: Jason van Zyl
Using proxy in settings.xml, I was able to download maven dependencies in
3.0.3, but this seems to be broken with 3.0.4:
Proxy definition in settings.xml (hidden ip adress below, but correct proxy
ip on my system):
{code:xml} proxies
proxy
idoptional/id
activetrue/active
protocolhttp/protocol
username/username
password/password
hostxxx.xx.xx.xx/host
port8080/port
nonProxyHostslocalhost|127.0.0.1/nonProxyHosts
/proxy
/proxies{code}
Output from 3.0.3:
{noformat}$ mvn -V clean
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: C:\Program Files\apache-maven-3.0.3
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_24\jre
Default locale: no_NO, platform encoding: Cp1252
OS name: windows xp, version: 5.2, arch: amd64, family: windows
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building xxx hidden xxx
[INFO]
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
Downloaded:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
(5 KB at 4.9 KB/sec)
. and so on...
Output from 3.0.4:
$ mvn -V clean
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: C:\Program Files\apache-maven-3.0.4
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_24\jre
Default locale: no_NO, platform encoding: Cp1252
OS name: windows xp, version: 5.2, arch: amd64, family: windows
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building xxx hidden xxx
[INFO]
Downloading:
http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.390s
[INFO] Finished at: Fri Feb 03 13:14:35 CET 2012
[INFO] Final Memory: 5M/490M
[INFO]
[ERROR] Plugin org.apache.maven.plugins:maven-clean-plugin:2.4.1 or one of
its dependencies could not be resolved: Failed to read artifact descriptor
for org.apache.maven.plugins:maven-clean-plugin:jar:2.4.1: Could not transfer
artifact org.apache.maven.plugins:maven-clean-plugin:pom:2.4.1 from/to
central (http://repo.maven.apache.org/maven2): Access denied to:
http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom,
ReasonPhrase:Forbidden. - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven
[jira] (MSHADE-154) Add ability for shade to find primary artifact from attached artifacts (similar to assembly-plugin)
Richard Sand created MSHADE-154: --- Summary: Add ability for shade to find primary artifact from attached artifacts (similar to assembly-plugin) Key: MSHADE-154 URL: https://jira.codehaus.org/browse/MSHADE-154 Project: Maven Shade Plugin Issue Type: New Feature Affects Versions: 2.0 Environment: all Reporter: Richard Sand Attachments: patch.txt When switching from assembly-plugin to shade-plugin for a given project, I discovered that the shade plugin did not have the capability of using an attached artifact as the primary artifact - only the project's main artifact was supported. I've attached changes to add a configuration parameter alternativeInputClassifier, which, when specified, tells the plugin to look for an artifact with the specified classifier in the project attachments, and to use that as the primary artifact. This makes shade behave similar to assembly-plugin, and allows shade to recognize attached artifacts generated by previous plugins in a maven execution. This was a trivial change, but required modifying several other classes and methods to accept the primary artifact as a parameter instead of a global variable. IMHO these changes are good for the plugin as a whole, as it will allow for future flexibility and logic for determining the entrypoint for the plugin (e.g. being able to run as a standalone goal with a specific artifact as input). -- 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-5237) Cannot download maven dependencies through NTLM proxy
[
https://jira.codehaus.org/browse/MNG-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=332304#comment-332304
]
Kristian Rosenvold commented on MNG-5237:
-
We just had a fix in Wagon (d6a6c6f6e133365ff6a68d06de3ab1bfc0a0484c) that
might resolve this issue also of wagon-http.
An updated version does not seem to be available at
https://repository.apache.org/content/groups/snapshots/org/apache/maven/wagon/wagon-http/2.5-SNAPSHOT/
yet, but people interested in testing this can build wagon from source
(https://github.com/apache/maven-wagon.git ) and copy the http-wagon jar file
to the lib installation directory of their maven installation (dont forget to
remove the old one)
Cannot download maven dependencies through NTLM proxy
-
Key: MNG-5237
URL: https://jira.codehaus.org/browse/MNG-5237
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.0.4
Environment: windows xp64 using cygwin
Reporter: Niels Mordt-Ostergaard
Assignee: Jason van Zyl
Using proxy in settings.xml, I was able to download maven dependencies in
3.0.3, but this seems to be broken with 3.0.4:
Proxy definition in settings.xml (hidden ip adress below, but correct proxy
ip on my system):
{code:xml} proxies
proxy
idoptional/id
activetrue/active
protocolhttp/protocol
username/username
password/password
hostxxx.xx.xx.xx/host
port8080/port
nonProxyHostslocalhost|127.0.0.1/nonProxyHosts
/proxy
/proxies{code}
Output from 3.0.3:
{noformat}$ mvn -V clean
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: C:\Program Files\apache-maven-3.0.3
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_24\jre
Default locale: no_NO, platform encoding: Cp1252
OS name: windows xp, version: 5.2, arch: amd64, family: windows
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building xxx hidden xxx
[INFO]
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
Downloaded:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
(5 KB at 4.9 KB/sec)
. and so on...
Output from 3.0.4:
$ mvn -V clean
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: C:\Program Files\apache-maven-3.0.4
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_24\jre
Default locale: no_NO, platform encoding: Cp1252
OS name: windows xp, version: 5.2, arch: amd64, family: windows
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building xxx hidden xxx
[INFO]
Downloading:
http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.390s
[INFO] Finished at: Fri Feb 03 13:14:35 CET 2012
[INFO] Final Memory: 5M/490M
[INFO]
[ERROR] Plugin org.apache.maven.plugins:maven-clean-plugin:2.4.1 or one of
its dependencies could not be resolved: Failed to read artifact descriptor
for org.apache.maven.plugins:maven-clean-plugin:jar:2.4.1: Could not transfer
artifact org.apache.maven.plugins:maven-clean-plugin:pom:2.4.1 from/to
central (http://repo.maven.apache.org/maven2): Access denied to:
http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom,
ReasonPhrase:Forbidden. - [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/PluginResolutionException
{noformat}
--
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] (MRELEASE-846) m2 release plugin exposes SCM password in release.properties file
Mark Maun created MRELEASE-846: -- Summary: m2 release plugin exposes SCM password in release.properties file Key: MRELEASE-846 URL: https://jira.codehaus.org/browse/MRELEASE-846 Project: Maven Release Plugin Issue Type: Bug Reporter: Mark Maun When executing a maven release build using the m2 release plugin in Jenkins a release.properties file is created in the workspace that has the SCM user/password credentials in plain text. In our jenkins instance this is a problem since we have multiple users with access to release the same job. The release.properties is removed after the release build is successful. If the release build fails the release.properties stays in the workspace until it's manually deleted. This allows other users to see SCM passwords in our organization if they view the workspace during a release build or after one fails. 4 If anyone has viable workarounds/solutions we can use in the meantime that would also be appreciated. Note I have a ticket open with Jenkins dev but they deferred me here: https://issues.jenkins-ci.org/browse/JENKINS-19416 -- 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] (SUREFIRE-1028) Unable to run single test (junit)
Diwaker Gupta created SUREFIRE-1028:
---
Summary: Unable to run single test (junit)
Key: SUREFIRE-1028
URL: https://jira.codehaus.org/browse/SUREFIRE-1028
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.16
Reporter: Diwaker Gupta
Priority: Critical
This is a regression from 2.15. It also looks like Surefire keeps regressing on
this feature (e.g. see SUREFIRE-827) -- are there no unit or integration tests
to prevent such regressions?
With Surefire 2.15
{noformat}
$ mvn test -Dtest=MyTest#testFoo
...
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
{noformat}
With Surefire 2.16
{noformat}
$ mvn test -Dtest=MyTest#testFoo
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
{noformat}
--
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
