[jira] (MENFORCER-133) Plugin brought by Maven extension fail the requirePluginVersions check
Vincent Massol created MENFORCER-133:
Summary: Plugin brought by Maven extension fail the
requirePluginVersions check
Key: MENFORCER-133
URL: https://jira.codehaus.org/browse/MENFORCER-133
Project: Maven 2.x Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 1.1
Reporter: Vincent Massol
Here's my use case (on the XWiki project):
* I have a custom maven lifecycle:
https://github.com/xwiki/xwiki-commons/tree/master/xwiki-commons-tools/xwiki-commons-tool-xar/xwiki-commons-tool-xar-handlers
* This lifecycle depends on a custom plugin:
https://github.com/xwiki/xwiki-commons/tree/master/xwiki-commons-tools/xwiki-commons-tool-xar/xwiki-commons-tool-xar-plugin
When I use this lifecycle in a project the enforcer check fails with:
{noformat}
[DEBUG] All Plugins in use: [Plugin
[org.apache.maven.plugins:maven-clean-plugin], Plugin
[org.apache.maven.plugins:maven-resources-plugin], Plugin
[org.xwiki.commons:xwiki-commons-tool-xar-plugin], Plugin
[org.apache.maven.plugins:maven-compiler-plugin], Plugin
[org.apache.maven.plugins:maven-deploy-plugin], Plugin
[org.apache.maven.plugins:maven-install-plugin], Plugin
[com.mycila.maven-license-plugin:maven-license-plugin], Plugin
[org.apache.maven.plugins:maven-site-plugin], Plugin
[org.apache.maven.plugins:maven-enforcer-plugin], Plugin
[org.apache.maven.plugins:maven-remote-resources-plugin], Plugin
[org.apache.maven.plugins:maven-checkstyle-plugin]]
[DEBUG] plugin org.xwiki.commons:xwiki-commons-tool-xar-plugin not found
[DEBUG] Adding failure due to exception
org.apache.maven.enforcer.rule.api.EnforcerRuleException: Some plugins are
missing valid versions:(SNAPSHOT are not allowed )
org.xwiki.commons:xwiki-commons-tool-xar-plugin.The version currently
in use is 4.1-milestone-2
{noformat}
The way the lifecycle is used is:
{noformat}
...
build
extensions
!-- Needed to add support for the xar packaging --
extension
groupIdorg.xwiki.commons/groupId
artifactIdxwiki-commons-tool-xar-handlers/artifactId
version${commons.version}/version
/extension
/extensions
...
{noformat}
So the problem is that the Enforcer seems to not see that the plugin *IS*
versionned in the xwiki-commons-tool-xar-handlers pom.xml.
Looks like a bug with extensions and enforcer plugin requirePluginVersions
rule. Not sure where the real culprit lies though.
--
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] (SUREFIRE-827) Surefire 2.12 cannot run a single test, regression from 2.11
[ https://jira.codehaus.org/browse/SUREFIRE-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300810#comment-300810 ] Falko Modler commented on SUREFIRE-827: --- Any progress? In my opinion this is a showstopper (for 2.13). Surefire 2.12 cannot run a single test, regression from 2.11 Key: SUREFIRE-827 URL: https://jira.codehaus.org/browse/SUREFIRE-827 Project: Maven Surefire Issue Type: Bug Components: Junit 4.7+ (parallel) support Affects Versions: 2.12 Environment: Ubuntu 11.10 Reporter: Andrew Gaul Assignee: Kristian Rosenvold Attachments: BUG-827.zip # Surefire 2.11 $ mvn test -Dtest=DataTest#testDataServerGetNonExistentFile ... Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 # Surefire 2.12 mvn test -Dtest=DataTest#testDataServerGetNonExistentFile ... Tests run: 9, Failures: 0, Errors: 0, Skipped: 0 -- 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-5245) upgrade default plugins versions
[ https://jira.codehaus.org/browse/MNG-5245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300811#comment-300811 ] Falko Modler commented on MNG-5245: --- I am strongly opposed to using surefire 2.12 because of this bug which affects many users: http://jira.codehaus.org/browse/SUREFIRE-827 upgrade default plugins versions Key: MNG-5245 URL: https://jira.codehaus.org/browse/MNG-5245 Project: Maven 2 3 Issue Type: Improvement Components: Plugins and Lifecycle Affects Versions: 3.0.4 Reporter: Olivier Lamy Fix For: 3.0.5 -- 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] (MPIR-246) use maven-plugin-tools' java 5 annotations
Herve Boutemy created MPIR-246: -- Summary: use maven-plugin-tools' java 5 annotations Key: MPIR-246 URL: https://jira.codehaus.org/browse/MPIR-246 Project: Maven 2.x Project Info Reports Plugin Issue Type: Task Affects Versions: 2.4 Reporter: Herve Boutemy see MPLUGIN-203 -- 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] (MDEP-330) Dependency exclusions are not respected
[
https://jira.codehaus.org/browse/MDEP-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300822#comment-300822
]
Benjamin Haag commented on MDEP-330:
I just tried to use excludeGroupIds.
This doesn't work too.
Version 2.4
Dependency exclusions are not respected
---
Key: MDEP-330
URL: https://jira.codehaus.org/browse/MDEP-330
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: copy-dependencies
Affects Versions: 2.3
Reporter: Lon Binder
Assignee: Brian Fox
Priority: Critical
The copy-dependencies goal does not respect the {{exclusions}} list for a
dependency and copies even excluded dependencies. Not sure whether this is
intentional or not, so marking as a bug (perhaps this should be an
enhancement?).
If a transitive dependency is excluded it should not be copied.
--
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] (MWAR-269) war fails to build while using m2e in workspace resolution mode
[ https://jira.codehaus.org/browse/MWAR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300828#comment-300828 ] Thomas Broyer commented on MWAR-269: Isn't that a manifestation of MNG-5214? war fails to build while using m2e in workspace resolution mode --- Key: MWAR-269 URL: https://jira.codehaus.org/browse/MWAR-269 Project: Maven 2.x WAR Plugin Issue Type: Improvement Affects Versions: 2.1.1 Reporter: Chris Gamache Attachments: maven-war-plugin.patch, screenshot-1.png This is my first time for an issue/patch submission. Apologies if I'm doing it wrong When building in Eclipse using m2e in workspace resolution mode, the maven-war-plugin is not prepared for a dependency which isn't an assembly but is instead a folder containing the compiled classes from within the local workspace. I propose that if the incoming dependency happens to be a directory that it get packaged up and copied to the destination instead of blowing up with an exception. See attached patch for your review... -- 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] (MWAR-269) war fails to build while using m2e in workspace resolution mode
[ https://jira.codehaus.org/browse/MWAR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300830#comment-300830 ] Chris Gamache commented on MWAR-269: I don't think so, but I am no Maven expert. The problem I was observing was an interaction in the war plugin plus m2e. In workspace resolution mode, m2e is happy to provide a folder of classes instead of building a jar for a named artifact. This is fine when you stay within the bounds of Eclipse for your program execution. If you happen to want to build a war consisting of classes in the workspace using m2e you're out of luck. Taking a page from the way the assembly plugin handles this situation, the patch I proposed would allow the war plugin to package the classes folder and add it to the war. war fails to build while using m2e in workspace resolution mode --- Key: MWAR-269 URL: https://jira.codehaus.org/browse/MWAR-269 Project: Maven 2.x WAR Plugin Issue Type: Improvement Affects Versions: 2.1.1 Reporter: Chris Gamache Attachments: maven-war-plugin.patch, screenshot-1.png This is my first time for an issue/patch submission. Apologies if I'm doing it wrong When building in Eclipse using m2e in workspace resolution mode, the maven-war-plugin is not prepared for a dependency which isn't an assembly but is instead a folder containing the compiled classes from within the local workspace. I propose that if the incoming dependency happens to be a directory that it get packaged up and copied to the destination instead of blowing up with an exception. See attached patch for your review... -- 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] (MDEP-330) Dependency exclusions are not respected
[
https://jira.codehaus.org/browse/MDEP-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300831#comment-300831
]
Benjamin Haag commented on MDEP-330:
Depended on the phase I bind the plugin too ...
Dependency exclusions are not respected
---
Key: MDEP-330
URL: https://jira.codehaus.org/browse/MDEP-330
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: copy-dependencies
Affects Versions: 2.3
Reporter: Lon Binder
Assignee: Brian Fox
Priority: Critical
The copy-dependencies goal does not respect the {{exclusions}} list for a
dependency and copies even excluded dependencies. Not sure whether this is
intentional or not, so marking as a bug (perhaps this should be an
enhancement?).
If a transitive dependency is excluded it should not be copied.
--
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] (MWAR-269) war fails to build while using m2e in workspace resolution mode
[
https://jira.codehaus.org/browse/MWAR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300832#comment-300832
]
Thomas Broyer commented on MWAR-269:
Ah, you're right. The issue seems to actually be that the war plugin doesn't
support artifacts coming from the reactor, when they haven't been packaged,
when using Maven 3.
To reproduce outside Eclipse: have a module B with packaging=war depends on a
module A with packaging=jar; configure the war plugin to execute
{{war:exploded}} in the {{prepare-package}} phase, then run {{mvn
prepare-package}} at the reactor level. Building project B will fail when it'll
try to copy project A, because it expects a packaged JAR, but the JAR wasn't
created as the {{package}} phase wasn't executed, so Maven 3 gives the
{{project.build.outputDirectory}} ({{target/classes}}) instead.
FYI, the Tomcat plugin has a special step using
{{MavenProject#getCompileClasspathElements}} (the war plugin could use
{{getRuntimeClasspathElements}}) and then only {{getDependencies}} (where the
war plugin uses {{getArtifacts}}), skipping those that are part of
{{getProjectReferences}}.
I'm afraid it would require an important refactoring of the war plugin though.
See
https://github.com/apache/tomcat-maven-plugin/blob/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java
war fails to build while using m2e in workspace resolution mode
---
Key: MWAR-269
URL: https://jira.codehaus.org/browse/MWAR-269
Project: Maven 2.x WAR Plugin
Issue Type: Improvement
Affects Versions: 2.1.1
Reporter: Chris Gamache
Attachments: maven-war-plugin.patch, screenshot-1.png
This is my first time for an issue/patch submission. Apologies if I'm doing
it wrong
When building in Eclipse using m2e in workspace resolution mode, the
maven-war-plugin is not prepared for a dependency which isn't an assembly
but is instead a folder containing the compiled classes from within the local
workspace. I propose that if the incoming dependency happens to be a
directory that it get packaged up and copied to the destination instead of
blowing up with an exception.
See attached patch for your review...
--
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] (MRELEASE-285) Unresolved test-jar dependency during release
[ https://jira.codehaus.org/browse/MRELEASE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300844#comment-300844 ] Israel E. Bethencourt commented on MRELEASE-285: A workarround could be to change the preparationgoals in the release plugin configuration: preparationGoalsclean install verify/preparationGoals Unresolved test-jar dependency during release - Key: MRELEASE-285 URL: https://jira.codehaus.org/browse/MRELEASE-285 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0-beta-4 Environment: Maven version: 2.0.7 Java version: 1.5.0_07 OS name: mac os x version: 10.4.10 arch: i386 Reporter: Rod Coffin Attachments: example.jar I have a multi-module project where one project produces a normal jar and a test-jar (http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html). Another submodule has a test scoped dependency on the test-jar from the first submodule. For example, this is the structure and produced artifacts for a small sample (attached) I built to reproduce this behavior: release-test-jar (parent project) project-with-test-jar (submodule) = project-with-test-jar-1.0.jar = project-with-test-jar-1.0-tests.jar project-using-test-jar (submodule) = project-user-test-jar-1.0.jar When I run a 'clean install' the build succeeds. However, when I run a 'release:prepare' the build fails with the following error: 1 required artifact is missing. for artifact: com.rfc:project-using-test-jar:jar:1.1 from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing: -- 1) com.rfc:project-with-test-jar:test-jar:tests:1.1 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.rfc -DartifactId=project-with-test-jar \ -Dversion=1.1 -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=com.rfc -DartifactId=project-with-test-jar \ -Dversion=1.1 -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.rfc:project-using-test-jar:jar:1.1 2) com.rfc:project-with-test-jar:test-jar:tests:1.1 -- 1 required artifact is missing. for artifact: com.rfc:project-using-test-jar:jar:1.1 from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:305) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) at
[jira] (MINVOKER-132) maximumLifetime parameter
Yegor Bugayenko created MINVOKER-132:
Summary: maximumLifetime parameter
Key: MINVOKER-132
URL: https://jira.codehaus.org/browse/MINVOKER-132
Project: Maven 2.x Invoker Plugin
Issue Type: Improvement
Affects Versions: 1.6
Reporter: Yegor Bugayenko
Would be very useful to have {{maximumLifetime}} parameter, which will mean how
many seconds any particular Maven instance can stay alive. Sometimes it's
necessary to test plugins that start some background process and wait for user
action (for example, a servlet container). Would be nice to have an ability to
kill them after, say, a minute.
At the moment there is absolutely no ability to test such a plugin. At least I
didn't find any.
--
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] (MRELEASE-771) release:prepare tries to push tag with invalid Git URL
Tuukka Mustonen created MRELEASE-771:
Summary: release:prepare tries to push tag with invalid Git URL
Key: MRELEASE-771
URL: https://jira.codehaus.org/browse/MRELEASE-771
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: Git, prepare, scm
Affects Versions: 2.3.1
Environment: Debian 6, run form shell
Reporter: Tuukka Mustonen
Suddenly, after no version change of maven-release-plugin, our
{{release:prepare}} started to fail into:
{noformat}
[INFO] Unable to tag SCM
Provider message:
The git-push command failed.
Command output:
ssh: Could not resolve hostname : Name or service not known
fatal: The remote end hung up unexpectedly
{noformat}
The reason appears to be that pushing of the tag uses invalid syntax for git
command:
{noformat}
[INFO] Executing: /bin/sh -c cd /jenkins/job1 git push
ssh://g...@github.mydomain.com myproduct-1.0.0
{noformat}
The problem here is that the target URL ({{ssh://g...@github.mydomain.com}}) is
lacking the actual repository identifier ({{/MyOrganization/myproduct.git}}) -
the plugin is using just {{ssh://g...@github.mydomain.com}} while it should be
using something like
{{ssh://g...@github.mydomain.com/MyOrganization/myproduct.git}}.
I cannot come up with a reason why it started to do this so I cannot give
instructions on to how to reproduce it either. For us, it occurs in one
repository, while in another one using the same plugin version and
configuration the problem doesn't occur.
Apparently the behavior of using ssh-URL instead of {{origin}} as remote
repository has been there for ages, added in SCM-498.
--
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] (MANTTASKS-228) Support maven 3
Orion Poplawski created MANTTASKS-228: - Summary: Support maven 3 Key: MANTTASKS-228 URL: https://jira.codehaus.org/browse/MANTTASKS-228 Project: Maven 2.x Ant Tasks Issue Type: New Feature Reporter: Orion Poplawski Are there any plans to support maven 3? Fedora just dropped maven 2 completely so unless there is maven ant tasks for maven 3 I'm going to need to drop the package from Fedora. -- 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
