[jira] [Commented] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MNG-6112:
-

GitHub user ChristianSchulte opened a pull request:

https://github.com/apache/maven/pull/145

[MNG-6112] Central repository in the 4.0.0 super POM should declare u…

…pdate policy 'never'.

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

$ git pull https://github.com/ChristianSchulte/maven MNG-6112

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

https://github.com/apache/maven/pull/145.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 #145


commit a70406bb2cfe6ec14f717c53cebe8f23919aa0fc
Author: Christian Schulte 
Date:   2017-03-25T23:18:24Z

[MNG-6112] Central repository in the 4.0.0 super POM should declare update 
policy 'never'.




> Central repository in the 4.0.0 super POM should declare update policy 
> 'never'.
> ---
>
> Key: MNG-6112
> URL: https://issues.apache.org/jira/browse/MNG-6112
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.0-beta-1
>Reporter: Christian Schulte
> Fix For: 3.5.x-candidate
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-2893) Update the DefaultPluginManager to not use a project depMan for controlling it's transitive dependencies

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MNG-2893:
-

GitHub user ChristianSchulte opened a pull request:

https://github.com/apache/maven/pull/144

[MNG-2893] Update the DefaultPluginManager to not use a project depMa…

…n for controlling it's transitive dependencies

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

$ git pull https://github.com/ChristianSchulte/maven MNG-2893

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

https://github.com/apache/maven/pull/144.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 #144


commit 1de1ce1fdc50a8574a6b0e32ce4adc8389fcf73a
Author: Christian Schulte 
Date:   2017-03-25T22:01:03Z

[MNG-2893] Update the DefaultPluginManager to not use a project depMan for 
controlling it's transitive dependencies




> Update the DefaultPluginManager to not use a project depMan for controlling 
> it's transitive dependencies
> 
>
> Key: MNG-2893
> URL: https://issues.apache.org/jira/browse/MNG-2893
> Project: Maven
>  Issue Type: Task
>  Components: Plugins and Lifecycle
>Affects Versions: 2.0.5
>Reporter: Jason van Zyl
> Fix For: 3.2.x, 3.5.x-candidate
>
>
> An adjustment to MNG-1577. The classpath for plugins should not be affected 
> by a projects depMan.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-5359) Declared execution in PluginMgmt gets bound to lifecycle (regression)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MNG-5359:
-

GitHub user ChristianSchulte opened a pull request:

https://github.com/apache/maven/pull/143

[MNG-5359] Declared execution in PluginMgmt gets bound to lifecycle (…

…regression)

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

$ git pull https://github.com/ChristianSchulte/maven MNG-5359

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

https://github.com/apache/maven/pull/143.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 #143


commit 06d8d4533b3810cf767615e83f51ac43e4f474c0
Author: Christian Schulte 
Date:   2017-10-22T04:22:10Z

[MNG-5359] Declared execution in PluginMgmt gets bound to lifecycle 
(regression)




> Declared execution in PluginMgmt gets bound to lifecycle (regression)
> -
>
> Key: MNG-5359
> URL: https://issues.apache.org/jira/browse/MNG-5359
> Project: Maven
>  Issue Type: Bug
>  Components: Plugins and Lifecycle
>Affects Versions: 3.0.1, 3.0.2, 3.0.3, 3.0.4
> Environment: Mac OS 10.7.5, Apple JDK 1.6.0_35
> (Same behavior seen on Windows XP with Sun JDK 1.6.0 as well)
>Reporter: Anders Hammar
> Fix For: 3.5.x-candidate
>
> Attachments: MNG-5359-IT.patch, binding-test.zip
>
>
> If a plugin execution binding is declared in pluginManagement it gets bound 
> to the build lifecycle in Maven 3.0.x, but not with Maven 2.2.1.
> My understanding is that the behavior in Maven 3.0 is wrong; an execution 
> binding needs to be declared in build/plugins/plugin to be bound.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MNG-6114:
-

GitHub user ChristianSchulte opened a pull request:

https://github.com/apache/maven/pull/142

[MNG-6114] Profiles from the global settings should be ordered before…

… profiles from the user settings.

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

$ git pull https://github.com/ChristianSchulte/maven MNG-6114

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

https://github.com/apache/maven/pull/142.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 #142


commit 633af8e1d7a841f3829121ffda69e35f89775b3e
Author: Christian Schulte 
Date:   2016-11-12T20:06:19Z

[MNG-6114] 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
> Fix For: 3.5.x-candidate
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-6164) Collections inconsistently immutable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MNG-6164:
-

GitHub user ChristianSchulte opened a pull request:

https://github.com/apache/maven/pull/141

[MNG-6164] Collections inconsistently immutable.



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

$ git pull https://github.com/ChristianSchulte/maven MNG-6164

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

https://github.com/apache/maven/pull/141.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 #141


commit d08cb28d5353b1dc71ffd314b23c08a7fefec484
Author: Christian Schulte 
Date:   2015-12-14T03:57:47Z

[MNG-6164] Collections inconsistently immutable.




> Collections inconsistently immutable
> 
>
> Key: MNG-6164
> URL: https://issues.apache.org/jira/browse/MNG-6164
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.6.0-candidate
>
>
> There are plenty of places where empty collections are returned from public 
> API in methods written like:
> {code}
>  public List getExceptions()
>  {
> return exceptions == null ? Collections.emptyList() : 
> exceptions;
>  }
> {code}
> The issue with this is that the empty list is immutable but the collection 
> returned for the nun-null case is not immutable.
> All those methods should return a collection with consistent "mutability": 
> either mutable, either immutable.
> Given empty immutable collections do not cause harm until now, switching 
> consistently to immutable collections is more conservative and should not be 
> risky



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MCHECKSTYLE-346) Release a new version

[richard (JIRA)]

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

richard commented on MCHECKSTYLE-346:
-

As we have still not heard anything, we have started the process to break away 
from using maven-checkstyle-plugin in Checkstyle. Since it is the holiday 
season, we will wait until January before getting started. I suspect it may 
take us a month or so before we start incorporating serious backward breaking 
changes that will cause the plugin not to function with future versions of 
Checkstyle unless a new version of the maven plugin is released.

Here are some of the referenced issues:
https://github.com/checkstyle/contribution/issues/273
https://github.com/checkstyle/checkstyle/issues/5385
https://github.com/checkstyle/checkstyle/issues/5386
https://github.com/checkstyle/checkstyle/issues/2883

> Release a new version
> -
>
> Key: MCHECKSTYLE-346
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-346
> Project: Maven Checkstyle Plugin
>  Issue Type: Bug
>Affects Versions: 2.17
> Environment: All
>Reporter: richard
>Priority: Blocker
>
> Hello,
> Since my posts in another issue have gone unnoticed 
> (https://issues.apache.org/jira/browse/MCHECKSTYLE-332), I am creating this 
> one to bring it up front.
> The main checkstyle community have been waiting years for a 2.18 release for 
> fixes and functionality needed. As it is now, we cannot remove old deprecated 
> code from our utility as the plugin relies on them too much and breaks if 
> they are removed which forces us to continue supporting them just for you.
> See Issue: https://github.com/checkstyle/checkstyle/issues/2883
> The last release for maven checkstyle plugin was 2015, but you continue to 
> update the code base. Why is this? Is there something that prevents you from 
> creating a new release? Do you lack personnel of some kind? Is it possible to 
> give us a time table for a 2.18 release?
> If things continue as they are now, we may begin looking into breaking 
> compatibility with the plugin in newer versions as this project seems to have 
> run stagnant and is lacking support. If compatibility is broken, the current 
> plugin released will then only work with old and outdated versions. I, and I 
> am sure the community, don't wish to see this happen but the checkstyle 
> utility needs to keep evolving and remove outdated code.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MSCMPUB-35) add support for symbolic links

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSCMPUB-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16302917#comment-16302917
 ] 

