[jira] [Commented] (MNG-6069) Migrate to non deprecated parts of Commons CLI

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660571#comment-15660571
 ] 

Michael Osipov commented on MNG-6069:
-

Any reason not to add this to 3.4?

> Migrate to non deprecated parts of Commons CLI
> --
>
> Key: MNG-6069
> URL: https://issues.apache.org/jira/browse/MNG-6069
> Project: Maven
>  Issue Type: Improvement
>  Components: Embedding
>Affects Versions: 3.3.9
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.0
>
>
> At the moment all parts of {{OptionBuilder...}} are marked deprecated in 
> {{CLIManager}}. They should be migrated to:
> {code:java}
> Option.builder( HELP ).longOpt( "help" ).desc( "Display help information" 
> ).build()
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1301) baseDir system-property gets overridden by other builder threads if forking is disabled

[Tibor Digana (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660562#comment-15660562
 ] 

Tibor Digana commented on SUREFIRE-1301:


[~rraumberger]
Thx for the PR.
Have you tried to pass a value of ${project.basedir} in 
 ?
The key of sys prop is up to you.

> baseDir system-property gets overridden by other builder threads if forking 
> is disabled
> ---
>
> Key: SUREFIRE-1301
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1301
> Project: Maven Surefire
>  Issue Type: Documentation
>  Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Richard Raumberger
>Priority: Minor
>
> When running tests in a multi-module project with multiple builder threads 
> and surefire's forkCount set to 0, the threads override each other when 
> setting the baseDir system-property.
> Running the [sample 
> project|https://cloud.almost-a-blog.net/s/IHS63tBqowjhvBh/download] results 
> in the below output with the given commands.
> (Note: First number is the expected path. e.g. 11 => wrapper1; module1)
> *Correct*
> {code}
> mvn clean install | grep basedir
> 01 basedir=/maven-surefire-example/module1
> 02 basedir=/maven-surefire-example/module2
> 03 basedir=/maven-surefire-example/module3
> 11 basedir=/maven-surefire-example/wrapper1/module1
> 12 basedir=/maven-surefire-example/wrapper1/module2
> 13 basedir=/maven-surefire-example/wrapper1/module3
> 21 basedir=/maven-surefire-example/wrapper2/module1
> 22 basedir=/maven-surefire-example/wrapper2/module2
> 23 basedir=/maven-surefire-example/wrapper2/module3
> 31 basedir=/maven-surefire-example/wrapper3/module1
> 32 basedir=/maven-surefire-example/wrapper3/module2
> 33 basedir=/maven-surefire-example/wrapper3/module3
> {code}
> *Incorrect*
> {code}
> mvn clean install -T 3 | grep basedir
> 02 basedir=/maven-surefire-example/module2
> 01 basedir=/maven-surefire-example/module2
> 03 basedir=/maven-surefire-example/module2
> 13 basedir=/maven-surefire-example/wrapper1/module1
> 23 basedir=/maven-surefire-example/wrapper1/module1
> 11 basedir=/maven-surefire-example/wrapper1/module1
> 12 basedir=/maven-surefire-example/wrapper2/module2
> 21 basedir=/maven-surefire-example/wrapper2/module2
> 22 basedir=/maven-surefire-example/wrapper2/module2
> 32 basedir=/maven-surefire-example/wrapper3/module3
> 31 basedir=/maven-surefire-example/wrapper3/module3
> 33 basedir=/maven-surefire-example/wrapper3/module3
> {code}
> This is correct behaviour from a technical point of view as the 
> system-properties are shared between the threads and the surefire-executions 
> (due to the disabled forking), therefore I opened this issue mainly for 
> documentation purpose.
> This behaviour does not affect our current project anymore due to the removal 
> of the forkCount setting, yet I think that this behaviour should be 
> documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MRESOURCES-230) Can't escape the escape string

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MRESOURCES-230:
-
Fix Version/s: waiting-for-feedback

> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>Assignee: Christian Schulte
> Fix For: waiting-for-feedback
>
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MRESOURCES-230) Can't escape the escape string

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte reassigned MRESOURCES-230:


Assignee: Christian Schulte

> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>Assignee: Christian Schulte
> Fix For: waiting-for-feedback
>
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered

[Christian Schulte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660550#comment-15660550
 ] 

Christian Schulte commented on MRESOURCES-171:
--

The IDE I am using writes unicode escapes into the properties files. There is 
no way to disable that and IMHO it's the way to go. Doing it that way, no 
conversion takes place as it pretty much makes the properties files contain 
ASCII only. We maybe need to think about the filtering to use unicode escapes 
as well. For example: Having a non-ASCII project name the substituted 
$project.name should use unicode escapes. Maybe add a boolean 
{{unicodeEscapes}} parameter to the plugin and make the filtering produce those 
escapes.


> ISO8859-1 properties files get changed into UTF-8 when filtered
> ---
>
> Key: MRESOURCES-171
> URL: https://issues.apache.org/jira/browse/MRESOURCES-171
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: filtering
>Reporter: Alex Collins
>Priority: Minor
> Attachments: filtering-bug.zip
>
>
> Create:
> src/main/resources/test.properties
> And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u 
> formatting.
> When adding this line:
> src/main/resourcestrue
> Expected:
> ISO8859-1 encoded file in jar.
> Actual:
> UTF-8 encoded file in jar.
> ---
> If there are any property files (which can only be ISO8859-1) they appear to 
> be converted into UTF-8 in the jar.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MPH-105) Effective pom aggregation is not triggered

[JIRA]

 [ 
https://issues.apache.org/jira/browse/MPH-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Boué closed MPH-105.
--
   Resolution: Fixed
 Assignee: Guillaume Boué
Fix Version/s: (was: waiting-for-feedback)
   3.0.0

> Effective pom aggregation is not triggered
> --
>
> Key: MPH-105
> URL: https://issues.apache.org/jira/browse/MPH-105
> Project: Maven Help Plugin
>  Issue Type: Bug
>  Components: effective-pom
>Affects Versions: 2.2
> Environment: Maven 3.0.5
>Reporter: Wisen Tanasa
>Assignee: Guillaume Boué
> Fix For: 3.0.0
>
> Attachments: MPH-105.patch
>
>
> Patch attached and contains JUnit.
> The bug is happening when it hits this portion and `projects.get( 0 ).equals( 
> project )` is returning false. In my JUnit, this is happening when a sub 
> module's parent is not the aggregator pom.
> EffectivePomMojo.java#90:
> {code}
> if ( projects.get( 0 ).equals( project ) && projects.size() > 1 )
> {code}
> Is the first check really necessary?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (MRESOURCES-230) Can't escape the escape string

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MRESOURCES-230:
-
Comment: was deleted

(was: Could you please test the issue is fixed in the current 3.0.2-SNAPSHOT 
version.)

> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MRESOURCES-230) Can't escape the escape string

[Christian Schulte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660533#comment-15660533
 ] 

Christian Schulte commented on MRESOURCES-230:
--

Could you please test the issue is fixed in the current 3.0.2-SNAPSHOT version.

> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MRESOURCES-230) Can't escape the escape string

[Christian Schulte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660532#comment-15660532
 ] 

Christian Schulte commented on MRESOURCES-230:
--

Could you please test the issue is fixed in the current 3.0.2-SNAPSHOT version.

> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MPH-105) Effective pom aggregation is not triggered

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPH-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660512#comment-15660512
 ] 

Hudson commented on MPH-105:


