[jira] [Updated] (MNG-6171) REGRESSION: WARNING about usage of a non threadsafe marked plugin is not showed anymore
[
https://issues.apache.org/jira/browse/MNG-6171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-6171:
-
Fix Version/s: (was: 3.5.0)
3.5.1
> REGRESSION: WARNING about usage of a non threadsafe marked plugin is not
> showed anymore
> ---
>
> Key: MNG-6171
> URL: https://issues.apache.org/jira/browse/MNG-6171
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.1, 3.2.5, 3.3.9, 3.5.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
> Fix For: 3.5.1
>
>
> If you call Maven via command line like this:
> {{mvn -T 5 versions:set -DnewVersion=...}} in Maven 3.0.5, 3.1.1 you will get
> a message like this:
> {code}
> [INFO] Building with 20 threads
> [INFO]
> [INFO]
>
> [INFO] Building reactor-parent 1.0-SNAPSHOT
> [INFO]
>
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in reactor-parent:
> [WARNING] org.codehaus.mojo:versions-maven-plugin:2.3
> [WARNING] *
> [INFO]
> [INFO] --- versions-maven-plugin:2.3:set (default-cli) @ reactor-parent ---
> [INFO] Searching for local aggregator root...
> [INFO] Local aggregation root:
> /Users/kama/ws-git-soebes/maven-memory-problem/test-project/reactor
> [INFO] Processing change of org.test.parent:reactor-parent:1.0-SNAPSHOT ->
> 1.0-SNAPSHOT
> [INFO]
>
> {code}
> Starting with Maven 3.2.5 and above you don't get the WARNING anymore. Also
> for [current Master of
> Maven|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=0284dda81beb43b54116326f9a6efd439d40c922]
> it will not beed showed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6170) NPE in cases using Multithreaded -T X versions:set -DnewVersion=1.0-SNAPSHOT
[
https://issues.apache.org/jira/browse/MNG-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-6170:
-
Priority: Major (was: Blocker)
> NPE in cases using Multithreaded -T X versions:set -DnewVersion=1.0-SNAPSHOT
>
>
> Key: MNG-6170
> URL: https://issues.apache.org/jira/browse/MNG-6170
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.1.1, 3.2.5, 3.3.1, 3.3.9
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
> Fix For: 3.5.1
>
>
> Based on the
> [issue|https://github.com/mojohaus/versions-maven-plugin/issues/54] marked
> for the versions-maven-plugin investigation shows that the real cause of this
> problem is located in maven-core. I identified the following point in code as
> culprit for the problem:
> MultiThreadedBuilder.java
> {code}
> // for each finished project
> for ( int i = 0; i < analyzer.getNumberOfBuilds(); i++ )
> {
> try
> {
> ProjectSegment projectBuild = service.take().get();
> if ( reactorContext.getReactorBuildStatus().isHalted() )
> {
> break;
> }
> final List newItemsThatCanBeBuilt =
> analyzer.markAsFinished( projectBuild.getProject() );
> for ( MavenProject mavenProject : newItemsThatCanBeBuilt )
> {
> ProjectSegment scheduledDependent = projectBuildList.get(
> mavenProject );
> logger.debug( "Scheduling: " + scheduledDependent );
> Callable cb =
> createBuildCallable( rootSession, scheduledDependent,
> reactorContext, taskSegment, muxer );
> service.submit( cb );
> }
> }
> catch ( InterruptedException e )
> {
> rootSession.getResult().addException( e );
> break;
> }
> catch ( ExecutionException e )
> {
> // TODO MNG-5766 changes likely made this redundant
> rootSession.getResult().addException( e );
> break;
> }
> }
> {code}
> And the problematic part is before the second debugging output line:
> {code}
> ProjectSegment scheduledDependent = projectBuildList.get(
> mavenProject );
> logger.debug( "Scheduling: " + scheduledDependent );
> Callable cb =
> createBuildCallable( rootSession, scheduledDependent,
> reactorContext, taskSegment, muxer );
> service.submit( cb );
> {code}
> Cause it happens that the {{scheduledDependent}} could be null which will
> cause the issue.
> This -looks like- is a regression, cause in Maven 3.0.5 it works without any
> issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6170) NPE in cases using Multithreaded -T X versions:set -DnewVersion=1.0-SNAPSHOT
[
https://issues.apache.org/jira/browse/MNG-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-6170:
-
Fix Version/s: (was: 3.5.0)
3.5.1
> NPE in cases using Multithreaded -T X versions:set -DnewVersion=1.0-SNAPSHOT
>
>
> Key: MNG-6170
> URL: https://issues.apache.org/jira/browse/MNG-6170
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.1.1, 3.2.5, 3.3.1, 3.3.9
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
> Fix For: 3.5.1
>
>
> Based on the
> [issue|https://github.com/mojohaus/versions-maven-plugin/issues/54] marked
> for the versions-maven-plugin investigation shows that the real cause of this
> problem is located in maven-core. I identified the following point in code as
> culprit for the problem:
> MultiThreadedBuilder.java
> {code}
> // for each finished project
> for ( int i = 0; i < analyzer.getNumberOfBuilds(); i++ )
> {
> try
> {
> ProjectSegment projectBuild = service.take().get();
> if ( reactorContext.getReactorBuildStatus().isHalted() )
> {
> break;
> }
> final List newItemsThatCanBeBuilt =
> analyzer.markAsFinished( projectBuild.getProject() );
> for ( MavenProject mavenProject : newItemsThatCanBeBuilt )
> {
> ProjectSegment scheduledDependent = projectBuildList.get(
> mavenProject );
> logger.debug( "Scheduling: " + scheduledDependent );
> Callable cb =
> createBuildCallable( rootSession, scheduledDependent,
> reactorContext, taskSegment, muxer );
> service.submit( cb );
> }
> }
> catch ( InterruptedException e )
> {
> rootSession.getResult().addException( e );
> break;
> }
> catch ( ExecutionException e )
> {
> // TODO MNG-5766 changes likely made this redundant
> rootSession.getResult().addException( e );
> break;
> }
> }
> {code}
> And the problematic part is before the second debugging output line:
> {code}
> ProjectSegment scheduledDependent = projectBuildList.get(
> mavenProject );
> logger.debug( "Scheduling: " + scheduledDependent );
> Callable cb =
> createBuildCallable( rootSession, scheduledDependent,
> reactorContext, taskSegment, muxer );
> service.submit( cb );
> {code}
> Cause it happens that the {{scheduledDependent}} could be null which will
> cause the issue.
> This -looks like- is a regression, cause in Maven 3.0.5 it works without any
> issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MNG-6170) NPE in cases using Multithreaded -T X versions:set -DnewVersion=1.0-SNAPSHOT
[
https://issues.apache.org/jira/browse/MNG-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873023#comment-15873023
]
Hervé Boutemy edited comment on MNG-6170 at 2/18/17 8:43 AM:
-
why priority blocker?
this has not blocked many people from using Maven 3.1.0 to 3.3.9, isn't it?
and no real pressure to not release 3.5.0 before this is fixed, no?
notice: using versions:set in parallel mode is really looking for trouble :)
was (Author: hboutemy):
why priority blocker?
this has not blocked many people from using Maven 3.1 to 3.9, isn't it?
and no real pressure to not release 3.5.0 before this is fixed, no?
notice: using versions:set in parallel mode is really looking for trouble :)
> NPE in cases using Multithreaded -T X versions:set -DnewVersion=1.0-SNAPSHOT
>
>
> Key: MNG-6170
> URL: https://issues.apache.org/jira/browse/MNG-6170
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.1.1, 3.2.5, 3.3.1, 3.3.9
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
> Fix For: 3.5.1
>
>
> Based on the
> [issue|https://github.com/mojohaus/versions-maven-plugin/issues/54] marked
> for the versions-maven-plugin investigation shows that the real cause of this
> problem is located in maven-core. I identified the following point in code as
> culprit for the problem:
> MultiThreadedBuilder.java
> {code}
> // for each finished project
> for ( int i = 0; i < analyzer.getNumberOfBuilds(); i++ )
> {
> try
> {
> ProjectSegment projectBuild = service.take().get();
> if ( reactorContext.getReactorBuildStatus().isHalted() )
> {
> break;
> }
> final List newItemsThatCanBeBuilt =
> analyzer.markAsFinished( projectBuild.getProject() );
> for ( MavenProject mavenProject : newItemsThatCanBeBuilt )
> {
> ProjectSegment scheduledDependent = projectBuildList.get(
> mavenProject );
> logger.debug( "Scheduling: " + scheduledDependent );
> Callable cb =
> createBuildCallable( rootSession, scheduledDependent,
> reactorContext, taskSegment, muxer );
> service.submit( cb );
> }
> }
> catch ( InterruptedException e )
> {
> rootSession.getResult().addException( e );
> break;
> }
> catch ( ExecutionException e )
> {
> // TODO MNG-5766 changes likely made this redundant
> rootSession.getResult().addException( e );
> break;
> }
> }
> {code}
> And the problematic part is before the second debugging output line:
> {code}
> ProjectSegment scheduledDependent = projectBuildList.get(
> mavenProject );
> logger.debug( "Scheduling: " + scheduledDependent );
> Callable cb =
> createBuildCallable( rootSession, scheduledDependent,
> reactorContext, taskSegment, muxer );
> service.submit( cb );
> {code}
> Cause it happens that the {{scheduledDependent}} could be null which will
> cause the issue.
> This -looks like- is a regression, cause in Maven 3.0.5 it works without any
> issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6169) Lifecycle/binding plugin version updates
[ https://issues.apache.org/jira/browse/MNG-6169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873063#comment-15873063 ] Hervé Boutemy commented on MNG-6169: why a clone of MNG-5968? how is this issue different from MNG-5968? (notice: MNG-5968 is supposed to be fixed in 3.5.0, but current MNG-6169 not: since there is not even any description, how are we supposed to understand that?) > Lifecycle/binding plugin version updates > > > Key: MNG-6169 > URL: https://issues.apache.org/jira/browse/MNG-6169 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.3.9 >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.5.0-candidate > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6169) Lifecycle/binding plugin version updates
[ https://issues.apache.org/jira/browse/MNG-6169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873068#comment-15873068 ] Michael Osipov commented on MNG-6169: - The clone was simple laziness to fill all fields in a new ticket. > Lifecycle/binding plugin version updates > > > Key: MNG-6169 > URL: https://issues.apache.org/jira/browse/MNG-6169 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.3.9 >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.5.0-candidate > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (MNG-6169) Lifecycle/binding plugin version updates
[ https://issues.apache.org/jira/browse/MNG-6169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873068#comment-15873068 ] Michael Osipov edited comment on MNG-6169 at 2/18/17 9:05 AM: -- The clone was simple laziness to fill all fields in a new ticket. I will update the description. Note that I have split that from the original ticket reported by Christian Schulte. was (Author: michael-o): The clone was simple laziness to fill all fields in a new ticket. > Lifecycle/binding plugin version updates > > > Key: MNG-6169 > URL: https://issues.apache.org/jira/browse/MNG-6169 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.3.9 >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.5.0-candidate > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6170) NPE in cases using Multithreaded -T X versions:set -DnewVersion=1.0-SNAPSHOT
[
https://issues.apache.org/jira/browse/MNG-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873119#comment-15873119
]
Karl Heinz Marbaise commented on MNG-6170:
--
Using versions:set with {{-T X}} could mean to run versions:set parallel
(Currently not possible but could improve the run time for larger projects).
> NPE in cases using Multithreaded -T X versions:set -DnewVersion=1.0-SNAPSHOT
>
>
> Key: MNG-6170
> URL: https://issues.apache.org/jira/browse/MNG-6170
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.1.1, 3.2.5, 3.3.1, 3.3.9
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
> Fix For: 3.5.1
>
>
> Based on the
> [issue|https://github.com/mojohaus/versions-maven-plugin/issues/54] marked
> for the versions-maven-plugin investigation shows that the real cause of this
> problem is located in maven-core. I identified the following point in code as
> culprit for the problem:
> MultiThreadedBuilder.java
> {code}
> // for each finished project
> for ( int i = 0; i < analyzer.getNumberOfBuilds(); i++ )
> {
> try
> {
> ProjectSegment projectBuild = service.take().get();
> if ( reactorContext.getReactorBuildStatus().isHalted() )
> {
> break;
> }
> final List newItemsThatCanBeBuilt =
> analyzer.markAsFinished( projectBuild.getProject() );
> for ( MavenProject mavenProject : newItemsThatCanBeBuilt )
> {
> ProjectSegment scheduledDependent = projectBuildList.get(
> mavenProject );
> logger.debug( "Scheduling: " + scheduledDependent );
> Callable cb =
> createBuildCallable( rootSession, scheduledDependent,
> reactorContext, taskSegment, muxer );
> service.submit( cb );
> }
> }
> catch ( InterruptedException e )
> {
> rootSession.getResult().addException( e );
> break;
> }
> catch ( ExecutionException e )
> {
> // TODO MNG-5766 changes likely made this redundant
> rootSession.getResult().addException( e );
> break;
> }
> }
> {code}
> And the problematic part is before the second debugging output line:
> {code}
> ProjectSegment scheduledDependent = projectBuildList.get(
> mavenProject );
> logger.debug( "Scheduling: " + scheduledDependent );
> Callable cb =
> createBuildCallable( rootSession, scheduledDependent,
> reactorContext, taskSegment, muxer );
> service.submit( cb );
> {code}
> Cause it happens that the {{scheduledDependent}} could be null which will
> cause the issue.
> This -looks like- is a regression, cause in Maven 3.0.5 it works without any
> issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6170) NPE in cases using Multithreaded -T X versions:set -DnewVersion=1.0-SNAPSHOT
[
https://issues.apache.org/jira/browse/MNG-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873133#comment-15873133
]
Karl Heinz Marbaise commented on MNG-6170:
--
So after more detailed analysis:
The {{build()}} Method of {{MultiThreadedBuilder}} has a projectDependencyGraph
which which lists all projects whereas the {{projectBuildMap}}
{code}
Map projectBuildMap =
projectBuilds.selectSegment( taskSegment );
{code}
only contains the projects which should be built. In case calling {{mvn -T X
versions:set ..}} is only the root module. Inside the method
{{multiThreadedProjectTaskSegmentBuild}} the root module will be scheduled for
execution which looks correct so far.
{code}
// schedule independent projects
for ( MavenProject mavenProject : analyzer.getRootSchedulableBuilds() )
{
ProjectSegment projectSegment = projectBuildList.get( mavenProject
);
logger.debug( "Scheduling: " + projectSegment.getProject() );
Callable cb =
createBuildCallable( rootSession, projectSegment,
reactorContext, taskSegment, muxer );
service.submit( cb );
}
{code}
The second part is:
{code}
for ( int i = 0; i < analyzer.getNumberOfBuilds(); i++ )
{
try
{
ProjectSegment projectBuild = service.take().get();
if ( reactorContext.getReactorBuildStatus().isHalted() )
{
break;
}
final List newItemsThatCanBeBuilt =
analyzer.markAsFinished( projectBuild.getProject() );
for ( MavenProject mavenProject : newItemsThatCanBeBuilt )
{
...
}
{code}
At the moment it looks like the the information of {{newItemsThatCanBeBuilt}}
is simply wrong in such cases, cause it will return an non empty list where it
should be empty where only the root module should be built.
> NPE in cases using Multithreaded -T X versions:set -DnewVersion=1.0-SNAPSHOT
>
>
> Key: MNG-6170
> URL: https://issues.apache.org/jira/browse/MNG-6170
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.1.1, 3.2.5, 3.3.1, 3.3.9
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
> Fix For: 3.5.1
>
>
> Based on the
> [issue|https://github.com/mojohaus/versions-maven-plugin/issues/54] marked
> for the versions-maven-plugin investigation shows that the real cause of this
> problem is located in maven-core. I identified the following point in code as
> culprit for the problem:
> MultiThreadedBuilder.java
> {code}
> // for each finished project
> for ( int i = 0; i < analyzer.getNumberOfBuilds(); i++ )
> {
> try
> {
> ProjectSegment projectBuild = service.take().get();
> if ( reactorContext.getReactorBuildStatus().isHalted() )
> {
> break;
> }
> final List newItemsThatCanBeBuilt =
> analyzer.markAsFinished( projectBuild.getProject() );
> for ( MavenProject mavenProject : newItemsThatCanBeBuilt )
> {
> ProjectSegment scheduledDependent = projectBuildList.get(
> mavenProject );
> logger.debug( "Scheduling: " + scheduledDependent );
> Callable cb =
> createBuildCallable( rootSession, scheduledDependent,
> reactorContext, taskSegment, muxer );
> service.submit( cb );
> }
> }
> catch ( InterruptedException e )
> {
> rootSession.getResult().addException( e );
> break;
> }
> catch ( ExecutionException e )
> {
> // TODO MNG-5766 changes likely made this redundant
> rootSession.getResult().addException( e );
> break;
> }
> }
> {code}
> And the problematic part is before the second debugging output line:
> {code}
> ProjectSegment scheduledDependent = projectBuildList.get(
> mavenProject );
> logger.debug( "Scheduling: " + scheduledDependent );
> Callable cb =
> createBuildCallable( rootSession, scheduledDependent,
> reactorContext, taskSegment, muxer );
> service.submit( cb );
> {code}
> Cause it happens that the {{scheduledDependent}} could be null which will
> cause the issue.
> This -looks like- is a regression, cause in Maven 3.0.5 it works without any
> issue.
--
This message was sent by Atlassian JIRA
(v
[jira] [Updated] (MPLUGIN-322) The javadoc for the @Parameter annotation should clearly state that those are only evaluated on fields of a Mojo
[
https://issues.apache.org/jira/browse/MPLUGIN-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MPLUGIN-322:
--
Issue Type: Documentation (was: Improvement)
> The javadoc for the @Parameter annotation should clearly state that those are
> only evaluated on fields of a Mojo
>
>
> Key: MPLUGIN-322
> URL: https://issues.apache.org/jira/browse/MPLUGIN-322
> Project: Maven Plugin Tools
> Issue Type: Documentation
> Components: maven-plugin-annotations
>Affects Versions: 3.5
>Reporter: Konrad Windszus
>
> As it is not obvious that {{@Parameter}} annotations must only be used on
> fields of a Mojo class (see
> http://maven.40175.n5.nabble.com/why-the-defaultValue-is-not-being-injected-in-Parameter-inside-a-complex-parameter-bean-td5835732.html)
> this should be explicitly stated. I would propose to change the javadoc in
> http://svn.apache.org/viewvc/maven/plugin-tools/trunk/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations/Parameter.java?revision=1757927&view=markup#l29
> from
> {quote}
> Used to configure your Mojo parameters to be injected by
> href="/ref/current/maven-core/apidocs/org/apache/maven/plugin/MavenPluginManager.html">
> MavenPluginManager.getConfiguredMojo(...).
> {quote}
> to
> {quote}
> Used to configure your Mojo parameters to be injected by
> href="/ref/current/maven-core/apidocs/org/apache/maven/plugin/MavenPluginManager.html">
> MavenPluginManager.getConfiguredMojo(...).
> Although nested bean injection is supported by that method, this annotation
> is only effective on fields of the Mojo class itself and not on fields of any
> bean classes being used as Mojo parameter.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MPLUGIN-322) The javadoc for the @Parameter annotation should clearly state that those are only evaluated on fields of a Mojo
[
https://issues.apache.org/jira/browse/MPLUGIN-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873162#comment-15873162
]
Hervé Boutemy commented on MPLUGIN-322:
---
when you used @Parameter on beans, what did you expect to happen?
> The javadoc for the @Parameter annotation should clearly state that those are
> only evaluated on fields of a Mojo
>
>
> Key: MPLUGIN-322
> URL: https://issues.apache.org/jira/browse/MPLUGIN-322
> Project: Maven Plugin Tools
> Issue Type: Documentation
> Components: maven-plugin-annotations
>Affects Versions: 3.5
>Reporter: Konrad Windszus
>
> As it is not obvious that {{@Parameter}} annotations must only be used on
> fields of a Mojo class (see
> http://maven.40175.n5.nabble.com/why-the-defaultValue-is-not-being-injected-in-Parameter-inside-a-complex-parameter-bean-td5835732.html)
> this should be explicitly stated. I would propose to change the javadoc in
> http://svn.apache.org/viewvc/maven/plugin-tools/trunk/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations/Parameter.java?revision=1757927&view=markup#l29
> from
> {quote}
> Used to configure your Mojo parameters to be injected by
> href="/ref/current/maven-core/apidocs/org/apache/maven/plugin/MavenPluginManager.html">
> MavenPluginManager.getConfiguredMojo(...).
> {quote}
> to
> {quote}
> Used to configure your Mojo parameters to be injected by
> href="/ref/current/maven-core/apidocs/org/apache/maven/plugin/MavenPluginManager.html">
> MavenPluginManager.getConfiguredMojo(...).
> Although nested bean injection is supported by that method, this annotation
> is only effective on fields of the Mojo class itself and not on fields of any
> bean classes being used as Mojo parameter.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MPLUGIN-323) create @Requirement annotation to replace @Component (should be deprecated)
Hervé Boutemy created MPLUGIN-323:
-
Summary: create @Requirement annotation to replace @Component
(should be deprecated)
Key: MPLUGIN-323
URL: https://issues.apache.org/jira/browse/MPLUGIN-323
Project: Maven Plugin Tools
Issue Type: Wish
Components: maven-plugin-annotations, maven-plugin-tools-javadoc
Affects Versions: 3.5
Reporter: Hervé Boutemy
injecting a Plexus component into a mojo is currently marked through
{{@Component}} annotation (or {{@component}} javadoc tag)
This "component" term is misleading for 2 reasons:
1. in plugin descriptor, it creates a {{}} XML element:
http://maven.apache.org/ref/3-LATEST/maven-plugin-api/plugin.html#class_requirement
2. in Plexus, injecting is marked with {{@Requirement}} annotation, when
{{@Component}} is used to define a component:
http://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/
This annotation creates great confusion for years, then even if Plexus is being
dropped for javax.inject, fixing this misleading terms would be beneficial IMHO
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6140) update documentation's dependency graph with resolver + resolver-provider + slf4j-provider
[ https://issues.apache.org/jira/browse/MNG-6140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873185#comment-15873185 ] Hudson commented on MNG-6140: - SUCCESS: Integrated in Jenkins build maven-3.x #1549 (See [https://builds.apache.org/job/maven-3.x/1549/]) [MNG-6140] maven-core depends on shared-utils (not project-utils) (hboutemy: [http://git-wip-us.apache.org/repos/asf/?p=maven.git&a=commit&h=f1cc1d4e5aec96c9bd54219304e1b6b08855b102]) * (edit) src/site/resources/images/maven-deps.png * (edit) src/site/xdoc/maven-deps.odg > update documentation's dependency graph with resolver + resolver-provider + > slf4j-provider > -- > > Key: MNG-6140 > URL: https://issues.apache.org/jira/browse/MNG-6140 > Project: Maven > Issue Type: Task > Components: Documentation: General >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 3.5.0 > > > http://maven.apache.org/ref/3-LATEST/ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6171) REGRESSION: WARNING about usage of a non threadsafe marked plugin is not showed anymore
[
https://issues.apache.org/jira/browse/MNG-6171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873186#comment-15873186
]
Hervé Boutemy commented on MNG-6171:
after bisect,
[09961c3150b1a9ddaa88760d3a91f86542e5827d|https://github.com/apache/maven/commit/09961c3150b1a9ddaa88760d3a91f86542e5827d]
is the first bad commit
ok, a refactoring...
> REGRESSION: WARNING about usage of a non threadsafe marked plugin is not
> showed anymore
> ---
>
> Key: MNG-6171
> URL: https://issues.apache.org/jira/browse/MNG-6171
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.1, 3.2.5, 3.3.9, 3.5.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
> Fix For: 3.5.1
>
>
> If you call Maven via command line like this:
> {{mvn -T 5 versions:set -DnewVersion=...}} in Maven 3.0.5, 3.1.1 you will get
> a message like this:
> {code}
> [INFO] Building with 20 threads
> [INFO]
> [INFO]
>
> [INFO] Building reactor-parent 1.0-SNAPSHOT
> [INFO]
>
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in reactor-parent:
> [WARNING] org.codehaus.mojo:versions-maven-plugin:2.3
> [WARNING] *
> [INFO]
> [INFO] --- versions-maven-plugin:2.3:set (default-cli) @ reactor-parent ---
> [INFO] Searching for local aggregator root...
> [INFO] Local aggregation root:
> /Users/kama/ws-git-soebes/maven-memory-problem/test-project/reactor
> [INFO] Processing change of org.test.parent:reactor-parent:1.0-SNAPSHOT ->
> 1.0-SNAPSHOT
> [INFO]
>
> {code}
> Starting with Maven 3.2.5 and above you don't get the WARNING anymore. Also
> for [current Master of
> Maven|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=0284dda81beb43b54116326f9a6efd439d40c922]
> it will not beed showed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MNG-6171) REGRESSION: WARNING about usage of a non threadsafe marked plugin is not showed anymore
[
https://issues.apache.org/jira/browse/MNG-6171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy closed MNG-6171.
--
Resolution: Fixed
Assignee: Hervé Boutemy (was: Karl Heinz Marbaise)
Fix Version/s: (was: 3.5.1)
3.5.0
stupid bug fixed :)
> REGRESSION: WARNING about usage of a non threadsafe marked plugin is not
> showed anymore
> ---
>
> Key: MNG-6171
> URL: https://issues.apache.org/jira/browse/MNG-6171
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.1, 3.2.5, 3.3.9, 3.5.0
>Reporter: Karl Heinz Marbaise
>Assignee: Hervé Boutemy
> Fix For: 3.5.0
>
>
> If you call Maven via command line like this:
> {{mvn -T 5 versions:set -DnewVersion=...}} in Maven 3.0.5, 3.1.1 you will get
> a message like this:
> {code}
> [INFO] Building with 20 threads
> [INFO]
> [INFO]
>
> [INFO] Building reactor-parent 1.0-SNAPSHOT
> [INFO]
>
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in reactor-parent:
> [WARNING] org.codehaus.mojo:versions-maven-plugin:2.3
> [WARNING] *
> [INFO]
> [INFO] --- versions-maven-plugin:2.3:set (default-cli) @ reactor-parent ---
> [INFO] Searching for local aggregator root...
> [INFO] Local aggregation root:
> /Users/kama/ws-git-soebes/maven-memory-problem/test-project/reactor
> [INFO] Processing change of org.test.parent:reactor-parent:1.0-SNAPSHOT ->
> 1.0-SNAPSHOT
> [INFO]
>
> {code}
> Starting with Maven 3.2.5 and above you don't get the WARNING anymore. Also
> for [current Master of
> Maven|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=0284dda81beb43b54116326f9a6efd439d40c922]
> it will not beed showed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6171) REGRESSION: WARNING about usage of a non threadsafe marked plugin is not showed anymore
[
https://issues.apache.org/jira/browse/MNG-6171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MNG-6171:
---
Affects Version/s: (was: 3.5.0)
> REGRESSION: WARNING about usage of a non threadsafe marked plugin is not
> showed anymore
> ---
>
> Key: MNG-6171
> URL: https://issues.apache.org/jira/browse/MNG-6171
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.1, 3.2.5, 3.3.9
>Reporter: Karl Heinz Marbaise
>Assignee: Hervé Boutemy
> Fix For: 3.5.0
>
>
> If you call Maven via command line like this:
> {{mvn -T 5 versions:set -DnewVersion=...}} in Maven 3.0.5, 3.1.1 you will get
> a message like this:
> {code}
> [INFO] Building with 20 threads
> [INFO]
> [INFO]
>
> [INFO] Building reactor-parent 1.0-SNAPSHOT
> [INFO]
>
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in reactor-parent:
> [WARNING] org.codehaus.mojo:versions-maven-plugin:2.3
> [WARNING] *
> [INFO]
> [INFO] --- versions-maven-plugin:2.3:set (default-cli) @ reactor-parent ---
> [INFO] Searching for local aggregator root...
> [INFO] Local aggregation root:
> /Users/kama/ws-git-soebes/maven-memory-problem/test-project/reactor
> [INFO] Processing change of org.test.parent:reactor-parent:1.0-SNAPSHOT ->
> 1.0-SNAPSHOT
> [INFO]
>
> {code}
> Starting with Maven 3.2.5 and above you don't get the WARNING anymore. Also
> for [current Master of
> Maven|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=0284dda81beb43b54116326f9a6efd439d40c922]
> it will not beed showed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6136) Upgrade Maven Wagon from 2.10 to 2.12
[ https://issues.apache.org/jira/browse/MNG-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MNG-6136: --- Summary: Upgrade Maven Wagon from 2.10 to 2.12 (was: Upgrade Maven Wagon to 2.12) > Upgrade Maven Wagon from 2.10 to 2.12 > - > > Key: MNG-6136 > URL: https://issues.apache.org/jira/browse/MNG-6136 > Project: Maven > Issue Type: Task > Components: Deployment >Affects Versions: 3.3.9 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 3.5.0 > > > Let's absorb latest improvements to Wagon into Maven. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6171) REGRESSION: WARNING about usage of a non threadsafe marked plugin is not showed anymore
[
https://issues.apache.org/jira/browse/MNG-6171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873240#comment-15873240
]
Hudson commented on MNG-6171:
-
FAILURE: Integrated in Jenkins build maven-3.x #1550 (See
[https://builds.apache.org/job/maven-3.x/1550/])
[MNG-6171] always show WARNING about usage of a non threadsafe plugin
(hboutemy:
[http://git-wip-us.apache.org/repos/asf/?p=maven.git&a=commit&h=3982c195e91e3ea0f73ce9e61c6ddc57137726e9])
* (edit)
maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/BuilderCommon.java
> REGRESSION: WARNING about usage of a non threadsafe marked plugin is not
> showed anymore
> ---
>
> Key: MNG-6171
> URL: https://issues.apache.org/jira/browse/MNG-6171
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.1, 3.2.5, 3.3.9
>Reporter: Karl Heinz Marbaise
>Assignee: Hervé Boutemy
> Fix For: 3.5.0
>
>
> If you call Maven via command line like this:
> {{mvn -T 5 versions:set -DnewVersion=...}} in Maven 3.0.5, 3.1.1 you will get
> a message like this:
> {code}
> [INFO] Building with 20 threads
> [INFO]
> [INFO]
>
> [INFO] Building reactor-parent 1.0-SNAPSHOT
> [INFO]
>
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in reactor-parent:
> [WARNING] org.codehaus.mojo:versions-maven-plugin:2.3
> [WARNING] *
> [INFO]
> [INFO] --- versions-maven-plugin:2.3:set (default-cli) @ reactor-parent ---
> [INFO] Searching for local aggregator root...
> [INFO] Local aggregation root:
> /Users/kama/ws-git-soebes/maven-memory-problem/test-project/reactor
> [INFO] Processing change of org.test.parent:reactor-parent:1.0-SNAPSHOT ->
> 1.0-SNAPSHOT
> [INFO]
>
> {code}
> Starting with Maven 3.2.5 and above you don't get the WARNING anymore. Also
> for [current Master of
> Maven|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=0284dda81beb43b54116326f9a6efd439d40c922]
> it will not beed showed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6136) Upgrade Maven Wagon from 2.10 to 2.12
[ https://issues.apache.org/jira/browse/MNG-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MNG-6136: --- Description: Let's absorb latest improvements to Wagon into Maven. Release Notes - Maven Wagon - Version 2.12 ** Bug * [WAGON-408] - ITs for #testSecuredGet() fail with Windows * [WAGON-426] - Fingerprints loss in known_hosts * [WAGON-439] - Jsch issue in java 1.7 and Kerberos-enabled ssh servers * [WAGON-449] - CLIENT not changed after setting PoolingHttpClientConnectionManager * [WAGON-469] - wagon-http does not enable Expect-Continue by default * [WAGON-475] - TransferEvent GET used instead of PUT and vice versa * [WAGON-476] - HTTP Provider follows redirects on PUT and may change request method * [WAGON-479] - Preemptive auth with HTTP Provider may fail because BasicScheme is added as completed=true to the AuthCache * [WAGON-480] - Non-threadsafe HttpClientContext is shared between threaded use of HttpClientWagon * [WAGON-481] - Sensitive (auth) information is not cleared when HttpClientWagon is disconnected * [WAGON-485] - ScpWagon parses file size to int causing overflow for large files ** Improvement * [WAGON-455] - Upgrade of 'plexus-utils' to version 3.0.23. * [WAGON-458] - Implementation for FTPS * [WAGON-460] - Upgrade plexus-utils to 3.0.24 * [WAGON-464] - Upgrade jsch dependency to 0.1.51 or newer to support ECDSA host key typess * [WAGON-465] - wagon-ssh: add API option to check for remote exit code * [WAGON-466] - wagon-ssh: Better error message when ssh account is locked * [WAGON-467] - wagon-ssh: options to configure hostKeyChecking and PreferredAuthentications * [WAGON-472] - Upgrade Commons IO to 2.5 * [WAGON-484] - Update WebDAV Provider naming ** Task * [WAGON-389] - Incorrect versions on gh-pages * [WAGON-447] - Remove Commons Lang 2 for a few cases * [WAGON-457] - Wagon tests fail on Windows because Subversion crashes on a test repo * [WAGON-470] - Update TLS certificates for HTTPS tests * [WAGON-471] - Clean up dependency mess (reported by dependency:analyze) * [WAGON-473] - Don't abuse IllegalArgumentException to intercept null input * [WAGON-474] - Upgrade and revise all tests for Jetty 8 * [WAGON-483] - Upgrade SLF4J to 1.7.22 was:Let's absorb latest improvements to Wagon into Maven. > Upgrade Maven Wagon from 2.10 to 2.12 > - > > Key: MNG-6136 > URL: https://issues.apache.org/jira/browse/MNG-6136 > Project: Maven > Issue Type: Task > Components: Deployment >Affects Versions: 3.3.9 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 3.5.0 > > > Let's absorb latest improvements to Wagon into Maven. > Release Notes - Maven Wagon - Version 2.12 > ** Bug > * [WAGON-408] - ITs for #testSecuredGet() fail with Windows > * [WAGON-426] - Fingerprints loss in known_hosts > * [WAGON-439] - Jsch issue in java 1.7 and Kerberos-enabled ssh servers > * [WAGON-449] - CLIENT not changed after setting > PoolingHttpClientConnectionManager > * [WAGON-469] - wagon-http does not enable Expect-Continue by default > * [WAGON-475] - TransferEvent GET used instead of PUT and vice versa > * [WAGON-476] - HTTP Provider follows redirects on PUT and may change > request method > * [WAGON-479] - Preemptive auth with HTTP Provider may fail because > BasicScheme is added as completed=true to the AuthCache > * [WAGON-480] - Non-threadsafe HttpClientContext is shared between > threaded use of HttpClientWagon > * [WAGON-481] - Sensitive (auth) information is not cleared when > HttpClientWagon is disconnected > * [WAGON-485] - ScpWagon parses file size to int causing overflow for > large files > ** Improvement > * [WAGON-455] - Upgrade of 'plexus-utils' to version 3.0.23. > * [WAGON-458] - Implementation for FTPS > * [WAGON-460] - Upgrade plexus-utils to 3.0.24 > * [WAGON-464] - Upgrade jsch dependency to 0.1.51 or newer to support > ECDSA host key typess > * [WAGON-465] - wagon-ssh: add API option to check for remote exit code > * [WAGON-466] - wagon-ssh: Better error message when ssh account is locked > * [WAGON-467] - wagon-ssh: options to configure hostKeyChecking and > PreferredAuthentications > * [WAGON-472] - Upgrade Commons IO to 2.5 > * [WAGON-484] - Update WebDAV Provider naming > ** Task > * [WAGON-389] - Incorrect versions on gh-pages > * [WAGON-447] - Remove Commons Lang 2 for a few cases > * [WAGON-457] - Wagon tests fail on Windows because Subversion crashes on > a test repo > * [WAGON-470] - Update TLS certificates for HTTPS tests > * [WAGON-471] - Clean up dependency mess (reported by dependency:analyze) > * [WAGON-473]
[jira] [Updated] (MNG-6136) Upgrade Maven Wagon from 2.10 to 2.12
[ https://issues.apache.org/jira/browse/MNG-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MNG-6136: --- Description: Let's absorb latest improvements to Wagon into Maven. Release Notes - Maven Wagon - Version 2.11 Release Notes - Maven Wagon - Version 2.12 ** Bug * [WAGON-408] - ITs for #testSecuredGet() fail with Windows * [WAGON-426] - Fingerprints loss in known_hosts * [WAGON-439] - Jsch issue in java 1.7 and Kerberos-enabled ssh servers * [WAGON-449] - CLIENT not changed after setting PoolingHttpClientConnectionManager * [WAGON-469] - wagon-http does not enable Expect-Continue by default * [WAGON-475] - TransferEvent GET used instead of PUT and vice versa * [WAGON-476] - HTTP Provider follows redirects on PUT and may change request method * [WAGON-479] - Preemptive auth with HTTP Provider may fail because BasicScheme is added as completed=true to the AuthCache * [WAGON-480] - Non-threadsafe HttpClientContext is shared between threaded use of HttpClientWagon * [WAGON-481] - Sensitive (auth) information is not cleared when HttpClientWagon is disconnected * [WAGON-485] - ScpWagon parses file size to int causing overflow for large files ** Improvement * [WAGON-455] - Upgrade of 'plexus-utils' to version 3.0.23. * [WAGON-458] - Implementation for FTPS * [WAGON-460] - Upgrade plexus-utils to 3.0.24 * [WAGON-464] - Upgrade jsch dependency to 0.1.51 or newer to support ECDSA host key typess * [WAGON-465] - wagon-ssh: add API option to check for remote exit code * [WAGON-466] - wagon-ssh: Better error message when ssh account is locked * [WAGON-467] - wagon-ssh: options to configure hostKeyChecking and PreferredAuthentications * [WAGON-472] - Upgrade Commons IO to 2.5 * [WAGON-484] - Update WebDAV Provider naming ** Task * [WAGON-389] - Incorrect versions on gh-pages * [WAGON-447] - Remove Commons Lang 2 for a few cases * [WAGON-457] - Wagon tests fail on Windows because Subversion crashes on a test repo * [WAGON-470] - Update TLS certificates for HTTPS tests * [WAGON-471] - Clean up dependency mess (reported by dependency:analyze) * [WAGON-473] - Don't abuse IllegalArgumentException to intercept null input * [WAGON-474] - Upgrade and revise all tests for Jetty 8 * [WAGON-483] - Upgrade SLF4J to 1.7.22 was: Let's absorb latest improvements to Wagon into Maven. Release Notes - Maven Wagon - Version 2.12 ** Bug * [WAGON-408] - ITs for #testSecuredGet() fail with Windows * [WAGON-426] - Fingerprints loss in known_hosts * [WAGON-439] - Jsch issue in java 1.7 and Kerberos-enabled ssh servers * [WAGON-449] - CLIENT not changed after setting PoolingHttpClientConnectionManager * [WAGON-469] - wagon-http does not enable Expect-Continue by default * [WAGON-475] - TransferEvent GET used instead of PUT and vice versa * [WAGON-476] - HTTP Provider follows redirects on PUT and may change request method * [WAGON-479] - Preemptive auth with HTTP Provider may fail because BasicScheme is added as completed=true to the AuthCache * [WAGON-480] - Non-threadsafe HttpClientContext is shared between threaded use of HttpClientWagon * [WAGON-481] - Sensitive (auth) information is not cleared when HttpClientWagon is disconnected * [WAGON-485] - ScpWagon parses file size to int causing overflow for large files ** Improvement * [WAGON-455] - Upgrade of 'plexus-utils' to version 3.0.23. * [WAGON-458] - Implementation for FTPS * [WAGON-460] - Upgrade plexus-utils to 3.0.24 * [WAGON-464] - Upgrade jsch dependency to 0.1.51 or newer to support ECDSA host key typess * [WAGON-465] - wagon-ssh: add API option to check for remote exit code * [WAGON-466] - wagon-ssh: Better error message when ssh account is locked * [WAGON-467] - wagon-ssh: options to configure hostKeyChecking and PreferredAuthentications * [WAGON-472] - Upgrade Commons IO to 2.5 * [WAGON-484] - Update WebDAV Provider naming ** Task * [WAGON-389] - Incorrect versions on gh-pages * [WAGON-447] - Remove Commons Lang 2 for a few cases * [WAGON-457] - Wagon tests fail on Windows because Subversion crashes on a test repo * [WAGON-470] - Update TLS certificates for HTTPS tests * [WAGON-471] - Clean up dependency mess (reported by dependency:analyze) * [WAGON-473] - Don't abuse IllegalArgumentException to intercept null input * [WAGON-474] - Upgrade and revise all tests for Jetty 8 * [WAGON-483] - Upgrade SLF4J to 1.7.22 > Upgrade Maven Wagon from 2.10 to 2.12 > - > > Key: MNG-6136 > URL: https://issues.apache.org/jira/browse/MNG-6136 > Project: Maven > Issue Type: Task > Components: Deployment >Affects Versions: 3.3.9 >Reporter: Mi
[jira] [Created] (SUREFIRE-1335) Surefire final test report format demark methodname with '#' for IDE integration
Mikhail Fedorov created SUREFIRE-1335: - Summary: Surefire final test report format demark methodname with '#' for IDE integration Key: SUREFIRE-1335 URL: https://issues.apache.org/jira/browse/SUREFIRE-1335 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Reporter: Mikhail Fedorov Attachments: eclipse.png, goto_line.png The current final report/summary of the test cases have the following format (in simple cases): Results : Tests in error: TestTest.test:12 » IllegalArgument Full rules are described in file newerrorsummary.md Initially the report format had separtor '#' symbols for methods (but line numbers were in braces). Currently it's point symbol, and line number is separated with colon. The suggestion is to have the following format (at least for simple cases) TestTest#test:12 » IllegalArgument The reason is IntelliJ Idea does not support goto class/file action in format with point as method name separator. When replaced with '#', surefire plugin user will be able to do simple copy-paste from build console, go to Intellij IDE, press Ctrl-N and go to particular line where the error happened (see goto_line screenshot), I also wondered maybe Eclipse maven build console supports this format to go to the line quickly (appears that it is not so, see eclipse screenshot). The stacktraces from above result report, which have other format, supported by IDEs seem to be not enough in real projects, because I have to scroll up too much, through stacktraces. Other solution might be to print next to each failed test [Class:33] that both eclipse and Intellij supports. I tried to see if it would be possible for Intellij to parse this line, but it seems to be hard to distinguish method name from class name if it's separated with point symbol. Intellij currently supports goto Class#methodName Class#methodName:33 even some weird formats line Class on line 33 Class#L33 Eclipse supports: Class:NN -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1335) Surefire final test report format demark methodname with '#' for IDE integration
[
https://issues.apache.org/jira/browse/SUREFIRE-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Fedorov updated SUREFIRE-1335:
--
Description:
The current final report/summary of the test cases have the following format
(in simple cases):
{quote}
Results :
Tests in error:
TestTest.test:12 » IllegalArgument
{quote}
Full rules are described in file newerrorsummary.md
Initially the report format had separtor '#' symbols for methods (but line
numbers were in braces).
Currently it's point symbol, and line number is separated with colon.
The suggestion is to have the following format (at least for simple cases)
{quote}
TestTest#test:12 » IllegalArgument
{quote}
The reason is IntelliJ Idea does not support goto class/file action in format
with point as method name separator.
When replaced with '#', surefire plugin user will be able to do simple
copy-paste from build console, go to Intellij IDE, press Ctrl-N and go to
particular line where the error happened (see goto_line screenshot),
I also wondered maybe Eclipse maven build console supports this format to go to
the line quickly (appears that it is not so, see eclipse screenshot).
The stacktraces from above result report, which have other format, supported by
IDEs seem to be not enough in real projects, because I have to scroll up too
much, through stacktraces.
Other solution might be to print next to each failed test [Class:33] that both
eclipse and Intellij supports.
I tried to see if it would be possible for Intellij to parse this line, but it
seems to be hard to distinguish method name from class name if it's separated
with point symbol.
Intellij currently supports goto
Class#methodName
Class#methodName:33
even some weird formats line
Class on line 33
Class#L33
Eclipse supports:
Class:NN
was:
The current final report/summary of the test cases have the following format
(in simple cases):
{quote}
Results :
Tests in error:
TestTest.test:12 » IllegalArgument
{quote}
Full rules are described in file newerrorsummary.md
Initially the report format had separtor '#' symbols for methods (but line
numbers were in braces).
Currently it's point symbol, and line number is separated with colon.
The suggestion is to have the following format (at least for simple cases)
TestTest#test:12 » IllegalArgument
The reason is IntelliJ Idea does not support goto class/file action in format
with point as method name separator.
When replaced with '#', surefire plugin user will be able to do simple
copy-paste from build console, go to Intellij IDE, press Ctrl-N and go to
particular line where the error happened (see goto_line screenshot),
I also wondered maybe Eclipse maven build console supports this format to go to
the line quickly (appears that it is not so, see eclipse screenshot).
The stacktraces from above result report, which have other format, supported by
IDEs seem to be not enough in real projects, because I have to scroll up too
much, through stacktraces.
Other solution might be to print next to each failed test [Class:33] that both
eclipse and Intellij supports.
I tried to see if it would be possible for Intellij to parse this line, but it
seems to be hard to distinguish method name from class name if it's separated
with point symbol.
Intellij currently supports goto
Class#methodName
Class#methodName:33
even some weird formats line
Class on line 33
Class#L33
Eclipse supports:
Class:NN
> Surefire final test report format demark methodname with '#' for IDE
> integration
>
>
> Key: SUREFIRE-1335
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1335
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Reporter: Mikhail Fedorov
> Attachments: eclipse.png, goto_line.png
>
>
> The current final report/summary of the test cases have the following format
> (in simple cases):
> {quote}
> Results :
> Tests in error:
>TestTest.test:12 » IllegalArgument
> {quote}
> Full rules are described in file newerrorsummary.md
> Initially the report format had separtor '#' symbols for methods (but line
> numbers were in braces).
> Currently it's point symbol, and line number is separated with colon.
> The suggestion is to have the following format (at least for simple cases)
> {quote}
> TestTest#test:12 » IllegalArgument
> {quote}
> The reason is IntelliJ Idea does not support goto class/file action in format
> with point as method name separator.
> When replaced with '#', surefire plugin user will be able to do simple
> copy-paste from build console, go to Intellij IDE, press Ctrl-N and go to
> particular line where the error happened (see goto_line screenshot),
> I also wondered maybe Ecl
[jira] [Updated] (SUREFIRE-1335) Surefire final test report format demark methodname with '#' for IDE integration
[
https://issues.apache.org/jira/browse/SUREFIRE-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Fedorov updated SUREFIRE-1335:
--
Description:
The current final report/summary of the test cases have the following format
(in simple cases):
{quote}
Results :
Tests in error:
TestTest.test:12 » IllegalArgument
{quote}
Full rules are described in file newerrorsummary.md
Initially the report format had separtor '#' symbols for methods (but line
numbers were in braces).
Currently it's point symbol, and line number is separated with colon.
The suggestion is to have the following format (at least for simple cases)
TestTest#test:12 » IllegalArgument
The reason is IntelliJ Idea does not support goto class/file action in format
with point as method name separator.
When replaced with '#', surefire plugin user will be able to do simple
copy-paste from build console, go to Intellij IDE, press Ctrl-N and go to
particular line where the error happened (see goto_line screenshot),
I also wondered maybe Eclipse maven build console supports this format to go to
the line quickly (appears that it is not so, see eclipse screenshot).
The stacktraces from above result report, which have other format, supported by
IDEs seem to be not enough in real projects, because I have to scroll up too
much, through stacktraces.
Other solution might be to print next to each failed test [Class:33] that both
eclipse and Intellij supports.
I tried to see if it would be possible for Intellij to parse this line, but it
seems to be hard to distinguish method name from class name if it's separated
with point symbol.
Intellij currently supports goto
Class#methodName
Class#methodName:33
even some weird formats line
Class on line 33
Class#L33
Eclipse supports:
Class:NN
was:
The current final report/summary of the test cases have the following format
(in simple cases):
Results :
Tests in error:
TestTest.test:12 » IllegalArgument
Full rules are described in file newerrorsummary.md
Initially the report format had separtor '#' symbols for methods (but line
numbers were in braces).
Currently it's point symbol, and line number is separated with colon.
The suggestion is to have the following format (at least for simple cases)
TestTest#test:12 » IllegalArgument
The reason is IntelliJ Idea does not support goto class/file action in format
with point as method name separator.
When replaced with '#', surefire plugin user will be able to do simple
copy-paste from build console, go to Intellij IDE, press Ctrl-N and go to
particular line where the error happened (see goto_line screenshot),
I also wondered maybe Eclipse maven build console supports this format to go to
the line quickly (appears that it is not so, see eclipse screenshot).
The stacktraces from above result report, which have other format, supported by
IDEs seem to be not enough in real projects, because I have to scroll up too
much, through stacktraces.
Other solution might be to print next to each failed test [Class:33] that both
eclipse and Intellij supports.
I tried to see if it would be possible for Intellij to parse this line, but it
seems to be hard to distinguish method name from class name if it's separated
with point symbol.
Intellij currently supports goto
Class#methodName
Class#methodName:33
even some weird formats line
Class on line 33
Class#L33
Eclipse supports:
Class:NN
> Surefire final test report format demark methodname with '#' for IDE
> integration
>
>
> Key: SUREFIRE-1335
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1335
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Reporter: Mikhail Fedorov
> Attachments: eclipse.png, goto_line.png
>
>
> The current final report/summary of the test cases have the following format
> (in simple cases):
> {quote}
> Results :
> Tests in error:
>TestTest.test:12 » IllegalArgument
> {quote}
> Full rules are described in file newerrorsummary.md
> Initially the report format had separtor '#' symbols for methods (but line
> numbers were in braces).
> Currently it's point symbol, and line number is separated with colon.
> The suggestion is to have the following format (at least for simple cases)
> TestTest#test:12 » IllegalArgument
> The reason is IntelliJ Idea does not support goto class/file action in format
> with point as method name separator.
> When replaced with '#', surefire plugin user will be able to do simple
> copy-paste from build console, go to Intellij IDE, press Ctrl-N and go to
> particular line where the error happened (see goto_line screenshot),
> I also wondered maybe Eclipse maven build console supports this format to go
[jira] [Updated] (SUREFIRE-1335) Surefire final test report format demark methodname with '#' for IDE integration
[
https://issues.apache.org/jira/browse/SUREFIRE-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Fedorov updated SUREFIRE-1335:
--
Description:
The current final report/summary of the test cases have the following format
(in simple cases):
{quote}
Results :
Tests in error:
TestTest.test:12 » IllegalArgument
{quote}
Full rules are described in file newerrorsummary.md
Initially the report format had separtor '#' symbols for methods (but line
numbers were in braces).
Currently it's point symbol, and line number is separated with colon.
The suggestion is to have the following format (at least for simple cases)
{quote}
TestTest#test:12 » IllegalArgument
{quote}
The reason is IntelliJ Idea does not support goto class/file action in format
with point as method name separator.
When replaced with '#', surefire plugin user will be able to do simple
copy-paste from build console, go to Intellij IDE, press Ctrl-N and go to
particular line where the error happened (see attached goto_line.png
screenshot),
I also wondered maybe Eclipse maven build console supports this format to go to
the line quickly (appears that it is not so, see eclipse screenshot).
The stacktraces from above result report, which have other format, supported by
IDEs seem to be not enough in real projects, because I have to scroll up too
much, through stacktraces.
Other solution might be to print next to each failed test [Class:33] that both
eclipse and Intellij supports.
I tried to see if it would be possible for Intellij to parse this line, but it
seems to be hard to distinguish method name from class name if it's separated
with point symbol.
Intellij currently supports goto
Class#methodName
Class#methodName:33
even some weird formats line
Class on line 33
Class#L33
Eclipse supports:
Class:33 (you may see blue highlighted strings on eclipse.png screenshot)
was:
The current final report/summary of the test cases have the following format
(in simple cases):
{quote}
Results :
Tests in error:
TestTest.test:12 » IllegalArgument
{quote}
Full rules are described in file newerrorsummary.md
Initially the report format had separtor '#' symbols for methods (but line
numbers were in braces).
Currently it's point symbol, and line number is separated with colon.
The suggestion is to have the following format (at least for simple cases)
{quote}
TestTest#test:12 » IllegalArgument
{quote}
The reason is IntelliJ Idea does not support goto class/file action in format
with point as method name separator.
When replaced with '#', surefire plugin user will be able to do simple
copy-paste from build console, go to Intellij IDE, press Ctrl-N and go to
particular line where the error happened (see goto_line screenshot),
I also wondered maybe Eclipse maven build console supports this format to go to
the line quickly (appears that it is not so, see eclipse screenshot).
The stacktraces from above result report, which have other format, supported by
IDEs seem to be not enough in real projects, because I have to scroll up too
much, through stacktraces.
Other solution might be to print next to each failed test [Class:33] that both
eclipse and Intellij supports.
I tried to see if it would be possible for Intellij to parse this line, but it
seems to be hard to distinguish method name from class name if it's separated
with point symbol.
Intellij currently supports goto
Class#methodName
Class#methodName:33
even some weird formats line
Class on line 33
Class#L33
Eclipse supports:
Class:NN
> Surefire final test report format demark methodname with '#' for IDE
> integration
>
>
> Key: SUREFIRE-1335
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1335
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Reporter: Mikhail Fedorov
> Attachments: eclipse.png, goto_line.png
>
>
> The current final report/summary of the test cases have the following format
> (in simple cases):
> {quote}
> Results :
> Tests in error:
>TestTest.test:12 » IllegalArgument
> {quote}
> Full rules are described in file newerrorsummary.md
> Initially the report format had separtor '#' symbols for methods (but line
> numbers were in braces).
> Currently it's point symbol, and line number is separated with colon.
> The suggestion is to have the following format (at least for simple cases)
> {quote}
> TestTest#test:12 » IllegalArgument
> {quote}
> The reason is IntelliJ Idea does not support goto class/file action in format
> with point as method name separator.
> When replaced with '#', surefire plugin user will be able to do simple
> copy-paste from build console, go to Intellij IDE, press Ctrl-N and go to
> p
[jira] [Closed] (MSCMPUB-31) Request for granting me access to publish to maven 2 nexus
[ https://issues.apache.org/jira/browse/MSCMPUB-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSCMPUB-31. - Resolution: Invalid I think you are competely wrong here. > Request for granting me access to publish to maven 2 nexus > -- > > Key: MSCMPUB-31 > URL: https://issues.apache.org/jira/browse/MSCMPUB-31 > Project: Maven SCM Publish Plugin > Issue Type: New JIRA Project >Reporter: Sreedhar Puttagunta > > I want to contribute to the OS community with this plugin using which people > can parallelize cucumber scenario execution. > Project URL: www.cucumbergoodies.com. > SVN URL: https://github.com/puttagunta/supercucumber.git > Maven Group Ids: com.cucumbergoodies.selenium -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MINSTALL-108) installAtEnd cannot be overwritten from command line using -DinstallAtEnd=false
[
https://issues.apache.org/jira/browse/MINSTALL-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MINSTALL-108.
---
Resolution: Invalid
Assignee: Robert Scholte
Fix Version/s: (was: more-investigation)
This is by design of Maven. If you give a parameter an explicit value inside
the plugins configuration, it cannot be overwritten. Instead you can do the
following:
{code:xml}
true
{code}
> installAtEnd cannot be overwritten from command line using
> -DinstallAtEnd=false
> ---
>
> Key: MINSTALL-108
> URL: https://issues.apache.org/jira/browse/MINSTALL-108
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 2.5.2
>Reporter: Karl Heinz Marbaise
>Assignee: Robert Scholte
>Priority: Critical
>
> 1. Declare the maven-install-plugin and as configuration, add
> true.
> 2. Override installAtEnd property using the command line argument
> '-DinstallAtEnd=false'.
> 3. Install plugin still wants to install all artifacts at the end.
> Expected behaviour:
> Deploy plugin honors command line argument '-DinstallAtEnd=false'.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MINSTALL-134) Remove checksum generation
Robert Scholte created MINSTALL-134: --- Summary: Remove checksum generation Key: MINSTALL-134 URL: https://issues.apache.org/jira/browse/MINSTALL-134 Project: Maven Install Plugin Issue Type: Improvement Affects Versions: 2.5.2 Reporter: Robert Scholte Assignee: Robert Scholte Fix For: 3.0.0 Checksum doesn't make sense for install to local repository. It should be part of the deployments of artifacts. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (MSHARED-418) Verifier should not use hard coded CLI options without possibility to modify them
[ https://issues.apache.org/jira/browse/MSHARED-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575205#comment-14575205 ] Hervé Boutemy edited comment on MSHARED-418 at 2/19/17 4:19 AM: commited in SVN #1683964 http://svn.apache.org/viewvc/r1683964 https://svn.apache.org/repos/asf/maven/shared/trunk/maven-verifier was (Author: tibor17): commited in SVN #1683964 https://svn.apache.org/repos/asf/maven/shared/trunk/maven-verifier > Verifier should not use hard coded CLI options without possibility to modify > them > - > > Key: MSHARED-418 > URL: https://issues.apache.org/jira/browse/MSHARED-418 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-verifier >Affects Versions: maven-verifier-1.5 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: maven-verifier-1.6 > > > Verifier used -e and -B by default. These CLI options violate my ITs in > surefire and I need to fully control the CLI options in integration tests. > Introduced new constructor. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (MSHARED-418) Verifier should not use hard coded CLI options without possibility to modify them
[ https://issues.apache.org/jira/browse/MSHARED-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575205#comment-14575205 ] Hervé Boutemy edited comment on MSHARED-418 at 2/19/17 4:19 AM: commited in SVN #1683964 http://svn.apache.org/r1683964 https://svn.apache.org/repos/asf/maven/shared/trunk/maven-verifier was (Author: tibor17): commited in SVN #1683964 http://svn.apache.org/viewvc/r1683964 https://svn.apache.org/repos/asf/maven/shared/trunk/maven-verifier > Verifier should not use hard coded CLI options without possibility to modify > them > - > > Key: MSHARED-418 > URL: https://issues.apache.org/jira/browse/MSHARED-418 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-verifier >Affects Versions: maven-verifier-1.5 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: maven-verifier-1.6 > > > Verifier used -e and -B by default. These CLI options violate my ITs in > surefire and I need to fully control the CLI options in integration tests. > Introduced new constructor. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (MSHARED-418) Verifier should not use hard coded CLI options without possibility to modify them
[ https://issues.apache.org/jira/browse/MSHARED-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575205#comment-14575205 ] Hervé Boutemy edited comment on MSHARED-418 at 2/19/17 4:21 AM: commited in SVN #1683864 http://svn.apache.org/r1683864 https://svn.apache.org/repos/asf/maven/shared/trunk/maven-verifier was (Author: tibor17): commited in SVN #1683964 http://svn.apache.org/r1683964 https://svn.apache.org/repos/asf/maven/shared/trunk/maven-verifier > Verifier should not use hard coded CLI options without possibility to modify > them > - > > Key: MSHARED-418 > URL: https://issues.apache.org/jira/browse/MSHARED-418 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-verifier >Affects Versions: maven-verifier-1.5 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: maven-verifier-1.6 > > > Verifier used -e and -B by default. These CLI options violate my ITs in > surefire and I need to fully control the CLI options in integration tests. > Introduced new constructor. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
