[jira] [Commented] (MPMD-171) Rule properties are ignored when run under MPMD
[
https://issues.apache.org/jira/browse/MPMD-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14571584#comment-14571584
]
Johannes Wienke commented on MPMD-171:
--
Ah sorry, I tried this on a different project. But since you already know the
RSB project, I have reproduced the settings in a branch called
wip-checks-during-build. You can actually see, that nothing of the provided
configuration is used by the plugin, because event the excluded directories are
scanned.
Rule properties are ignored when run under MPMD
---
Key: MPMD-171
URL: https://issues.apache.org/jira/browse/MPMD-171
Project: Maven PMD Plugin
Issue Type: Bug
Components: PMD
Affects Versions: 3.0.1
Environment: Linux
Reporter: Johannes Wienke
Assignee: Michael Osipov
Fix For: 3.3, 3.4
For our project I have defined a custom ruleset for PMD in an XML file [1].
This ruleset defines properties for some of the standard PMD rules using this
syntax:
{noformat}
rule ref=rulesets/java/naming.xml/LongVariable
properties
property name=minimum value=25/
/properties
/rule
{noformat}
When I execute PMD using a parallel ant file we maintain, these custom
properties are respected correctly. However, when executing PMD through
maven, the properties are completely ignored.
The pom.xml we are using is available at [2].
[1]
https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/7e71d4d3e6d57c8529111a7f7143edeb48ddec59/entry/codecheck/pmd-rules.xml
[2]
https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/ff17c0dd008697f70dad27bd0319f4475ab87712/entry/pom.xml
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPMD-171) Rule properties are ignored when run under MPMD
[
https://issues.apache.org/jira/browse/MPMD-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14571594#comment-14571594
]
Johannes Wienke commented on MPMD-171:
--
Strange, when I do mvn clean compile I get different warnings compared to
when I do mvn clean compile site. But either the warnings are less then
expected or too many. They never match what is correctly reported in the site
report.
Rule properties are ignored when run under MPMD
---
Key: MPMD-171
URL: https://issues.apache.org/jira/browse/MPMD-171
Project: Maven PMD Plugin
Issue Type: Bug
Components: PMD
Affects Versions: 3.0.1
Environment: Linux
Reporter: Johannes Wienke
Assignee: Michael Osipov
Fix For: 3.3, 3.4
For our project I have defined a custom ruleset for PMD in an XML file [1].
This ruleset defines properties for some of the standard PMD rules using this
syntax:
{noformat}
rule ref=rulesets/java/naming.xml/LongVariable
properties
property name=minimum value=25/
/properties
/rule
{noformat}
When I execute PMD using a parallel ant file we maintain, these custom
properties are respected correctly. However, when executing PMD through
maven, the properties are completely ignored.
The pom.xml we are using is available at [2].
[1]
https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/7e71d4d3e6d57c8529111a7f7143edeb48ddec59/entry/codecheck/pmd-rules.xml
[2]
https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/ff17c0dd008697f70dad27bd0319f4475ab87712/entry/pom.xml
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MSHARED-418) Verifier should not use hard coded CLI options without possibility to modify them
Tibor Digana created MSHARED-418: Summary: Verifier should not use hard coded CLI options without possibility to modify them Key: MSHARED-418 URL: https://issues.apache.org/jira/browse/MSHARED-418 Project: Maven Shared Components Issue Type: Bug Components: maven-verifier Affects Versions: maven-verifier-1.5 Reporter: Tibor Digana Assignee: Tibor Digana Fix For: maven-verifier-1.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSHARED-418) Verifier should not use hard coded CLI options without possibility to modify them
[ https://issues.apache.org/jira/browse/MSHARED-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated MSHARED-418: - Issue Type: Improvement (was: Bug) Verifier should not use hard coded CLI options without possibility to modify them - Key: MSHARED-418 URL: https://issues.apache.org/jira/browse/MSHARED-418 Project: Maven Shared Components Issue Type: Improvement Components: maven-verifier Affects Versions: maven-verifier-1.5 Reporter: Tibor Digana Assignee: Tibor Digana Fix For: maven-verifier-1.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSHARED-418) Verifier should not use hard coded CLI options without possibility to modify them
[ https://issues.apache.org/jira/browse/MSHARED-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated MSHARED-418: - Description: Verifier used -e and -B by default. These CLI options violate my ITs in surefire and I need to fully control the CLI options in integration tests. Introduced new constructor. Verifier should not use hard coded CLI options without possibility to modify them - Key: MSHARED-418 URL: https://issues.apache.org/jira/browse/MSHARED-418 Project: Maven Shared Components Issue Type: Improvement Components: maven-verifier Affects Versions: maven-verifier-1.5 Reporter: Tibor Digana Assignee: Tibor Digana Fix For: maven-verifier-1.6 Verifier used -e and -B by default. These CLI options violate my ITs in surefire and I need to fully control the CLI options in integration tests. Introduced new constructor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSHARED-418) Verifier should not use hard coded CLI options without possibility to modify them
[ https://issues.apache.org/jira/browse/MSHARED-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14571815#comment-14571815 ] Tibor Digana commented on MSHARED-418: -- https://github.com/apache/maven-shared/pull/9 Verifier should not use hard coded CLI options without possibility to modify them - Key: MSHARED-418 URL: https://issues.apache.org/jira/browse/MSHARED-418 Project: Maven Shared Components Issue Type: Bug Components: maven-verifier Affects Versions: maven-verifier-1.5 Reporter: Tibor Digana Assignee: Tibor Digana Fix For: maven-verifier-1.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MWAR-345) Resources from src/main/resources are not added to the current build overlay
[ https://issues.apache.org/jira/browse/MWAR-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14570523#comment-14570523 ] Karl Heinz Marbaise commented on MWAR-345: -- Can you check this with 2.5 for example if we have an regression or a general problem. Thanks in advance. Resources from src/main/resources are not added to the current build overlay Key: MWAR-345 URL: https://issues.apache.org/jira/browse/MWAR-345 Project: Maven WAR Plugin Issue Type: Bug Components: overlay Affects Versions: 2.6 Reporter: Andriy Sharandakov Resources from the default resource directory src/main/resources are copied to WEB-INF/classes, but they are not added to the implicit current build overlay and as the result are overwritten by the resource files from the applied overlays. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SCM-775) Add workItem and changeset associate support for scm deliver
[
https://issues.apache.org/jira/browse/SCM-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14570841#comment-14570841
]
Frank Brewer commented on SCM-775:
--
Chris-
I was looking for your updated maven-scm-provider-jazz (version 1.9.5) at
http://maven.org and could only find version 1.9.4. Is it possible that
version 1.9.5 is not available yet? If so, do you have an early-release copy
that you could share with me?
Thanks.
-Frank
Add workItem and changeset associate support for scm deliver
Key: SCM-775
URL: https://issues.apache.org/jira/browse/SCM-775
Project: Maven SCM
Issue Type: Improvement
Components: maven-scm-provider-jazz
Affects Versions: 1.9.1
Reporter: AShit Shah
Assignee: Chris Graham
Fix For: 1.9.5
Maven {{release:prepare}} command is failing with below error while
delivering updated pom.xml to the stream due to Preconditions configured in
RTC to have comments and associated work item with every delivery.
{noformat}
[ERROR] Name: Deliver
[ERROR] Participant Reports:
[ERROR] Name: Require Work items and Comments
[ERROR] A work item must be associated with the change set.`
[ERROR] At least one of the associated work items must specify that the work
is planned for the current iteration.
[ERROR] At least one of the associated work items must be assigned to you.
[ERROR] Problem running 'deliver':
[ERROR] 'Deliver' failed. Preconditions have not been met: A work item must
be associated with the change set.
[ERROR] - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-release-plugin:2.5:prepare (default-cli)
on project junit-ext: Unable to commit files
Provider message:
Error code for Jazz SCM deliver command - 17
{noformat}
I can not find any optional parameters on
http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html
for release:prepare command which I can use and pass the RTC workitem number
on command line.
Suggestion:
It will be great if you can provide optional parameters like workItem which
I can use and pass RTC workitem number with release:prepare at command line.
Example: {{mvn -PmyProfile release:prepare -DworkItem=123456}}
So build process should associate change sets created by {{release:prepare}}
with work item 123456 and deliver change sets to the stream.
As of now I have to use {{-DpushChanges=false}} parameter to block delivery
process and I have to manually find the change sets, associate them with work
item and deliver them before I run {{release:perform}}.
Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MSHARED-417) Infinite loop when loading self-referencing properties
[
https://issues.apache.org/jira/browse/MSHARED-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Milliken updated MSHARED-417:
--
Description:
I've recently encountered a situation in which maven-resources-plugin would
hang indefinitely when using resource filtering. I've managed to track it down
to the loadPropertyFile and getPropertyValue methods in PropertyUtils.
getPropertyValue appears to have some protection against a property referring
to itself. So, the following properties file loads fine:
{code}
test=${test}
test2=${test2}
{code}
With the value of the test property ending up as $\{test\}. However, if you
load the following properties file:
{code}
test=${test2}
test2=${test2}
{code}
then getPropertyValue seems to get stuck in a loop attempting to resolve the
property.
In our case, this was encountered as a result of a misconfiguration (our
filters.properties is being generated based on a number of sources, and
something was configured incorrectly). Causing the Maven process to hang
indefinitely (while using 100% of a CPU core) isn't ideal behaviour.
I have reproduced this in isolation by directly invoking
{{PropertyUtils.loadPropertyFile(File, null)}} with the the above data as the
input file.
was:
I've recently encountered a situation in which maven-resources-plugin would
hang indefinitely when using resource filtering. I've managed to track it down
to the loadPropertyFile and getPropertyValue methods in PropertyUtils.
getPropertyValue appears to have some protection against a property referring
to itself. So, the following properties file loads fine:
{code}
test=${test}
test2=${test2}
{code}
With the value of the test property ending up as $\{test\}. However, if you
load the following properties file:
{code}
test=${test2}
test2=${test2}
{code}
then getPropertyValue seems to get stuck in a loop attempting to resolve the
property.
In our case, this was encountered as a result of a misconfiguration (our
filters.properties is being generated based on a number of sources, and
something was configured incorrectly). Causing the Maven process to hang
indefinitely (while using 100% of a CPU core) isn't ideal behaviour.
Infinite loop when loading self-referencing properties
--
Key: MSHARED-417
URL: https://issues.apache.org/jira/browse/MSHARED-417
Project: Maven Shared Components
Issue Type: Bug
Components: maven-filtering
Affects Versions: maven-filtering-1.3
Environment: Maven 3.2.5. Maven-filtering-1.3.
Reporter: Paul Milliken
I've recently encountered a situation in which maven-resources-plugin would
hang indefinitely when using resource filtering. I've managed to track it
down to the loadPropertyFile and getPropertyValue methods in PropertyUtils.
getPropertyValue appears to have some protection against a property referring
to itself. So, the following properties file loads fine:
{code}
test=${test}
test2=${test2}
{code}
With the value of the test property ending up as $\{test\}. However, if
you load the following properties file:
{code}
test=${test2}
test2=${test2}
{code}
then getPropertyValue seems to get stuck in a loop attempting to resolve the
property.
In our case, this was encountered as a result of a misconfiguration (our
filters.properties is being generated based on a number of sources, and
something was configured incorrectly). Causing the Maven process to hang
indefinitely (while using 100% of a CPU core) isn't ideal behaviour.
I have reproduced this in isolation by directly invoking
{{PropertyUtils.loadPropertyFile(File, null)}} with the the above data as the
input file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MSHARED-417) Infinite loop when loading self-referencing properties
Paul Milliken created MSHARED-417:
-
Summary: Infinite loop when loading self-referencing properties
Key: MSHARED-417
URL: https://issues.apache.org/jira/browse/MSHARED-417
Project: Maven Shared Components
Issue Type: Bug
Components: maven-filtering
Affects Versions: maven-filtering-1.3
Environment: Maven 3.2.5. Maven-filtering-1.3.
Reporter: Paul Milliken
I've recently encountered a situation in which maven-resources-plugin would
hang indefinitely when using resource filtering. I've managed to track it down
to the loadPropertyFile and getPropertyValue methods in PropertyUtils.
getPropertyValue appears to have some protection against a property referring
to itself. So, the following properties file loads fine:
{code}
test=${test}
test2=${test2}
{code}
With the value of the test property ending up as ${test}. However, if you
load the following properties file:
{code}
test=${test2}
test2=${test2}
{code}
then getPropertyValue seems to get stuck in a loop attempting to resolve the
property.
In our case, this was encountered as a result of a misconfiguration (our
filters.properties is being generated based on a number of sources, and
something was configured incorrectly). Causing the Maven process to hang
indefinitely (while using 100% of a CPU core) isn't ideal behaviour.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MSHARED-417) Infinite loop when loading self-referencing properties
[
https://issues.apache.org/jira/browse/MSHARED-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Milliken updated MSHARED-417:
--
Description:
I've recently encountered a situation in which maven-resources-plugin would
hang indefinitely when using resource filtering. I've managed to track it down
to the loadPropertyFile and getPropertyValue methods in PropertyUtils.
getPropertyValue appears to have some protection against a property referring
to itself. So, the following properties file loads fine:
{code}
test=${test}
test2=${test2}
{code}
With the value of the test property ending up as $\{test\}. However, if you
load the following properties file:
{code}
test=${test2}
test2=${test2}
{code}
then getPropertyValue seems to get stuck in a loop attempting to resolve the
property.
In our case, this was encountered as a result of a misconfiguration (our
filters.properties is being generated based on a number of sources, and
something was configured incorrectly). Causing the Maven process to hang
indefinitely (while using 100% of a CPU core) isn't ideal behaviour.
was:
I've recently encountered a situation in which maven-resources-plugin would
hang indefinitely when using resource filtering. I've managed to track it down
to the loadPropertyFile and getPropertyValue methods in PropertyUtils.
getPropertyValue appears to have some protection against a property referring
to itself. So, the following properties file loads fine:
{code}
test=${test}
test2=${test2}
{code}
With the value of the test property ending up as ${test}. However, if you
load the following properties file:
{code}
test=${test2}
test2=${test2}
{code}
then getPropertyValue seems to get stuck in a loop attempting to resolve the
property.
In our case, this was encountered as a result of a misconfiguration (our
filters.properties is being generated based on a number of sources, and
something was configured incorrectly). Causing the Maven process to hang
indefinitely (while using 100% of a CPU core) isn't ideal behaviour.
Infinite loop when loading self-referencing properties
--
Key: MSHARED-417
URL: https://issues.apache.org/jira/browse/MSHARED-417
Project: Maven Shared Components
Issue Type: Bug
Components: maven-filtering
Affects Versions: maven-filtering-1.3
Environment: Maven 3.2.5. Maven-filtering-1.3.
Reporter: Paul Milliken
I've recently encountered a situation in which maven-resources-plugin would
hang indefinitely when using resource filtering. I've managed to track it
down to the loadPropertyFile and getPropertyValue methods in PropertyUtils.
getPropertyValue appears to have some protection against a property referring
to itself. So, the following properties file loads fine:
{code}
test=${test}
test2=${test2}
{code}
With the value of the test property ending up as $\{test\}. However, if
you load the following properties file:
{code}
test=${test2}
test2=${test2}
{code}
then getPropertyValue seems to get stuck in a loop attempting to resolve the
property.
In our case, this was encountered as a result of a misconfiguration (our
filters.properties is being generated based on a number of sources, and
something was configured incorrectly). Causing the Maven process to hang
indefinitely (while using 100% of a CPU core) isn't ideal behaviour.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SCM-775) Add workItem and changeset associate support for scm deliver
[
https://issues.apache.org/jira/browse/SCM-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14570963#comment-14570963
]
Eric B commented on SCM-775:
Hi Frank,
I've been working with Chris on 1.9.5 and is not released yet. It is still in
SNAPSHOT mode. You can get the code from github @
https://github.com/apache/maven-scm/tree/master.
Thanks
Eric
Add workItem and changeset associate support for scm deliver
Key: SCM-775
URL: https://issues.apache.org/jira/browse/SCM-775
Project: Maven SCM
Issue Type: Improvement
Components: maven-scm-provider-jazz
Affects Versions: 1.9.1
Reporter: AShit Shah
Assignee: Chris Graham
Fix For: 1.9.5
Maven {{release:prepare}} command is failing with below error while
delivering updated pom.xml to the stream due to Preconditions configured in
RTC to have comments and associated work item with every delivery.
{noformat}
[ERROR] Name: Deliver
[ERROR] Participant Reports:
[ERROR] Name: Require Work items and Comments
[ERROR] A work item must be associated with the change set.`
[ERROR] At least one of the associated work items must specify that the work
is planned for the current iteration.
[ERROR] At least one of the associated work items must be assigned to you.
[ERROR] Problem running 'deliver':
[ERROR] 'Deliver' failed. Preconditions have not been met: A work item must
be associated with the change set.
[ERROR] - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-release-plugin:2.5:prepare (default-cli)
on project junit-ext: Unable to commit files
Provider message:
Error code for Jazz SCM deliver command - 17
{noformat}
I can not find any optional parameters on
http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html
for release:prepare command which I can use and pass the RTC workitem number
on command line.
Suggestion:
It will be great if you can provide optional parameters like workItem which
I can use and pass RTC workitem number with release:prepare at command line.
Example: {{mvn -PmyProfile release:prepare -DworkItem=123456}}
So build process should associate change sets created by {{release:prepare}}
with work item 123456 and deliver change sets to the stream.
As of now I have to use {{-DpushChanges=false}} parameter to block delivery
process and I have to manually find the change sets, associate them with work
item and deliver them before I run {{release:perform}}.
Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPMD-171) Rule properties are ignored when run under MPMD
[
https://issues.apache.org/jira/browse/MPMD-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14571004#comment-14571004
]
Johannes Wienke commented on MPMD-171:
--
I am still experiencing this bug with the 3.4 release of MPMD. That release
should contain the fix?
Rule properties are ignored when run under MPMD
---
Key: MPMD-171
URL: https://issues.apache.org/jira/browse/MPMD-171
Project: Maven PMD Plugin
Issue Type: Bug
Components: PMD
Affects Versions: 3.0.1
Environment: Linux
Reporter: Johannes Wienke
Assignee: Michael Osipov
Fix For: 3.3, 3.4
For our project I have defined a custom ruleset for PMD in an XML file [1].
This ruleset defines properties for some of the standard PMD rules using this
syntax:
{noformat}
rule ref=rulesets/java/naming.xml/LongVariable
properties
property name=minimum value=25/
/properties
/rule
{noformat}
When I execute PMD using a parallel ant file we maintain, these custom
properties are respected correctly. However, when executing PMD through
maven, the properties are completely ignored.
The pom.xml we are using is available at [2].
[1]
https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/7e71d4d3e6d57c8529111a7f7143edeb48ddec59/entry/codecheck/pmd-rules.xml
[2]
https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/ff17c0dd008697f70dad27bd0319f4475ab87712/entry/pom.xml
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5805) Custom packaging types: configuring DefaultLifecycleMapping mojo executions
[
https://issues.apache.org/jira/browse/MNG-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14572150#comment-14572150
]
Hudson commented on MNG-5805:
-
SUCCESS: Integrated in maven-3.x #1081 (See
[https://builds.apache.org/job/maven-3.x/1081/])
MNG-5805: Custom packaging types: configuring DefaultLifecycleMapping mojo
executions (jason: rev d8ae13fd7b6be8a238a2b74f2b494668cd967c30)
* pom.xml
MNG-5805: Custom packaging types: configuring DefaultLifecycleMapping mojo
executions (jason: rev 1d148be82bcf3e16c01477d412f4f9206445a7aa)
*
maven-core/src/main/java/org/apache/maven/lifecycle/mapping/LifecyclePhase.java
* maven-core/src/main/java/org/apache/maven/lifecycle/mapping/Lifecycle.java
* maven-core/src/main/java/org/apache/maven/lifecycle/Lifecycle.java
*
maven-core/src/main/java/org/apache/maven/lifecycle/mapping/DefaultLifecycleMapping.java
* maven-core/src/main/java/org/apache/maven/lifecycle/mapping/LifecycleMojo.java
*
maven-core/src/main/java/org/apache/maven/lifecycle/mapping/LifecycleMapping.java
*
maven-core/src/main/java/org/apache/maven/lifecycle/internal/DefaultLifecyclePluginAnalyzer.java
Custom packaging types: configuring DefaultLifecycleMapping mojo executions
---
Key: MNG-5805
URL: https://issues.apache.org/jira/browse/MNG-5805
Project: Maven
Issue Type: Improvement
Components: Plugins and Lifecycle
Reporter: Anton Tanasenko
Assignee: Jason van Zyl
Priority: Minor
Fix For: 3.3.4
Currently, DefaultLifecycleMapping does not support mapping phases to goals
with a custom configuration (see
maven-core/src/main/resources/META-INF/plexus/default-bindings.xml). It is
impossible to bind, say, an assembly plugin to 'package' phase within a
custom packaging type, since assembly plugin requires a meaningful
configuration to be set.
At my job, we have a number of poms, each serving a purpose of defining a
lifecycle for a particular type of project (there's one for jar, a couple for
wars and several more for other types of deployable artifacts).
Now that I somewhat understand maven's lifecycle, It seems natural to convert
such poms to custom packaging types, leaving only a single parent with global
config and pluginManagement. But it is currently impossible, since we are
using mostly standard plugins (only occasional dedicated ones) to configure
projects' lifecycles.
I did some digging around and put together a relatively straightforward
change to maven-core:
https://github.com/apache/maven/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
It both introduces support for specifying configuration and dependencies for
mojo executions:
{code:xml}
install
mojos
mojo
goalorg.apache.maven.plugins:maven-install-plugin:2.4:install/goal
configuration.../configuration
dependencies.../dependencies
/mojo
mojo
...
/mojo
/mojos
/install
{code}
as well as retains support for existing mapping syntax:
{code:xml}
installorg.apache.maven.plugins:maven-install-plugin:2.4:install,
.../install
{code}
I will put together some its (as well as make sure that existing are running
ok) and create a pull request for both. Also, there are a couple of changes
that break API in org/apache/maven/lifecycle/Lifecycle.java and
org/apache/maven/lifecycle/mapping/Lifecycle.java. How critical is it to
mantain compatibility in those two?
ITS:
https://github.com/apache/maven-integration-testing/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5793) same class realm registered both with plugin and extensions realm caches
[ https://issues.apache.org/jira/browse/MNG-5793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14572149#comment-14572149 ] Hudson commented on MNG-5793: - SUCCESS: Integrated in maven-3.x #1081 (See [https://builds.apache.org/job/maven-3.x/1081/]) MNG-5793 do not register same realm both with plugin and extensions realm caches (ifedorenko: rev 9f50eabea54343fca522f42a2a41ffdb086e3240) * maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultMavenPluginManager.java same class realm registered both with plugin and extensions realm caches Key: MNG-5793 URL: https://issues.apache.org/jira/browse/MNG-5793 Project: Maven Issue Type: Bug Components: Class Loading, Embedding Affects Versions: 3.3.1 Reporter: Igor Fedorenko Assignee: igorfie Fix For: 3.3.3 This is a regression introduced by fix for MNG-5742. Although there is only one realm for plugins with extensions=true now, the realm is registered with both plugin realm and extensions realm caches. This make it impossible to properly dispose of unused realms when maven is embedded in a long-running application like m2e or maven shell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5783) cobertura-maven-plugin:instrument failing NoClassDefFoundError: org/slf4j/LoggerFactory
[
https://issues.apache.org/jira/browse/MNG-5783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14572157#comment-14572157
]
Hudson commented on MNG-5783:
-
SUCCESS: Integrated in maven-3.x #1081 (See
[https://builds.apache.org/job/maven-3.x/1081/])
MNG-5783 fixed slf4j is missing from ${plugin.artifacts} (ifedorenko: rev
b7088a34edd8cd34ab3b376d9baf90bdb6f8dc00)
*
maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginDependenciesResolver.java
*
maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java
cobertura-maven-plugin:instrument failing NoClassDefFoundError:
org/slf4j/LoggerFactory
---
Key: MNG-5783
URL: https://issues.apache.org/jira/browse/MNG-5783
Project: Maven
Issue Type: Bug
Affects Versions: 3.3.0
Reporter: Hervé Boutemy
Assignee: igorfie
Priority: Critical
Fix For: 3.3.1
Attachments: build-3.2.5.log, build-3.3.0-SNAPSHOT.log
testing cobertura-maven-plugin from svn
http://mojo.codehaus.org/cobertura-maven-plugin/
IT pass with Maven 3.2.5 but fail with 3.3.0-SNAPSHOT
(not the same issue as MNG-5779)
{noformat}[DEBUG] /bin/sh -c /opt/jdk1.7.0_71/jre/bin/java
-Dlog4j.configuration=file:/tmp/log4j1560920244563737852config.properties
-Xmx1024m net.sourceforge.cobertura.instrument.InstrumentMain --commandsfile
/tmp/cobertura.4914644993417176752.cmdline
[DEBUG] exit code: 1
[DEBUG]
[DEBUG] Standard error from the Cobertura task:
[DEBUG]
[ERROR] Exception in thread main java.lang.NoClassDefFoundError:
org/slf4j/LoggerFactory
at
net.sourceforge.cobertura.instrument.InstrumentMain$LoggerWrapper.init(InstrumentMain.java:165)
at
net.sourceforge.cobertura.instrument.InstrumentMain$LoggerWrapper.init(InstrumentMain.java:164)
at
net.sourceforge.cobertura.instrument.InstrumentMain.clinit(InstrumentMain.java:66)
Caused by: java.lang.ClassNotFoundException: org.slf4j.LoggerFactory
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 3 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5771) improved user-configurable core extensions mechanism
[
https://issues.apache.org/jira/browse/MNG-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14572155#comment-14572155
]
Hudson commented on MNG-5771:
-
SUCCESS: Integrated in maven-3.x #1081 (See
[https://builds.apache.org/job/maven-3.x/1081/])
[MNG-5771] added core extension reference (hboutemy: rev
08715d87d92b06aa2845250c0caee5b271cf37c2)
* maven-embedder/src/site/apt/index.apt.vm
improved user-configurable core extensions mechanism
Key: MNG-5771
URL: https://issues.apache.org/jira/browse/MNG-5771
Project: Maven
Issue Type: Improvement
Components: Class Loading
Reporter: Igor Fedorenko
Assignee: igorfie
Fix For: 3.3.1
As of version 3.2.5 maven provides two mechanisms to contribute additional
components to maven core runtime. It is possible to add component jars to
{{$M2_HOME/lib/ext directory}}. It is also possible to specify component jars
using {{-Dmaven.ext.class.path}} command line parameter. Neither of the
mechanisms is user friendly. In both cases, the user is expected to manually
locate and download all required jar file. In both cases, this has to be done
on all systems where the extensions are needed. In both cases, all extra jars
are loaded into single classloader so all extensions must agree of the same
set of dependencies.
This jira is to track changes needed to make it possible to configure core
extensions in terms of groupId/artifactId/version and share set of required
extensions across multiple systems.
More specifically,
* introduce new {{$\{maven.projectBasedir\}/.mvn/extensions.xml}} descriptor
to specify list of extensions. Initially, the descriptor will only allow
specification of extension groupId/artifactId/version, but can be extended to
support dependency includes/excludes mechanism and configuration parameters
later
{code:xml}
?xml version=1.0 encoding=UTF-8?
extensions
extension
groupId.../groupId
artifactId.../artifactId
version.../version
/extension
extension.../extension
...
/extensions
{code}
* change maven to read and load core extensions in separate class realms as
part of plexus container setup.
* provide mechanism for extensions to declare exported artifacts and packages
using {{META-INF/maven/extension.xml}} descriptor.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5767) project-specific default jvm options and command line parameters
[ https://issues.apache.org/jira/browse/MNG-5767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14572146#comment-14572146 ] Hudson commented on MNG-5767: - SUCCESS: Integrated in maven-3.x #1081 (See [https://builds.apache.org/job/maven-3.x/1081/]) [MNG-5767] added documentation for project-specific jvm options and (hboutemy: rev cb356ed478c5c42489b394720990a1696cb27b52) * maven-embedder/src/site/apt/index.apt.vm project-specific default jvm options and command line parameters Key: MNG-5767 URL: https://issues.apache.org/jira/browse/MNG-5767 Project: Maven Issue Type: Improvement Reporter: Igor Fedorenko Assignee: igorfie Fix For: 3.3.1 Some of the projects builds I work on require special jvm options, like minimal -Xmx value, and specific command line parameters, like --builder. Currently, I have to manually configure these every time run the build, which is rather annoying and error prone. This manual configuration also makes it harder for new or external developers to build the projects and many simply give up trying after mvn package does not work from the first try. This enhancement request proposes to introduce two new optional configuration files .mvn/jvm.config and .mvn/maven.config, located at the base directory of project source tree. If present, these files will provide default jvm and maven options. Because these files are part of the project source tree, they will be present in all project checkouts and will be automatically used every time the project is build. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5818) Disallow plugins from programmatically adding dependencies to projects
[ https://issues.apache.org/jira/browse/MNG-5818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14572147#comment-14572147 ] Hudson commented on MNG-5818: - SUCCESS: Integrated in maven-3.x #1081 (See [https://builds.apache.org/job/maven-3.x/1081/]) MNG-5818: Disallow the programmatic injection of project dependencies (jason: rev 4567c8319e95d58e258e9a8c2067ed9bbe01b58e) * maven-core/src/main/java/org/apache/maven/project/MavenProject.java Disallow plugins from programmatically adding dependencies to projects -- Key: MNG-5818 URL: https://issues.apache.org/jira/browse/MNG-5818 Project: Maven Issue Type: Task Reporter: Jason van Zyl Assignee: Jason van Zyl MavenProject.setDependencyArtifacts(deps) is publicly available to plugins that can alter the classpath non-declaratively. For compatibility reasons in MNG-4363 we restored this capability for the cobertura-maven-plugin but it needs to be removed. It causes some nasty logic in the core, but it being non-delclarative and magical is the real problem. We need to deprecate MavenProject.setDependencyArtifacts(deps), and replace the logic for constructing the artifacts in a better. Preferably passing in the artifacts in the constructor of MavenProject. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5797) 'mvn deploy' sends HTTP User-Agent twice
[
https://issues.apache.org/jira/browse/MNG-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14572154#comment-14572154
]
Hudson commented on MNG-5797:
-
SUCCESS: Integrated in maven-3.x #1081 (See
[https://builds.apache.org/job/maven-3.x/1081/])
MNG-5797: Check to see if the user agent header is set before trying to set it
again (jason: rev da98af988d373dbf82745530ceb2caaa1197dbc4)
*
maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultWagonManager.java
'mvn deploy' sends HTTP User-Agent twice
Key: MNG-5797
URL: https://issues.apache.org/jira/browse/MNG-5797
Project: Maven
Issue Type: Bug
Components: Deployment
Affects Versions: 3.2.1, 3.3.1
Environment: maven 3.2.1 or later (up to 3.3.1), Java 7, Windows 7 64
bit
Reporter: Jan Sievers
Assignee: Jason van Zyl
Fix For: 3.3.3
Attachments: userAgent.zip
This may be actually a wagon-http problem but I'm opening it here since maven
redistributes wagon-http.
Steps to reproduce:
Using maven 3.2.1 or later (i.e. wagon-http 2.6 or later):
# unzip attached userAgent.zip
# copy simplelogger.properties to $M2_HOME/conf/logging/ (as per
[instructions|https://support.sonatype.com/entries/23656571-Configuring-Maven-HTTP-Wagon-Detailed-Logging]
# export MAVEN_OPTS=$MAVEN_OPTS
-Djava.util.logging.config.file=$M2_HOME/conf/logging/simplelogger.properties
# using pom.xml from attached userAgent.zip:
{code}
mvn -V clean deploy
-DaltDeploymentRepository=id::default::HTTP_DEPLOYMENT_URL
{code}
you can see in the build log that HTTP header User-Agent is sent twice:
{code}
FINE: http-outgoing-0 User-Agent: Apache-Maven/3.2.1 (Java 1.7.0_67;
Windows 7 6.1)
Apr 02, 2015 1:34:52 PM
org.apache.maven.wagon.providers.http.httpclient.headers onRequestSubmitted
FINE: http-outgoing-0 User-Agent: Apache-Maven/3.2.1 (Java 1.7.0_67;
Windows 7 6.1)
Apr 02, 2015 1:34:52 PM
org.apache.maven.wagon.providers.http.httpclient.headers onRequestSubmitted
{code}
when using maven 3.1.1 or earlier, User-Agent is sent only once.
You could argue that HTTP headers are map keys and sending them twice with
the same value should not hurt. However, this causes an issue when deploying
to Sonatype Nexus.
Background: Nexus uses the value of User-Agent to disambiguate deployments
from multiple clients into separate staging repos. Nexus concatenates the two
values instead, effectively using value, value as staging repo key. Not
sure if this is a Nexus bug as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5774) Provide an extension point to provide alternate CLI configuration mechanism
[ https://issues.apache.org/jira/browse/MNG-5774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14572151#comment-14572151 ] Hudson commented on MNG-5774: - SUCCESS: Integrated in maven-3.x #1081 (See [https://builds.apache.org/job/maven-3.x/1081/]) MNG-5774 restored MavenCli user/global settings location contants (ifedorenko: rev cc429e84515a2f6bae05cd7cd81c3f622d0c8b57) * maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java Provide an extension point to provide alternate CLI configuration mechanism --- Key: MNG-5774 URL: https://issues.apache.org/jira/browse/MNG-5774 Project: Maven Issue Type: New Feature Reporter: Jason van Zyl Assignee: Jason van Zyl Fix For: 3.3.1 Currently the only way to configure an execution session is the settings.xml file mechanism. In essence the code currently works to read the settings.xml file(s) and stuffs a bunch of values in the MavenExecutionRequest. It should be possible to easily use different sources of values and use different logic to populate those values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5796) mvn fails when the current directory is a root drive on Windows
[ https://issues.apache.org/jira/browse/MNG-5796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14572156#comment-14572156 ] Hudson commented on MNG-5796: - SUCCESS: Integrated in maven-3.x #1081 (See [https://builds.apache.org/job/maven-3.x/1081/]) MNG-5796 fix mvn.cmd execution when invoked at drive root (agudian: rev f27c348bbaf51046029ce2853feeaf98700f1aca) * apache-maven/src/bin/mvn.cmd mvn fails when the current directory is a root drive on Windows --- Key: MNG-5796 URL: https://issues.apache.org/jira/browse/MNG-5796 Project: Maven Issue Type: Bug Components: Command Line Affects Versions: 3.3.1 Environment: Windows 7 Reporter: Brandon Enochs Assignee: Andreas Gudian Priority: Minor Fix For: 3.3.4 Executing mvn.cmd when the current directory is a drive root like C: outputs the help for the java command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MPIR-322) Dependencies Files Details should reuse installed jars instead of target/classes
[
https://issues.apache.org/jira/browse/MPIR-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14572148#comment-14572148
]
Hudson commented on MPIR-322:
-
SUCCESS: Integrated in maven-3.x #1081 (See
[https://builds.apache.org/job/maven-3.x/1081/])
upgraded MPIR plugin to benefit from MPIR-322 (hboutemy: rev
d8527aa9ce3938d20f49ff49dc3c32d744b22fa2)
* pom.xml
Dependencies Files Details should reuse installed jars instead of
target/classes
Key: MPIR-322
URL: https://issues.apache.org/jira/browse/MPIR-322
Project: Maven Project Info Reports Plugin
Issue Type: Improvement
Components: dependencies
Affects Versions: 2.7
Reporter: Hervé Boutemy
Assignee: Hervé Boutemy
Fix For: 2.8
Attachments: MPIR-322.zip
in general, site is generated in a mvn run separate from initial build:
{noformat}mvn install
mvn site{noformat}
what I expect is that the {{mvn site}} command reuse packaged artifacts from
{{mvn install}} (or even {{mvn package}})
but that's not what happens, and I can't tell it's a bug: AFAIK, there is no
feature in Maven for the site phase to reuse
the result is unfortunate in multi-module builds with dependencies inside the
reactor: Dependencies Files Details display {{xxx/target/classes}} instead of
{{xxx-version.jar}}
see real world example:
http://maven.apache.org/wagon-archives/wagon-2.8/wagon-providers/wagon-file/dependencies.html#Dependency_File_Details
{{wagon-provider-api/target/classes}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-5836) logging config is overwritten by $M2_HOME/lib/ext/*.jar
Igor Fedorenko created MNG-5836: --- Summary: logging config is overwritten by $M2_HOME/lib/ext/*.jar Key: MNG-5836 URL: https://issues.apache.org/jira/browse/MNG-5836 Project: Maven Issue Type: Bug Reporter: Igor Fedorenko If one of the jars in $M2_HOME/lib/ext/*.jar happens to have simplelogger.properties, that configuration file masks logging configuration under $M2_HOME/conf/logging -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MPMD-171) Rule properties are ignored when run under MPMD
[
https://issues.apache.org/jira/browse/MPMD-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14571356#comment-14571356
]
Andreas Dangel commented on MPMD-171:
-
How do you exactly generate the PMD report?
I just checked out rsb and have seen, that pmd is only configured in the
{{reporting}} section. This means, your custom ruleset should be used for the
maven site generation ({{mvn site}}).
If you want to run pmd manually, e.g. via {{mvn pmd:pmd}} then you'll need to
configure the pmd plugin additionally under {{build/plugins}}. I have done this
and I found two instances of LongVariable:
{code}
violation beginline=63 endline=63 begincolumn=33 endcolumn=61
rule=LongVariable ruleset=Naming package=rsb class=Factory
variable=INTROSPECTION_DISPLAYNAME_KEY
externalInfoUrl=http://pmd.sourceforge.net/snapshot/pmd-java/rules/java/naming.html#LongVariable;
priority=3
violation beginline=119 endline=119 begincolumn=21 endcolumn=46
rule=LongVariable ruleset=Naming package=rsb.util class=UUIDTools
method=setVersionAndVariant variable=clockSeqHiAndReservedByte8
externalInfoUrl=http://pmd.sourceforge.net/snapshot/pmd-java/rules/java/naming.html#LongVariable;
priority=3
{code}
Both are variable names indeed longer than 25 characters
(INTROSPECTION_DISPLAYNAME_KEY has 29 and clockSeqHiAndReservedByte8 has 26),
so this seems to be ok.
Can you give other examples, where the properties are ignored? Maybe there is
really another bug hidden somewhere in PMD...
Thanks!
Rule properties are ignored when run under MPMD
---
Key: MPMD-171
URL: https://issues.apache.org/jira/browse/MPMD-171
Project: Maven PMD Plugin
Issue Type: Bug
Components: PMD
Affects Versions: 3.0.1
Environment: Linux
Reporter: Johannes Wienke
Assignee: Michael Osipov
Fix For: 3.3, 3.4
For our project I have defined a custom ruleset for PMD in an XML file [1].
This ruleset defines properties for some of the standard PMD rules using this
syntax:
{noformat}
rule ref=rulesets/java/naming.xml/LongVariable
properties
property name=minimum value=25/
/properties
/rule
{noformat}
When I execute PMD using a parallel ant file we maintain, these custom
properties are respected correctly. However, when executing PMD through
maven, the properties are completely ignored.
The pom.xml we are using is available at [2].
[1]
https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/7e71d4d3e6d57c8529111a7f7143edeb48ddec59/entry/codecheck/pmd-rules.xml
[2]
https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/ff17c0dd008697f70dad27bd0319f4475ab87712/entry/pom.xml
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