SUCCESS: Integrated in Jenkins build maven-plugins #7626 (See 
[https://builds.apache.org/job/maven-plugins/7626/])
[MPH-105] Effective pom aggregation is not triggered

When the plugin is invoked from the command-line, always show all effective 
POMs for all projects in the reactor. When it is invoked from the lifecycle, 
only show all effective POMs for the head project in the reactor (see commit 
497785 and resolution of MPH-21); otherwise, show the effective POM for the 
current project only. (gboue: 
[http://svn.apache.org/viewvc/?view=rev=1769446])
* (add) maven-help-plugin/src/it/effective-pom-from-lifecycle
* (add) maven-help-plugin/src/it/effective-pom-from-lifecycle/module
* (add) maven-help-plugin/src/it/effective-pom-from-lifecycle/module/pom.xml
* (add) maven-help-plugin/src/it/effective-pom-from-lifecycle/pom.xml
* (add) maven-help-plugin/src/it/effective-pom-from-lifecycle/verify.groovy
* (add) maven-help-plugin/src/it/effective-pom-multimodule
* (add) maven-help-plugin/src/it/effective-pom-multimodule-unlink-parent
* (add) 
maven-help-plugin/src/it/effective-pom-multimodule-unlink-parent/invoker.properties
* (add) maven-help-plugin/src/it/effective-pom-multimodule-unlink-parent/module
* (add) 
maven-help-plugin/src/it/effective-pom-multimodule-unlink-parent/module/pom.xml
* (add) maven-help-plugin/src/it/effective-pom-multimodule-unlink-parent/pom.xml
* (add) 
maven-help-plugin/src/it/effective-pom-multimodule-unlink-parent/verify.groovy
* (add) maven-help-plugin/src/it/effective-pom-multimodule/invoker.properties
* (add) maven-help-plugin/src/it/effective-pom-multimodule/module
* (add) maven-help-plugin/src/it/effective-pom-multimodule/module/pom.xml
* (add) maven-help-plugin/src/it/effective-pom-multimodule/pom.xml
* (add) maven-help-plugin/src/it/effective-pom-multimodule/verify.groovy
* (edit) 
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/EffectivePomMojo.java


> Effective pom aggregation is not triggered
> --
>
> Key: MPH-105
> URL: https://issues.apache.org/jira/browse/MPH-105
> Project: Maven Help Plugin
>  Issue Type: Bug
>  Components: effective-pom
>Affects Versions: 2.2
> Environment: Maven 3.0.5
>Reporter: Wisen Tanasa
> Fix For: waiting-for-feedback
>
> Attachments: MPH-105.patch
>
>
> Patch attached and contains JUnit.
> The bug is happening when it hits this portion and `projects.get( 0 ).equals( 
> project )` is returning false. In my JUnit, this is happening when a sub 
> module's parent is not the aggregator pom.
> EffectivePomMojo.java#90:
> {code}
> if ( projects.get( 0 ).equals( project ) && projects.size() > 1 )
> {code}
> Is the first check really necessary?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MEAR-245) Upgrade of plexus-interpolation to 1.24.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MEAR-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660514#comment-15660514
 ] 

Hudson commented on MEAR-245:
-

SUCCESS: Integrated in Jenkins build maven-plugins #7626 (See 
[https://builds.apache.org/job/maven-plugins/7626/])
[MEAR-245] Upgrade of plexus-interpolation to 1.24. (schulte: 
[http://svn.apache.org/viewvc/?view=rev=1769441])
* (edit) maven-ear-plugin/pom.xml


> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MEAR-245
> URL: https://issues.apache.org/jira/browse/MEAR-245
> Project: Maven Ear Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MINVOKER-212) Upgrade of plexus-interpolation to 1.24.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINVOKER-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660522#comment-15660522
 ] 

Hudson commented on MINVOKER-212:
-

SUCCESS: Integrated in Jenkins build maven-plugins #7626 (See 
[https://builds.apache.org/job/maven-plugins/7626/])
[MINVOKER-212] Upgrade of plexus-interpolation to 1.24. (schulte: 
[http://svn.apache.org/viewvc/?view=rev=1769443])
* (edit) maven-invoker-plugin/pom.xml


> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MINVOKER-212
> URL: https://issues.apache.org/jira/browse/MINVOKER-212
> Project: Maven Invoker Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MPDF-79) Upgrade of plexus-interpolation to 1.24.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPDF-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660516#comment-15660516
 ] 

Hudson commented on MPDF-79:


SUCCESS: Integrated in Jenkins build maven-plugins #7626 (See 
[https://builds.apache.org/job/maven-plugins/7626/])
[MPDF-79] Upgrade of plexus-interpolation to 1.24. (schulte: 
[http://svn.apache.org/viewvc/?view=rev=1769444])
* (edit) maven-pdf-plugin/pom.xml


> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MPDF-79
> URL: https://issues.apache.org/jira/browse/MPDF-79
> Project: Maven PDF Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 1.4
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MRESOURCES-234) Upgrade of commons-io to 2.5 and correction of invalid scope.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOURCES-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660511#comment-15660511
 ] 

Hudson commented on MRESOURCES-234:
---

SUCCESS: Integrated in Jenkins build maven-plugins #7626 (See 
[https://builds.apache.org/job/maven-plugins/7626/])
[MRESOURCES-234] Upgrade of commons-io to 2.5 and correction of invalid scope. 
(schulte: [http://svn.apache.org/viewvc/?view=rev=1769451])
* (edit) maven-resources-plugin/pom.xml


> Upgrade of commons-io to 2.5 and correction of invalid scope.
> -
>
> Key: MRESOURCES-234
> URL: https://issues.apache.org/jira/browse/MRESOURCES-234
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: 3.0.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MACR-41) Upgrade of plexus-interpolation 1.24 to correct escaping issue.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MACR-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660515#comment-15660515
 ] 

Hudson commented on MACR-41:


SUCCESS: Integrated in Jenkins build maven-plugins #7626 (See 
[https://builds.apache.org/job/maven-plugins/7626/])
[MACR-41] Upgrade of plexus-interpolation 1.24 to correct escaping issue. 
(schulte: [http://svn.apache.org/viewvc/?view=rev=1769435])
* (edit) maven-acr-plugin/pom.xml


> Upgrade of plexus-interpolation 1.24 to correct escaping issue.
> ---
>
> Key: MACR-41
> URL: https://issues.apache.org/jira/browse/MACR-41
> Project: Maven ACR Plugin
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: 3.0.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MPH-21) Help;effective-pom: don't aggregrate when called from lifecycle

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPH-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660517#comment-15660517
 ] 

Hudson commented on MPH-21:
---

SUCCESS: Integrated in Jenkins build maven-plugins #7626 (See 
[https://builds.apache.org/job/maven-plugins/7626/])
[MPH-105] Effective pom aggregation is not triggered

When the plugin is invoked from the command-line, always show all effective 
POMs for all projects in the reactor. When it is invoked from the lifecycle, 
only show all effective POMs for the head project in the reactor (see commit 
497785 and resolution of MPH-21); otherwise, show the effective POM for the 
current project only. (gboue: 
[http://svn.apache.org/viewvc/?view=rev=1769446])
* (add) maven-help-plugin/src/it/effective-pom-from-lifecycle
* (add) maven-help-plugin/src/it/effective-pom-from-lifecycle/module
* (add) maven-help-plugin/src/it/effective-pom-from-lifecycle/module/pom.xml
* (add) maven-help-plugin/src/it/effective-pom-from-lifecycle/pom.xml
* (add) maven-help-plugin/src/it/effective-pom-from-lifecycle/verify.groovy
* (add) maven-help-plugin/src/it/effective-pom-multimodule
* (add) maven-help-plugin/src/it/effective-pom-multimodule-unlink-parent
* (add) 
maven-help-plugin/src/it/effective-pom-multimodule-unlink-parent/invoker.properties
* (add) maven-help-plugin/src/it/effective-pom-multimodule-unlink-parent/module
* (add) 
maven-help-plugin/src/it/effective-pom-multimodule-unlink-parent/module/pom.xml
* (add) maven-help-plugin/src/it/effective-pom-multimodule-unlink-parent/pom.xml
* (add) 
maven-help-plugin/src/it/effective-pom-multimodule-unlink-parent/verify.groovy
* (add) maven-help-plugin/src/it/effective-pom-multimodule/invoker.properties
* (add) maven-help-plugin/src/it/effective-pom-multimodule/module
* (add) maven-help-plugin/src/it/effective-pom-multimodule/module/pom.xml
* (add) maven-help-plugin/src/it/effective-pom-multimodule/pom.xml
* (add) maven-help-plugin/src/it/effective-pom-multimodule/verify.groovy
* (edit) 
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/EffectivePomMojo.java


> Help;effective-pom: don't aggregrate when called from lifecycle
> ---
>
> Key: MPH-21
> URL: https://issues.apache.org/jira/browse/MPH-21
> Project: Maven Help Plugin
>  Issue Type: Bug
>Affects Versions: 2.0.1
>Reporter: Kenney Westerhof
>Assignee: kenneyw
> Fix For: 2.0.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MRRESOURCES-99) Upgrade of plexus-interpolation to 1.24.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRRESOURCES-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660525#comment-15660525
 ] 

Hudson commented on MRRESOURCES-99:
---

SUCCESS: Integrated in Jenkins build maven-plugins #7626 (See 
[https://builds.apache.org/job/maven-plugins/7626/])
[MRRESOURCES-99] Upgrade of plexus-interpolation to 1.24. (schulte: 
[http://svn.apache.org/viewvc/?view=rev=1769448])
* (edit) maven-remote-resources-plugin/pom.xml


> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MRRESOURCES-99
> URL: https://issues.apache.org/jira/browse/MRRESOURCES-99
> Project: Maven Remote Resources Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 1.6
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MCHECKSTYLE-331) Upgrade of plexus-interpolation to 1.24.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MCHECKSTYLE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660518#comment-15660518
 ] 

Hudson commented on MCHECKSTYLE-331:


SUCCESS: Integrated in Jenkins build maven-plugins #7626 (See 
[https://builds.apache.org/job/maven-plugins/7626/])
[MCHECKSTYLE-331] Upgrade of plexus-interpolation to 1.24. (schulte: 
[http://svn.apache.org/viewvc/?view=rev=1769437])
* (edit) maven-checkstyle-plugin/pom.xml


> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MCHECKSTYLE-331
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-331
> Project: Maven Checkstyle Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 2.18
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MWAR-398) Upgrade of plexus-interpolation to 1.24 to correct escaping issue.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MWAR-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660524#comment-15660524
 ] 

Hudson commented on MWAR-398:
-

SUCCESS: Integrated in Jenkins build maven-plugins #7626 (See 
[https://builds.apache.org/job/maven-plugins/7626/])
[MWAR-398] Upgrade of plexus-interpolation to 1.24 to correct escaping issue. 
(schulte: [http://svn.apache.org/viewvc/?view=rev=1769450])
* (edit) maven-war-plugin/pom.xml


> Upgrade of plexus-interpolation to 1.24 to correct escaping issue.
> --
>
> Key: MWAR-398
> URL: https://issues.apache.org/jira/browse/MWAR-398
> Project: Maven WAR Plugin
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: 3.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MPIR-350) Upgrade of plexus-interpolation to 1.24.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPIR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660523#comment-15660523
 ] 

Hudson commented on MPIR-350:
-

SUCCESS: Integrated in Jenkins build maven-plugins #7626 (See 
[https://builds.apache.org/job/maven-plugins/7626/])
[MPIR-350] Upgrade of plexus-interpolation to 1.24. (schulte: 
[http://svn.apache.org/viewvc/?view=rev=1769445])
* (edit) maven-project-info-reports-plugin/pom.xml


> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MPIR-350
> URL: https://issues.apache.org/jira/browse/MPIR-350
> Project: Maven Project Info Reports Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 2.10
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MDEP-544) Upgrade of plexus-interpolation to 1.24.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660521#comment-15660521
 ] 

Hudson commented on MDEP-544:
-

SUCCESS: Integrated in Jenkins build maven-plugins #7626 (See 
[https://builds.apache.org/job/maven-plugins/7626/])
[MDEP-544] Upgrade of plexus-interpolation to 1.24. (schulte: 
[http://svn.apache.org/viewvc/?view=rev=1769438])
* (edit) maven-dependency-plugin/pom.xml


> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MDEP-544
> URL: https://issues.apache.org/jira/browse/MDEP-544
> Project: Maven Dependency Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MRESOURCES-233) Upgrade of plexus-interpolation 1.24 to correct escaping issue.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOURCES-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660513#comment-15660513
 ] 

Hudson commented on MRESOURCES-233:
---

SUCCESS: Integrated in Jenkins build maven-plugins #7626 (See 
[https://builds.apache.org/job/maven-plugins/7626/])
[MRESOURCES-233] Upgrade of plexus-interpolation 1.24 to correct escaping 
issue. (schulte: [http://svn.apache.org/viewvc/?view=rev=1769449])
* (edit) maven-resources-plugin/pom.xml


> Upgrade of plexus-interpolation 1.24 to correct escaping issue.
> ---
>
> Key: MRESOURCES-233
> URL: https://issues.apache.org/jira/browse/MRESOURCES-233
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: 3.0.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MEJB-107) Upgrade of plexus-interpolation to 1.24.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MEJB-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660526#comment-15660526
 ] 

Hudson commented on MEJB-107:
-

SUCCESS: Integrated in Jenkins build maven-plugins #7626 (See 
[https://builds.apache.org/job/maven-plugins/7626/])
[MEJB-107] Upgrade of plexus-interpolation to 1.24. (schulte: 
[http://svn.apache.org/viewvc/?view=rev=1769442])
* (edit) maven-ejb-plugin/pom.xml


> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MEJB-107
> URL: https://issues.apache.org/jira/browse/MEJB-107
> Project: Maven EJB Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MRAR-66) Upgrade of plexus-interpolation to 1.24.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRAR-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660519#comment-15660519
 ] 

Hudson commented on MRAR-66:


SUCCESS: Integrated in Jenkins build maven-plugins #7626 (See 
[https://builds.apache.org/job/maven-plugins/7626/])
[MRAR-66] Upgrade of plexus-interpolation to 1.24. (schulte: 
[http://svn.apache.org/viewvc/?view=rev=1769447])
* (edit) maven-rar-plugin/pom.xml


> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MRAR-66
> URL: https://issues.apache.org/jira/browse/MRAR-66
> Project: Maven Rar Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MCHANGES-377) Upgrade of plexus-interpolation to 1.24.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MCHANGES-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660520#comment-15660520
 ] 

Hudson commented on MCHANGES-377:
-

SUCCESS: Integrated in Jenkins build maven-plugins #7626 (See 
[https://builds.apache.org/job/maven-plugins/7626/])
[MCHANGES-377] Upgrade of plexus-interpolation to 1.24. (schulte: 
[http://svn.apache.org/viewvc/?view=rev=1769439])
* (edit) maven-changes-plugin/pom.xml


> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MCHANGES-377
> URL: https://issues.apache.org/jira/browse/MCHANGES-377
> Project: Maven Changes Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MDOAP-48) Upgrade of plexus-interpolation to 1.24.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDOAP-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660510#comment-15660510
 ] 

Hudson commented on MDOAP-48:
-

SUCCESS: Integrated in Jenkins build maven-plugins #7626 (See 
[https://builds.apache.org/job/maven-plugins/7626/])
[MDOAP-48] Upgrade of plexus-interpolation to 1.24. (schulte: 
[http://svn.apache.org/viewvc/?view=rev=1769440])
* (edit) maven-doap-plugin/pom.xml


> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MDOAP-48
> URL: https://issues.apache.org/jira/browse/MDOAP-48
> Project: Maven DOAP Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MNG-6115) Add Jansi native library search path to our start scripts

[Michael Osipov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-6115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MNG-6115:

Affects Version/s: 3.4.0

> Add Jansi native library search path to our start scripts
> -
>
> Key: MNG-6115
> URL: https://issues.apache.org/jira/browse/MNG-6115
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build, Command Line
>Affects Versions: 3.4.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.4.0
>
>
> By default Jansi extracts the native, shared library to temp which results in 
> unnecessary file I/O and a huge amount of temp files when Maven is run very 
> often. One can avoid that by adding 
> {{-Dlibrary.jansi.path=$\{MAVEN_HOME\}/lib}} to the start script. The user 
> has to copy the {{libjansi.so}} or {{jansi.dll}} once and will avoid the 
> overhead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MNG-6116) Document Jansi native library search path feature in install.md.vm

[Michael Osipov (JIRA)]

Michael Osipov created MNG-6116:
---

 Summary: Document Jansi native library search path feature in 
install.md.vm
 Key: MNG-6116
 URL: https://issues.apache.org/jira/browse/MNG-6116
 Project: Maven
  Issue Type: Sub-task
  Components: Documentation:  General
Affects Versions: 3.4.0
Reporter: Michael Osipov
Assignee: Michael Osipov
 Fix For: 3.4.0


By adding MNG-6115 people should actually know how to utilize the improvement. 
Document it in {{install.md.vm}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MNG-6115) Add Jansi native library search path to our start scripts

[Michael Osipov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-6115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MNG-6115:

Summary: Add Jansi native library search path to our start scripts  (was: 
Create Jansi native search path to our start scripts)

> Add Jansi native library search path to our start scripts
> -
>
> Key: MNG-6115
> URL: https://issues.apache.org/jira/browse/MNG-6115
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build, Command Line
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.4.0
>
>
> By default Jansi extracts the native, shared library to temp which results in 
> unnecessary file I/O and a huge amount of temp files when Maven is run very 
> often. One can avoid that by adding 
> {{-Dlibrary.jansi.path=$\{MAVEN_HOME\}/lib}} to the start script. The user 
> has to copy the {{libjansi.so}} or {{jansi.dll}} once and will avoid the 
> overhead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MRESOURCES-234) Upgrade of commons-io to 2.5 and correction of invalid scope.

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MRESOURCES-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MRESOURCES-234.

   Resolution: Fixed
Fix Version/s: 3.0.2

> Upgrade of commons-io to 2.5 and correction of invalid scope.
> -
>
> Key: MRESOURCES-234
> URL: https://issues.apache.org/jira/browse/MRESOURCES-234
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: 3.0.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MRESOURCES-234) Upgrade of commons-io to 2.5 and correction of invalid scope.

[Christian Schulte (JIRA)]

Christian Schulte created MRESOURCES-234:


 Summary: Upgrade of commons-io to 2.5 and correction of invalid 
scope.
 Key: MRESOURCES-234
 URL: https://issues.apache.org/jira/browse/MRESOURCES-234
 Project: Maven Resources Plugin
  Issue Type: Bug
Reporter: Christian Schulte
Assignee: Christian Schulte






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MNG-6115) Create Jansi native search path to our start scripts

[Michael Osipov (JIRA)]

Michael Osipov created MNG-6115:
---

 Summary: Create Jansi native search path to our start scripts
 Key: MNG-6115
 URL: https://issues.apache.org/jira/browse/MNG-6115
 Project: Maven
  Issue Type: Improvement
  Components: Bootstrap & Build, Command Line
Reporter: Michael Osipov
Assignee: Michael Osipov
 Fix For: 3.4.0


By default Jansi extracts the native, shared library to temp which results in 
unnecessary file I/O and a huge amount of temp files when Maven is run very 
often. One can avoid that by adding 
{{-Dlibrary.jansi.path=$\{MAVEN_HOME\}/lib}} to the start script. The user has 
to copy the {{libjansi.so}} or {{jansi.dll}} once and will avoid the overhead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MWAR-398) Upgrade of plexus-interpolation to 1.24 to correct escaping issue.

[Christian Schulte (JIRA)]

Christian Schulte created MWAR-398:
--

 Summary: Upgrade of plexus-interpolation to 1.24 to correct 
escaping issue.
 Key: MWAR-398
 URL: https://issues.apache.org/jira/browse/MWAR-398
 Project: Maven WAR Plugin
  Issue Type: Bug
Reporter: Christian Schulte
Assignee: Christian Schulte
 Fix For: 3.1.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MRESOURCES-233) Upgrade of plexus-interpolation 1.24 to correct escaping issue.

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MRESOURCES-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MRESOURCES-233.

Resolution: Fixed

> Upgrade of plexus-interpolation 1.24 to correct escaping issue.
> ---
>
> Key: MRESOURCES-233
> URL: https://issues.apache.org/jira/browse/MRESOURCES-233
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: 3.0.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MNG-5457) Show repository id when downloading or uploading from/to a remote repository

[Michael Osipov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-5457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MNG-5457:

Fix Version/s: (was: 3.x / Backlog)
   3.4.0

> Show repository id when downloading or uploading from/to a remote repository
> 
>
> Key: MNG-5457
> URL: https://issues.apache.org/jira/browse/MNG-5457
> Project: Maven
>  Issue Type: Improvement
>  Components: General
>Affects Versions: 3.0.5
>Reporter: Hervé Boutemy
>Assignee: Michael Osipov
> Fix For: 3.4.0
>
> Attachments: 2016-05-18_204749.png
>
>
> currently, the log only show the url being downloaded:
> {noformat}Downloading: 
> http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-plugins/23/maven-plugins-23.pom
> Downloaded: 
> http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-plugins/23/maven-plugins-23.pom
>  (9 KB at 98.7 KB/sec){noformat}
> nothing is told about the repository id.
> But as shown in MNG-5181, repository id is an important information since it 
> is stored in local repository to limit artifact scope: it would be useful 
> IMHO to display the id in the output, like 
> {noformat}Downloading from central: 
> http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-plugins/23/maven-plugins-23.pom
> Downloaded from central: 
> http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-plugins/23/maven-plugins-23.pom
>  (9 KB at 98.7 KB/sec){noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MNG-5896) Download dependency POMs in parallel

[Michael Osipov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MNG-5896:

Fix Version/s: 3.4.0

> Download dependency POMs in parallel
> 
>
> Key: MNG-5896
> URL: https://issues.apache.org/jira/browse/MNG-5896
> Project: Maven
>  Issue Type: Improvement
>  Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Harald Wellmann
>Assignee: Michael Osipov
> Fix For: 3.4.0
>
>
> h3. Background
> When building a project with dependencies not yet available in the local 
> repository, I noticed that Maven 3.3.3 first downloads the dependency POMs 
> _sequentially_ and then proceeds downloading the dependency JARs with up to 5 
> threads _in parallel_.
> Due to this, when first building a project with a large number of 
> dependencies, downloading a large number of small POMs may take a lot longer 
> than downloading the much larger JARs, or even longer than building the 
> project itself, especially when a repository manager is used which increases 
> the download latency.
> h3. Enhancement
> Download POMs of (transitive) dependencies in parallel to significantly speed 
> up initial builds of large projects.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MRESOURCES-233) Upgrade of plexus-interpolation 1.24 to correct escaping issue.

[Christian Schulte (JIRA)]

Christian Schulte created MRESOURCES-233:


 Summary: Upgrade of plexus-interpolation 1.24 to correct escaping 
issue.
 Key: MRESOURCES-233
 URL: https://issues.apache.org/jira/browse/MRESOURCES-233
 Project: Maven Resources Plugin
  Issue Type: Bug
Reporter: Christian Schulte
Assignee: Christian Schulte
 Fix For: 3.0.2






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MRRESOURCES-99) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MRRESOURCES-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MRRESOURCES-99.

Resolution: Fixed

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MRRESOURCES-99
> URL: https://issues.apache.org/jira/browse/MRRESOURCES-99
> Project: Maven Remote Resources Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 1.6
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MRRESOURCES-99) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

Christian Schulte created MRRESOURCES-99:


 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MRRESOURCES-99
 URL: https://issues.apache.org/jira/browse/MRRESOURCES-99
 Project: Maven Remote Resources Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
 Fix For: 1.6






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MPH-105) Effective pom aggregation is not triggered

[JIRA]

[ 
https://issues.apache.org/jira/browse/MPH-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660456#comment-15660456
 ] 

Guillaume Boué commented on MPH-105:


This check was added to take into account direct binding of the 
{{effective-pom}} goal, in the POM, during a phase of the lifecycle. In that 
case, it lists all effective POMs in the reactor only for the head project; for 
the other projects in the reactor, it will only list their effective-pom during 
the build.

Now that the plugin has been migrated to Maven 3, there is a good way to 
determine if the plugin was invoked from the command-line or not by looking at 
the source of the mojo execution. This behaviour needs to be kept only when the 
plugin is invoked from within a POM; on the command-line, all the effective 
POMs should be written.

Fixed in [r1769446|http://svn.apache.org/viewvc?rev=1769446=rev].

> Effective pom aggregation is not triggered
> --
>
> Key: MPH-105
> URL: https://issues.apache.org/jira/browse/MPH-105
> Project: Maven Help Plugin
>  Issue Type: Bug
>  Components: effective-pom
>Affects Versions: 2.2
> Environment: Maven 3.0.5
>Reporter: Wisen Tanasa
> Fix For: waiting-for-feedback
>
> Attachments: MPH-105.patch
>
>
> Patch attached and contains JUnit.
> The bug is happening when it hits this portion and `projects.get( 0 ).equals( 
> project )` is returning false. In my JUnit, this is happening when a sub 
> module's parent is not the aggregator pom.
> EffectivePomMojo.java#90:
> {code}
> if ( projects.get( 0 ).equals( project ) && projects.size() > 1 )
> {code}
> Is the first check really necessary?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MRAR-66) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MRAR-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MRAR-66.
-
   Resolution: Fixed
Fix Version/s: 3.0.0

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MRAR-66
> URL: https://issues.apache.org/jira/browse/MRAR-66
> Project: Maven Rar Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MRAR-66) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

Christian Schulte created MRAR-66:
-

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MRAR-66
 URL: https://issues.apache.org/jira/browse/MRAR-66
 Project: Maven Rar Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MPIR-350) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MPIR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MPIR-350.
--
Resolution: Fixed

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MPIR-350
> URL: https://issues.apache.org/jira/browse/MPIR-350
> Project: Maven Project Info Reports Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 2.10
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MPIR-350) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

Christian Schulte created MPIR-350:
--

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MPIR-350
 URL: https://issues.apache.org/jira/browse/MPIR-350
 Project: Maven Project Info Reports Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
 Fix For: 2.10






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MPDF-79) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MPDF-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MPDF-79.
-
Resolution: Fixed

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MPDF-79
> URL: https://issues.apache.org/jira/browse/MPDF-79
> Project: Maven PDF Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 1.4
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MPDF-79) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

Christian Schulte created MPDF-79:
-

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MPDF-79
 URL: https://issues.apache.org/jira/browse/MPDF-79
 Project: Maven PDF Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
 Fix For: 1.4






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MINVOKER-212) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MINVOKER-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MINVOKER-212.
--
Resolution: Fixed

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MINVOKER-212
> URL: https://issues.apache.org/jira/browse/MINVOKER-212
> Project: Maven Invoker Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MINVOKER-212) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

Christian Schulte created MINVOKER-212:
--

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MINVOKER-212
 URL: https://issues.apache.org/jira/browse/MINVOKER-212
 Project: Maven Invoker Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
 Fix For: 3.0.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MEJB-107) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MEJB-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MEJB-107.
--
Resolution: Fixed

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MEJB-107
> URL: https://issues.apache.org/jira/browse/MEJB-107
> Project: Maven EJB Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MEJB-107) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

Christian Schulte created MEJB-107:
--

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MEJB-107
 URL: https://issues.apache.org/jira/browse/MEJB-107
 Project: Maven EJB Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
 Fix For: 3.0.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MEAR-245) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MEAR-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MEAR-245.
--
Resolution: Fixed

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MEAR-245
> URL: https://issues.apache.org/jira/browse/MEAR-245
> Project: Maven Ear Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MEAR-245) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