Hudson commented on MSCMPUB-35:
---

Build succeeded in Jenkins: Maven TLP » maven-scm-publish-plugin » master #6

See 
https://builds.apache.org/job/maven-box/job/maven-scm-publish-plugin/job/master/6/

> add support for symbolic links
> --
>
> Key: MSCMPUB-35
> URL: https://issues.apache.org/jira/browse/MSCMPUB-35
> Project: Maven SCM Publish Plugin
>  Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Hervé Boutemy
>
> Maven site uses symbolic links to link from main site to components
> If we want to publish the site without SCM, we'll need to have a Jenkins job 
> to publish generated html to 
> https://svn.apache.org/repos/infra/websites/production/maven/content/
> then we'll need symbolic link support, which currently is failing
> {noformat}[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-scm-publish-plugin:1.2-SNAPSHOT:publish-scm 
> (default-cli) on project maven-scm-publish-plugin-002-publish-scm: Could not 
> copy content to SCM checkout: Source 
> '/home/herve/projets/maven/git/plugins/maven-scm-publish-plugin/target/it/002-publish-scm/target/site/link'
>  does not exist -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal 
> org.apache.maven.plugins:maven-scm-publish-plugin:1.2-SNAPSHOT:publish-scm 
> (default-cli) on project maven-scm-publish-plugin-002-publish-scm: Could not 
> copy content to SCM checkout
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:146)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:606)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main 
> (Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Could not copy 
> content to SCM checkout
> at 
> org.apache.maven.plugins.scmpublish.ScmPublishPublishScmMojo.scmPublishExecute
>  (ScmPublishPublishScmMojo.java:262)
> at org.apache.maven.plugins.scmpublish.AbstractScmPublishMojo.execute 
> (AbstractScmPublishMojo.java:579)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:146)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at 

[jira] [Created] (MSCMPUB-35) add support for symbolic links

[JIRA]

Hervé Boutemy created MSCMPUB-35:


 Summary: add support for symbolic links
 Key: MSCMPUB-35
 URL: https://issues.apache.org/jira/browse/MSCMPUB-35
 Project: Maven SCM Publish Plugin
  Issue Type: Improvement
Affects Versions: 1.1
Reporter: Hervé Boutemy


Maven site uses symbolic links to link from main site to components
If we want to publish the site without SCM, we'll need to have a Jenkins job to 
publish generated html to 
https://svn.apache.org/repos/infra/websites/production/maven/content/

then we'll need symbolic link support, which currently is failing

{noformat}[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-scm-publish-plugin:1.2-SNAPSHOT:publish-scm 
(default-cli) on project maven-scm-publish-plugin-002-publish-scm: Could not 
copy content to SCM checkout: Source 
'/home/herve/projets/maven/git/plugins/maven-scm-publish-plugin/target/it/002-publish-scm/target/site/link'
 does not exist -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-scm-publish-plugin:1.2-SNAPSHOT:publish-scm 
(default-cli) on project maven-scm-publish-plugin-002-publish-scm: Could not 
copy content to SCM checkout
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:213)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
 (SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Could not copy 
content to SCM checkout
at 
org.apache.maven.plugins.scmpublish.ScmPublishPublishScmMojo.scmPublishExecute 
(ScmPublishPublishScmMojo.java:262)
at org.apache.maven.plugins.scmpublish.AbstractScmPublishMojo.execute 
(AbstractScmPublishMojo.java:579)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
 (SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:606)
at 

[jira] [Created] (MSCMPUB-34) switch to Git

[JIRA]

Hervé Boutemy created MSCMPUB-34:


 Summary: switch to Git
 Key: MSCMPUB-34
 URL: https://issues.apache.org/jira/browse/MSCMPUB-34
 Project: Maven SCM Publish Plugin
  Issue Type: Task
Affects Versions: 1.1
Reporter: Hervé Boutemy
Assignee: Hervé Boutemy
 Fix For: 1.2


https://gitbox.apache.org/repos/asf?p=maven-scm-publish-plugin.git;a=commit;h=0a0f45f4dc5f97b397953924af4b818b33234e92



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (MSCMPUB-34) switch to Git

[JIRA]

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

Hervé Boutemy closed MSCMPUB-34.

Resolution: Fixed

> switch to Git
> -
>
> Key: MSCMPUB-34
> URL: https://issues.apache.org/jira/browse/MSCMPUB-34
> Project: Maven SCM Publish Plugin
>  Issue Type: Task
>Affects Versions: 1.1
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
> Fix For: 1.2
>
>
> https://gitbox.apache.org/repos/asf?p=maven-scm-publish-plugin.git;a=commit;h=0a0f45f4dc5f97b397953924af4b818b33234e92



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MSCMPUB-16) MavenProject/MavenSession Injection as a parameter instead as a component.

