[jira] (MINSTALL-74) CLONE -Don't create checksums for gpg signature files
[ https://jira.codehaus.org/browse/MINSTALL-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338242#comment-338242 ] SebbASF commented on MINSTALL-74: - MDEPLOY-73 now redirects to MNG-5504 > CLONE -Don't create checksums for gpg signature files > - > > Key: MINSTALL-74 > URL: https://jira.codehaus.org/browse/MINSTALL-74 > Project: Maven Install Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: SebbASF >Assignee: Benjamin Bentmann >Priority: Minor > > If the gpg plugin is configured and the install plugin configured to create > checksums - then it ends up creating checksums for the signature files as > well as the actual artifacts being installed. > Attaching a patch which stops checksums being created for files ending in > ".asc" -- 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-tabpanel&focusedCommentId=338248#comment-338248
]
Anders Hammar commented on MNG-5237:
@Kristian; Unfortunately you can't drop in wagon-http.jar as the Maven bundled
one includes shaded classes. What I did to try Wagon 2.6 was to build latest
3.2.0-SNAPSHOT of Maven core (0f48aabf522983f648455dba80c4d97980143495) where I
updated the wagon version to 2.6. Trying that shows no success with a NTLM
proxy. However, adding wagon-http-lightweight-2.6.jar to lib/ext makes NTLM
work with the proxy.
> 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}
>
> optional
> true
> http
>
>
> xxx.xx.xx.xx
> 8080
> localhost|127.0.0.1
>
> {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
> [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
> [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] (MNG-5237) Cannot download maven dependencies through NTLM proxy
[
https://jira.codehaus.org/browse/MNG-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338249#comment-338249
]
Anders Hammar commented on MNG-5237:
Also tried Wagon 2.5 in core 3.2.0-SNAPSHOT which doesn't work either.
> 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}
>
> optional
> true
> http
>
>
> xxx.xx.xx.xx
> 8080
> localhost|127.0.0.1
>
> {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
> [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
> [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] (MNG-1977) Global dependency exclusions
[ https://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338250#comment-338250 ] Christoph Henrici commented on MNG-1977: A real world problem needs a solution. > Global dependency exclusions > > > Key: MNG-1977 > URL: https://jira.codehaus.org/browse/MNG-1977 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: POM >Reporter: Kees de Kooter > Fix For: Issues to be reviewed for 4.x > > Attachments: global_excls_it-test_v2.patch, > global_excls_it-test_v3.patch, global_excls_maven3_v2.patch, > global_excls_maven3_v3.patch > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > dependency. -- 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-1977) Global dependency exclusions
[ https://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338250#comment-338250 ] Christoph Henrici edited comment on MNG-1977 at 1/8/14 9:19 AM: A real world problem needs a solution. Is there any real intention to adress this? was (Author: chenrici): A real world problem needs a solution. > Global dependency exclusions > > > Key: MNG-1977 > URL: https://jira.codehaus.org/browse/MNG-1977 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: POM >Reporter: Kees de Kooter > Fix For: Issues to be reviewed for 4.x > > Attachments: global_excls_it-test_v2.patch, > global_excls_it-test_v3.patch, global_excls_maven3_v2.patch, > global_excls_maven3_v3.patch > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > dependency. -- 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-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[ https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338259#comment-338259 ] Paul Millar commented on MRELEASE-812: -- Hit this problem myself (or one like it). The trigger seems to be an upgrade of git from 1.8.5.1 to 1.8.5.2, but I'm still double-checking that. I tried the above work-around posted by Catalin (updating maven-scm version dependency to 1.8.1) but encountered the problem described in SCM 709: support for sub-projects/modules is broken. Is there a way to test SCM 686 and SCM 709 together; e.g., a snapshot or nightly release of maven-scm I could add as a dependency instead of 1.8.1? In SCM 709, they cite a lack of feedback as a reason why progress isn't being made, but it's unclear to me how they expect to receive this feedback if the patch isn't available for testing somewhere. > "prepare" does not commit before tagging and therefore deploys snapshot > instead of release > -- > > Key: MRELEASE-812 > URL: https://jira.codehaus.org/browse/MRELEASE-812 > Project: Maven Release Plugin > Issue Type: Bug > Components: Git >Affects Versions: 2.4 >Reporter: Andrei Pozolotin >Priority: Critical > Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt > > > thank you very much for new release! > http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E > it seems we need an emergency fix: > attached are 2 logs: > 1) mvn-2.3.2.txt invocation that works fine with 2.3.2 > 2) mvn-2.4.0.txt invocation that fails with 2.4 > problem: > "perform" does not commit tags, deploys snapshot instead of release > here is project parent: > http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom > build is invoked both times with this: > mvn --define resume=false release:prepare > mvn --define resume=false release:perform -- 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-5356) Make encrypt/decrypt logic pluggable
[ https://jira.codehaus.org/browse/MNG-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338268#comment-338268 ] Dominik Bartholdi commented on MNG-5356: The issue already exists in Jenkins (https://issues.jenkins-ci.org/browse/JENKINS-16705) and I also resolved it by implementing it this way: https://wiki.jenkins-ci.org/display/JENKINS/Config+File+Provider+Plugin#ConfigFileProviderPlugin-MavenServerCredentials%28since2.7%29 Technically the current solution in Jenkins is done by rewriting the settings.xml and and passing it with "-s" and "-g" - but if maven would provide a plugable solution, I could implement it in a more elegant way. ...I don't know about Hudson... > Make encrypt/decrypt logic pluggable > > > Key: MNG-5356 > URL: https://jira.codehaus.org/browse/MNG-5356 > Project: Maven 2 & 3 > Issue Type: Improvement > Environment: n/a >Reporter: Anders Hammar >Assignee: Anders Hammar > Fix For: Issues to be reviewed for 4.x > > > It would be good if Maven Core facilitated the encryption (and decryption) > logic to be replaceable. Today's solution is very much hard-coded to the > plexus logic. > This would make it possible for enterprise environments to re-use existing > solutions, like for eg smart cards, for this. The default should be the > current implementation though. -- 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-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[ https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338270#comment-338270 ] Robert Scholte commented on MRELEASE-812: - There's a call for vote for SCM 1.9 at this moment. If the vote succeeds, it'll probably be available this weekend. > "prepare" does not commit before tagging and therefore deploys snapshot > instead of release > -- > > Key: MRELEASE-812 > URL: https://jira.codehaus.org/browse/MRELEASE-812 > Project: Maven Release Plugin > Issue Type: Bug > Components: Git >Affects Versions: 2.4 >Reporter: Andrei Pozolotin >Priority: Critical > Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt > > > thank you very much for new release! > http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E > it seems we need an emergency fix: > attached are 2 logs: > 1) mvn-2.3.2.txt invocation that works fine with 2.3.2 > 2) mvn-2.4.0.txt invocation that fails with 2.4 > problem: > "perform" does not commit tags, deploys snapshot instead of release > here is project parent: > http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom > build is invoked both times with this: > mvn --define resume=false release:prepare > mvn --define resume=false release:perform -- 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] (MASSEMBLY-680) Allow option to silently skip empty assemblies
Jeff Care created MASSEMBLY-680: --- Summary: Allow option to silently skip empty assemblies Key: MASSEMBLY-680 URL: https://jira.codehaus.org/browse/MASSEMBLY-680 Project: Maven Assembly Plugin Issue Type: Improvement Components: maven-archiver Affects Versions: 2.4 Reporter: Jeff Care Priority: Minor I have a use case where many of my projects need to construct an "installation fragment" as a secondary artifact. I would like to define the assembly configuration for this installation fragment on a parent project such that it is automatically inherited by all of my projects. Certain projects though do not have any content that would get picked up by the assembly descriptor, thus assembly:single fails for these projects. I would like to add an option to the single mojo such that empty assemblies can be silently skipped instead of failing the build. I have started researching how to accomplish this & would be willing to submit patches. -- 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] (MENFORCER-169) No Unit Test for RequireActiveProfile Rule and no documentation
[ https://jira.codehaus.org/browse/MENFORCER-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reassigned MENFORCER-169: - Assignee: Karl Heinz Marbaise > No Unit Test for RequireActiveProfile Rule and no documentation > --- > > Key: MENFORCER-169 > URL: https://jira.codehaus.org/browse/MENFORCER-169 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Documentation, Standard Rules >Affects Versions: 1.3.1 > Environment: all >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Attachments: index.apt.diff, requireActiveProfile.apt.vm, > RequireActiveProfileTest.java > > > After diving into the code i found that there is no unit test for the > RequireActiveProfile rule which i have attached to this issue. > Apart from that the unit tests proves that the all option does not work as > expected. > If i change the code based on suggested change of MENFORCER-143 i got a green > bar. -- 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] (MENFORCER-169) No Unit Test for RequireActiveProfile Rule and no documentation
[ https://jira.codehaus.org/browse/MENFORCER-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MENFORCER-169. - Resolution: Fixed Fix Version/s: 2.0 Fixed in r155. > No Unit Test for RequireActiveProfile Rule and no documentation > --- > > Key: MENFORCER-169 > URL: https://jira.codehaus.org/browse/MENFORCER-169 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Documentation, Standard Rules >Affects Versions: 1.3.1 > Environment: all >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 2.0 > > Attachments: index.apt.diff, requireActiveProfile.apt.vm, > RequireActiveProfileTest.java > > > After diving into the code i found that there is no unit test for the > RequireActiveProfile rule which i have attached to this issue. > Apart from that the unit tests proves that the all option does not work as > expected. > If i change the code based on suggested change of MENFORCER-143 i got a green > bar. -- 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-5230) Command line option to exclude modules from reactor
[
https://jira.codehaus.org/browse/MNG-5230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-5230.
---
Resolution: Fixed
Fix Version/s: 3.2
Fixed in http://git-wip-us.apache.org/repos/asf/maven/commit/91499839
IT in
http://git-wip-us.apache.org/repos/asf/maven-integration-testing/commit/71cd6c8d
[~tadukurow], your patches were very helpful! I've synced the include/exclude
char with profiles, so you can use the '+' and '' for includes, '!' and '-' for
excludes.
However, I hit a bug in the commons-cli parser when using the '-', so I renamed
the modules of the ITs.
> Command line option to exclude modules from reactor
> ---
>
> Key: MNG-5230
> URL: https://jira.codehaus.org/browse/MNG-5230
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 3.0.3
>Reporter: Falko Modler
>Assignee: Robert Scholte
> Fix For: 3.2
>
> Attachments: MNG-5230-maven-core.patch,
> MNG-5230-maven-integration-testing.patch
>
>
> Every now and then I want to exclude one or more modules from a rather large
> reactor build.
> One reason for this can be: The respective module has tests that take long
> time to execute and I know that I don't need to execute them.
> Introducing yet another profile for this is not desirable for various reasons.
> So, something like an opposite to -pl would come in handy. Let's say "-el"
> for "exclude list".
> Example:
> {code}
> root
> + module a
> + module a1
> + module a2
> + module b
> + module b1
> + module c
> {code}
> Calling _mvn -el a1,c_ would build all modules execpt a1 and c.
--
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] (MENFORCER-143) 'All' propery is not handled by RequireActiveProfile rule
[
https://jira.codehaus.org/browse/MENFORCER-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MENFORCER-143.
-
Resolution: Fixed
Fix Version/s: 2.0
Fixed in r1556667.
Using the second code example of Marciej Kwiecien.
> 'All' propery is not handled by RequireActiveProfile rule
> -
>
> Key: MENFORCER-143
> URL: https://jira.codehaus.org/browse/MENFORCER-143
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 1.1.1
>Reporter: Maciej Kwiecien
>Assignee: Karl Heinz Marbaise
> Fix For: 2.0
>
> Attachments: HandlingAllPropertyInRequireActiveProfileRule.patch,
> HandlingAllPropertyInRequireActiveProfileRuleSimplified.patch
>
>
> Although you have rules configured, as follows:
> {code}
> ...
>
>
>
> dev,selenium
> false
>
>
> true
>
> {code}
> And you run build : mvn clean install *-Pselenium*
> You still get error:
> {code}
> Supported profiles: selenium,dev
> Profile "dev" is not activated.
> {code}
> Fix is quite simple (tested on tag 1.1.1 and trunk) - please find in
> attachment.
> Best Regards,
> Maciej
--
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] (MENFORCER-143) 'All' propery is not handled by RequireActiveProfile rule
[
https://jira.codehaus.org/browse/MENFORCER-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reassigned MENFORCER-143:
-
Assignee: Karl Heinz Marbaise
> 'All' propery is not handled by RequireActiveProfile rule
> -
>
> Key: MENFORCER-143
> URL: https://jira.codehaus.org/browse/MENFORCER-143
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 1.1.1
>Reporter: Maciej Kwiecien
>Assignee: Karl Heinz Marbaise
> Attachments: HandlingAllPropertyInRequireActiveProfileRule.patch,
> HandlingAllPropertyInRequireActiveProfileRuleSimplified.patch
>
>
> Although you have rules configured, as follows:
> {code}
> ...
>
>
>
> dev,selenium
> false
>
>
> true
>
> {code}
> And you run build : mvn clean install *-Pselenium*
> You still get error:
> {code}
> Supported profiles: selenium,dev
> Profile "dev" is not activated.
> {code}
> Fix is quite simple (tested on tag 1.1.1 and trunk) - please find in
> attachment.
> Best Regards,
> Maciej
--
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] (MENFORCER-170) Refactored Unit Test Code
[ https://jira.codehaus.org/browse/MENFORCER-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MENFORCER-170. - Resolution: Fixed Fixed in r1556678. > Refactored Unit Test Code > - > > Key: MENFORCER-170 > URL: https://jira.codehaus.org/browse/MENFORCER-170 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Rule API >Affects Versions: 1.3.1 > Environment: all >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Trivial > Fix For: 2.0 > > Attachments: x.diff > > > I have refactored the code of the unit test a little bit. Patch attached > (against r1554171 from trunk). -- 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] (MENFORCER-167) Documented '*' feature of banned dependencies doesn't work
[
https://jira.codehaus.org/browse/MENFORCER-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reassigned MENFORCER-167:
-
Assignee: Karl Heinz Marbaise
> Documented '*' feature of banned dependencies doesn't work
> --
>
> Key: MENFORCER-167
> URL: https://jira.codehaus.org/browse/MENFORCER-167
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Documentation, Standard Rules
>Affects Versions: 1.3.1
>Reporter: Will May
>Assignee: Karl Heinz Marbaise
> Attachments: regex-banned-dependencies.patch
>
>
> The documentation states that it is possible to ban dependencies with the
> pattern
> {code}
> org.apache.*:maven-*:*
> {code}
> The attached test case shows that this isn't the case.
--
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-5230) Command line option to exclude modules from reactor
[
https://jira.codehaus.org/browse/MNG-5230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338283#comment-338283
]
Luuk van den Broek commented on MNG-5230:
--
[~rfscholte] Thanks for the fixes and the merge.
> Command line option to exclude modules from reactor
> ---
>
> Key: MNG-5230
> URL: https://jira.codehaus.org/browse/MNG-5230
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 3.0.3
>Reporter: Falko Modler
>Assignee: Robert Scholte
> Fix For: 3.2
>
> Attachments: MNG-5230-maven-core.patch,
> MNG-5230-maven-integration-testing.patch
>
>
> Every now and then I want to exclude one or more modules from a rather large
> reactor build.
> One reason for this can be: The respective module has tests that take long
> time to execute and I know that I don't need to execute them.
> Introducing yet another profile for this is not desirable for various reasons.
> So, something like an opposite to -pl would come in handy. Let's say "-el"
> for "exclude list".
> Example:
> {code}
> root
> + module a
> + module a1
> + module a2
> + module b
> + module b1
> + module c
> {code}
> Calling _mvn -el a1,c_ would build all modules execpt a1 and c.
--
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