Christian Schulte created MEAR-245:
--

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MEAR-245
 URL: https://issues.apache.org/jira/browse/MEAR-245
 Project: Maven Ear Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
 Fix For: 3.0.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MDOAP-48) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

Christian Schulte created MDOAP-48:
--

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MDOAP-48
 URL: https://issues.apache.org/jira/browse/MDOAP-48
 Project: Maven DOAP Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
 Fix For: 3.0.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MCHANGES-377) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MCHANGES-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MCHANGES-377.
--
Resolution: Fixed

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MCHANGES-377
> URL: https://issues.apache.org/jira/browse/MCHANGES-377
> Project: Maven Changes Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MCHANGES-377) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

Christian Schulte created MCHANGES-377:
--

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MCHANGES-377
 URL: https://issues.apache.org/jira/browse/MCHANGES-377
 Project: Maven Changes Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
 Fix For: 3.0.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MDEP-544) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MDEP-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MDEP-544.
--
Resolution: Fixed

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MDEP-544
> URL: https://issues.apache.org/jira/browse/MDEP-544
> Project: Maven Dependency Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MDEP-544) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

Christian Schulte created MDEP-544:
--

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MDEP-544
 URL: https://issues.apache.org/jira/browse/MDEP-544
 Project: Maven Dependency Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
 Fix For: 3.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MCHECKSTYLE-331) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MCHECKSTYLE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MCHECKSTYLE-331.