[JIRA]

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

Hervé Boutemy updated MSCMPUB-16:
-
Summary: MavenProject/MavenSession Injection as a parameter instead as a 
component.  (was: MavenProject/MavenSession Injection as a paremeter instead as 
a component.)

> MavenProject/MavenSession Injection as a parameter instead as a component.
> --
>
> Key: MSCMPUB-16
> URL: https://issues.apache.org/jira/browse/MSCMPUB-16
> Project: Maven SCM Publish Plugin
>  Issue Type: Improvement
>Affects Versions: 1.2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 1.2
>
>
> The following:
> {code:java}
> @Component
> protected MavenProject project;
> {code}
> has to be replaced by the following:
> {code:java}
> @Parameter( defaultValue = "${project}", readonly = true, required = true )
> protected MavenProject project;
> {code}
> The following:
> {code:java}
> @Component
> protected MavenSession session;
> {code}
> has to be replaced by the following:
> {code:java}
> @Parameter( defaultValue = "${session}", readonly = true, required = true )
> protected MavenSession session;
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user mpkorstanje commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
>  The build passed successfully. I will refactor little details, I will 
squash our commits and then I will push it to master.

Cheers.

> I could not find a documentation for configuring annotation

I've changed the layout of the project to match the default used by 
cucumber. When using the default layout  `@CucumberOptions` is not needed. 
Cucumber uses the location of the runner class to figure out where the features 
and glue are. 

All in all  `@CucumberOptions` influences which features are included but 
doesn't change how cucumber presents itself to surefire. From surefires 
perspective it should be yet another junit test suite. 

> One more question I have is regarding artifacts of Cucumber. Which one is 
right to use:

`cucumber-junit` provides integration with junit and should be used when 
junit is to be used. `cucumber-java` provides java annotations to denote step 
definitions. `cucumber-java8` depends on `cucumber-java` and adds lambda based 
step  definitions. Using `cucumber-java` is sufficient.


> Rerunning failing tests fails in combination with 
> Description#createSuiteDescription
> 
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
> Fix For: 2.21.1
>
>
> When using surefire to rerun failing tests created by a Runner that uses 
> {noformat}Description#createSuiteDescription{noformat} with a human readable 
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
> test class 'Scenario: Fail when running'
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] maven-surefire issue #150: SUREFIRE-1372 Filter tests to be rerun by descrip...

[mpkorstanje]

Github user mpkorstanje commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
>  The build passed successfully. I will refactor little details, I will 
squash our commits and then I will push it to master.

Cheers.

> I could not find a documentation for configuring annotation

I've changed the layout of the project to match the default used by 
cucumber. When using the default layout  `@CucumberOptions` is not needed. 
Cucumber uses the location of the runner class to figure out where the features 
and glue are. 

All in all  `@CucumberOptions` influences which features are included but 
doesn't change how cucumber presents itself to surefire. From surefires 
perspective it should be yet another junit test suite. 

> One more question I have is regarding artifacts of Cucumber. Which one is 
right to use:

`cucumber-junit` provides integration with junit and should be used when 
junit is to be used. `cucumber-java` provides java annotations to denote step 
definitions. `cucumber-java8` depends on `cucumber-java` and adds lambda based 
step  definitions. Using `cucumber-java` is sufficient.


---

[jira] [Commented] (MINVOKER-191) “Artifact is not fully assembled” error with maven-invoker-plugin in parallel build

[Hudson (JIRA)]

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

Hudson commented on MINVOKER-191:
-

SUCCESS: Integrated in Jenkins build Axis2 #3856 (See 
[https://builds.apache.org/job/Axis2/3856/])
Work around MINVOKER-191. (veithen: rev 1819211)
* (edit) axis2/modules/tool/axis2-aar-maven-plugin/pom.xml
* (edit) axis2/modules/tool/axis2-java2wsdl-maven-plugin/pom.xml
* (edit) axis2/modules/tool/axis2-repo-maven-plugin/pom.xml
* (edit) axis2/modules/tool/axis2-wsdl2code-maven-plugin/pom.xml


> “Artifact is not fully assembled” error with maven-invoker-plugin in parallel 
> build
> ---
>
> Key: MINVOKER-191
> URL: https://issues.apache.org/jira/browse/MINVOKER-191
> Project: Maven Invoker Plugin
>  Issue Type: Bug
>Affects Versions: 1.10
>Reporter: Tavian Barnes
>Assignee: Robert Scholte
>
> According to the docs 
> (https://maven.apache.org/plugins/maven-invoker-plugin/install-mojo.html), 
> maven-invoker-plugin is "thread-safe and supports parallel builds." However, 
> when I build by multi-module project with -T 1C, I get an error like the 
> following:
> bq. [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-invoker-plugin:1.10:install (integration-test) 
> on project my-archetype: Failed to install project dependencies: 
> MavenProject: com.tavianator:my-archetype:1.6-SNAPSHOT @ 
> /home/tavianator/code/Project/my-archetype/pom.xml: Failed to install project 
> artifacts: MavenProject: com.tavianator:my-project-2:1.6-SNAPSHOT @ 
> /home/tavianator/code/Project/my-project-2/pom.xml: Failed to install 
> artifact: com.tavianator:my-project-2:jar:1.6-SNAPSHOT: Artifact is not fully 
> assembled: /home/tavianator/code/Project/my-project-2/target/classes -> [Help 
> 1]
> The project layout is like this:
> {code}
> Root
> |--Project 1
> |--Project 2
> |--Archetype (depends on Project 1, scope=test)
> {code}
> The archetype integration tests use the maven-invoker-plugin to install the 
> relevant dependencies (Root and Project 1) to a local repository, then runs 
> the normal archetype integration tests. In parallel builds, Archetype and 
> Project 2 run at the same time. When the maven-invoker-plugin runs, it tries 
> to install Project 2 to the local repo, but Project 2 isn't built yet, hence 
> the error.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNGSITE-310) general recommendation for the element order in the POM

[Stephane Nicoll (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16302824#comment-16302824
 ] 

Stephane Nicoll commented on MNGSITE-310:
-

Alright, thanks for the suggestion!

> general recommendation for the element order in the POM
> ---
>
> Key: MNGSITE-310
> URL: https://issues.apache.org/jira/browse/MNGSITE-310
> Project: Maven Project Web Site
>  Issue Type: Improvement
>Reporter: Franz van Betteraey
>Priority: Minor
>  Labels: convention, pom
>
> A 
> [convention|https://maven.apache.org/developers/conventions/code.html#POM_Code_Convention]
>  for the element order in POM files is recommended for Maven developer and 
> contributor but not for the general usage of Maven. I think it would be 
> useful to recommend the element order also for general usage. A common order 
> would
> * give an answer to the question of the order for all who ask themselves this 
> question
> * help to easily cope with the content of pom files (even in unknown projects)
> A good place for the recommendation would be the [Maven 
> conventions|https://maven.apache.org/maven-conventions.html] or [POM 
> reference |https://maven.apache.org/pom.html] document.
> The background for this request is a discussion on twitter:
> https://twitter.com/FrVaBe/status/870263530473369601
> https://twitter.com/snicoll/status/874231018957545472
> A possible argument against such a convention would probably be, that 
> projects that used another element order would be suddenly considered as 
> "wrong" ordered.
> But I think that everyone that wondered about how to order the elements has 
> probably found the developer conventions and used theses as an appropriate 
> convention. There are even tools to check this convention 
> ([SonarQube|https://jira.sonarsource.com/browse/RSPEC-3423]) and to support 
> this convention ([Tidy Maven 
> plugin|http://www.mojohaus.org/tidy-maven-plugin/]). The Convention is thus 
> already established.
>   



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (MNGSITE-310) general recommendation for the element order in the POM

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll closed MNGSITE-310.
---
Resolution: Won't Fix

> general recommendation for the element order in the POM
> ---
>
> Key: MNGSITE-310
> URL: https://issues.apache.org/jira/browse/MNGSITE-310
> Project: Maven Project Web Site
>  Issue Type: Improvement
>Reporter: Franz van Betteraey
>Priority: Minor
>  Labels: convention, pom
>
> A 
> [convention|https://maven.apache.org/developers/conventions/code.html#POM_Code_Convention]
>  for the element order in POM files is recommended for Maven developer and 
> contributor but not for the general usage of Maven. I think it would be 
> useful to recommend the element order also for general usage. A common order 
> would
> * give an answer to the question of the order for all who ask themselves this 
> question
> * help to easily cope with the content of pom files (even in unknown projects)
> A good place for the recommendation would be the [Maven 
> conventions|https://maven.apache.org/maven-conventions.html] or [POM 
> reference |https://maven.apache.org/pom.html] document.
> The background for this request is a discussion on twitter:
> https://twitter.com/FrVaBe/status/870263530473369601
> https://twitter.com/snicoll/status/874231018957545472
> A possible argument against such a convention would probably be, that 
> projects that used another element order would be suddenly considered as 
> "wrong" ordered.
> But I think that everyone that wondered about how to order the elements has 
> probably found the developer conventions and used theses as an appropriate 
> convention. There are even tools to check this convention 
> ([SonarQube|https://jira.sonarsource.com/browse/RSPEC-3423]) and to support 
> this convention ([Tidy Maven 
> plugin|http://www.mojohaus.org/tidy-maven-plugin/]). The Convention is thus 
> already established.
>   



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
@mpkorstanje 
The build passed successfully. I will refactor little details, I will 
squash our commits and then I will push it to master.

I could not find a documentation for configuring annotation 
`CucumberOptions`. For instance we were using it like this 
`@CucumberOptions(features = {"classpath:flake"})` in your previous commit. Why 
we do not use it any more and why it was important? Do you think it is 
important for the users and important for proper functionality of Surefire?

One more question I have is regarding artifacts of Cucumber. Which one is 
right to use:
`cucumber-junit`
`cucumber-java8`



> Rerunning failing tests fails in combination with 
> Description#createSuiteDescription
> 
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
> Fix For: 2.21.1
>
>
> When using surefire to rerun failing tests created by a Runner that uses 
> {noformat}Description#createSuiteDescription{noformat} with a human readable 
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
> test class 'Scenario: Fail when running'
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] maven-surefire issue #150: SUREFIRE-1372 Filter tests to be rerun by descrip...

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
@mpkorstanje 
The build passed successfully. I will refactor little details, I will 
squash our commits and then I will push it to master.

I could not find a documentation for configuring annotation 
`CucumberOptions`. For instance we were using it like this 
`@CucumberOptions(features = {"classpath:flake"})` in your previous commit. Why 
we do not use it any more and why it was important? Do you think it is 
important for the users and important for proper functionality of Surefire?

One more question I have is regarding artifacts of Cucumber. Which one is 
right to use:
`cucumber-junit`
`cucumber-java8`



---