[jira] (MENFORCER-195) Dependency convergence does not support wildcard exclusions
[ https://jira.codehaus.org/browse/MENFORCER-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347929#comment-347929 ] Paul Gier commented on MENFORCER-195: - To give some more background on this, the dependency convergence rule used the shared maven dependency tree component. This component has a Maven 2 API/impl (DependencyTreeBuilder) and a second API (DependencyGraphBuilder) which works with Maven 2 and 3. The dependency convergence rule currently relies on the older Maven 2 API to provide a full dependency tree which it checks for transitive dependency conflicts. Unfortunately, the Maven 3 compatible API does not provide a full dependency tree so it's impossible to find dependency convergence conflicts. To resolve this issue the Maven 3 compatible API needs to provide an option for accessing the full dependency tree (MSHARED-339). > Dependency convergence does not support wildcard exclusions > --- > > Key: MENFORCER-195 > URL: https://jira.codehaus.org/browse/MENFORCER-195 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Plugin >Affects Versions: 1.3.1 > Environment: Maven 3.2.1 >Reporter: Tomaz Cerar > > Maven 3.2 introduced wildcard exclusions for dependencies. > But if you use them dependencyConvergence wrongly complains about conflicting > transitive dependencies. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-339) DependencyGraphBuilder does not provide verbose tree
Paul Gier created MSHARED-339: - Summary: DependencyGraphBuilder does not provide verbose tree Key: MSHARED-339 URL: https://jira.codehaus.org/browse/MSHARED-339 Project: Maven Shared Components Issue Type: Improvement Components: maven-dependency-tree Affects Versions: maven-dependency-tree-2.1 Reporter: Paul Gier The dependency graph builder provides a dependency tree which has already filtered out duplicate dependencies. In some cases such as testing dependency convergence or viewing the verbose dependency tree, it's useful to get information about the full tree including duplicates. The dependency graph builder should provide an option for including the unfiltered dependency tree. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-195) Dependency convergence does not support wildcard exclusions
[ https://jira.codehaus.org/browse/MENFORCER-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MENFORCER-195: Description: Maven 3.2 introduced wildcard exclusions for dependencies. But if you use them dependencyConvergence wrongly complains about conflicting transitive dependencies. was: Maven 3.2 introduced wildcard exclusions for dependencies. But if you use them ban-bad-dependencies wrongly complains that transitive dependencies are still present. Summary: Dependency convergence does not support wildcard exclusions (was: Ban bad depedencies does not support wildcard exclusions) > Dependency convergence does not support wildcard exclusions > --- > > Key: MENFORCER-195 > URL: https://jira.codehaus.org/browse/MENFORCER-195 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Plugin >Affects Versions: 1.3.1 > Environment: Maven 3.2.1 >Reporter: Tomaz Cerar > > Maven 3.2 introduced wildcard exclusions for dependencies. > But if you use them dependencyConvergence wrongly complains about conflicting > transitive dependencies. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-195) Ban bad depedencies does not support wildcard exclusions
[ https://jira.codehaus.org/browse/MENFORCER-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347794#comment-347794 ] Paul Gier commented on MENFORCER-195: - Ok, the problem is in the dependencyConvergence rule, I was looking at the banTransitiveDependencies rule. I can reproduce it now. > Ban bad depedencies does not support wildcard exclusions > > > Key: MENFORCER-195 > URL: https://jira.codehaus.org/browse/MENFORCER-195 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Plugin >Affects Versions: 1.3.1 > Environment: Maven 3.2.1 >Reporter: Tomaz Cerar > > Maven 3.2 introduced wildcard exclusions for dependencies. > But if you use them ban-bad-dependencies wrongly complains that transitive > dependencies are still present. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-195) Ban bad depedencies does not support wildcard exclusions
[
https://jira.codehaus.org/browse/MENFORCER-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347747#comment-347747
]
Paul Gier commented on MENFORCER-195:
-
I wasn't able to reproduce a build failure. I experimented with enforcer 1.3,
1.3.1, and the latest 2.0-SNAPSHOT. Using Maven 3.1 and lower I saw the
following warnings:
{noformat}
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
org.apache.maven.its.enforcer:ban-transitive-test:jar:1.0
[WARNING] 'dependencies.dependency.exclusions.exclusion.groupId' for
org.apache.myfaces.core:myfaces-impl:jar with value '*' does not match a valid
id pattern. @ line 51, column 20
[WARNING] 'dependencies.dependency.exclusions.exclusion.artifactId' for
org.apache.myfaces.core:myfaces-impl:jar with value '*' does not match a valid
id pattern. @ line 52, column 23
[WARNING]
{noformat}
But the dependencies appeared to be excluded, and the build was successful.
Using Maven 3.2.1, there were no warnings, and the dependencies were excluded
as expected.
> Ban bad depedencies does not support wildcard exclusions
>
>
> Key: MENFORCER-195
> URL: https://jira.codehaus.org/browse/MENFORCER-195
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 1.3.1
> Environment: Maven 3.2.1
>Reporter: Tomaz Cerar
>
> Maven 3.2 introduced wildcard exclusions for dependencies.
> But if you use them ban-bad-dependencies wrongly complains that transitive
> dependencies are still present.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-405) purge-local-repository on multi-module project results in failure
[
https://jira.codehaus.org/browse/MDEP-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325014#comment-325014
]
Paul Gier commented on MDEP-405:
I think the reason this happens is because in order to determine the full set
of transitive dependencies to delete, the poms need to be available. If the
poms were already resolved in the previous module, Maven won't re-resolve them
again and just fails. So the dependency doesn't have a problem with the file
already being deleted from the local repo, but the maven dependency resolution
code fails when trying to resolve the same file twice in the same build.
You might try the build with Maven 3.0.3 because there was a change in this in
Maven 3.0.4:
http://mail-archives.apache.org/mod_mbox/maven-dev/201210.mbox/%3C5752023.Vp0WJBo1vZ%40bigmax%3E
> purge-local-repository on multi-module project results in failure
> -
>
> Key: MDEP-405
> URL: https://jira.codehaus.org/browse/MDEP-405
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: purge-local-repository
>Affects Versions: 2.6
>Reporter: Stephen Cooper
>
> I have several multi-module projects all suffering from this issue.
> As a post-build step in jenkins, we want to clean up the repository to keep
> disk space usage to a minimum.
> We execute the following:
> {code}
> mvn -f pom.xml -DsnapshotsOnly=false -DreResolve=false -Dverbose=true -e
> -Dmaven.repo.local=/var/lib/jenkins/maven-repositories/12
> dependency:purge-local-repository
> {code}
> We have reresolve set to false so that the files don't get downloaded again.
> This works fine for the first modules, but once we hit a module which has the
> same dependencies as a previous module, we get an error that we cannot
> resolve dependencies and the build fails.
> {code}
> [INFO] Building ften-rewind-1.0.2-SNAPSHOT 1.0.2-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-dependency-plugin:2.6:purge-local-repository (default-cli) @
> ften-rewind ---
> [INFO] Unable to resolve all dependencies for :
> com.ften.stream:ften-rewind:1.0.2-SNAPSHOT. Falling back to non-transitive
> mode for initial artifact resolution.
> [INFO] Purging dependencies for project:
> com.ften.stream:ften-rewind:jar:1.0.2-SNAPSHOT
> [INFO] Purging artifact: com.googlecode.jmockit:jmockit:jar:1.1
> [INFO] Deleting:
> /var/lib/jenkins/maven-repositories/12/com/googlecode/jmockit/jmockit/1.1
> [WARNING] Unable to purge local repository location:
> /var/lib/jenkins/maven-repositories/12/com/googlecode/jmockit/jmockit/1.1
> [INFO] Purging artifact: junit:junit:jar:4.11
> [INFO] Deleting: /var/lib/jenkins/maven-repositories/12/junit/junit/4.11
> [WARNING] Unable to purge local repository location:
> /var/lib/jenkins/maven-repositories/12/junit/junit/4.11
> [INFO] Purging artifact: genium.common:risk-ring-framework:jar:1.0.2
> [INFO] Deleting:
> /var/lib/jenkins/maven-repositories/12/genium/common/risk-ring-framework/1.0.2
> [WARNING] Unable to purge local repository location:
> /var/lib/jenkins/maven-repositories/12/genium/common/risk-ring-framework/1.0.2
> [INFO] Purging artifact: genium.common:imb:jar:2.0.48
> [INFO] Deleting:
> /var/lib/jenkins/maven-repositories/12/genium/common/imb/2.0.48
> [WARNING] Unable to purge local repository location:
> /var/lib/jenkins/maven-repositories/12/genium/common/imb/2.0.48
> [INFO] Purging artifact: genium.common:framework-base:jar:1.2.5
> [INFO] Deleting:
> /var/lib/jenkins/maven-repositories/12/genium/common/framework-base/1.2.5
> [WARNING] Unable to purge local repository location:
> /var/lib/jenkins/maven-repositories/12/genium/common/framework-base/1.2.5
> [INFO] Purging artifact: amt:amt:jar:3.15.2
> [INFO] Deleting: /var/lib/jenkins/maven-repositories/12/amt/amt/3.15.2
> [WARNING] Unable to purge local repository location:
> /var/lib/jenkins/maven-repositories/12/amt/amt/3.15.2
> [INFO]
>
> [INFO]
>
> [INFO] Building ften-appmind-base 1.0.2-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-dependency-plugin:2.6:purge-local-repository (default-cli) @
> ften-appmind-base ---
> Downloading:
> http://nexus.carteret.ften.com//content/groups/public/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
> Downloaded:
> http://nexus.carteret.ften.com//content/groups/public/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
> (38 KB at 1687.5 KB/sec)
> [INFO]
>
> [INFO] Reactor Summary:
>
[jira] (MDEP-415) Add option to include parent poms in dependency:resolve output
[ https://jira.codehaus.org/browse/MDEP-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MDEP-415. -- Resolution: Fixed Fixed in [r1482080|http://svn.apache.org/viewvc?view=revision&revision=1482080] > Add option to include parent poms in dependency:resolve output > -- > > Key: MDEP-415 > URL: https://jira.codehaus.org/browse/MDEP-415 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: resolve >Reporter: Paul Gier >Assignee: Paul Gier >Priority: Minor > Fix For: 2.9 > > > It would be helpful to have an option to see the parent poms resolved by a > build. -- 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] (MDEP-415) Add option to include parent poms in dependency:resolve output
Paul Gier created MDEP-415: -- Summary: Add option to include parent poms in dependency:resolve output Key: MDEP-415 URL: https://jira.codehaus.org/browse/MDEP-415 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: resolve Reporter: Paul Gier Priority: Minor It would be helpful to have an option to see the parent poms resolved by a build. -- 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] (MDEP-415) Add option to include parent poms in dependency:resolve output
[ https://jira.codehaus.org/browse/MDEP-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-415: --- Assignee: Paul Gier > Add option to include parent poms in dependency:resolve output > -- > > Key: MDEP-415 > URL: https://jira.codehaus.org/browse/MDEP-415 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: resolve >Reporter: Paul Gier >Assignee: Paul Gier >Priority: Minor > > It would be helpful to have an option to see the parent poms resolved by a > build. -- 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] (MDEP-415) Add option to include parent poms in dependency:resolve output
[ https://jira.codehaus.org/browse/MDEP-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-415: --- Fix Version/s: 2.9 > Add option to include parent poms in dependency:resolve output > -- > > Key: MDEP-415 > URL: https://jira.codehaus.org/browse/MDEP-415 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: resolve >Reporter: Paul Gier >Assignee: Paul Gier >Priority: Minor > Fix For: 2.9 > > > It would be helpful to have an option to see the parent poms resolved by a > build. -- 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] (MDEP-414) Add option to sort output of dependency:resolve/list
[ https://jira.codehaus.org/browse/MDEP-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MDEP-414. -- Resolution: Fixed Fixed in [r1482068|http://svn.apache.org/viewvc?view=revision&revision=1482068] > Add option to sort output of dependency:resolve/list > > > Key: MDEP-414 > URL: https://jira.codehaus.org/browse/MDEP-414 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: resolve >Reporter: Paul Gier >Assignee: Paul Gier >Priority: Minor > Fix For: 2.9 > > > The use case we have is that we take a project and compare dependency changes > over time. This is done by running "mvn dependency:resolve" against the > project at different commits. In order to show only dependencies which have > been added/removed/upgraded it's necessary to sort the output before > comparing two dependency lists. This would be a bit easier if the output > could be sorted by the plugin. -- 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] (MDEP-414) Add option to sort output of dependency:resolve/list
[ https://jira.codehaus.org/browse/MDEP-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-414: --- Fix Version/s: 2.9 > Add option to sort output of dependency:resolve/list > > > Key: MDEP-414 > URL: https://jira.codehaus.org/browse/MDEP-414 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: resolve >Reporter: Paul Gier >Assignee: Paul Gier >Priority: Minor > Fix For: 2.9 > > > The use case we have is that we take a project and compare dependency changes > over time. This is done by running "mvn dependency:resolve" against the > project at different commits. In order to show only dependencies which have > been added/removed/upgraded it's necessary to sort the output before > comparing two dependency lists. This would be a bit easier if the output > could be sorted by the plugin. -- 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] (MDEP-414) Add option to sort output of dependency:resolve/list
[ https://jira.codehaus.org/browse/MDEP-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-414: --- Fix Version/s: (was: 2.8) > Add option to sort output of dependency:resolve/list > > > Key: MDEP-414 > URL: https://jira.codehaus.org/browse/MDEP-414 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: resolve >Reporter: Paul Gier >Assignee: Paul Gier >Priority: Minor > > The use case we have is that we take a project and compare dependency changes > over time. This is done by running "mvn dependency:resolve" against the > project at different commits. In order to show only dependencies which have > been added/removed/upgraded it's necessary to sort the output before > comparing two dependency lists. This would be a bit easier if the output > could be sorted by the plugin. -- 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] (MDEP-414) Add option to sort output of dependency:resolve/list
[ https://jira.codehaus.org/browse/MDEP-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-414: --- Assignee: Paul Gier > Add option to sort output of dependency:resolve/list > > > Key: MDEP-414 > URL: https://jira.codehaus.org/browse/MDEP-414 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: resolve >Reporter: Paul Gier >Assignee: Paul Gier >Priority: Minor > Fix For: 2.8 > > > The use case we have is that we take a project and compare dependency changes > over time. This is done by running "mvn dependency:resolve" against the > project at different commits. In order to show only dependencies which have > been added/removed/upgraded it's necessary to sort the output before > comparing two dependency lists. This would be a bit easier if the output > could be sorted by the plugin. -- 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] (MDEP-414) Add option to sort output of dependency:resolve/list
[ https://jira.codehaus.org/browse/MDEP-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-414: --- Fix Version/s: 2.8 > Add option to sort output of dependency:resolve/list > > > Key: MDEP-414 > URL: https://jira.codehaus.org/browse/MDEP-414 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: resolve >Reporter: Paul Gier >Priority: Minor > Fix For: 2.8 > > > The use case we have is that we take a project and compare dependency changes > over time. This is done by running "mvn dependency:resolve" against the > project at different commits. In order to show only dependencies which have > been added/removed/upgraded it's necessary to sort the output before > comparing two dependency lists. This would be a bit easier if the output > could be sorted by the plugin. -- 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] (MDEP-414) Add option to sort output of dependency:resolve/list
Paul Gier created MDEP-414: -- Summary: Add option to sort output of dependency:resolve/list Key: MDEP-414 URL: https://jira.codehaus.org/browse/MDEP-414 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: resolve Reporter: Paul Gier Priority: Minor The use case we have is that we take a project and compare dependency changes over time. This is done by running "mvn dependency:resolve" against the project at different commits. In order to show only dependencies which have been added/removed/upgraded it's necessary to sort the output before comparing two dependency lists. This would be a bit easier if the output could be sorted by the plugin. -- 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] (MDEP-295) Add ability to strip classifier
[ https://jira.codehaus.org/browse/MDEP-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-295: --- Assignee: (was: Paul Gier) > Add ability to strip classifier > --- > > Key: MDEP-295 > URL: https://jira.codehaus.org/browse/MDEP-295 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: copy-dependencies >Reporter: Jason Smith > Attachments: > 0002-stripClassifier-option-added-to-the-copy-dependency-.patch, > episode3.patch, good.patch > > > In addition to the ability to specify that the version be stripped from the > artifact it would be helpful to be able to specify that the classifier be > stripped also. -- 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] (MDEPLOY-99) deploy:deploy-file overwrites maven-metadata.xml
[
https://jira.codehaus.org/browse/MDEPLOY-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MDEPLOY-99:
-
Summary: deploy:deploy-file overwrites maven-metadata.xml (was:
deploy:deploy-file over rights maven-metadata.xml)
> deploy:deploy-file overwrites maven-metadata.xml
>
>
> Key: MDEPLOY-99
> URL: https://jira.codehaus.org/browse/MDEPLOY-99
> Project: Maven 2.x and 3.x Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy-file
>Affects Versions: 2.4
> Environment: Windows XP
> Maven 2.1.0
>Reporter: Jim McCaskey
> Labels: scrub-review-started
>
> Using {{deploy:deploy-file}} to add multiple version of an artifact causes
> the artifactId {{maven-metadata.xml}} file to be recreated new and the old
> contents to be removed. Once done I am left with contents like this:
> {code:xml}
>
> com.pervasive.component
> artifact-distribution
> 4.0.2.11
>
>
> 4.0.2.11
>
> 20090401013925
>
>
> {code}
> This is using Maven 2.1.0 and maven-deploy-plugin 2.4.
--
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] (MENFORCER-139) Regex rule example is incorrect; matching is not described
[
https://jira.codehaus.org/browse/MENFORCER-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MENFORCER-139.
---
Resolution: Fixed
Thanks for catching that. Grammar is fixed in
[r1413200|http://svn.apache.org/viewvc?view=revision&revision=1413200]
> Regex rule example is incorrect; matching is not described
> --
>
> Key: MENFORCER-139
> URL: https://jira.codehaus.org/browse/MENFORCER-139
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
> Environment:
> http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
>Reporter: SebbASF
>Assignee: Paul Gier
>Priority: Minor
> Fix For: 1.2
>
>
> The documentation page [1] has an example rule containing:
> {noformat}
> \d
> You must have a digit in your baseDir!
> {noformat}
> This is very misleading, as \d only matches a single digit.
> The example should be:
> {noformat}
> .*\d.*
> You must have a digit in your baseDir!
> {noformat}
> or possibly:
> {noformat}
> \d
> Your baseDir must consist of a single digit only!
> {noformat}
> The documentation should state that the regex is applied to the entire value
> of the property.
> That is, it uses regex "match" rather than regex "contains", effectively the
> regex string is enclosed in "^" and "$" before use.
> [1] http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
--
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] (MENFORCER-139) Regex rule example is incorrect; matching is not described
[
https://jira.codehaus.org/browse/MENFORCER-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MENFORCER-139.
---
Resolution: Fixed
Fixed in [r1412920|http://svn.apache.org/viewvc?view=revision&revision=1412920].
> Regex rule example is incorrect; matching is not described
> --
>
> Key: MENFORCER-139
> URL: https://jira.codehaus.org/browse/MENFORCER-139
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
> Environment:
> http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
>Reporter: SebbASF
>Assignee: Paul Gier
>Priority: Minor
> Fix For: 1.2
>
>
> The documentation page [1] has an example rule containing:
> {noformat}
> \d
> You must have a digit in your baseDir!
> {noformat}
> This is very misleading, as \d only matches a single digit.
> The example should be:
> {noformat}
> .*\d.*
> You must have a digit in your baseDir!
> {noformat}
> or possibly:
> {noformat}
> \d
> Your baseDir must consist of a single digit only!
> {noformat}
> The documentation should state that the regex is applied to the entire value
> of the property.
> That is, it uses regex "match" rather than regex "contains", effectively the
> regex string is enclosed in "^" and "$" before use.
> [1] http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
--
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] (MENFORCER-139) Regex rule example is incorrect; matching is not described
[
https://jira.codehaus.org/browse/MENFORCER-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MENFORCER-139:
Fix Version/s: 1.2
Assignee: Paul Gier
> Regex rule example is incorrect; matching is not described
> --
>
> Key: MENFORCER-139
> URL: https://jira.codehaus.org/browse/MENFORCER-139
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
> Environment:
> http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
>Reporter: SebbASF
>Assignee: Paul Gier
> Fix For: 1.2
>
>
> The documentation page [1] has an example rule containing:
> {noformat}
> \d
> You must have a digit in your baseDir!
> {noformat}
> This is very misleading, as \d only matches a single digit.
> The example should be:
> {noformat}
> .*\d.*
> You must have a digit in your baseDir!
> {noformat}
> or possibly:
> {noformat}
> \d
> Your baseDir must consist of a single digit only!
> {noformat}
> The documentation should state that the regex is applied to the entire value
> of the property.
> That is, it uses regex "match" rather than regex "contains", effectively the
> regex string is enclosed in "^" and "$" before use.
> [1] http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
--
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] (MENFORCER-139) Regex rule example is incorrect; matching is not described
[
https://jira.codehaus.org/browse/MENFORCER-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MENFORCER-139:
Priority: Minor (was: Major)
> Regex rule example is incorrect; matching is not described
> --
>
> Key: MENFORCER-139
> URL: https://jira.codehaus.org/browse/MENFORCER-139
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
> Environment:
> http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
>Reporter: SebbASF
>Assignee: Paul Gier
>Priority: Minor
> Fix For: 1.2
>
>
> The documentation page [1] has an example rule containing:
> {noformat}
> \d
> You must have a digit in your baseDir!
> {noformat}
> This is very misleading, as \d only matches a single digit.
> The example should be:
> {noformat}
> .*\d.*
> You must have a digit in your baseDir!
> {noformat}
> or possibly:
> {noformat}
> \d
> Your baseDir must consist of a single digit only!
> {noformat}
> The documentation should state that the regex is applied to the entire value
> of the property.
> That is, it uses regex "match" rather than regex "contains", effectively the
> regex string is enclosed in "^" and "$" before use.
> [1] http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
--
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] (MENFORCER-137) DependencyConvergence should log only as WARNING instead of ERROR.
[
https://jira.codehaus.org/browse/MENFORCER-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MENFORCER-137.
---
Resolution: Fixed
Fixed in [r1412915|http://svn.apache.org/viewvc?view=revision&revision=1412915]
> DependencyConvergence should log only as WARNING instead of ERROR.
> --
>
> Key: MENFORCER-137
> URL: https://jira.codehaus.org/browse/MENFORCER-137
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
>Affects Versions: 1.1.1
>Reporter: Mirko Friedenhagen
>Assignee: Paul Gier
>Priority: Minor
> Fix For: 1.2
>
>
> I find it disturbing that all other rules only log in level WARNING or even
> INFO, only DependencyConvergence uses ERROR. When looking in e.g. Jenkins for
> "real" errors I always stumble upon these messages. I therefore suggest
> turning the log-level down to WARNING. I ran {{mvn clean install -Prun-its}}
> successfully with my patched version.
> {code}
> # This patch file was generated by NetBeans IDE
> # It uses platform neutral UTF-8 encoding and \n newlines.
> --- HEAD
> +++ Modified In Working Tree
> @@ -123,7 +123,7 @@
> errorMsgs.addAll( getConvergenceErrorMsgs(
> visitor.getConflictedVersionNumbers() ) );
> for ( CharSequence errorMsg : errorMsgs )
> {
> -log.error( errorMsg );
> \ No newline at end of file
> +log.warn( errorMsg );
> \ No newline at end of file
> }
> if ( errorMsgs.size() > 0 )
> {
> {code}
--
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] (MENFORCER-137) DependencyConvergence should log only as WARNING instead of ERROR.
[
https://jira.codehaus.org/browse/MENFORCER-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MENFORCER-137:
Fix Version/s: 1.2
Assignee: Paul Gier
> DependencyConvergence should log only as WARNING instead of ERROR.
> --
>
> Key: MENFORCER-137
> URL: https://jira.codehaus.org/browse/MENFORCER-137
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
>Affects Versions: 1.1.1
>Reporter: Mirko Friedenhagen
>Assignee: Paul Gier
>Priority: Minor
> Fix For: 1.2
>
>
> I find it disturbing that all other rules only log in level WARNING or even
> INFO, only DependencyConvergence uses ERROR. When looking in e.g. Jenkins for
> "real" errors I always stumble upon these messages. I therefore suggest
> turning the log-level down to WARNING. I ran {{mvn clean install -Prun-its}}
> successfully with my patched version.
> {code}
> # This patch file was generated by NetBeans IDE
> # It uses platform neutral UTF-8 encoding and \n newlines.
> --- HEAD
> +++ Modified In Working Tree
> @@ -123,7 +123,7 @@
> errorMsgs.addAll( getConvergenceErrorMsgs(
> visitor.getConflictedVersionNumbers() ) );
> for ( CharSequence errorMsg : errorMsgs )
> {
> -log.error( errorMsg );
> \ No newline at end of file
> +log.warn( errorMsg );
> \ No newline at end of file
> }
> if ( errorMsgs.size() > 0 )
> {
> {code}
--
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] (MENFORCER-97) Standard rule to check that no dependencies have system scope
[ https://jira.codehaus.org/browse/MENFORCER-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MENFORCER-97. -- Resolution: Fixed Fix Version/s: 1.2 Fixed by MENFORCER-72 > Standard rule to check that no dependencies have system scope > - > > Key: MENFORCER-97 > URL: https://jira.codehaus.org/browse/MENFORCER-97 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules > Environment: n/a >Reporter: Anders Hammar > Fix For: 1.2 > > > As it is bad practice to use the system scope, it would be great to have a > rule that checks that no dependencies are defined with system scope. -- 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-5366) [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4
[ https://jira.codehaus.org/browse/MNG-5366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MNG-5366: --- Fix Version/s: 3.1 > [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4 > -- > > Key: MNG-5366 > URL: https://jira.codehaus.org/browse/MNG-5366 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.4 >Reporter: Paul Gier > Fix For: 3.1 > > > Using Maven 3.0.4, artifacts can only be resolved a single time during the > build lifecycle using the Maven 2.x dependency resolution API. Using > resolver.resolveAlways() should force re-resolution of the artifact, however > if the artifact was already resolved once during the build, then it will not > be re-resolved even when calling resolveAlways(). > This works as expected in Maven 3.0.0-3.0.3, and the artifact is re-resolved. -- 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-5366) [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4
Paul Gier created MNG-5366: -- Summary: [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4 Key: MNG-5366 URL: https://jira.codehaus.org/browse/MNG-5366 Project: Maven 2 & 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0.4 Reporter: Paul Gier Using Maven 3.0.4, artifacts can only be resolved a single time during the build lifecycle using the Maven 2.x dependency resolution API. Using resolver.resolveAlways() should force re-resolution of the artifact, however if the artifact was already resolved once during the build, then it will not be re-resolved even when calling resolveAlways(). This works as expected in Maven 3.0.0-3.0.3, and the artifact is re-resolved. -- 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-386) Split purge-local-repository into manual and transitive
[ https://jira.codehaus.org/browse/MDEP-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MDEP-386. -- Resolution: Won't Fix Splitting the two features into separate goals didn't resolve the issue related to re-resolving dependencies in Maven 3.0.4. So the goals were merged back into a single mojo along with some additional refactoring in [r1401967|http://svn.apache.org/viewvc?view=revision&revision=1401976]. > Split purge-local-repository into manual and transitive > --- > > Key: MDEP-386 > URL: https://jira.codehaus.org/browse/MDEP-386 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: purge-local-repository >Reporter: Paul Gier >Assignee: Paul Gier > Fix For: 2.6 > > > There doesn't seem to be a good way to resolve/purge/re-resolve from the > local repository in a reliable way that works with both Maven 2 and 3. So to > simplify the code for this goal, it could be split into a manual mode goal > which doesn't required dependency resolution, and a transitive mode which > uses the plugin configuration for the initial dependency resolution. > The manual mode simply deletes a set of directories from the local repository. > The automated mode first resolves to the project dependencies to get the full > information about them, then purges a filtered list from the local > repository, then optionally re-resolves any dependencies that were purged. -- 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-386) Split purge-local-repository into manual and transitive
[ https://jira.codehaus.org/browse/MDEP-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier reopened MDEP-386: > Split purge-local-repository into manual and transitive > --- > > Key: MDEP-386 > URL: https://jira.codehaus.org/browse/MDEP-386 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: purge-local-repository >Reporter: Paul Gier >Assignee: Paul Gier > Fix For: 2.6 > > > There doesn't seem to be a good way to resolve/purge/re-resolve from the > local repository in a reliable way that works with both Maven 2 and 3. So to > simplify the code for this goal, it could be split into a manual mode goal > which doesn't required dependency resolution, and a transitive mode which > uses the plugin configuration for the initial dependency resolution. > The manual mode simply deletes a set of directories from the local repository. > The automated mode first resolves to the project dependencies to get the full > information about them, then purges a filtered list from the local > repository, then optionally re-resolves any dependencies that were purged. -- 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-386) Split purge-local-repository into manual and transitive
[ https://jira.codehaus.org/browse/MDEP-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MDEP-386. -- Resolution: Fixed Fixed in [r1400930|http://svn.apache.org/viewvc?view=revision&revision=1400930] > Split purge-local-repository into manual and transitive > --- > > Key: MDEP-386 > URL: https://jira.codehaus.org/browse/MDEP-386 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: purge-local-repository >Reporter: Paul Gier >Assignee: Paul Gier > Fix For: 2.6 > > > There doesn't seem to be a good way to resolve/purge/re-resolve from the > local repository in a reliable way that works with both Maven 2 and 3. So to > simplify the code for this goal, it could be split into a manual mode goal > which doesn't required dependency resolution, and a transitive mode which > uses the plugin configuration for the initial dependency resolution. > The manual mode simply deletes a set of directories from the local repository. > The automated mode first resolves to the project dependencies to get the full > information about them, then purges a filtered list from the local > repository, then optionally re-resolves any dependencies that were purged. -- 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-386) Split purge-local-repository into manual and transitive
Paul Gier created MDEP-386: -- Summary: Split purge-local-repository into manual and transitive Key: MDEP-386 URL: https://jira.codehaus.org/browse/MDEP-386 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: purge-local-repository Reporter: Paul Gier There doesn't seem to be a good way to resolve/purge/re-resolve from the local repository in a reliable way that works with both Maven 2 and 3. So to simplify the code for this goal, it could be split into a manual mode goal which doesn't required dependency resolution, and a transitive mode which uses the plugin configuration for the initial dependency resolution. The manual mode simply deletes a set of directories from the local repository. The automated mode first resolves to the project dependencies to get the full information about them, then purges a filtered list from the local repository, then optionally re-resolves any dependencies that were purged. -- 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-386) Split purge-local-repository into manual and transitive
[ https://jira.codehaus.org/browse/MDEP-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-386: --- Fix Version/s: 2.6 Assignee: Paul Gier > Split purge-local-repository into manual and transitive > --- > > Key: MDEP-386 > URL: https://jira.codehaus.org/browse/MDEP-386 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: purge-local-repository >Reporter: Paul Gier >Assignee: Paul Gier > Fix For: 2.6 > > > There doesn't seem to be a good way to resolve/purge/re-resolve from the > local repository in a reliable way that works with both Maven 2 and 3. So to > simplify the code for this goal, it could be split into a manual mode goal > which doesn't required dependency resolution, and a transitive mode which > uses the plugin configuration for the initial dependency resolution. > The manual mode simply deletes a set of directories from the local repository. > The automated mode first resolves to the project dependencies to get the full > information about them, then purges a filtered list from the local > repository, then optionally re-resolves any dependencies that were purged. -- 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-272) purge-local-repository does nothing if certain dependencies are included
[
https://jira.codehaus.org/browse/MDEP-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MDEP-272.
--
Resolution: Fixed
More refactoring of the purge-local-repository goal in
[r1400760|http://svn.apache.org/viewvc?view=revision&revision=1400760],
including an IT using a version range. I believe this issues is resolved now.
> purge-local-repository does nothing if certain dependencies are included
>
>
> Key: MDEP-272
> URL: https://jira.codehaus.org/browse/MDEP-272
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: purge-local-repository
>Affects Versions: 2.0
>Reporter: Michele Lorenzini
>Assignee: Paul Gier
> Fix For: 2.6
>
> Attachments: pom.xml, PurgeLocalRepositoryMojo.patch,
> PurgeLocalRepositoryMojo.patch
>
>
> I've noticed that the {{purge-local-repository}} goal does nothing if certain
> dependencies are present in the dependency tree of the project.
> After some attempts I've found some of the dependencies that can show problem.
> See attached {{pom.xml}}: if I run {{mvn validate}} as is, maven purges the
> local repository and the log4j jar is downloaded from the remote repository.
> Removing the comment around the jasperreports dependency and re-running {{mvn
> validate}} gives the following result:
> {code}
> [INFO] [dependency:purge-local-repository {execution: default}]
> [INFO] Nothing to do for project: test-issue:test-issue:pom:1.0.0.0-SNAPSHOT
> {code}
> So it seems that something goes wrong while resolving the dependencies for
> the project if the jasperreports jar is included, resulting in the
> {{purge-local-repository}} to skip the clean of the local repository.
> I dont know if this happens only with jasperreports dependency or if it is
> something more general.
--
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-290) purge-local-repository fails when the dependency was never download yet and copying is declared
[
https://jira.codehaus.org/browse/MDEP-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MDEP-290:
---
Fix Version/s: (was: 2.6)
Assignee: (was: Paul Gier)
> purge-local-repository fails when the dependency was never download yet and
> copying is declared
> ---
>
> Key: MDEP-290
> URL: https://jira.codehaus.org/browse/MDEP-290
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: purge-local-repository
>Affects Versions: 2.1
>Reporter: Dieter König
>
> Using goal "purge-local-repository" together with "copy-dependencies" leads
> to failure of build with "dependency is missing" if one of the declared
> snapshot-dependencies was never downloaded before.
> Example, pom.xml:
> {code:xml}
>
>
> some.groupid
> some.artifactid
> 1.0-SNAPSHOT
>
>
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.1
>
>
> clean-local-repository
> prepare-package
>
> purge-local-repository
>
>
> false
> true
>
>
>
> copy-artifact
> package
>
> copy-dependencies
>
>
>
> some.artifactid
>
>
>
>
>
>
> {code}
> In the local maven repository the folder "some.artifactid" should be missing
> (just delete it manually if you are testing with something which you already
> have there). Now try to build the project with the given pom. It will fail
> with the message that dependency is missing.
> If you comment out the execution of purge-local-repository the build will run
> successfully (maven downloads the declared dependency).
> Otherwise if you comment out the execution of copy-dependencies the build
> will also run successfully.
> But if you have both executions together declared it will fail as long as the
> declared dependency is not in the local repository...
--
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-124) Dependency incorrectly reported as "Unused declared"
[
https://jira.codehaus.org/browse/MDEP-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MDEP-124:
---
Fix Version/s: (was: 2.6)
> Dependency incorrectly reported as "Unused declared"
>
>
> Key: MDEP-124
> URL: https://jira.codehaus.org/browse/MDEP-124
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Reporter: Olivier Dehon
>Assignee: Brian Fox
>
> When a dependency is only required for a constant in a JAR,
> dependency:analyze incorrectly reports the dependency as "Unused declared".
> Example:
> Constants.jar has 1 class called Constants.java:
> {code}
> package com.myco.util;
> public class Constants
> {
> private Constants() {};
> public static final double PI = 3.14159;
> }
> {code}
> Then App jar has App.java as:
> {code}
> package com.myco.app;
> public class App
> {
> public static void main( String[] args )
> {
> System.out.println( com.myco.util.Constants.PI );
> }
> }
> {code}
> Since the constant gets optimized away in the generated {{App.class}}, the
> dependency is not detected, even though the project won't compile without it.
--
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-166) runtime-scoped dependencies should be specially handled
[ https://jira.codehaus.org/browse/MDEP-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-166: --- Fix Version/s: (was: 2.6) Assignee: (was: Brian Fox) > runtime-scoped dependencies should be specially handled > --- > > Key: MDEP-166 > URL: https://jira.codehaus.org/browse/MDEP-166 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 2.0 >Reporter: Max Bowsher > > Currently the plugin warns that runtime-scope dependencies are unused. > It should understand that the correct status for a runtime-scoped dependency > is to *not* be discoverable in the bytecode. -- 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-385) Default fuzziness level should be version instead of file
[ https://jira.codehaus.org/browse/MDEP-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MDEP-385. -- Resolution: Fixed Fixed [r1400467|http://svn.apache.org/viewvc?view=revision&revision=1400467] > Default fuzziness level should be version instead of file > - > > Key: MDEP-385 > URL: https://jira.codehaus.org/browse/MDEP-385 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: purge-local-repository >Reporter: Paul Gier >Assignee: Paul Gier > Fix For: 2.6 > > > The default fuzziness property of the purge-local-repository goal, should be > "version" instead of "file". Deleting only a single file from the local > repository seems risky because if one jar in the remote repository has > changed, it's likely that the pom, and possibly other artifacts have changed > as well. Deleting only a single file from a GAV could leave the local > repository in an unpredictable state which doesn't match the remote > repository. > Changing this property should have no impact on existing builds, because if > the purge works for a single file, it should normally work to purge the whole > version directory instead. -- 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-385) Default fuzziness level should be version instead of file
Paul Gier created MDEP-385: -- Summary: Default fuzziness level should be version instead of file Key: MDEP-385 URL: https://jira.codehaus.org/browse/MDEP-385 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: purge-local-repository Reporter: Paul Gier The default fuzziness property of the purge-local-repository goal, should be "version" instead of "file". Deleting only a single file from the local repository seems risky because if one jar in the remote repository has changed, it's likely that the pom, and possibly other artifacts have changed as well. Deleting only a single file from a GAV could leave the local repository in an unpredictable state which doesn't match the remote repository. Changing this property should have no impact on existing builds, because if the purge works for a single file, it should normally work to purge the whole version directory instead. -- 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-385) Default fuzziness level should be version instead of file
[ https://jira.codehaus.org/browse/MDEP-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-385: --- Fix Version/s: 2.6 Assignee: Paul Gier > Default fuzziness level should be version instead of file > - > > Key: MDEP-385 > URL: https://jira.codehaus.org/browse/MDEP-385 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: purge-local-repository >Reporter: Paul Gier >Assignee: Paul Gier > Fix For: 2.6 > > > The default fuzziness property of the purge-local-repository goal, should be > "version" instead of "file". Deleting only a single file from the local > repository seems risky because if one jar in the remote repository has > changed, it's likely that the pom, and possibly other artifacts have changed > as well. Deleting only a single file from a GAV could leave the local > repository in an unpredictable state which doesn't match the remote > repository. > Changing this property should have no impact on existing builds, because if > the purge works for a single file, it should normally work to purge the whole > version directory instead. -- 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-205) type configuration ignored in sources goal
[ https://jira.codehaus.org/browse/MDEP-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311900#comment-311900 ] Paul Gier edited comment on MDEP-205 at 10/20/12 9:16 AM: -- The sources mojo has been refactored to be a subclass of the resolve mojo with the default classifier "sources". Fixed in [r1400457|http://svn.apache.org/viewvc?view=revision&revision=1400457] was (Author: pgier): Fixed in [r1400457|http://svn.apache.org/viewvc?view=revision&revision=1400457] > type configuration ignored in sources goal > -- > > Key: MDEP-205 > URL: https://jira.codehaus.org/browse/MDEP-205 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: resolve, sources >Affects Versions: 2.1 >Reporter: Dave Syer >Assignee: Paul Gier > Fix For: 2.6 > > > It says here http://jira.codehaus.org/browse/MDEP-11 that "mvn > dependency:resolve -Dclassifer=sources does the same as mvn > dependency:sources". This appears not to be the case since this.type is > hard-coded to "java-source" and "jar" is the correct type for most cases (so > the default is wrong too). > On the other hand, I can't see the sources mojo anywhere in trunk. Was it > removed? -- 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-298) mvn dependency:sources lists parameters 'classifier' and 'type', but manually overrides them
[
https://jira.codehaus.org/browse/MDEP-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MDEP-298.
--
Resolution: Fixed
Fixed by MDEP-205 in
[r1400457|http://svn.apache.org/viewvc?view=revision&revision=1400457].
> mvn dependency:sources lists parameters 'classifier' and 'type', but manually
> overrides them
>
>
> Key: MDEP-298
> URL: https://jira.codehaus.org/browse/MDEP-298
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: sources
>Affects Versions: 2.1
>Reporter: Sean Patrick Floyd
>Assignee: Paul Gier
> Fix For: 2.6
>
>
> The documentation of dependency:sources lists the parameters
> - type
> http://maven.apache.org/plugins/maven-dependency-plugin/sources-mojo.html#type
> - classifier
> http://maven.apache.org/plugins/maven-dependency-plugin/sources-mojo.html#classifier
> This suggests that the mojo could be used to resolve other artifact types as
> well, a functionality that was requested today in this StackOverflow
> question: http://stackoverflow.com/q/4734407/342852
> e.g.
> {code}
> mvn dependency:sources -Dclassifier=javadoc -Dtype=jar
> {code}
> But in the
> org.apache.maven.plugin.dependency.resolvers.ResolveDependencySourcesMojo
> source code, both parameters are manually overwritten with the constant
> values 'java-source' and 'sources', respectively.
> {code}
> this.classifier = SOURCE_CLASSIFIER;
> this.type = SOURCE_TYPE;
> {code}
> This is clearly in violation of the documented behavior. I suggest these
> assignments to be replaced with the following code:
> {code}
> if(StringUtils.isEmpty(this.classifier)){
> this.classifier=SOURCE_CLASSIFIER;
> }
> if(StringUtils.isEmpty(this.type)){
> this.type=SOURCE_TYPE;
> }
> {code}
--
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-205) type configuration ignored in sources goal
[ https://jira.codehaus.org/browse/MDEP-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MDEP-205. -- Resolution: Fixed Fixed in [r1400457|http://svn.apache.org/viewvc?view=revision&revision=1400457] > type configuration ignored in sources goal > -- > > Key: MDEP-205 > URL: https://jira.codehaus.org/browse/MDEP-205 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: resolve, sources >Affects Versions: 2.1 >Reporter: Dave Syer >Assignee: Paul Gier > Fix For: 2.6 > > > It says here http://jira.codehaus.org/browse/MDEP-11 that "mvn > dependency:resolve -Dclassifer=sources does the same as mvn > dependency:sources". This appears not to be the case since this.type is > hard-coded to "java-source" and "jar" is the correct type for most cases (so > the default is wrong too). > On the other hand, I can't see the sources mojo anywhere in trunk. Was it > removed? -- 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-298) mvn dependency:sources lists parameters 'classifier' and 'type', but manually overrides them
[
https://jira.codehaus.org/browse/MDEP-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MDEP-298:
---
Fix Version/s: 2.6
Assignee: Paul Gier (was: Brian Fox)
> mvn dependency:sources lists parameters 'classifier' and 'type', but manually
> overrides them
>
>
> Key: MDEP-298
> URL: https://jira.codehaus.org/browse/MDEP-298
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: sources
>Affects Versions: 2.1
>Reporter: Sean Patrick Floyd
>Assignee: Paul Gier
> Fix For: 2.6
>
>
> The documentation of dependency:sources lists the parameters
> - type
> http://maven.apache.org/plugins/maven-dependency-plugin/sources-mojo.html#type
> - classifier
> http://maven.apache.org/plugins/maven-dependency-plugin/sources-mojo.html#classifier
> This suggests that the mojo could be used to resolve other artifact types as
> well, a functionality that was requested today in this StackOverflow
> question: http://stackoverflow.com/q/4734407/342852
> e.g.
> {code}
> mvn dependency:sources -Dclassifier=javadoc -Dtype=jar
> {code}
> But in the
> org.apache.maven.plugin.dependency.resolvers.ResolveDependencySourcesMojo
> source code, both parameters are manually overwritten with the constant
> values 'java-source' and 'sources', respectively.
> {code}
> this.classifier = SOURCE_CLASSIFIER;
> this.type = SOURCE_TYPE;
> {code}
> This is clearly in violation of the documented behavior. I suggest these
> assignments to be replaced with the following code:
> {code}
> if(StringUtils.isEmpty(this.classifier)){
> this.classifier=SOURCE_CLASSIFIER;
> }
> if(StringUtils.isEmpty(this.type)){
> this.type=SOURCE_TYPE;
> }
> {code}
--
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-298) mvn dependency:sources lists parameters 'classifier' and 'type', but manually overrides them
[
https://jira.codehaus.org/browse/MDEP-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MDEP-298:
---
Component/s: sources
> mvn dependency:sources lists parameters 'classifier' and 'type', but manually
> overrides them
>
>
> Key: MDEP-298
> URL: https://jira.codehaus.org/browse/MDEP-298
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: sources
>Affects Versions: 2.1
>Reporter: Sean Patrick Floyd
>Assignee: Brian Fox
>
> The documentation of dependency:sources lists the parameters
> - type
> http://maven.apache.org/plugins/maven-dependency-plugin/sources-mojo.html#type
> - classifier
> http://maven.apache.org/plugins/maven-dependency-plugin/sources-mojo.html#classifier
> This suggests that the mojo could be used to resolve other artifact types as
> well, a functionality that was requested today in this StackOverflow
> question: http://stackoverflow.com/q/4734407/342852
> e.g.
> {code}
> mvn dependency:sources -Dclassifier=javadoc -Dtype=jar
> {code}
> But in the
> org.apache.maven.plugin.dependency.resolvers.ResolveDependencySourcesMojo
> source code, both parameters are manually overwritten with the constant
> values 'java-source' and 'sources', respectively.
> {code}
> this.classifier = SOURCE_CLASSIFIER;
> this.type = SOURCE_TYPE;
> {code}
> This is clearly in violation of the documented behavior. I suggest these
> assignments to be replaced with the following code:
> {code}
> if(StringUtils.isEmpty(this.classifier)){
> this.classifier=SOURCE_CLASSIFIER;
> }
> if(StringUtils.isEmpty(this.type)){
> this.type=SOURCE_TYPE;
> }
> {code}
--
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-295) Add ability to strip classifier
[ https://jira.codehaus.org/browse/MDEP-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-295: --- Component/s: copy-dependencies Assignee: Paul Gier (was: Brian Fox) Unfortunately, it looks like the patch became out of date with some recent changes to the copy-dependencies mojo. Any possibility you can provide one more update? > Add ability to strip classifier > --- > > Key: MDEP-295 > URL: https://jira.codehaus.org/browse/MDEP-295 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: copy-dependencies >Reporter: Jason Smith >Assignee: Paul Gier > Attachments: > 0002-stripClassifier-option-added-to-the-copy-dependency-.patch, > episode3.patch, good.patch > > > In addition to the ability to specify that the version be stripped from the > artifact it would be helpful to be able to specify that the classifier be > stripped also. -- 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-205) type configuration ignored in sources goal
[ https://jira.codehaus.org/browse/MDEP-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-205: --- Component/s: sources resolve Fix Version/s: 2.6 Assignee: Paul Gier (was: Brian Fox) > type configuration ignored in sources goal > -- > > Key: MDEP-205 > URL: https://jira.codehaus.org/browse/MDEP-205 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: resolve, sources >Affects Versions: 2.1 >Reporter: Dave Syer >Assignee: Paul Gier > Fix For: 2.6 > > > It says here http://jira.codehaus.org/browse/MDEP-11 that "mvn > dependency:resolve -Dclassifer=sources does the same as mvn > dependency:sources". This appears not to be the case since this.type is > hard-coded to "java-source" and "jar" is the correct type for most cases (so > the default is wrong too). > On the other hand, I can't see the sources mojo anywhere in trunk. Was it > removed? -- 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-358) go-offline does not include parent(s)
[ https://jira.codehaus.org/browse/MDEP-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-358: --- Component/s: go-offline > go-offline does not include parent(s) > - > > Key: MDEP-358 > URL: https://jira.codehaus.org/browse/MDEP-358 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: go-offline >Affects Versions: 2.4 > Environment: Maven 3.0.4, Java 6u33, Windows 7 x64 >Reporter: Falko Modler > > I expected go-offline to download the parent (and all transitive parents) of > the module it is executed for, but it doesn't do so. > AFAIK there is no workaround, as the copy goal does not retain the repository > layout (there is no useRepositoryLayout). > copy-dependencies does retain the repository layout (see useRepositoryLayout) > but it does not find the parent(s). -- 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-282) Incorrect result with dependency:analyze for multi-module project
[ https://jira.codehaus.org/browse/MDEP-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-282: --- Component/s: analyze > Incorrect result with dependency:analyze for multi-module project > - > > Key: MDEP-282 > URL: https://jira.codehaus.org/browse/MDEP-282 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 2.1 > Environment: MacOS 10.6.4 > Mac Java 1.6.0 >Reporter: Anders Hammar > Attachments: depanalyze-bug.zip > > > I found this regression in Maven 3.0-beta-2 compared to Maven 2.2.1: > For the attached project, execute > mvn dependency:analyze > in the aggregating project. > This will (incorrectly) report a dependency problem for module2, when > executed with Maven 3.0-beta-2. With Maven 2.2.1, no problems is reported > (which is correct). > If executing the analyze in the module2 project with Maven 3.0-beta-2, no > problem is reported however. -- 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-311) Parameter for "dependency:copy-dependencies" could not provided from command line
[ https://jira.codehaus.org/browse/MDEP-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-311: --- Component/s: copy-dependencies > Parameter for "dependency:copy-dependencies" could not provided from command > line > - > > Key: MDEP-311 > URL: https://jira.codehaus.org/browse/MDEP-311 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy-dependencies >Affects Versions: 2.2 >Reporter: Conny Kreyssel >Assignee: Brian Fox > > I have to try to make a offline repository for our multi project. > But if i call "mvn dependency:copy-dependencies -DoutputDirectory=... > -DcopyPom=true -DuseRepositoryLayout=true" it exports all artifacts in flat > mode without poms. > If i set this plugin params in the project master pom, it exports all > artifact in repository layout and inclusive poms. > I think this could happen on more than the provided params. -- 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-251) Artifacts qualifier are NOT taken into accounts correctly
[
https://jira.codehaus.org/browse/MDEP-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MDEP-251:
---
Component/s: tree
> Artifacts qualifier are NOT taken into accounts correctly
> -
>
> Key: MDEP-251
> URL: https://jira.codehaus.org/browse/MDEP-251
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: tree
>Affects Versions: 2.1
> Environment: OSX 10.6.2, java 1.6.0_17
>Reporter: Jean Seurin
>Assignee: Brian Fox
>Priority: Critical
> Attachments: test.maven-dependency-plugin.zip
>
>
> I just introduced some qualifier for some libs that require to be compiled in
> java5.
> I've been very confused when realizing that when packaging a webapp depending
> on those qualified artifacts, the non qualified versions are included instead.
> It seems to come from dependency plugin.
> Here is what happens:
> When I do a dependency:tree on an artifact that depends directly on qualified
> libs, I get something regular:
> [INFO] [dependency:tree {execution: default-cli}]
> [INFO] org.company.project:stageof:jar:1.4-SNAPSHOT
> [INFO] +- org.company.project:jar:jdk1.5:1.5-SNAPSHOT:compile
>
> [INFO] +- org.company.commons:commons-xml:jar:jdk1.5:1.4-SNAPSHOT:compile
> The stageof lib depends on the jdk1.5 qualified commons and commons-xml libs.
> When I do a dependency:tree on an upper level webapp that depends on this
> stageof lib:
> [INFO] org.company.project:webapp:war:1.13-SNAPSHOT
> [INFO] +- org.company.project:stageof:jar:jdk1.5:1.4-SNAPSHOT:compile
> [INFO] | +- org.company.commons:jar:1.4.0:compile
> [INFO] | \- org.company.commons:commons-xml:jar:1.4-SNAPSHOT:compile
> [INFO] +- org.company.commons:jar:jdk1.5:1.5-SNAPSHOT:compile
> ...
> it finds correctly the qualified version of stageof, but include non
> qualified commons and commons-xml.
> These unqualified versions are the dependencies of the also non qualified
> stageof-1.4-SNAPSHOT.
> From this behavior, I presume dependency plugin makes a mistake in looking
> from the wrong pom, probably not using the qualifier of the included
> dependency:
>
> org.company.project
> stageof
> 1.4-SNAPSHOT
> compile
> jdk1.5
>
> Hope this is clear.
> I could provide an example if you can't reproduce easily.
> Actually, just adding a qualifier to the jar-plugin to produce the artifact
> and to the section should do the job.
> rgds,
> jean
--
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-307) Version range doesn't work
[
https://jira.codehaus.org/browse/MDEP-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MDEP-307.
--
Resolution: Cannot Reproduce
Assignee: Paul Gier (was: Brian Fox)
This is probably a problem with the metadata in your repository. You can try
asking on the maven user list if you are still having a problem with this.
http://maven.apache.org/mail-lists.html
> Version range doesn't work
> --
>
> Key: MDEP-307
> URL: https://jira.codehaus.org/browse/MDEP-307
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Win XP, Eclipse 3.6.1
>Reporter: SirWayne
>Assignee: Paul Gier
>Priority: Critical
>
> I want to use a version range in my dependencies, but it doesn't work. If i
> use the fix version, all works fine. In my repo the version is
> org.eclipse.emf:common:jar:2.6.0
> {code:xml}
>
>
> org.eclipse.emf
> common
> [2.5.0,4.0.0)
>
> {code}
> Error
> [ERROR] An error occurred during dependency resolution of the following
> artifact:
> org.eclipse.emf:common:null
> Caused by: No versions are present in the repository for the artifact with a
> range [2.5.0,4.0.0)
> org.eclipse.emf:common:jar:null
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> myrepo(http://myRepo/m2repository)
> Path to dependency:
> 1) xyz:jar:1.0.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] (MDEP-290) purge-local-repository fails when the dependency was never download yet and copying is declared
[
https://jira.codehaus.org/browse/MDEP-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MDEP-290:
---
Description:
Using goal "purge-local-repository" together with "copy-dependencies" leads to
failure of build with "dependency is missing" if one of the declared
snapshot-dependencies was never downloaded before.
Example, pom.xml:
{code:xml}
some.groupid
some.artifactid
1.0-SNAPSHOT
org.apache.maven.plugins
maven-dependency-plugin
2.1
clean-local-repository
prepare-package
purge-local-repository
false
true
copy-artifact
package
copy-dependencies
some.artifactid
{code}
In the local maven repository the folder "some.artifactid" should be missing
(just delete it manually if you are testing with something which you already
have there). Now try to build the project with the given pom. It will fail with
the message that dependency is missing.
If you comment out the execution of purge-local-repository the build will run
successfully (maven downloads the declared dependency).
Otherwise if you comment out the execution of copy-dependencies the build will
also run successfully.
But if you have both executions together declared it will fail as long as the
declared dependency is not in the local repository...
was:
Using goal "purge-local-repository" together with "copy-dependencies" leads to
failure of build with "dependency is missing" if one of the declared
snapshot-dependencies was never downloaded before.
Example, pom.xml:
...
some.groupid
some.artifactid
1.0-SNAPSHOT
org.apache.maven.plugins
maven-dependency-plugin
2.1
clean-local-repository
prepare-package
purge-local-repository
false
true
copy-artifact
package
copy-dependencies
some.artifactid
...
In the local maven repository the folder "some.artifactid" should be missing
(just delete it manually if you are testing with something which you already
have there). Now try to build the project with the given pom. It will fail with
the message that dependency is missing.
If you comment out the execution of purge-local-repository the build will run
successfully (maven downloads the declared dependency).
Otherwise if you comment out the execution of copy-dependencies the build will
also run successfully.
But if you have both executions together declared it will fail as long as the
declared dependency is not in the local repository...
> purge-local-repository fails when the dependency was never download yet and
> copying is declared
> ---
>
> Key: MDEP-290
> URL: https://jira.codehaus.org/browse/MDEP-290
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: purge-local-repository
>Affects Versions: 2.1
>Reporter: Dieter König
>Assignee: Paul Gier
> Fix For: 2.6
>
>
> Using goal "purge-local-repository" together with "copy-dependencies" leads
> to failure of build with "dependency is missing" if one of the declared
> snapshot-dependencies was never downloaded before.
> Example, pom.xml:
> {code:xml}
>
>
>
[jira] (MDEP-290) purge-local-repository fails when the dependency was never download yet and copying is declared
[ https://jira.codehaus.org/browse/MDEP-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-290: --- Fix Version/s: 2.6 Assignee: Paul Gier (was: Brian Fox) > purge-local-repository fails when the dependency was never download yet and > copying is declared > --- > > Key: MDEP-290 > URL: https://jira.codehaus.org/browse/MDEP-290 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: purge-local-repository >Affects Versions: 2.1 >Reporter: Dieter König >Assignee: Paul Gier > Fix For: 2.6 > > > Using goal "purge-local-repository" together with "copy-dependencies" leads > to failure of build with "dependency is missing" if one of the declared > snapshot-dependencies was never downloaded before. > Example, pom.xml: > ... > > > some.groupid > some.artifactid > 1.0-SNAPSHOT > > > > > > org.apache.maven.plugins > maven-dependency-plugin > 2.1 > > > clean-local-repository > prepare-package > > purge-local-repository > > > false > true > > > > copy-artifact > package > > copy-dependencies > > > > some.artifactid > > > > > > > ... > In the local maven repository the folder "some.artifactid" should be missing > (just delete it manually if you are testing with something which you already > have there). Now try to build the project with the given pom. It will fail > with the message that dependency is missing. > If you comment out the execution of purge-local-repository the build will run > successfully (maven downloads the declared dependency). > Otherwise if you comment out the execution of copy-dependencies the build > will also run successfully. > But if you have both executions together declared it will fail as long as the > declared dependency is not in the local repository... -- 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-272) purge-local-repository does nothing if certain dependencies are included
[
https://jira.codehaus.org/browse/MDEP-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MDEP-272:
---
Fix Version/s: 2.6
Assignee: Paul Gier (was: Brian Fox)
Thanks for the patch, however we've made some recent changes to the
purge-local-repository goal, and not every use case requires the full test
scope dependency resolution. Can you check if this issue still affects you?
And if possible provide a new patch?
> purge-local-repository does nothing if certain dependencies are included
>
>
> Key: MDEP-272
> URL: https://jira.codehaus.org/browse/MDEP-272
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: purge-local-repository
>Affects Versions: 2.0
>Reporter: Michele Lorenzini
>Assignee: Paul Gier
> Fix For: 2.6
>
> Attachments: pom.xml, PurgeLocalRepositoryMojo.patch,
> PurgeLocalRepositoryMojo.patch
>
>
> I've noticed that the {{purge-local-repository}} goal does nothing if certain
> dependencies are present in the dependency tree of the project.
> After some attempts I've found some of the dependencies that can show problem.
> See attached {{pom.xml}}: if I run {{mvn validate}} as is, maven purges the
> local repository and the log4j jar is downloaded from the remote repository.
> Removing the comment around the jasperreports dependency and re-running {{mvn
> validate}} gives the following result:
> {code}
> [INFO] [dependency:purge-local-repository {execution: default}]
> [INFO] Nothing to do for project: test-issue:test-issue:pom:1.0.0.0-SNAPSHOT
> {code}
> So it seems that something goes wrong while resolving the dependencies for
> the project if the jasperreports jar is included, resulting in the
> {{purge-local-repository}} to skip the clean of the local repository.
> I dont know if this happens only with jasperreports dependency or if it is
> something more general.
--
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-343) Add "skip" parameter for copy-dependencies
[ https://jira.codehaus.org/browse/MDEP-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MDEP-343. -- Resolution: Fixed Done in [r1399962|http://svn.apache.org/viewvc?view=revision&revision=1399962] > Add "skip" parameter for copy-dependencies > -- > > Key: MDEP-343 > URL: https://jira.codehaus.org/browse/MDEP-343 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: copy-dependencies >Reporter: Denis >Assignee: Paul Gier > Fix For: 2.6 > > > It would be nice if the "copy-dependencies" goal could be skipped by defining > a parameter "skip" (just like you can do within the copy goal configuration) -- 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-343) Add "skip" parameter for copy-dependencies
[ https://jira.codehaus.org/browse/MDEP-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-343: --- Affects Version/s: (was: 2.4) Fix Version/s: 2.6 Assignee: Paul Gier > Add "skip" parameter for copy-dependencies > -- > > Key: MDEP-343 > URL: https://jira.codehaus.org/browse/MDEP-343 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: copy-dependencies >Reporter: Denis >Assignee: Paul Gier > Fix For: 2.6 > > > It would be nice if the "copy-dependencies" goal could be skipped by defining > a parameter "skip" (just like you can do within the copy goal configuration) -- 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-256) invoking purge-local-repository leads to deletion of %JDK_HOME%/lib/tools.jar
[ https://jira.codehaus.org/browse/MDEP-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MDEP-256. -- Resolution: Fixed I added a check to avoid trying to purge any system dependencies since these cannot easily be reresolved. http://svn.apache.org/viewvc?view=revision&revision=1399958 > invoking purge-local-repository leads to deletion of %JDK_HOME%/lib/tools.jar > - > > Key: MDEP-256 > URL: https://jira.codehaus.org/browse/MDEP-256 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: purge-local-repository >Affects Versions: 2.0 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) > Java version: 1.6.0_05 > Java home: c:\bea10\jdk160_05\jre > Default locale: cs_CZ, platform encoding: Cp1250 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Marian Stránecký >Assignee: Paul Gier > Fix For: 2.6 > > > RELEVANT PARTS of maven output: > [DEBUG] Adding managed dependencies for org.apache.maven:maven-artifact > [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9 > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.1 > [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-6 > [DEBUG] org.apache.maven.wagon:wagon-ssh:jar:1.0-alpha-7 > [DEBUG] org.apache.maven.wagon:wagon-ssh-external:jar:1.0-alpha-6 > [DEBUG] org.apache.maven.wagon:wagon-file:jar:1.0-alpha-7 > [DEBUG] org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-6 > [DEBUG] org.apache.maven:maven-artifact:jar:2.0.4:compile > (selected for compile) > [DEBUG] > org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-6:compile (selected > for compile) > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:compile > (removed - nearer found: 1.1) > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.1:compile > (selected for compile) > [DEBUG] org.apache.maven:maven-artifact:jar:2.0.4:compile > (selected for compile) > [DEBUG] > org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile > (selected for compile) > [DEBUG] junit:junit:jar:3.8.1:compile (removed - nearer found: > 4.8.1) > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:compile > (removed - nearer found: 1.1) > [DEBUG] classworlds:classworlds:jar:1.1-alpha-2:compile > (selected for compile) > [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.4:compile > (selected for compile) > [DEBUG] com.sun:tools:jar:1.5.0:system (selected for system) > ... > [INFO] Processing artifact: com.sun:tools:jar:1.5.0 > [INFO] Deleting: c:\bea10\jdk160_05\jre\..\lib\tools.jar > [INFO] Re-resolving. > [DEBUG] System artifact: com.sun:tools:jar:1.5.0:system is not a file: > c:\bea10\jdk160_05\jre\..\lib\tools.jar -- 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-256) invoking purge-local-repository leads to deletion of %JDK_HOME%/lib/tools.jar
[ https://jira.codehaus.org/browse/MDEP-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-256: --- Fix Version/s: 2.6 Assignee: Paul Gier (was: Brian Fox) > invoking purge-local-repository leads to deletion of %JDK_HOME%/lib/tools.jar > - > > Key: MDEP-256 > URL: https://jira.codehaus.org/browse/MDEP-256 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: purge-local-repository >Affects Versions: 2.0 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) > Java version: 1.6.0_05 > Java home: c:\bea10\jdk160_05\jre > Default locale: cs_CZ, platform encoding: Cp1250 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Marian Stránecký >Assignee: Paul Gier > Fix For: 2.6 > > > RELEVANT PARTS of maven output: > [DEBUG] Adding managed dependencies for org.apache.maven:maven-artifact > [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9 > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.1 > [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-6 > [DEBUG] org.apache.maven.wagon:wagon-ssh:jar:1.0-alpha-7 > [DEBUG] org.apache.maven.wagon:wagon-ssh-external:jar:1.0-alpha-6 > [DEBUG] org.apache.maven.wagon:wagon-file:jar:1.0-alpha-7 > [DEBUG] org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-6 > [DEBUG] org.apache.maven:maven-artifact:jar:2.0.4:compile > (selected for compile) > [DEBUG] > org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-6:compile (selected > for compile) > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:compile > (removed - nearer found: 1.1) > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.1:compile > (selected for compile) > [DEBUG] org.apache.maven:maven-artifact:jar:2.0.4:compile > (selected for compile) > [DEBUG] > org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile > (selected for compile) > [DEBUG] junit:junit:jar:3.8.1:compile (removed - nearer found: > 4.8.1) > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:compile > (removed - nearer found: 1.1) > [DEBUG] classworlds:classworlds:jar:1.1-alpha-2:compile > (selected for compile) > [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.4:compile > (selected for compile) > [DEBUG] com.sun:tools:jar:1.5.0:system (selected for system) > ... > [INFO] Processing artifact: com.sun:tools:jar:1.5.0 > [INFO] Deleting: c:\bea10\jdk160_05\jre\..\lib\tools.jar > [INFO] Re-resolving. > [DEBUG] System artifact: com.sun:tools:jar:1.5.0:system is not a file: > c:\bea10\jdk160_05\jre\..\lib\tools.jar -- 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-253) Purge does not purge released artifacts
[ https://jira.codehaus.org/browse/MDEP-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MDEP-253. -- Resolution: Cannot Reproduce Fix Version/s: 2.6 Assignee: Paul Gier (was: Brian Fox) > Purge does not purge released artifacts > --- > > Key: MDEP-253 > URL: https://jira.codehaus.org/browse/MDEP-253 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: purge-local-repository >Affects Versions: 2.0 > Environment: Linux, JDK 1.5, Maven 2.0.10 >Reporter: James Lorenzen >Assignee: Paul Gier > Fix For: 2.6 > > > I am running into a problem when running mvn > dependency:purge-local-repository in that it does not remove any local > artifacts for a large multi-module project. > I run it from the parent directory and it reports the following for all my > sub modules > [INFO] Nothing to do for project: ... > I expect the goal to examine all my dependencies, including transitive > dependencies, and remove them from the local repository. -- 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-246) purge-local-repository inclusions
[ https://jira.codehaus.org/browse/MDEP-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MDEP-246. -- Resolution: Fixed This should be resolved by the new options included in MDEP-173. http://svn.apache.org/viewvc?view=revision&revision=1399955 > purge-local-repository inclusions > - > > Key: MDEP-246 > URL: https://jira.codehaus.org/browse/MDEP-246 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: purge-local-repository >Affects Versions: 2.1 >Reporter: Lukas Fryc >Assignee: Paul Gier > Fix For: 2.6 > > > (Maybe I omit some options, please correct me in that case.) > I want to use purge-local-repository goal to delete specific artifact by > groupId:artifactId to reresolve them. > (Actually I want to be sure using snapshot from remote repository instead of > local). > This is not possible in other way then list all of the other artifacts in > exclude parameter, > but it should be possible to list the reversion - include parameter which is > currently not available. -- 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-173) Support 'includes' in purge-local-repository
[ https://jira.codehaus.org/browse/MDEP-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MDEP-173. -- Resolution: Fixed I updated the patch to work with recent changes to the plugin. I also added a separate manualIncludes parameter which allows artifacts to be purged which are not in the dependency tree of the current project. http://svn.apache.org/viewvc?view=revision&revision=1399955 > Support 'includes' in purge-local-repository > > > Key: MDEP-173 > URL: https://jira.codehaus.org/browse/MDEP-173 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: purge-local-repository >Affects Versions: 2.0 >Reporter: Dan Tran >Assignee: Paul Gier > Fix For: 2.6 > > Attachments: delta-MDEP-173.zip > > > The current configuration only supports excludes, which can be very > cumbersome since I only need to purge on single artifact among a long list of > dependencies. -- 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-246) purge-local-repository inclusions
[ https://jira.codehaus.org/browse/MDEP-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-246: --- Fix Version/s: 2.6 Assignee: Paul Gier (was: Brian Fox) > purge-local-repository inclusions > - > > Key: MDEP-246 > URL: https://jira.codehaus.org/browse/MDEP-246 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: purge-local-repository >Affects Versions: 2.1 >Reporter: Lukas Fryc >Assignee: Paul Gier > Fix For: 2.6 > > > (Maybe I omit some options, please correct me in that case.) > I want to use purge-local-repository goal to delete specific artifact by > groupId:artifactId to reresolve them. > (Actually I want to be sure using snapshot from remote repository instead of > local). > This is not possible in other way then list all of the other artifacts in > exclude parameter, > but it should be possible to list the reversion - include parameter which is > currently not available. -- 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-383) Update purge-local-repository to work in Maven 3
[
https://jira.codehaus.org/browse/MDEP-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MDEP-383.
--
Resolution: Fixed
Fixed in [r1399508|http://svn.apache.org/viewvc?view=revision&revision=1399508].
> Update purge-local-repository to work in Maven 3
>
>
> Key: MDEP-383
> URL: https://jira.codehaus.org/browse/MDEP-383
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: purge-local-repository
>Affects Versions: 2.5.1
>Reporter: Paul Gier
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 2.6
>
>
> The purge-local-repository goal currently uses an empty set of remote
> repositories when initially resolving the dependency set. This doesn't work
> in Maven 3 because the dependency resolution in Maven 3 is more strict about
> checking that an artifact has to be available in the current set of remote
> repositories, otherwise the resolution fails.
> {code:java}
> List remoteRepositories = Collections.emptyList();
> {code}
> This should be fixed to work with both Maven 2 and 3 if possible.
--
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-383) Update purge-local-repository to work in Maven 3
[
https://jira.codehaus.org/browse/MDEP-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311744#comment-311744
]
Paul Gier edited comment on MDEP-383 at 10/17/12 10:02 PM:
---
Note, the reason that the purge-local-repository ITs pass even with Maven 3, is
because the test installs the artifacts locally instead of downloading from a
remote repo. This avoids the issue because the local metadata does not contain
the remote repo name.
was (Author: pgier):
Note, the reason that the purge-local-repository ITs pass, is because the
test installs the artifacts locally instead of downloading from a remote repo.
This avoids the issue because the local metadata does not contain the remote
repo name.
> Update purge-local-repository to work in Maven 3
>
>
> Key: MDEP-383
> URL: https://jira.codehaus.org/browse/MDEP-383
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: purge-local-repository
>Affects Versions: 2.5.1
>Reporter: Paul Gier
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 2.6
>
>
> The purge-local-repository goal currently uses an empty set of remote
> repositories when initially resolving the dependency set. This doesn't work
> in Maven 3 because the dependency resolution in Maven 3 is more strict about
> checking that an artifact has to be available in the current set of remote
> repositories, otherwise the resolution fails.
> {code:java}
> List remoteRepositories = Collections.emptyList();
> {code}
> This should be fixed to work with both Maven 2 and 3 if possible.
--
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-383) Update purge-local-repository to work in Maven 3
[
https://jira.codehaus.org/browse/MDEP-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311744#comment-311744
]
Paul Gier commented on MDEP-383:
Note, the reason that the purge-local-repository ITs pass, is because the test
installs the artifacts locally instead of downloading from a remote repo. This
avoids the issue because the local metadata does not contain the remote repo
name.
> Update purge-local-repository to work in Maven 3
>
>
> Key: MDEP-383
> URL: https://jira.codehaus.org/browse/MDEP-383
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: purge-local-repository
>Affects Versions: 2.5.1
>Reporter: Paul Gier
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 2.6
>
>
> The purge-local-repository goal currently uses an empty set of remote
> repositories when initially resolving the dependency set. This doesn't work
> in Maven 3 because the dependency resolution in Maven 3 is more strict about
> checking that an artifact has to be available in the current set of remote
> repositories, otherwise the resolution fails.
> {code:java}
> List remoteRepositories = Collections.emptyList();
> {code}
> This should be fixed to work with both Maven 2 and 3 if possible.
--
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-383) Update purge-local-repository to work in Maven 3
[
https://jira.codehaus.org/browse/MDEP-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MDEP-383:
---
Fix Version/s: 2.6
Assignee: Paul Gier
> Update purge-local-repository to work in Maven 3
>
>
> Key: MDEP-383
> URL: https://jira.codehaus.org/browse/MDEP-383
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: purge-local-repository
>Affects Versions: 2.5.1
>Reporter: Paul Gier
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 2.6
>
>
> The purge-local-repository goal currently uses an empty set of remote
> repositories when initially resolving the dependency set. This doesn't work
> in Maven 3 because the dependency resolution in Maven 3 is more strict about
> checking that an artifact has to be available in the current set of remote
> repositories, otherwise the resolution fails.
> {code:java}
> List remoteRepositories = Collections.emptyList();
> {code}
> This should be fixed to work with both Maven 2 and 3 if possible.
--
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-383) Update purge-local-repository to work in Maven 3
Paul Gier created MDEP-383:
--
Summary: Update purge-local-repository to work in Maven 3
Key: MDEP-383
URL: https://jira.codehaus.org/browse/MDEP-383
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: purge-local-repository
Affects Versions: 2.5.1
Reporter: Paul Gier
Priority: Critical
The purge-local-repository goal currently uses an empty set of remote
repositories when initially resolving the dependency set. This doesn't work in
Maven 3 because the dependency resolution in Maven 3 is more strict about
checking that an artifact has to be available in the current set of remote
repositories, otherwise the resolution fails.
{code:java}
List remoteRepositories = Collections.emptyList();
{code}
This should be fixed to work with both Maven 2 and 3 if possible.
--
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-173) Support 'includes' in purge-local-repository
[ https://jira.codehaus.org/browse/MDEP-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MDEP-173: --- Fix Version/s: 2.6 Assignee: Paul Gier (was: Brian Fox) > Support 'includes' in purge-local-repository > > > Key: MDEP-173 > URL: https://jira.codehaus.org/browse/MDEP-173 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: purge-local-repository >Affects Versions: 2.0 >Reporter: Dan Tran >Assignee: Paul Gier > Fix For: 2.6 > > Attachments: delta-MDEP-173.zip > > > The current configuration only supports excludes, which can be very > cumbersome since I only need to purge on single artifact among a long list of > dependencies. -- 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] (MENFORCER-138) Rule to ban all transitive dependencies
[ https://jira.codehaus.org/browse/MENFORCER-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MENFORCER-138. --- Resolution: Fixed Looks great, I applied the patch. Thanks! [r1395797|http://svn.apache.org/viewvc?view=revision&revision=1395797] > Rule to ban all transitive dependencies > --- > > Key: MENFORCER-138 > URL: https://jira.codehaus.org/browse/MENFORCER-138 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Reporter: Paul Gier >Assignee: Paul Gier > Fix For: 1.2 > > > In some projects it's necessary (or at least desirable) to have all > dependencies explicitly specified in pom. We have a build requirement to use > a strictly controlled maven repository which includes only artifacts which > are necessary and have been reviewed/approved. In order to meet this > requirement, each new dependency in the build much be reviewed before each > release. This can be done by periodically reviewing the dependency tree and > cleaning up any unnecessary dependencies, but it would be more efficient if > the developer adding the dependency was immediately notified that new > (possibly unnecessary) dependencies were added to the build and not > explicitly defined. The developer can immediately choose whether to exclude > the transitive dependency (if it's not really needed), or declare the > dependency and control the version using dependency management. Doing this > checking up front when the build is modified is more efficient than > periodically reviewing the dependency tree after several upgrades may have > taken place. > It In order to facilitate this use case, an enforcer rule could check that > all dependencies are explicitly defined unless they are specifically marked > to be ignored. This would ban all transitive dependencies so that the user > could either add the transitive dependency directly to the pom (if it's > actually needed), or exclude the dependency using exclusions in the > dependency management, or marked to be ignored using something like an > parameter similar to other standard enforcer rules. -- 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] (MENFORCER-138) Rule to ban all transitive dependencies
[ https://jira.codehaus.org/browse/MENFORCER-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MENFORCER-138: Fix Version/s: 1.2 > Rule to ban all transitive dependencies > --- > > Key: MENFORCER-138 > URL: https://jira.codehaus.org/browse/MENFORCER-138 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Reporter: Paul Gier >Assignee: Paul Gier > Fix For: 1.2 > > > In some projects it's necessary (or at least desirable) to have all > dependencies explicitly specified in pom. We have a build requirement to use > a strictly controlled maven repository which includes only artifacts which > are necessary and have been reviewed/approved. In order to meet this > requirement, each new dependency in the build much be reviewed before each > release. This can be done by periodically reviewing the dependency tree and > cleaning up any unnecessary dependencies, but it would be more efficient if > the developer adding the dependency was immediately notified that new > (possibly unnecessary) dependencies were added to the build and not > explicitly defined. The developer can immediately choose whether to exclude > the transitive dependency (if it's not really needed), or declare the > dependency and control the version using dependency management. Doing this > checking up front when the build is modified is more efficient than > periodically reviewing the dependency tree after several upgrades may have > taken place. > It In order to facilitate this use case, an enforcer rule could check that > all dependencies are explicitly defined unless they are specifically marked > to be ignored. This would ban all transitive dependencies so that the user > could either add the transitive dependency directly to the pom (if it's > actually needed), or exclude the dependency using exclusions in the > dependency management, or marked to be ignored using something like an > parameter similar to other standard enforcer rules. -- 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] (MENFORCER-138) Rule to ban all transitive dependencies
[ https://jira.codehaus.org/browse/MENFORCER-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=307411#comment-307411 ] Paul Gier commented on MENFORCER-138: - This looks good. I updated the formatting based on the Maven code style conventions [1], and I added two simple integration tests which you can pull from my branch [2]. One of the integration tests exposes what I think is a minor bug, where you can exclude two level-3 dependencies and then the plugin ignores the level-2 dependency that is the parent of these deps. Can you also add some site documentation similar to the other rules under src/site/apt? [1]http://maven.apache.org/developers/committer-environment.html [2]https://github.com/pgier/maven-enforcer/tree/MENFORCER-138 > Rule to ban all transitive dependencies > --- > > Key: MENFORCER-138 > URL: https://jira.codehaus.org/browse/MENFORCER-138 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Reporter: Paul Gier >Assignee: Paul Gier > > In some projects it's necessary (or at least desirable) to have all > dependencies explicitly specified in pom. We have a build requirement to use > a strictly controlled maven repository which includes only artifacts which > are necessary and have been reviewed/approved. In order to meet this > requirement, each new dependency in the build much be reviewed before each > release. This can be done by periodically reviewing the dependency tree and > cleaning up any unnecessary dependencies, but it would be more efficient if > the developer adding the dependency was immediately notified that new > (possibly unnecessary) dependencies were added to the build and not > explicitly defined. The developer can immediately choose whether to exclude > the transitive dependency (if it's not really needed), or declare the > dependency and control the version using dependency management. Doing this > checking up front when the build is modified is more efficient than > periodically reviewing the dependency tree after several upgrades may have > taken place. > It In order to facilitate this use case, an enforcer rule could check that > all dependencies are explicitly defined unless they are specifically marked > to be ignored. This would ban all transitive dependencies so that the user > could either add the transitive dependency directly to the pom (if it's > actually needed), or exclude the dependency using exclusions in the > dependency management, or marked to be ignored using something like an > parameter similar to other standard enforcer rules. -- 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] (MENFORCER-138) Rule to ban all transitive dependencies
[ https://jira.codehaus.org/browse/MENFORCER-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MENFORCER-138: Description: In some projects it's necessary (or at least desirable) to have all dependencies explicitly specified in pom. We have a build requirement to use a strictly controlled maven repository which includes only artifacts which are necessary and have been reviewed/approved. In order to meet this requirement, each new dependency in the build much be reviewed before each release. This can be done by periodically reviewing the dependency tree and cleaning up any unnecessary dependencies, but it would be more efficient if the developer adding the dependency was immediately notified that new (possibly unnecessary) dependencies were added to the build and not explicitly defined. The developer can immediately choose whether to exclude the transitive dependency (if it's not really needed), or declare the dependency and control the version using dependency management. Doing this checking up front when the build is modified is more efficient than periodically reviewing the dependency tree after several upgrades may have taken place. It In order to facilitate this use case, an enforcer rule could check that all dependencies are explicitly defined unless they are specifically marked to be ignored. This would ban all transitive dependencies so that the user could either add the transitive dependency directly to the pom (if it's actually needed), or exclude the dependency using exclusions in the dependency management, or marked to be ignored using something like an parameter similar to other standard enforcer rules. was: In some projects it's necessary (or at least desirable) to have all dependencies specified in pom. It would be nice to have an enforcer rule that would ban all transitive dependencies so that the user could either add the transitive dependency directly to the pom (if it's actually needed), or exclude the dependency. The rule should also have an option to ignore certain transitive dependencies, possibly using a similar syntax to other rules. Assignee: Paul Gier > Rule to ban all transitive dependencies > --- > > Key: MENFORCER-138 > URL: https://jira.codehaus.org/browse/MENFORCER-138 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Reporter: Paul Gier >Assignee: Paul Gier > > In some projects it's necessary (or at least desirable) to have all > dependencies explicitly specified in pom. We have a build requirement to use > a strictly controlled maven repository which includes only artifacts which > are necessary and have been reviewed/approved. In order to meet this > requirement, each new dependency in the build much be reviewed before each > release. This can be done by periodically reviewing the dependency tree and > cleaning up any unnecessary dependencies, but it would be more efficient if > the developer adding the dependency was immediately notified that new > (possibly unnecessary) dependencies were added to the build and not > explicitly defined. The developer can immediately choose whether to exclude > the transitive dependency (if it's not really needed), or declare the > dependency and control the version using dependency management. Doing this > checking up front when the build is modified is more efficient than > periodically reviewing the dependency tree after several upgrades may have > taken place. > It In order to facilitate this use case, an enforcer rule could check that > all dependencies are explicitly defined unless they are specifically marked > to be ignored. This would ban all transitive dependencies so that the user > could either add the transitive dependency directly to the pom (if it's > actually needed), or exclude the dependency using exclusions in the > dependency management, or marked to be ignored using something like an > parameter similar to other standard enforcer rules. -- 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] (MENFORCER-138) Rule to ban all transitive dependencies
[ https://jira.codehaus.org/browse/MENFORCER-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306864#comment-306864 ] Paul Gier commented on MENFORCER-138: - Thanks, this is a good start. I'd like this to be part of the standard set of enforcer rules, can you add it to the enforcer code as a standard rule? You can use the git repo of the enforcer from here: https://github.com/apache/maven-enforcer Here are a couple of suggestions for improvement: If the enforcer rule fails, it should print out all the dependencies that failed instead of just failing on the first one. This way if there are multiple failures they can all be fixed without runnning the build again. Also, I think the excludes should specify the transitive dependency to be ignored instead of specifying the direct dependency that brings in the transitive dependencies. For example, this allows you to configure that a direct dependency is allowed to have one or more specific transitive, but not allowed to bring in any other transitive deps. > Rule to ban all transitive dependencies > --- > > Key: MENFORCER-138 > URL: https://jira.codehaus.org/browse/MENFORCER-138 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Reporter: Paul Gier > > In some projects it's necessary (or at least desirable) to have all > dependencies specified in pom. It would be nice to have an enforcer rule > that would ban all transitive dependencies so that the user could either add > the transitive dependency directly to the pom (if it's actually needed), or > exclude the dependency. > The rule should also have an option to ignore certain transitive > dependencies, possibly using a similar syntax to other rules. -- 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] (MENFORCER-138) Rule to ban all transitive dependencies
Paul Gier created MENFORCER-138: --- Summary: Rule to ban all transitive dependencies Key: MENFORCER-138 URL: https://jira.codehaus.org/browse/MENFORCER-138 Project: Maven 2.x Enforcer Plugin Issue Type: New Feature Components: Standard Rules Reporter: Paul Gier In some projects it's necessary (or at least desirable) to have all dependencies specified in pom. It would be nice to have an enforcer rule that would ban all transitive dependencies so that the user could either add the transitive dependency directly to the pom (if it's actually needed), or exclude the dependency. The rule should also have an option to ignore certain transitive dependencies, possibly using a similar syntax to other rules. -- 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-889) JUnit | supprot inheritance of test's categories/groups
[
https://jira.codehaus.org/browse/SUREFIRE-889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed SUREFIRE-889.
--
Resolution: Fixed
Applied patches in
[r1366767|http://svn.apache.org/viewvc?view=revision&revision=1366767].
> JUnit | supprot inheritance of test's categories/groups
> ---
>
> Key: SUREFIRE-889
> URL: https://jira.codehaus.org/browse/SUREFIRE-889
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Reporter: Honza Brázdil
>Assignee: Paul Gier
> Fix For: 2.12.1
>
> Attachments: surefire-hierarchical-categories-doc.patch,
> surefire-hierarchical-categories.patch
>
>
> We have multiple tests in multiple groups and we want to use tests group
> hierarchy using interface inheritance so we can specify if we wants to run
> e.g. all NiceTests or more specific NicePurpleTests.
> Right now are tests @Category compared to surefire's group by class name.
> e.g.:
> If we have category hierarchy:
> {code:java}
> interface NiceTests extends AllTests;
> interface NicePurpleTests extends NiceTests;
> {code}
> and tests:
> {code:java}
> @Category(NiceTests.class) public void ReallyNiceTest();
> @Category(NicePurpleTests.class) public void NicePurpleTestWithDots();
> {code}
> and surefire groups set to:
> {code:xml}com.example.NiceTests{code}
> it runs only {{ReallyNiceTest}}, but not {{NicePurpleTestWithDots}} as wanted.
> I've attached patch which fixed it for me.
--
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-889) JUnit | supprot inheritance of test's categories/groups
[
https://jira.codehaus.org/browse/SUREFIRE-889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier reassigned SUREFIRE-889:
--
Assignee: Paul Gier
> JUnit | supprot inheritance of test's categories/groups
> ---
>
> Key: SUREFIRE-889
> URL: https://jira.codehaus.org/browse/SUREFIRE-889
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Reporter: Honza Brázdil
>Assignee: Paul Gier
> Fix For: 2.12.1
>
> Attachments: surefire-hierarchical-categories-doc.patch,
> surefire-hierarchical-categories.patch
>
>
> We have multiple tests in multiple groups and we want to use tests group
> hierarchy using interface inheritance so we can specify if we wants to run
> e.g. all NiceTests or more specific NicePurpleTests.
> Right now are tests @Category compared to surefire's group by class name.
> e.g.:
> If we have category hierarchy:
> {code:java}
> interface NiceTests extends AllTests;
> interface NicePurpleTests extends NiceTests;
> {code}
> and tests:
> {code:java}
> @Category(NiceTests.class) public void ReallyNiceTest();
> @Category(NicePurpleTests.class) public void NicePurpleTestWithDots();
> {code}
> and surefire groups set to:
> {code:xml}com.example.NiceTests{code}
> it runs only {{ReallyNiceTest}}, but not {{NicePurpleTestWithDots}} as wanted.
> I've attached patch which fixed it for me.
--
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-889) JUnit | supprot inheritance of test's categories/groups
[
https://jira.codehaus.org/browse/SUREFIRE-889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated SUREFIRE-889:
---
Component/s: Maven Surefire Plugin
Fix Version/s: 2.12.1
> JUnit | supprot inheritance of test's categories/groups
> ---
>
> Key: SUREFIRE-889
> URL: https://jira.codehaus.org/browse/SUREFIRE-889
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Reporter: Honza Brázdil
> Fix For: 2.12.1
>
> Attachments: surefire-hierarchical-categories.patch
>
>
> We have multiple tests in multiple groups and we want to use tests group
> hierarchy using interface inheritance so we can specify if we wants to run
> e.g. all NiceTests or more specific NicePurpleTests.
> Right now are tests @Category compared to surefire's group by class name.
> e.g.:
> If we have category hierarchy:
> {code:java}
> interface NiceTests extends AllTests;
> interface NicePurpleTests extends NiceTests;
> {code}
> and tests:
> {code:java}
> @Category(NiceTests.class) public void ReallyNiceTest();
> @Category(NicePurpleTests.class) public void NicePurpleTestWithDots();
> {code}
> and surefire groups set to:
> {code:xml}com.example.NiceTests{code}
> it runs only {{ReallyNiceTest}}, but not {{NicePurpleTestWithDots}} as wanted.
> I've attached patch which fixed it for me.
--
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-889) JUnit | supprot inheritance of test's categories/groups
[
https://jira.codehaus.org/browse/SUREFIRE-889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304554#comment-304554
]
Paul Gier commented on SUREFIRE-889:
Thanks for the patch! Can you add a usage example to the site docs? There are
some relevant pages located under src/site/apt/examples/ which describe the
"groups" parameter in the pages junit.apt.vm and testng.apt.vm. The apt format
is documented here: http://maven.apache.org/doxia/references/apt-format.html
> JUnit | supprot inheritance of test's categories/groups
> ---
>
> Key: SUREFIRE-889
> URL: https://jira.codehaus.org/browse/SUREFIRE-889
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Reporter: Honza Brázdil
> Fix For: 2.12.1
>
> Attachments: surefire-hierarchical-categories.patch
>
>
> We have multiple tests in multiple groups and we want to use tests group
> hierarchy using interface inheritance so we can specify if we wants to run
> e.g. all NiceTests or more specific NicePurpleTests.
> Right now are tests @Category compared to surefire's group by class name.
> e.g.:
> If we have category hierarchy:
> {code:java}
> interface NiceTests extends AllTests;
> interface NicePurpleTests extends NiceTests;
> {code}
> and tests:
> {code:java}
> @Category(NiceTests.class) public void ReallyNiceTest();
> @Category(NicePurpleTests.class) public void NicePurpleTestWithDots();
> {code}
> and surefire groups set to:
> {code:xml}com.example.NiceTests{code}
> it runs only {{ReallyNiceTest}}, but not {{NicePurpleTestWithDots}} as wanted.
> I've attached patch which fixed it for me.
--
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-847) surefire cannot run single testng test
[ https://jira.codehaus.org/browse/SUREFIRE-847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier reopened SUREFIRE-847: > surefire cannot run single testng test > --- > > Key: SUREFIRE-847 > URL: https://jira.codehaus.org/browse/SUREFIRE-847 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.12 > Environment: Windows 7 x64 >Reporter: Nikita Makarov >Priority: Minor > Fix For: 2.13 > > Attachments: onlyFailedTest.log, onlyPassedTest.log, > surefire-847_example.zip > > > Trying to run single testng test class with command mvn test -Dtest=SomeTest > fails with message > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-test) on > project web-integration-tests: No tests were executed! > (Set -DfailIfNoTests=false to ignore this error.) -> [Help 1]. -- 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-847) surefire cannot run single testng test
[ https://jira.codehaus.org/browse/SUREFIRE-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302934#comment-302934 ] Paul Gier edited comment on SUREFIRE-847 at 7/6/12 11:36 AM: - I was able to reproduce this with 2.12 using the sample project, but not with 2.13-SNAPSHOT, so the issue appears to be fixed. was (Author: pgier): I was able to reproduce this with 2.12 using the same project, but not with 2.13-SNAPSHOT, so the issue appears to be fixed. > surefire cannot run single testng test > --- > > Key: SUREFIRE-847 > URL: https://jira.codehaus.org/browse/SUREFIRE-847 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.12 > Environment: Windows 7 x64 >Reporter: Nikita Makarov >Priority: Minor > Fix For: 2.13 > > Attachments: surefire-847_example.zip > > > Trying to run single testng test class with command mvn test -Dtest=SomeTest > fails with message > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-test) on > project web-integration-tests: No tests were executed! > (Set -DfailIfNoTests=false to ignore this error.) -> [Help 1]. -- 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-847) surefire cannot run single testng test
[ https://jira.codehaus.org/browse/SUREFIRE-847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed SUREFIRE-847. -- Resolution: Fixed Fix Version/s: 2.13 I was able to reproduce this with 2.12 using the same project, but not with 2.13-SNAPSHOT, so the issue appears to be fixed. > surefire cannot run single testng test > --- > > Key: SUREFIRE-847 > URL: https://jira.codehaus.org/browse/SUREFIRE-847 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.12 > Environment: Windows 7 x64 >Reporter: Nikita Makarov >Priority: Minor > Fix For: 2.13 > > Attachments: surefire-847_example.zip > > > Trying to run single testng test class with command mvn test -Dtest=SomeTest > fails with message > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-test) on > project web-integration-tests: No tests were executed! > (Set -DfailIfNoTests=false to ignore this error.) -> [Help 1]. -- 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-847) surefire cannot run single testng test
[ https://jira.codehaus.org/browse/SUREFIRE-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302800#comment-302800 ] Paul Gier commented on SUREFIRE-847: Do you have a small sample project that reproduces the problem? That will make it easier to verify whether this has been fixed by recent related changes. > surefire cannot run single testng test > --- > > Key: SUREFIRE-847 > URL: https://jira.codehaus.org/browse/SUREFIRE-847 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.12 > Environment: Windows 7 x64 >Reporter: Nikita Makarov >Priority: Minor > > Trying to run single testng test class with command mvn test -Dtest=SomeTest > fails with message > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-test) on > project web-integration-tests: No tests were executed! > (Set -DfailIfNoTests=false to ignore this error.) -> [Help 1]. -- 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-879) maven-surefire-report-plugin fails some times with ConcurrentModificationException when running parallel TestNG
[ https://jira.codehaus.org/browse/SUREFIRE-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed SUREFIRE-879. -- Resolution: Fixed Merged the patch to the main svn repo, thanks! http://svn.apache.org/viewvc?view=revision&revision=1355045 > maven-surefire-report-plugin fails some times with > ConcurrentModificationException when running parallel TestNG > --- > > Key: SUREFIRE-879 > URL: https://jira.codehaus.org/browse/SUREFIRE-879 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.12 > Environment: Java version: 1.6.0_32 > Maven version: 3.0.4 > maven-surefire-report-plugin: 2.12 > TestNG: 5.14.10 >Reporter: Adrian Nistor >Assignee: Paul Gier > Fix For: 2.13 > > Attachments: surefire-879-bug.zip > > > I'm running TestNG tests in parallel and get this exception > ConcurrentModificationException. > My quick analysis is that at the end of the test the method > TestSetRunListener.getAsString is accessing the list of captured output while > another thread (a stray thread spawned by the test or a completely different > concurrent test) generates some more console output causing an append to the > list which results in ConcurrentModificationException. > To fix this we need to ensure getAsString accesses the list atomically. A > possible solution is to copy/clone the list before iterating over it. > Here is the stakctrace I get. > java.util.ConcurrentModificationException > at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) > at java.util.AbstractList$Itr.next(AbstractList.java:343) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.getAsString(TestSetRunListener.java:209) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.testFailed(TestSetRunListener.java:168) > at > org.apache.maven.surefire.testng.TestNGReporter.onTestFailure(TestNGReporter.java:104) > at org.testng.internal.Invoker.runTestListeners(Invoker.java:1796) > at org.testng.internal.Invoker.runTestListeners(Invoker.java:1780) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:749) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170) > at > org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) > at org.testng.TestRunner.runWorkers(TestRunner.java:1147) > at org.testng.TestRunner.privateRun(TestRunner.java:749) > at org.testng.TestRunner.run(TestRunner.java:600) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:317) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:34) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351) > at > org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147) > 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) -- 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-879) maven-surefire-report-plugin fails some times with ConcurrentModificationException when running parallel TestNG
[ https://jira.codehaus.org/browse/SUREFIRE-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated SUREFIRE-879: --- Description: I'm running TestNG tests in parallel and get this exception ConcurrentModificationException. My quick analysis is that at the end of the test the method TestSetRunListener.getAsString is accessing the list of captured output while another thread (a stray thread spawned by the test or a completely different concurrent test) generates some more console output causing an append to the list which results in ConcurrentModificationException. To fix this we need to ensure getAsString accesses the list atomically. A possible solution is to copy/clone the list before iterating over it. Here is the stakctrace I get. java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) at java.util.AbstractList$Itr.next(AbstractList.java:343) at org.apache.maven.plugin.surefire.report.TestSetRunListener.getAsString(TestSetRunListener.java:209) at org.apache.maven.plugin.surefire.report.TestSetRunListener.testFailed(TestSetRunListener.java:168) at org.apache.maven.surefire.testng.TestNGReporter.onTestFailure(TestNGReporter.java:104) at org.testng.internal.Invoker.runTestListeners(Invoker.java:1796) at org.testng.internal.Invoker.runTestListeners(Invoker.java:1780) at org.testng.internal.Invoker.invokeMethod(Invoker.java:749) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) at org.testng.TestRunner.runWorkers(TestRunner.java:1147) at org.testng.TestRunner.privateRun(TestRunner.java:749) at org.testng.TestRunner.run(TestRunner.java:600) at org.testng.SuiteRunner.runTest(SuiteRunner.java:317) at org.testng.SuiteRunner.access$000(SuiteRunner.java:34) at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351) at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147) 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) was: I'm running TestNG tests in parallel and get this exception ConcurrentModificationException. My quick analysis is that at the end of the test the method TestSetRunListener.getAsString is accessing the list of captured output while another thread (a stray thread spawned by the test or a completely different concurrent test) generates some more console output causing an append to the list which results in ConcurrentModificationException. To fix this we need to ensure getAsString accesses the list atomically. A possible solution is to copy/clone the list before iterating over it. Here is the stakctrace I get. java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) at java.util.AbstractList$Itr.next(AbstractList.java:343) at org.apache.maven.plugin.surefire.report.TestSetRunListener.getAsString(TestSetRunListener.java:209) at org.apache.maven.plugin.surefire.report.TestSetRunListener.testFailed(TestSetRunListener.java:168) at org.apache.maven.surefire.testng.TestNGReporter.onTestFailure(TestNGReporter.java:104) at org.testng.internal.Invoker.runTestListeners(Invoker.java:1796) at org.testng.internal.Invoker.runTestListeners(Invoker.java:1780) at org.testng.internal.Invoker.invokeMethod(Invoker.java:749) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) at org.testng.TestRunner.runWorkers(TestRunner.java:1147) at org.testng.TestRunner.privateRun(TestRunner.java:749) at org.testng.TestRunner.run(TestRunner.java:600) at org.testng.SuiteRunner.runTest(SuiteRunner.java:317) at org.testng.SuiteRunner.access$000(SuiteRunner.java:34) at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351) at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147) 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) Fix Version/s: 2.13 Assignee: Paul Gier > maven-surefire-report-plugin fails some times with > ConcurrentModificationException when running parallel TestNG > --- > >
[jira] (MENFORCER-98) requirePluginVersions rule is not compatible with maven 3.0-beta-1
[ https://jira.codehaus.org/browse/MENFORCER-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MENFORCER-98. -- Resolution: Fixed Applied patch with minor changes in [r1335846|http://svn.apache.org/viewvc?view=revision&revision=1335846] > requirePluginVersions rule is not compatible with maven 3.0-beta-1 > -- > > Key: MENFORCER-98 > URL: https://jira.codehaus.org/browse/MENFORCER-98 > Project: Maven 2.x Enforcer Plugin > Issue Type: Bug > Components: Standard Rules >Affects Versions: 1.0-beta-1 > Environment: Windows XP > Sun JDK 1.6.0_18 > Maven 3.0-beta-1 >Reporter: Anders Hammar >Assignee: Paul Gier > Fix For: 1.1 > > Attachments: MENFORCER-98.patch > > > When using the requirePluginVersions rule, I get a message saying "This rule > is not compatible with the current version of Maven. The rule is not able to > perform any checks." -- 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] (MENFORCER-98) requirePluginVersions rule is not compatible with maven 3.0-beta-1
[ https://jira.codehaus.org/browse/MENFORCER-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MENFORCER-98: --- Fix Version/s: 1.1 Assignee: Paul Gier > requirePluginVersions rule is not compatible with maven 3.0-beta-1 > -- > > Key: MENFORCER-98 > URL: https://jira.codehaus.org/browse/MENFORCER-98 > Project: Maven 2.x Enforcer Plugin > Issue Type: Bug > Components: Standard Rules >Affects Versions: 1.0-beta-1 > Environment: Windows XP > Sun JDK 1.6.0_18 > Maven 3.0-beta-1 >Reporter: Anders Hammar >Assignee: Paul Gier > Fix For: 1.1 > > Attachments: MENFORCER-98.patch > > > When using the requirePluginVersions rule, I get a message saying "This rule > is not compatible with the current version of Maven. The rule is not able to > perform any checks." -- 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] (MENFORCER-118) DependencyConvergence gets better if it doesn't fail on snapshots of same baseVersion
[ https://jira.codehaus.org/browse/MENFORCER-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MENFORCER-118. --- Resolution: Fixed Fixed in [r1335761|http://svn.apache.org/viewvc?view=revision&revision=1335761] > DependencyConvergence gets better if it doesn't fail on snapshots of same > baseVersion > - > > Key: MENFORCER-118 > URL: https://jira.codehaus.org/browse/MENFORCER-118 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 1.0.1 >Reporter: Poul Bildsøe >Assignee: Robert Scholte > Fix For: 1.1 > > Attachments: menforcer-118.patch > > > The DependencyVersionMap used by DependencyConvergense uses > node.getArtifact().getVersion() when comparing versions. This makes the rule > fail more often than needed because the version compare doens't ignore the > fact that some snapshots may have been resolved to timestamp. If the code was > node.getArtifact().getBaseVersion() instead then DependencyConvergense would > only fail on real version mismatches. -- 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] (MENFORCER-118) DependencyConvergence gets better if it doesn't fail on snapshots of same baseVersion
[ https://jira.codehaus.org/browse/MENFORCER-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MENFORCER-118: Priority: Major (was: Trivial) Fix Version/s: 1.1 Assignee: Robert Scholte > DependencyConvergence gets better if it doesn't fail on snapshots of same > baseVersion > - > > Key: MENFORCER-118 > URL: https://jira.codehaus.org/browse/MENFORCER-118 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 1.0.1 >Reporter: Poul Bildsøe >Assignee: Robert Scholte > Fix For: 1.1 > > Attachments: menforcer-118.patch > > > The DependencyVersionMap used by DependencyConvergense uses > node.getArtifact().getVersion() when comparing versions. This makes the rule > fail more often than needed because the version compare doens't ignore the > fact that some snapshots may have been resolved to timestamp. If the code was > node.getArtifact().getBaseVersion() instead then DependencyConvergense would > only fail on real version mismatches. -- 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-5134) Standard documentation for build-in properties
[ https://jira.codehaus.org/browse/MNG-5134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=295504#comment-295504 ] Paul Gier commented on MNG-5134: Here is the correct link: http://maven.apache.org/ref/3.0.4/maven-model-builder/ > Standard documentation for build-in properties > -- > > Key: MNG-5134 > URL: https://jira.codehaus.org/browse/MNG-5134 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Documentation: General >Reporter: Paul Gier >Assignee: Paul Gier >Priority: Minor > Fix For: 3.0.4 > > > The Maven site documentation should include a reference to all the available > properties. > There are a couple of existing locations of property documentation, but > nothing on the official Maven site from what I can tell. > http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide > http://www.sonatype.com/books/mvnref-book/reference/resource-filtering-sect-properties.html -- 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] (MENFORCER-128) Fail the build if a dependency is overwriten with an incompatible lower version (patch)
[
https://jira.codehaus.org/browse/MENFORCER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291550#comment-291550
]
Paul Gier commented on MENFORCER-128:
-
I added a bit more description to the site docs, just to try to make this clear.
[r1243555|http://svn.apache.org/viewvc?view=revision&revision=1243555]
> Fail the build if a dependency is overwriten with an incompatible lower
> version (patch)
> ---
>
> Key: MENFORCER-128
> URL: https://jira.codehaus.org/browse/MENFORCER-128
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Geoffrey De Smet
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.1
>
> Attachments: MENFORCER-128.patch
>
>
> Overwriting a dependency to a lower version than any of your other
> dependencies need should fail the build if this new enforcer rule is active.
> For example, this is bad:
> {code}
>
>
> org.slf4j
> slf4j-api
> 1.4.0
>
>
> ch.qos.logback
> logback-classic
> 0.9.9
>
>
>
> {code}
> Attaching patch in a few minutes.
--
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] (MENFORCER-128) Fail the build if a dependency is overwriten with an incompatible lower version (patch)
[
https://jira.codehaus.org/browse/MENFORCER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291493#comment-291493
]
Paul Gier commented on MENFORCER-128:
-
The reason I didn't go with something like RequireHighestDependencyVersion is
because it sounds like it will require the highest version available in the
repository. Upper bound makes more sense to me because what you are saying is
that the version in the POM is the highest version that is acceptable in the
dependency tree.
Anyway, I think as long at the description in the site docs are good, users
will be able to figure out what it means.
> Fail the build if a dependency is overwriten with an incompatible lower
> version (patch)
> ---
>
> Key: MENFORCER-128
> URL: https://jira.codehaus.org/browse/MENFORCER-128
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Geoffrey De Smet
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.1
>
> Attachments: MENFORCER-128.patch
>
>
> Overwriting a dependency to a lower version than any of your other
> dependencies need should fail the build if this new enforcer rule is active.
> For example, this is bad:
> {code}
>
>
> org.slf4j
> slf4j-api
> 1.4.0
>
>
> ch.qos.logback
> logback-classic
> 0.9.9
>
>
>
> {code}
> Attaching patch in a few minutes.
--
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] (MSOURCES-30) Should not output INFO message when maven is run in quiet mode
[ https://jira.codehaus.org/browse/MSOURCES-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291436#comment-291436 ] Paul Gier commented on MSOURCES-30: --- This should be fixed with the next release of plexus archiver. See commit [955c1827|https://github.com/sonatype/plexus-archiver/commit/955c18275e956cf61a4cfb5ce6a0602182a61b92]. > Should not output INFO message when maven is run in quiet mode > -- > > Key: MSOURCES-30 > URL: https://jira.codehaus.org/browse/MSOURCES-30 > Project: Maven 2.x Source Plugin > Issue Type: Bug >Affects Versions: 2.0.4 >Reporter: Mauritz Lovgren >Priority: Minor > > Currently, the source plugin produces INFO statement for created source jars > even if maven is run in quite mode. > This produces unwanted output to system.out during build. -- 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] (MENFORCER-128) Fail the build if a dependency is overwriten with an incompatible lower version (patch)
[
https://jira.codehaus.org/browse/MENFORCER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MENFORCER-128.
---
Resolution: Fixed
Updated goal name in
[r1243269|http://svn.apache.org/viewvc?view=revision&revision=1243269] and
[r1243270|http://svn.apache.org/viewvc?view=revision&revision=1243270]
> Fail the build if a dependency is overwriten with an incompatible lower
> version (patch)
> ---
>
> Key: MENFORCER-128
> URL: https://jira.codehaus.org/browse/MENFORCER-128
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Geoffrey De Smet
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.1
>
> Attachments: MENFORCER-128.patch
>
>
> Overwriting a dependency to a lower version than any of your other
> dependencies need should fail the build if this new enforcer rule is active.
> For example, this is bad:
> {code}
>
>
> org.slf4j
> slf4j-api
> 1.4.0
>
>
> ch.qos.logback
> logback-classic
> 0.9.9
>
>
>
> {code}
> Attaching patch in a few minutes.
--
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] (MENFORCER-128) Fail the build if a dependency is overwriten with an incompatible lower version (patch)
[
https://jira.codehaus.org/browse/MENFORCER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier reopened MENFORCER-128:
-
I agree the goal name could be more clear. How about
{{RequireUpperBoundDeps}}? Since other standard rules use "Require" instead of
"Force".
> Fail the build if a dependency is overwriten with an incompatible lower
> version (patch)
> ---
>
> Key: MENFORCER-128
> URL: https://jira.codehaus.org/browse/MENFORCER-128
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Geoffrey De Smet
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.1
>
> Attachments: MENFORCER-128.patch
>
>
> Overwriting a dependency to a lower version than any of your other
> dependencies need should fail the build if this new enforcer rule is active.
> For example, this is bad:
> {code}
>
>
> org.slf4j
> slf4j-api
> 1.4.0
>
>
> ch.qos.logback
> logback-classic
> 0.9.9
>
>
>
> {code}
> Attaching patch in a few minutes.
--
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] (MSOURCES-48) Including sources in project dependencies
[ https://jira.codehaus.org/browse/MSOURCES-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MSOURCES-48. - Resolution: Not A Bug Fix Version/s: 2.2 > Including sources in project dependencies > - > > Key: MSOURCES-48 > URL: https://jira.codehaus.org/browse/MSOURCES-48 > Project: Maven 2.x Source Plugin > Issue Type: New Feature > Environment: gwt compilation >Reporter: warren crossing > Fix For: 2.2 > > > perhaps type: > Corresponds to the dependant artifact's packaging type. This defaults to jar. > While it usually represents the extension on the filename of the dependency, > that is not always the case. A type can be mapped to a different extension > and a classifier. The type often correspongs to the packaging used, though > this is also not always the case. Some examples are jar, ejb-client and > test-jar. New types can be defined by plugins that set extensions to true, so > this is not a complete list. -- 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] (MENFORCER-114) Typo in Require Plugin Versions Documentation
[ https://jira.codehaus.org/browse/MENFORCER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MENFORCER-114. --- Resolution: Fixed Fixed in [r1242820|http://svn.apache.org/viewvc?view=revision&revision=1242820], thanks! > Typo in Require Plugin Versions Documentation > - > > Key: MENFORCER-114 > URL: https://jira.codehaus.org/browse/MENFORCER-114 > Project: Maven 2.x Enforcer Plugin > Issue Type: Bug > Components: Standard Rules >Reporter: Conny Kreyssel >Assignee: Paul Gier >Priority: Minor > Fix For: 1.1 > > Attachments: MENFORCER-114.diff > > > In the > http://maven.apache.org/enforcer/enforcer-rules/requirePluginVersions.html is > a typo for the property unCheckedPluginList. > In the list and the example you write "unCheckedPluginsList" - the 's' is too > much - it should be "unCheckedPluginList". > Thanks. -- 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] (MENFORCER-114) Typo in Require Plugin Versions Documentation
[ https://jira.codehaus.org/browse/MENFORCER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MENFORCER-114: Fix Version/s: 1.1 Assignee: Paul Gier > Typo in Require Plugin Versions Documentation > - > > Key: MENFORCER-114 > URL: https://jira.codehaus.org/browse/MENFORCER-114 > Project: Maven 2.x Enforcer Plugin > Issue Type: Bug > Components: Standard Rules >Reporter: Conny Kreyssel >Assignee: Paul Gier >Priority: Minor > Fix For: 1.1 > > Attachments: MENFORCER-114.diff > > > In the > http://maven.apache.org/enforcer/enforcer-rules/requirePluginVersions.html is > a typo for the property unCheckedPluginList. > In the list and the example you write "unCheckedPluginsList" - the 's' is too > much - it should be "unCheckedPluginList". > Thanks. -- 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] (MENFORCER-125) requireProperty documentation's example for property.version uses wrong regex
[
https://jira.codehaus.org/browse/MENFORCER-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MENFORCER-125.
---
Resolution: Fixed
Patch applied in
[r1242803|http://svn.apache.org/viewvc?view=revision&revision=1242803], thanks!
> requireProperty documentation's example for property.version uses wrong regex
> -
>
> Key: MENFORCER-125
> URL: https://jira.codehaus.org/browse/MENFORCER-125
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.0.1
> Environment: mvn --version
> Apache Maven 3.0.4-RC3 (r1210461; 2011-12-05 14:58:54+0100)
> Maven home: /usr/local/Cellar/maven/current/libexec
> Java version: 1.6.0_29, vendor: Apple Inc.
> Java home:
> /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
> Default locale: de_DE, platform encoding: MacRoman
> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
>Reporter: Mirko Friedenhagen
>Assignee: Paul Gier
> Fix For: 1.1
>
> Attachments: fix-documentation-for-requireProperty.patch
>
>
> Using the example from
> http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html states
> to use {{(\d|-SNAPSHOT)$}} for checking that
> {{property.version}} ends in a digit or -SNAPSHOT. However the code in
> http://svn.apache.org/repos/asf/maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireProperty.java
> revision 805190 uses {{java.lang.String.matches}} in line 73. So
> {{1.1-SNAPSHOT}} or {{1.1}} will not match. I attach a patch for the
> documentation which uses {{.*(\d|-SNAPSHOT)$}} which will
> succeed.
--
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] (MENFORCER-125) requireProperty documentation's example for property.version uses wrong regex
[
https://jira.codehaus.org/browse/MENFORCER-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MENFORCER-125:
Fix Version/s: 1.1
Assignee: Paul Gier
> requireProperty documentation's example for property.version uses wrong regex
> -
>
> Key: MENFORCER-125
> URL: https://jira.codehaus.org/browse/MENFORCER-125
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.0.1
> Environment: mvn --version
> Apache Maven 3.0.4-RC3 (r1210461; 2011-12-05 14:58:54+0100)
> Maven home: /usr/local/Cellar/maven/current/libexec
> Java version: 1.6.0_29, vendor: Apple Inc.
> Java home:
> /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
> Default locale: de_DE, platform encoding: MacRoman
> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
>Reporter: Mirko Friedenhagen
>Assignee: Paul Gier
> Fix For: 1.1
>
> Attachments: fix-documentation-for-requireProperty.patch
>
>
> Using the example from
> http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html states
> to use {{(\d|-SNAPSHOT)$}} for checking that
> {{property.version}} ends in a digit or -SNAPSHOT. However the code in
> http://svn.apache.org/repos/asf/maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireProperty.java
> revision 805190 uses {{java.lang.String.matches}} in line 73. So
> {{1.1-SNAPSHOT}} or {{1.1}} will not match. I attach a patch for the
> documentation which uses {{.*(\d|-SNAPSHOT)$}} which will
> succeed.
--
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] (MENFORCER-128) Fail the build if a dependency is overwriten with an incompatible lower version (patch)
[
https://jira.codehaus.org/browse/MENFORCER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MENFORCER-128.
---
Resolution: Fixed
Patch applied in
[r1242799|http://svn.apache.org/viewvc?view=revision&revision=1242799], thanks!
> Fail the build if a dependency is overwriten with an incompatible lower
> version (patch)
> ---
>
> Key: MENFORCER-128
> URL: https://jira.codehaus.org/browse/MENFORCER-128
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Reporter: Geoffrey De Smet
>Assignee: Paul Gier
>Priority: Critical
> Fix For: 1.1
>
> Attachments: MENFORCER-128.patch
>
>
> Overwriting a dependency to a lower version than any of your other
> dependencies need should fail the build if this new enforcer rule is active.
> For example, this is bad:
> {code}
>
>
> org.slf4j
> slf4j-api
> 1.4.0
>
>
> ch.qos.logback
> logback-classic
> 0.9.9
>
>
>
> {code}
> Attaching patch in a few minutes.
--
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