-
   Resolution: Fixed
Fix Version/s: 2.18

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MCHECKSTYLE-331
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-331
> Project: Maven Checkstyle Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 2.18
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MCHECKSTYLE-331) Upgrade of plexus-interpolation to 1.24.

[Christian Schulte (JIRA)]

Christian Schulte created MCHECKSTYLE-331:
-

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MCHECKSTYLE-331
 URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-331
 Project: Maven Checkstyle Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MACR-41) Upgrade of plexus-interpolation 1.24 to correct escaping issue.

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MACR-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MACR-41.
-
   Resolution: Fixed
Fix Version/s: 3.0.1

> Upgrade of plexus-interpolation 1.24 to correct escaping issue.
> ---
>
> Key: MACR-41
> URL: https://issues.apache.org/jira/browse/MACR-41
> Project: Maven ACR Plugin
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: 3.0.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MACR-41) Upgrade of plexus-interpolation 1.24 to correct escaping issue.

[Christian Schulte (JIRA)]

Christian Schulte created MACR-41:
-

 Summary: Upgrade of plexus-interpolation 1.24 to correct escaping 
issue.
 Key: MACR-41
 URL: https://issues.apache.org/jira/browse/MACR-41
 Project: Maven ACR Plugin
  Issue Type: Bug
Reporter: Christian Schulte
Assignee: Christian Schulte






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5805) Custom packaging types: configuring DefaultLifecycleMapping mojo executions

[Stuart McCulloch (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660390#comment-15660390
 ] 

Stuart McCulloch commented on MNG-5805:
---

note the MNG-5805 style of lifecycle configuration should go inside:
{code:xml}
  

  
foo
   
{code}
rather than:
{code:xml}
  

  
foo

{code}
There was a bug in Maven 3.3.9 where it also accepted MNG-5805 style 
configuration using {{}} but this broke backwards compatibility with 
plugins like flexmojos (see https://issues.apache.org/jira/browse/MNG-5958 for 
more details)

If you stick with {{}} then your MNG-5805 lifecycle 
configuration will work with 3.3.9 and 3.4.0+

An example of the new lifecycle configuration can be seen in 
https://github.com/apache/maven-integration-testing/blob/master/core-it-support/core-it-plugins/mng5805-extension/src/main/resources/META-INF/plexus/components.xml

> 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.9
>
>
> 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}
> 
>   
> 
>   org.apache.maven.plugins:maven-install-plugin:2.4:install
>   ...
>   ...
> 
> 
>   ...
> 
>   
> 
> {code}
> as well as retains support for existing mapping syntax:
> {code:xml}
> org.apache.maven.plugins:maven-install-plugin:2.4: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-5805) Custom packaging types: configuring DefaultLifecycleMapping mojo executions

[Mirko Friedenhagen (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660332#comment-15660332
 ] 

Mirko Friedenhagen commented on MNG-5805:
-

Hello I tried something like:
{code}




org.apache.maven.plugins:maven-resources-plugin:resources


@


false




{code}
for a custom spring-boot-jar type.
This works with  Maven 3.3.9 however breaks with a 3.4.0-SNAPSHOT.

> 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.9
>
>
> 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}
> 
>   
> 
>   org.apache.maven.plugins:maven-install-plugin:2.4:install
>   ...
>   ...
> 
> 
>   ...
> 
>   
> 
> {code}
> as well as retains support for existing mapping syntax:
> {code:xml}
> org.apache.maven.plugins:maven-install-plugin:2.4: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] (SUREFIRE-1301) baseDir system-property gets overridden by other builder threads if forking is disabled

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660296#comment-15660296
 ] 

ASF GitHub Bot commented on SUREFIRE-1301:
--

GitHub user rraumberger opened a pull request:

https://github.com/apache/maven-surefire/pull/131

[SUREFIRE-1301] add note for changing system properties when running 
parallel builds with disabled forking

Resolves 
[SUREFIRE-1301](https://issues.apache.org/jira/browse/SUREFIRE-1301).

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/rraumberger/maven-surefire master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-surefire/pull/131.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #131


commit 059bd029ccfc56a0d9370f9862d4feed5fc07448
Author: Richard Raumberger 
Date:   2016-11-12T21:06:23Z

[SUREFIRE-1301] add note for changing baseDir property




> baseDir system-property gets overridden by other builder threads if forking 
> is disabled
> ---
>
> Key: SUREFIRE-1301
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1301
> Project: Maven Surefire
>  Issue Type: Documentation
>  Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Richard Raumberger
>Priority: Minor
>
> When running tests in a multi-module project with multiple builder threads 
> and surefire's forkCount set to 0, the threads override each other when 
> setting the baseDir system-property.
> Running the [sample 
> project|https://cloud.almost-a-blog.net/s/IHS63tBqowjhvBh/download] results 
> in the below output with the given commands.
> (Note: First number is the expected path. e.g. 11 => wrapper1; module1)
> *Correct*
> {code}
> mvn clean install | grep basedir
> 01 basedir=/maven-surefire-example/module1
> 02 basedir=/maven-surefire-example/module2
> 03 basedir=/maven-surefire-example/module3
> 11 basedir=/maven-surefire-example/wrapper1/module1
> 12 basedir=/maven-surefire-example/wrapper1/module2
> 13 basedir=/maven-surefire-example/wrapper1/module3
> 21 basedir=/maven-surefire-example/wrapper2/module1
> 22 basedir=/maven-surefire-example/wrapper2/module2
> 23 basedir=/maven-surefire-example/wrapper2/module3
> 31 basedir=/maven-surefire-example/wrapper3/module1
> 32 basedir=/maven-surefire-example/wrapper3/module2
> 33 basedir=/maven-surefire-example/wrapper3/module3
> {code}
> *Incorrect*
> {code}
> mvn clean install -T 3 | grep basedir
> 02 basedir=/maven-surefire-example/module2
> 01 basedir=/maven-surefire-example/module2
> 03 basedir=/maven-surefire-example/module2
> 13 basedir=/maven-surefire-example/wrapper1/module1
> 23 basedir=/maven-surefire-example/wrapper1/module1
> 11 basedir=/maven-surefire-example/wrapper1/module1
> 12 basedir=/maven-surefire-example/wrapper2/module2
> 21 basedir=/maven-surefire-example/wrapper2/module2
> 22 basedir=/maven-surefire-example/wrapper2/module2
> 32 basedir=/maven-surefire-example/wrapper3/module3
> 31 basedir=/maven-surefire-example/wrapper3/module3
> 33 basedir=/maven-surefire-example/wrapper3/module3
> {code}
> This is correct behaviour from a technical point of view as the 
> system-properties are shared between the threads and the surefire-executions 
> (due to the disabled forking), therefore I opened this issue mainly for 
> documentation purpose.
> This behaviour does not affect our current project anymore due to the removal 
> of the forkCount setting, yet I think that this behaviour should be 
> documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6054) Removal of super pom plugin management.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660267#comment-15660267
 ] 

Hudson commented on MNG-6054:
-

SUCCESS: Integrated in Jenkins build maven-3.x #1411 (See 
[https://builds.apache.org/job/maven-3.x/1411/])
[MNG-6054] Removal of super pom plugin management. (schulte: rev 
a6f8bd1712a5ae30068424651bac35d2909dc4c1)
* (edit) 
maven-core/src/test/java/org/apache/maven/project/PomConstructionTest.java


> Removal of super pom plugin management.
> ---
>
> Key: MNG-6054
> URL: https://issues.apache.org/jira/browse/MNG-6054
> Project: Maven
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
>
> The super POM contains various plugins in the plugin management not part of 
> any default lifecycle. These should be removed from the super POM.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660265#comment-15660265
 ] 

Hudson commented on MNG-6114:
-

SUCCESS: Integrated in Jenkins build maven-3.x #1411 (See 
[https://builds.apache.org/job/maven-3.x/1411/])
[MNG-6114] Profiles from the global settings should be ordered before (schulte: 
rev c145eb5b219b89c306f9e4fa777e517ea87d8f27)
* (edit) 
maven-settings-builder/src/main/java/org/apache/maven/settings/merge/MavenSettingsMerger.java


> Elements from the global settings should be ordered before elements from the 
> user settings.
> ---
>
> Key: MNG-6114
> URL: https://issues.apache.org/jira/browse/MNG-6114
> Project: Maven
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6054) Removal of super pom plugin management.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660255#comment-15660255
 ] 

Hudson commented on MNG-6054:
-

SUCCESS: Integrated in Jenkins build maven-3.x Jigsaw #10 (See 
[https://builds.apache.org/job/maven-3.x%20Jigsaw/10/])
[MNG-6054] Removal of super pom plugin management. (schulte: rev 
a6f8bd1712a5ae30068424651bac35d2909dc4c1)
* (edit) 
maven-core/src/test/java/org/apache/maven/project/PomConstructionTest.java


> Removal of super pom plugin management.
> ---
>
> Key: MNG-6054
> URL: https://issues.apache.org/jira/browse/MNG-6054
> Project: Maven
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
>
> The super POM contains various plugins in the plugin management not part of 
> any default lifecycle. These should be removed from the super POM.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660253#comment-15660253
 ] 

Hudson commented on MNG-6114:
-

SUCCESS: Integrated in Jenkins build maven-3.x Jigsaw #10 (See 
[https://builds.apache.org/job/maven-3.x%20Jigsaw/10/])
[MNG-6114] Profiles from the global settings should be ordered before (schulte: 
rev c145eb5b219b89c306f9e4fa777e517ea87d8f27)
* (edit) 
maven-settings-builder/src/main/java/org/apache/maven/settings/merge/MavenSettingsMerger.java


> Elements from the global settings should be ordered before elements from the 
> user settings.
> ---
>
> Key: MNG-6114
> URL: https://issues.apache.org/jira/browse/MNG-6114
> Project: Maven
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings.

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MNG-6114:
---
Summary: Elements from the global settings should be ordered before 
elements from the user settings.  (was: Profiles from the global settings 
should be ordered before profiles from the user settings.)

> Elements from the global settings should be ordered before elements from the 
> user settings.
> ---
>
> Key: MNG-6114
> URL: https://issues.apache.org/jira/browse/MNG-6114
> Project: Maven
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MNG-6114) Profiles from the global settings should be ordered before profiles from the user settings.

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MNG-6114.
--
   Resolution: Fixed
Fix Version/s: 3.4.0

> Profiles from the global settings should be ordered before profiles from the 
> user settings.
> ---
>
> Key: MNG-6114
> URL: https://issues.apache.org/jira/browse/MNG-6114
> Project: Maven
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SUREFIRE-1301) baseDir system-property gets overridden by other builder threads if forking is disabled

[Tibor Digana (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana updated SUREFIRE-1301:
---
Issue Type: Documentation  (was: Bug)

> baseDir system-property gets overridden by other builder threads if forking 
> is disabled
> ---
>
> Key: SUREFIRE-1301
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1301
> Project: Maven Surefire
>  Issue Type: Documentation
>  Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Richard Raumberger
>Priority: Minor
>
> When running tests in a multi-module project with multiple builder threads 
> and surefire's forkCount set to 0, the threads override each other when 
> setting the baseDir system-property.
> Running the [sample 
> project|https://cloud.almost-a-blog.net/s/IHS63tBqowjhvBh/download] results 
> in the below output with the given commands.
> (Note: First number is the expected path. e.g. 11 => wrapper1; module1)
> *Correct*
> {code}
> mvn clean install | grep basedir
> 01 basedir=/maven-surefire-example/module1
> 02 basedir=/maven-surefire-example/module2
> 03 basedir=/maven-surefire-example/module3
> 11 basedir=/maven-surefire-example/wrapper1/module1
> 12 basedir=/maven-surefire-example/wrapper1/module2
> 13 basedir=/maven-surefire-example/wrapper1/module3
> 21 basedir=/maven-surefire-example/wrapper2/module1
> 22 basedir=/maven-surefire-example/wrapper2/module2
> 23 basedir=/maven-surefire-example/wrapper2/module3
> 31 basedir=/maven-surefire-example/wrapper3/module1
> 32 basedir=/maven-surefire-example/wrapper3/module2
> 33 basedir=/maven-surefire-example/wrapper3/module3
> {code}
> *Incorrect*
> {code}
> mvn clean install -T 3 | grep basedir
> 02 basedir=/maven-surefire-example/module2
> 01 basedir=/maven-surefire-example/module2
> 03 basedir=/maven-surefire-example/module2
> 13 basedir=/maven-surefire-example/wrapper1/module1
> 23 basedir=/maven-surefire-example/wrapper1/module1
> 11 basedir=/maven-surefire-example/wrapper1/module1
> 12 basedir=/maven-surefire-example/wrapper2/module2
> 21 basedir=/maven-surefire-example/wrapper2/module2
> 22 basedir=/maven-surefire-example/wrapper2/module2
> 32 basedir=/maven-surefire-example/wrapper3/module3
> 31 basedir=/maven-surefire-example/wrapper3/module3
> 33 basedir=/maven-surefire-example/wrapper3/module3
> {code}
> This is correct behaviour from a technical point of view as the 
> system-properties are shared between the threads and the surefire-executions 
> (due to the disabled forking), therefore I opened this issue mainly for 
> documentation purpose.
> This behaviour does not affect our current project anymore due to the removal 
> of the forkCount setting, yet I think that this behaviour should be 
> documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1301) baseDir system-property gets overridden by other builder threads if forking is disabled

[Tibor Digana (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660197#comment-15660197
 ] 

Tibor Digana commented on SUREFIRE-1301:


[~rraumberger]
You can open a pull request in GitHub and update project documentation:
https://github.com/apache/maven-surefire/blob/master/maven-surefire-plugin/src/site/apt/examples/fork-options-and-parallel-execution.apt.vm
and then I will release the documentation in Version 2.19.2.

> baseDir system-property gets overridden by other builder threads if forking 
> is disabled
> ---
>
> Key: SUREFIRE-1301
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1301
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Richard Raumberger
>Priority: Minor
>
> When running tests in a multi-module project with multiple builder threads 
> and surefire's forkCount set to 0, the threads override each other when 
> setting the baseDir system-property.
> Running the [sample 
> project|https://cloud.almost-a-blog.net/s/IHS63tBqowjhvBh/download] results 
> in the below output with the given commands.
> (Note: First number is the expected path. e.g. 11 => wrapper1; module1)
> *Correct*
> {code}
> mvn clean install | grep basedir
> 01 basedir=/maven-surefire-example/module1
> 02 basedir=/maven-surefire-example/module2
> 03 basedir=/maven-surefire-example/module3
> 11 basedir=/maven-surefire-example/wrapper1/module1
> 12 basedir=/maven-surefire-example/wrapper1/module2
> 13 basedir=/maven-surefire-example/wrapper1/module3
> 21 basedir=/maven-surefire-example/wrapper2/module1
> 22 basedir=/maven-surefire-example/wrapper2/module2
> 23 basedir=/maven-surefire-example/wrapper2/module3
> 31 basedir=/maven-surefire-example/wrapper3/module1
> 32 basedir=/maven-surefire-example/wrapper3/module2
> 33 basedir=/maven-surefire-example/wrapper3/module3
> {code}
> *Incorrect*
> {code}
> mvn clean install -T 3 | grep basedir
> 02 basedir=/maven-surefire-example/module2
> 01 basedir=/maven-surefire-example/module2
> 03 basedir=/maven-surefire-example/module2
> 13 basedir=/maven-surefire-example/wrapper1/module1
> 23 basedir=/maven-surefire-example/wrapper1/module1
> 11 basedir=/maven-surefire-example/wrapper1/module1
> 12 basedir=/maven-surefire-example/wrapper2/module2
> 21 basedir=/maven-surefire-example/wrapper2/module2
> 22 basedir=/maven-surefire-example/wrapper2/module2
> 32 basedir=/maven-surefire-example/wrapper3/module3
> 31 basedir=/maven-surefire-example/wrapper3/module3
> 33 basedir=/maven-surefire-example/wrapper3/module3
> {code}
> This is correct behaviour from a technical point of view as the 
> system-properties are shared between the threads and the surefire-executions 
> (due to the disabled forking), therefore I opened this issue mainly for 
> documentation purpose.
> This behaviour does not affect our current project anymore due to the removal 
> of the forkCount setting, yet I think that this behaviour should be 
> documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5940) Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660199#comment-15660199
 ] 

Hudson commented on MNG-5940:
-

UNSTABLE: Integrated in Jenkins build maven-3.x #1409 (See 
[https://builds.apache.org/job/maven-3.x/1409/])
[MNG-5940] Change the maven-source-plugin jar goal into jar-no-fork in 
(schulte: rev 8dab4440f0925ea4e4e0f7afe5fd28469b29257e)
* (edit) 
maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml


> Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM
> ---
>
> Key: MNG-5940
> URL: https://issues.apache.org/jira/browse/MNG-5940
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
>
> At the moment the {{maven-source-plugin:jar}} goal is defined in the Maven 
> super pom:
> {code:xml}
>   
> true
> maven-source-plugin
> 
>   
> attach-sources
> 
>   jar
> 
>   
> 
>   
> {code}
> where the goal of {{maven-source-plugin}} should be changed from {{jar}} into 
> {{jar-no-fork}}, cause most of the time you need to override this behaviour.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-2478) add "resources-filtered" filtered resource directories to super POM

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660193#comment-15660193
 ] 

Hudson commented on MNG-2478:
-

UNSTABLE: Integrated in Jenkins build maven-3.x #1409 (See 
[https://builds.apache.org/job/maven-3.x/1409/])
[MNG-2478] add "resources-filtered" filtered resource directories to (schulte: 
rev 33791993ae407eaabd075c407f93680f38b3b501)
* (edit) 
maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml


> add "resources-filtered" filtered resource directories to super POM
> ---
>
> Key: MNG-2478
> URL: https://issues.apache.org/jira/browse/MNG-2478
> Project: Maven
>  Issue Type: New Feature
>  Components: POM
>Affects Versions: 2.0.4
> Environment: any
>Reporter: Jörg Hohwiller
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>
> The super POM contains default folders for resources that are NOT filtered 
> (src/main/resources and src/test/resources). If one (additionally) needs a 
> filtered resources folder, it needs to override the default and therefore has 
> to add all default folders if he does NOT want to "loose" the defaults.
> To make this easier my suggestion is to add filtered resource folders to the 
> super POM. This should also fit to the philosophy of maven that aims to have 
> defaults and only declare as little custom configuration as needed.
> My personal favorite for the foldernames would be "templates" but to make 
> things more obvious to the user maybe "resources-filtered" would be better. 
> Actually I do not care to much about the name...
> So the resources in the super POM should look like this:
> {code:xml}
>   
> src/main/resources
>   
>   
>   
> src/main/resources-filtered
> true
>   
>   
> 
> 
>   
> src/test/resources
>   
>   
>   
> src/test/resources-filtered
> true
>   
>   
> {code}
> Update: The folder name has been changed to "resources-filtered".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6114) Profiles from the global settings should be ordered before profiles from the user settings.

[Christian Schulte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660194#comment-15660194
 ] 

Christian Schulte commented on MNG-6114:


See [this 
thread|http://mail-archives.apache.org/mod_mbox/maven-dev/201610.mbox/%3CCAK8jvqx5y987xjTNq4V-%2BYCQHP9xWeGNOMK5us%3Dp0m9OwYVSjg%40mail.gmail.com%3E]
 on dev@.


> Profiles from the global settings should be ordered before profiles from the 
> user settings.
> ---
>
> Key: MNG-6114
> URL: https://issues.apache.org/jira/browse/MNG-6114
> Project: Maven
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6054) Removal of super pom plugin management.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660196#comment-15660196
 ] 

Hudson commented on MNG-6054:
-

UNSTABLE: Integrated in Jenkins build maven-3.x #1409 (See 
[https://builds.apache.org/job/maven-3.x/1409/])
[MNG-6054] Removal of super pom plugin management. (schulte: rev 
6cca5643a82bdbe6545895a83bc3f16a0d3b4658)
* (edit) 
maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml


> Removal of super pom plugin management.
> ---
>
> Key: MNG-6054
> URL: https://issues.apache.org/jira/browse/MNG-6054
> Project: Maven
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
>
> The super POM contains various plugins in the plugin management not part of 
> any default lifecycle. These should be removed from the super POM.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MNG-6114) Profiles from the global settings should be ordered before profiles from the user settings.

[Christian Schulte (JIRA)]

Christian Schulte created MNG-6114:
--

 Summary: Profiles from the global settings should be ordered 
before profiles from the user settings.
 Key: MNG-6114
 URL: https://issues.apache.org/jira/browse/MNG-6114
 Project: Maven
  Issue Type: Bug
Reporter: Christian Schulte
Assignee: Christian Schulte






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5940) Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660176#comment-15660176
 ] 

Hudson commented on MNG-5940:
-

FAILURE: Integrated in Jenkins build maven-3.x Jigsaw #8 (See 
[https://builds.apache.org/job/maven-3.x%20Jigsaw/8/])
[MNG-5940] Change the maven-source-plugin jar goal into jar-no-fork in 
(schulte: rev 8dab4440f0925ea4e4e0f7afe5fd28469b29257e)
* (edit) 
maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml


> Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM
> ---
>
> Key: MNG-5940
> URL: https://issues.apache.org/jira/browse/MNG-5940
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
>
> At the moment the {{maven-source-plugin:jar}} goal is defined in the Maven 
> super pom:
> {code:xml}
>   
> true
> maven-source-plugin
> 
>   
> attach-sources
> 
>   jar
> 
>   
> 
>   
> {code}
> where the goal of {{maven-source-plugin}} should be changed from {{jar}} into 
> {{jar-no-fork}}, cause most of the time you need to override this behaviour.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6054) Removal of super pom plugin management.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660175#comment-15660175
 ] 

Hudson commented on MNG-6054:
-

FAILURE: Integrated in Jenkins build maven-3.x Jigsaw #8 (See 
[https://builds.apache.org/job/maven-3.x%20Jigsaw/8/])
[MNG-6054] Removal of super pom plugin management. (schulte: rev 
6cca5643a82bdbe6545895a83bc3f16a0d3b4658)
* (edit) 
maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml


> Removal of super pom plugin management.
> ---
>
> Key: MNG-6054
> URL: https://issues.apache.org/jira/browse/MNG-6054
> Project: Maven
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
>
> The super POM contains various plugins in the plugin management not part of 
> any default lifecycle. These should be removed from the super POM.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-2478) add "resources-filtered" filtered resource directories to super POM

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660173#comment-15660173
 ] 

Hudson commented on MNG-2478:
-

FAILURE: Integrated in Jenkins build maven-3.x Jigsaw #8 (See 
[https://builds.apache.org/job/maven-3.x%20Jigsaw/8/])
[MNG-2478] add "resources-filtered" filtered resource directories to (schulte: 
rev 33791993ae407eaabd075c407f93680f38b3b501)
* (edit) 
maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml


> add "resources-filtered" filtered resource directories to super POM
> ---
>
> Key: MNG-2478
> URL: https://issues.apache.org/jira/browse/MNG-2478
> Project: Maven
>  Issue Type: New Feature
>  Components: POM
>Affects Versions: 2.0.4
> Environment: any
>Reporter: Jörg Hohwiller
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>
> The super POM contains default folders for resources that are NOT filtered 
> (src/main/resources and src/test/resources). If one (additionally) needs a 
> filtered resources folder, it needs to override the default and therefore has 
> to add all default folders if he does NOT want to "loose" the defaults.
> To make this easier my suggestion is to add filtered resource folders to the 
> super POM. This should also fit to the philosophy of maven that aims to have 
> defaults and only declare as little custom configuration as needed.
> My personal favorite for the foldernames would be "templates" but to make 
> things more obvious to the user maybe "resources-filtered" would be better. 
> Actually I do not care to much about the name...
> So the resources in the super POM should look like this:
> {code:xml}
>   
> src/main/resources
>   
>   
>   
> src/main/resources-filtered
> true
>   
>   
> 
> 
>   
> src/test/resources
>   
>   
>   
> src/test/resources-filtered
> true
>   
>   
> {code}
> Update: The folder name has been changed to "resources-filtered".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (MNG-6082) Introduction of model version 4.1.0

[Michael Osipov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MNG-6082:

Comment: was deleted

(was: Alright, removed fix version then.)

> Introduction of model version 4.1.0
> ---
>
> Key: MNG-6082
> URL: https://issues.apache.org/jira/browse/MNG-6082
> Project: Maven
>  Issue Type: New Feature
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6082) Introduction of model version 4.1.0

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660145#comment-15660145
 ] 

Michael Osipov commented on MNG-6082:
-

Alright, removed fix version then.

> Introduction of model version 4.1.0
> ---
>
> Key: MNG-6082
> URL: https://issues.apache.org/jira/browse/MNG-6082
> Project: Maven
>  Issue Type: New Feature
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6082) Introduction of model version 4.1.0

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660146#comment-15660146
 ] 

Michael Osipov commented on MNG-6082:
-

Alright, removed fix version then.

> Introduction of model version 4.1.0
> ---
>
> Key: MNG-6082
> URL: https://issues.apache.org/jira/browse/MNG-6082
> Project: Maven
>  Issue Type: New Feature
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MNG-6082) Introduction of model version 4.1.0

[Michael Osipov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MNG-6082:

Fix Version/s: (was: 3.4.0)

> Introduction of model version 4.1.0
> ---
>
> Key: MNG-6082
> URL: https://issues.apache.org/jira/browse/MNG-6082
> Project: Maven
>  Issue Type: New Feature
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MNG-2478) add "resources-filtered" filtered resource directories to super POM

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MNG-2478.
--
   Resolution: Fixed
 Assignee: Christian Schulte
Fix Version/s: 3.4.0

Part of 3.4. See [this 
mail|http://mail-archives.apache.org/mod_mbox/maven-dev/201610.mbox/%3CCA%2BnPnMwwC7gpBe3u%2BsK8dPs5St3trAsgMXwUWvL7ksrj4tmqSQ%40mail.gmail.com%3E].

> add "resources-filtered" filtered resource directories to super POM
> ---
>
> Key: MNG-2478
> URL: https://issues.apache.org/jira/browse/MNG-2478
> Project: Maven
>  Issue Type: New Feature
>  Components: POM
>Affects Versions: 2.0.4
> Environment: any
>Reporter: Jörg Hohwiller
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>
> The super POM contains default folders for resources that are NOT filtered 
> (src/main/resources and src/test/resources). If one (additionally) needs a 
> filtered resources folder, it needs to override the default and therefore has 
> to add all default folders if he does NOT want to "loose" the defaults.
> To make this easier my suggestion is to add filtered resource folders to the 
> super POM. This should also fit to the philosophy of maven that aims to have 
> defaults and only declare as little custom configuration as needed.
> My personal favorite for the foldernames would be "templates" but to make 
> things more obvious to the user maybe "resources-filtered" would be better. 
> Actually I do not care to much about the name...
> So the resources in the super POM should look like this:
> {code:xml}
>   
> src/main/resources
>   
>   
>   
> src/main/resources-filtered
> true
>   
>   
> 
> 
>   
> src/test/resources
>   
>   
>   
> src/test/resources-filtered
> true
>   
>   
> {code}
> Update: The folder name has been changed to "resources-filtered".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MNG-5940) Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MNG-5940.
--
   Resolution: Fixed
 Assignee: Christian Schulte
Fix Version/s: 3.4.0

Part of 3.4. See [this 
mail|http://mail-archives.apache.org/mod_mbox/maven-dev/201610.mbox/%3CCA%2BnPnMwwC7gpBe3u%2BsK8dPs5St3trAsgMXwUWvL7ksrj4tmqSQ%40mail.gmail.com%3E].


> Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM
> ---
>
> Key: MNG-5940
> URL: https://issues.apache.org/jira/browse/MNG-5940
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
>
> At the moment the {{maven-source-plugin:jar}} goal is defined in the Maven 
> super pom:
> {code:xml}
>   
> true
> maven-source-plugin
> 
>   
> attach-sources
> 
>   jar
> 
>   
> 
>   
> {code}
> where the goal of {{maven-source-plugin}} should be changed from {{jar}} into 
> {{jar-no-fork}}, cause most of the time you need to override this behaviour.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MNG-6054) Removal of super pom plugin management.

[Christian Schulte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MNG-6054.
--
   Resolution: Fixed
 Assignee: Christian Schulte
Fix Version/s: 3.4.0

Part of 3.4. See [this 
mail|http://mail-archives.apache.org/mod_mbox/maven-dev/201610.mbox/%3CCA%2BnPnMwwC7gpBe3u%2BsK8dPs5St3trAsgMXwUWvL7ksrj4tmqSQ%40mail.gmail.com%3E].


> Removal of super pom plugin management.
> ---
>
> Key: MNG-6054
> URL: https://issues.apache.org/jira/browse/MNG-6054
> Project: Maven
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
>
> The super POM contains various plugins in the plugin management not part of 
> any default lifecycle. These should be removed from the super POM.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6082) Introduction of model version 4.1.0

[Christian Schulte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660123#comment-15660123
 ] 

Christian Schulte commented on MNG-6082:


It won't pass the release vote. See [this 
mail|http://mail-archives.apache.org/mod_mbox/maven-dev/201610.mbox/%3CCA%2BnPnMwCxMGwRf5fgspetRWj894hLcgFdFPT_P8TDbgoG_7xaA%40mail.gmail.com%3E]
 on dev@.


> Introduction of model version 4.1.0
> ---
>
> Key: MNG-6082
> URL: https://issues.apache.org/jira/browse/MNG-6082
> Project: Maven
>  Issue Type: New Feature
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
> Fix For: 3.4.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MPH-85) effective-pom should resolve properties in submodules

[JIRA]

 [ 
https://issues.apache.org/jira/browse/MPH-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Boué closed MPH-85.
-
Resolution: Not A Problem
  Assignee: Guillaume Boué

> effective-pom should resolve properties in submodules
> -
>
> Key: MPH-85
> URL: https://issues.apache.org/jira/browse/MPH-85
> Project: Maven Help Plugin
>  Issue Type: Improvement
>  Components: effective-pom
>Affects Versions: 2.1.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: Guillaume Boué
> Attachments: mfriedenhagen-multi-module-sample-6d3b71a.zip
>
>
> When defining the {{scm}} in the parent and referencing it in the
> module projects I would expect {{help:effective-pom}} to resolve these.
> Right now running {{{mvn clean install site site:stage}}} is resolving
> this IMO correctly as specified in {{source-repository.html}} 
> while in the the output of {{help:effective-pom}} leaves the properties alone.
> I have assembled a small multi-module project to show the effect.
> Run
> {code}
> mvn clean install site site:stage
> mvn help:effective-pom -Doutput=target/ep.xml
> {code}
> The original code may be seen at 
> https://github.com/mfriedenhagen/multi-module-sample/tree/help-effective-pom
> This is maybe somewhat related to MPIR-234.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MPH-120) Migrate plugin to Maven 3.0

[JIRA]

 [ 
https://issues.apache.org/jira/browse/MPH-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Boué closed MPH-120.
--
   Resolution: Fixed
 Assignee: Guillaume Boué
Fix Version/s: 3.0.0

> Migrate plugin to Maven 3.0
> ---
>
> Key: MPH-120
> URL: https://issues.apache.org/jira/browse/MPH-120
> Project: Maven Help Plugin
>  Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Robert Scholte
>Assignee: Guillaume Boué
> Fix For: 3.0.0
>
>
> Migrate plugin as described at 
> https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MPH-85) effective-pom should resolve properties in submodules

[JIRA]

[ 
https://issues.apache.org/jira/browse/MPH-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660052#comment-15660052
 ] 

Guillaume Boué commented on MPH-85:
---

During the construction of the effective POM, {{project.parent}} represents 
only the {{}} element of the POM, and not the complete parent project. 
So it is normal that the {{project.parent.scm}} tokens are not replaced in it.

On another hand, during late binding substitution for the plugin parameters of 
the {{ScmReport}} mojo, the tokens are correctly replaced and shown in the HTML 
site, which explains your output.

> effective-pom should resolve properties in submodules
> -
>
> Key: MPH-85
> URL: https://issues.apache.org/jira/browse/MPH-85
> Project: Maven Help Plugin
>  Issue Type: Improvement
>  Components: effective-pom
>Affects Versions: 2.1.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
> Attachments: mfriedenhagen-multi-module-sample-6d3b71a.zip
>
>
> When defining the {{scm}} in the parent and referencing it in the
> module projects I would expect {{help:effective-pom}} to resolve these.
> Right now running {{{mvn clean install site site:stage}}} is resolving
> this IMO correctly as specified in {{source-repository.html}} 
> while in the the output of {{help:effective-pom}} leaves the properties alone.
> I have assembled a small multi-module project to show the effect.
> Run
> {code}
> mvn clean install site site:stage
> mvn help:effective-pom -Doutput=target/ep.xml
> {code}
> The original code may be seen at 
> https://github.com/mfriedenhagen/multi-module-sample/tree/help-effective-pom
> This is maybe somewhat related to MPIR-234.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15659922#comment-15659922
 ] 

ASF GitHub Bot commented on MNG-5889:
-

Github user michael-o commented on the issue:

https://github.com/apache/maven/pull/94
  
I would rather see @rpatrick00 providing the IT. 


> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
> Fix For: 3.4.0
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15659915#comment-15659915
 ] 

ASF GitHub Bot commented on MNG-5889:
-

Github user Tibor17 commented on the issue:

https://github.com/apache/maven/pull/94
  
@michael-o 
I will merge it no problem. The only problem on IT is my spare time.


> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
> Fix For: 3.4.0
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1301) baseDir system-property gets overridden by other builder threads if forking is disabled

[Andreas Gudian (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15659903#comment-15659903
 ] 

Andreas Gudian commented on SUREFIRE-1301:
--

@[~tibor17], a missing note in the docs? ;-)

Obviously we can't provide the right baseDir property in a parallel build when 
not forking, as Richard described correctly already.
A good place for adding a note on that could be the forking/parallel page in 
the documentation.

Or were you looking for a way to somehow solve this?

> baseDir system-property gets overridden by other builder threads if forking 
> is disabled
> ---
>
> Key: SUREFIRE-1301
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1301
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Richard Raumberger
>Priority: Minor
>
> When running tests in a multi-module project with multiple builder threads 
> and surefire's forkCount set to 0, the threads override each other when 
> setting the baseDir system-property.
> Running the [sample 
> project|https://cloud.almost-a-blog.net/s/IHS63tBqowjhvBh/download] results 
> in the below output with the given commands.
> (Note: First number is the expected path. e.g. 11 => wrapper1; module1)
> *Correct*
> {code}
> mvn clean install | grep basedir
> 01 basedir=/maven-surefire-example/module1
> 02 basedir=/maven-surefire-example/module2
> 03 basedir=/maven-surefire-example/module3
> 11 basedir=/maven-surefire-example/wrapper1/module1
> 12 basedir=/maven-surefire-example/wrapper1/module2
> 13 basedir=/maven-surefire-example/wrapper1/module3
> 21 basedir=/maven-surefire-example/wrapper2/module1
> 22 basedir=/maven-surefire-example/wrapper2/module2
> 23 basedir=/maven-surefire-example/wrapper2/module3
> 31 basedir=/maven-surefire-example/wrapper3/module1
> 32 basedir=/maven-surefire-example/wrapper3/module2
> 33 basedir=/maven-surefire-example/wrapper3/module3
> {code}
> *Incorrect*
> {code}
> mvn clean install -T 3 | grep basedir
> 02 basedir=/maven-surefire-example/module2
> 01 basedir=/maven-surefire-example/module2
> 03 basedir=/maven-surefire-example/module2
> 13 basedir=/maven-surefire-example/wrapper1/module1
> 23 basedir=/maven-surefire-example/wrapper1/module1
> 11 basedir=/maven-surefire-example/wrapper1/module1
> 12 basedir=/maven-surefire-example/wrapper2/module2
> 21 basedir=/maven-surefire-example/wrapper2/module2
> 22 basedir=/maven-surefire-example/wrapper2/module2
> 32 basedir=/maven-surefire-example/wrapper3/module3
> 31 basedir=/maven-surefire-example/wrapper3/module3
> 33 basedir=/maven-surefire-example/wrapper3/module3
> {code}
> This is correct behaviour from a technical point of view as the 
> system-properties are shared between the threads and the surefire-executions 
> (due to the disabled forking), therefore I opened this issue mainly for 
> documentation purpose.
> This behaviour does not affect our current project anymore due to the removal 
> of the forkCount setting, yet I think that this behaviour should be 
> documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15659855#comment-15659855
 ] 

ASF GitHub Bot commented on MNG-5889:
-

Github user michael-o commented on the issue:

https://github.com/apache/maven/pull/94
  
I think this really deserves an IT too. The shell script is fine. Can't 
just on the command script, I am virtually illiterate here. I trust @rpatrick00 
 here. Willing to blindly to merge when the IT is ready.


> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
> Fix For: 3.4.0
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15659804#comment-15659804
 ] 

ASF GitHub Bot commented on MNG-5889:
-

Github user Tibor17 commented on the issue:

https://github.com/apache/maven/pull/94
  
@michael-o 
Any objections to merget this or do we need to test it with specific use 
case?


> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap & Build
>Affects Versions: 3.3.3
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
> Fix For: 3.4.0
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to 
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of 
> the POM selected by {{--file}} and then go through the parent directories.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MRELEASE-827) Passing "-pl" via arguments is not accepted

[Robert Scholte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15659566#comment-15659566
 ] 

Robert Scholte commented on MRELEASE-827:
-

At the moment I don't think we will or should support {{-pl}} for the reasons 
describes earlier. There are several options I'm thinking of:
- as developer, if you don't want to install an artifact, set their 
plugins skip-value to true.
- there seems to be a need for a (release-) aggregator, where you can define 
all modules which are part of the release. We're working on the pom-5.0.0 
model, where I think we should handle aggregators as special type of pom files 
and which should make it easier to do things like this.

> Passing "-pl" via arguments is not accepted
> ---
>
> Key: MRELEASE-827
> URL: https://issues.apache.org/jira/browse/MRELEASE-827
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: perform
>Affects Versions: 2.4
>Reporter: Konrad Windszus
>
> If I try to pass on a "-pl" to the forked Maven via arguments, I get the 
> following exception:
> Failed to re-parse additional arguments for Maven
> {noformat}
> Failed to execute goal 
> org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) on 
> project testproject: Failed to re-parse additional arguments for Maven 
> invocation.
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>   at 
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
>   at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
>   at hudson.maven.Maven3Builder.call(Maven3Builder.java:100)
>   at hudson.maven.Maven3Builder.call(Maven3Builder.java:66)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:118)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:48)
>   at hudson.remoting.Request$2.run(Request.java:326)
>   at 
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>   at java.lang.Thread.run(Thread.java:662)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to re-parse 
> additional arguments for Maven invocation.
>   at 
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:281)
>   at 
> org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:232)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>   ... 27 more
> Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Failed 
> to re-parse additional arguments for Maven invocation.
>   at 
> org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:89)
>   at 
> org.apache.maven.shared.release.phase.RunPrepareGoalsPhase.execute(RunPrepareGoalsPhase.java:44)
>   at 
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:234)
>   at 
> 

[jira] [Commented] (SUREFIRE-1300) threadCount is 0 when surefire-junit47 and surefire-testng are used together

[Julien Herr (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15659532#comment-15659532
 ] 

Julien Herr commented on SUREFIRE-1300:
---

{quote}
Therefore I have said that these tests do not use any annotations and config 
for parallel execution. That's the reason that maybe TestNG should not need to 
make a lookup of this parameter threadCount. WDYT?
{quote}

Yes, according to [the 
documentation|http://testng.org/doc/documentation-main.html#running-testng], 
the param value is supposed to be ignored at runtime: ??It will only take 
effect if the parallel mode has been selected (for example, with the -parallel 
option). This can be overridden in the suite definition.??
In our case, the passed value is wrong but we can imagine to be more smart with 
params like you say. We can discuss on current and future implementation on 
https://github.com/cbeust/testng/issues/1223
But even fixed, we can imagine having others different default values between 
junit and testng where we won't be able to fix them so "easily".

{quote}
Do you have min requirements of threadcount in TestNG documentation?
{quote}

The documentation is not so verbose but the code is: 
https://github.com/cbeust/testng/blob/master/src/main/java/org/testng/TestNG.java#L461
Surefire is using the old api with map and `threadcount` will be ignored with 
`null` value: 
https://github.com/cbeust/testng/blob/master/src/main/java/org/testng/TestNG.java#L1635
 / 
https://github.com/cbeust/testng/blob/master/src/main/java/org/testng/TestNG.java#L1497



> threadCount is 0 when surefire-junit47 and surefire-testng are used together
> 
>
> Key: SUREFIRE-1300
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1300
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.x support, TestNG support
>Reporter: Julien Herr
>Assignee: Tibor Digana
>Priority: Minor
>
> Initial discussion: 
> https://github.com/easymock/easymock/pull/186#discussion_r85655490
> Sample on: https://gist.github.com/juherr/6eb3e93e2db33979b7e90b63ddadc888
> Workaround: Force `1` in surefire configuration



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6082) Introduction of model version 4.1.0

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15659506#comment-15659506
 ] 

Michael Osipov commented on MNG-6082:
-

This won't happen in 3.4, will it?

> Introduction of model version 4.1.0
> ---
>
> Key: MNG-6082
> URL: https://issues.apache.org/jira/browse/MNG-6082
> Project: Maven
>  Issue Type: New Feature
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
> Fix For: 3.4.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SUREFIRE-1300) threadCount is 0 when surefire-junit47 and surefire-testng are used together

[Tibor Digana (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15659321#comment-15659321
 ] 

Tibor Digana edited comment on SUREFIRE-1300 at 11/12/16 9:03 AM:
--

When I launched the build of the sample I got:
{quote}
[INFO] parallel='none', perCoreThreadCount=true, threadCount=0,
{quote}
This is printed by MOJO class executed in Maven process which refers to 
parameters written in POM.
Therefore I have said that these tests do not use any annotations and config 
for parallel execution. That's the reason that maybe TestNG should not need to 
make a lookup of this parameter {{threadCount}}. WDYT?
Do you have such section in TestNG which makes a lookup of {{threadCount}} if 
{{parallel}} execution is detected? Other features maybe would make another 
lookup.


was (Author: tibor17):
When I launched the build of the sample I got:
{{parallel='none', perCoreThreadCount=true, threadCount=0, useUn }}
This is printed by MOJO class executed in Maven process which refers to 
parameters written in POM.
Therefore I have said that these tests do not use any annotations and config 
for parallel execution. That's the reason that maybe TestNG should not need to 
lookup this parameter {{threadCount}}. WDYT?
Do you have such section in TestNG which makes a lookup of {{threadCount}} if 
{{parallel}} execution is detected? Other features maybe would make another 
lookup.

> threadCount is 0 when surefire-junit47 and surefire-testng are used together
> 
>
> Key: SUREFIRE-1300
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1300
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.x support, TestNG support
>Reporter: Julien Herr
>Assignee: Tibor Digana
>Priority: Minor
>
> Initial discussion: 
> https://github.com/easymock/easymock/pull/186#discussion_r85655490
> Sample on: https://gist.github.com/juherr/6eb3e93e2db33979b7e90b63ddadc888
> Workaround: Force `1` in surefire configuration



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)