[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&focusedCommentId=16283215#comment-16283215
 ] 

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user naveedriay commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
Is it possible to ask the original developer (@mpkorstanje ) to look at 
this deleted file changes as it might help get it through quickly. I suppose 
quite a number of people are waiting for this fix to go in (including me)


> 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)

[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&focusedCommentId=16283697#comment-16283697
 ] 

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user mpkorstanje commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
@Tibor17 would it help if I rebased this branch against master?




> 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)

[jira] [Commented] (MNG-5885) Optimize execution when phases of same lifecycle are called

[Daniel Cruver (JIRA)]

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

Daniel Cruver commented on MNG-5885:


A potential solution to this is to detect when phases of the same lifecyle are 
adjacent to each other on the command line an report a run-time error.

For example:
mvn clean install deploy

ERROR: the phases install and deploy both belong to the 'default' Lifecycle, 
please build with the command 'mvn clean deploy'. 

> Optimize execution when phases of same lifecycle are called
> ---
>
> Key: MNG-5885
> URL: https://issues.apache.org/jira/browse/MNG-5885
> Project: Maven
>  Issue Type: Sub-task
>  Components: Plugins and Lifecycle
>Affects Versions: 3.3.3
>Reporter: Robert Scholte
> Fix For: 3.x / Backlog
>
>
> In case someone calls {{compile package}} there's no need for the separate 
> {{compile}} call. Now the lifecycle is executed twice: once until {{compile}} 
> and once again until {{package}}.
> Note: {{package compile}} is weird due to its order, but should not be 
> optimized. {{compile resources:copy-resources package}} is a bit complicated. 
> Ideally this should call all phases up until {{compile}}, followed by 
> {{resources:copy-resources}}, followed by the {{process-classes}} to 
> {{package}} phases.



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

[jira] [Created] (MNG-6319) Allow for building of the whole project multiple times (with different phases/goals/lifecycles) but with one command

[Daniel Cruver (JIRA)]

Daniel Cruver created MNG-6319:
--

 Summary: Allow for building of the whole project multiple times 
(with different phases/goals/lifecycles) but with one command
 Key: MNG-6319
 URL: https://issues.apache.org/jira/browse/MNG-6319
 Project: Maven
  Issue Type: Sub-task
Reporter: Daniel Cruver
Priority: Trivial


Most of the use cases I can think of deal with the iterative process of 
development, make a change, clean all modules, install all modules etc
Regardless it could serve some usefulness in CI or release management 
regardless.  

So say you wanted to clean all modules, you could do a mvn clean followed by a 
mvn install in a script or on the command line but what if you could just 
provided this in one command.

For example mvn '{clean install}, {clean deploy}' where it would actually clean 
and install all modules, then if that succeeded it would then clean and deploy 
all projects.  Obviously there are some semantics that are unclear like if the 
second deploy could reuse the previous builds outputs (if clean wasn't done) 
etc.

Unfortunately I can see that the syntax might be confusing and consideration to 
how it would be escaped on different consoles/platforms might be troublesome.  
It might be just that we should stick to scripted process with separate 
executions of the maven binary if we really need this functionality.



--
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&focusedCommentId=16283769#comment-16283769
 ] 

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user mpkorstanje commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
@Tibor17  It appears this branch is still up to date with master. 

Is the removal of the class the problem or the underlying fundamentals? If 
it is just the removal I can restore `FailingMethodFilter.java`. It went unused 
after my changes. If it is the underlying fundamentals please let me know how I 
can help you.




> 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)

[jira] [Created] (MPLUGIN-330) If and else-if branches has the same condition

[songwanging (JIRA)]

songwanging created MPLUGIN-330:
---

 Summary: If and else-if branches has the same condition
 Key: MPLUGIN-330
 URL: https://issues.apache.org/jira/browse/MPLUGIN-330
 Project: Maven Plugin Tools
  Issue Type: Bug
  Components: Plugin Plugin
Affects Versions: 3.5
Reporter: songwanging
Priority: Minor


Our tool DeepTect has detected a piece of buggy code snippet, in which the if 
and else branches has the same condition.

Path: 
maven-plugin-tools/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/AbstractGeneratorMojo.java

{code:java}
public void execute(){
...
Set requestDependencies;
if ( mojoDependencies == null )
{
requestDependencies = dependencies;
}
else if ( mojoDependencies == null )
{
requestDependencies = null;
}
...
}
{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 
@ckurban 
@sworisbreathing 
I could not merge and release this PR because the class 
`FailingMethodFilter.java` in [1] was deleted.
We have to have it back and find root cause and good cure.
I may have spare time during the weekend but this troubleshooting may take 
several days to understand the cure.
[1]: 
https://github.com/apache/maven-surefire/pull/150/commits/780e878a3c2d15547bc0157ebef67de793b06862



---

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

[naveedriay]

Github user naveedriay commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
Is it possible to ask the original developer (@mpkorstanje ) to look at 
this deleted file changes as it might help get it through quickly. I suppose 
quite a number of people are waiting for this fix to go in (including me)


---

[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
  
@Tibor17  It appears this branch is still up to date with master. 

Is the removal of the class the problem or the underlying fundamentals? If 
it is just the removal I can restore `FailingMethodFilter.java`. It went unused 
after my changes. If it is the underlying fundamentals please let me know how I 
can help you.




---

[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
  
As far as I remember the filter was used in rerun feature where broken
tests were executed several more times after.
Yet let me check your branch because that's better than if you spent your
time again.
I will inform you about my findings in few days.

On Fri, Dec 8, 2017 at 5:07 PM, M.P. Korstanje 
wrote:

> @Tibor17  It appears this branch is still up
> to date with master.
>
> Is the removal of the class the problem or the underlying fundamentals? If
> it is just the removal I can restore FailingMethodFilter.java. It went
> unused after my changes. If it is the underlying fundamentals please let 
me
> know how I can help you.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> 
,
> or mute the thread
> 

> .
>



-- 
Cheers
Tibor



---

[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&focusedCommentId=16283907#comment-16283907
 ] 

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
As far as I remember the filter was used in rerun feature where broken
tests were executed several more times after.
Yet let me check your branch because that's better than if you spent your
time again.
I will inform you about my findings in few days.

On Fri, Dec 8, 2017 at 5:07 PM, M.P. Korstanje 
wrote:

> @Tibor17  It appears this branch is still up
> to date with master.
>
> Is the removal of the class the problem or the underlying fundamentals? If
> it is just the removal I can restore FailingMethodFilter.java. It went
> unused after my changes. If it is the underlying fundamentals please let 
me
> know how I can help you.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> 
,
> or mute the thread
> 

> .
>



-- 
Cheers
Tibor



> 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)

[jira] [Created] (SCM-856) use objects as String without calling the toString method

[songwanging (JIRA)]

songwanging created SCM-856:
---

 Summary: use objects as String without calling the toString method
 Key: SCM-856
 URL: https://issues.apache.org/jira/browse/SCM-856
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-plugin
Affects Versions: 1.9.5
Reporter: songwanging
Priority: Blocker


Our tool DeepTect has detected two buggy code snippets, in which the code 
prints out an object without calling the toString method:

Path: 
maven-scm/maven-scm-plugin/src/main/java/org/apache/maven/scm/plugin/ExportMojo.java


{code:java}
this.exportDirectory = new File( this.getBasedir(), "target/export" );
...
this.getLog().info( "Removing " + this.exportDirectory );
...
 throw new MojoExecutionException( "Cannot create " + this.exportDirectory );
{code}




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

[jira] [Updated] (SCM-856) use objects as String without calling the toString method

[songwanging (JIRA)]

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

songwanging updated SCM-856:

Priority: Minor  (was: Blocker)

> use objects as String without calling the toString method
> -
>
> Key: SCM-856
> URL: https://issues.apache.org/jira/browse/SCM-856
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-plugin
>Affects Versions: 1.9.5
>Reporter: songwanging
>Priority: Minor
>
> Our tool DeepTect has detected two buggy code snippets, in which the code 
> prints out an object without calling the toString method:
> Path: 
> maven-scm/maven-scm-plugin/src/main/java/org/apache/maven/scm/plugin/ExportMojo.java
> {code:java}
> this.exportDirectory = new File( this.getBasedir(), "target/export" );
> ...
> this.getLog().info( "Removing " + this.exportDirectory );
> ...
>  throw new MojoExecutionException( "Cannot create " + this.exportDirectory );
> {code}



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

[jira] [Updated] (MNG-6319) Allow for building of the whole project multiple times (with different phases/goals/lifecycles) but with one command

[Robert Scholte (JIRA)]

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

Robert Scholte updated MNG-6319:

Description: 
Most of the use cases I can think of deal with the iterative process of 
development, make a change, clean all modules, install all modules etc
Regardless it could serve some usefulness in CI or release management 
regardless.  

So say you wanted to clean all modules, you could do a mvn clean followed by a 
mvn install in a script or on the command line but what if you could just 
provided this in one command.

For example mvn {{clean install,clean deploy}} where it would actually clean 
and install all modules, then if that succeeded it would then clean and deploy 
all projects.  Obviously there are some semantics that are unclear like if the 
second deploy could reuse the previous builds outputs (if clean wasn't done) 
etc.

Unfortunately I can see that the syntax might be confusing and consideration to 
how it would be escaped on different consoles/platforms might be troublesome.  
It might be just that we should stick to scripted process with separate 
executions of the maven binary if we really need this functionality.

  was:
Most of the use cases I can think of deal with the iterative process of 
development, make a change, clean all modules, install all modules etc
Regardless it could serve some usefulness in CI or release management 
regardless.  

So say you wanted to clean all modules, you could do a mvn clean followed by a 
mvn install in a script or on the command line but what if you could just 
provided this in one command.

For example mvn '{clean install}, {clean deploy}' where it would actually clean 
and install all modules, then if that succeeded it would then clean and deploy 
all projects.  Obviously there are some semantics that are unclear like if the 
second deploy could reuse the previous builds outputs (if clean wasn't done) 
etc.

Unfortunately I can see that the syntax might be confusing and consideration to 
how it would be escaped on different consoles/platforms might be troublesome.  
It might be just that we should stick to scripted process with separate 
executions of the maven binary if we really need this functionality.


> Allow for building of the whole project multiple times (with different 
> phases/goals/lifecycles) but with one command
> 
>
> Key: MNG-6319
> URL: https://issues.apache.org/jira/browse/MNG-6319
> Project: Maven
>  Issue Type: Sub-task
>  Components: FDPFC, Plugins and Lifecycle
>Reporter: Daniel Cruver
>Priority: Trivial
> Fix For: 3.x / Backlog
>
>
> Most of the use cases I can think of deal with the iterative process of 
> development, make a change, clean all modules, install all modules etc
> Regardless it could serve some usefulness in CI or release management 
> regardless.  
> So say you wanted to clean all modules, you could do a mvn clean followed by 
> a mvn install in a script or on the command line but what if you could just 
> provided this in one command.
> For example mvn {{clean install,clean deploy}} where it would actually clean 
> and install all modules, then if that succeeded it would then clean and 
> deploy all projects.  Obviously there are some semantics that are unclear 
> like if the second deploy could reuse the previous builds outputs (if clean 
> wasn't done) etc.
> Unfortunately I can see that the syntax might be confusing and consideration 
> to how it would be escaped on different consoles/platforms might be 
> troublesome.  It might be just that we should stick to scripted process with 
> separate executions of the maven binary if we really need this functionality.



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

[jira] [Commented] (MNG-6319) Allow for building of the whole project multiple times (with different phases/goals/lifecycles) but with one command

[Robert Scholte (JIRA)]

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

Robert Scholte commented on MNG-6319:
-

I've changed the markup a nity, assuming this is what you meant.
Have you tried {{clean install clean deploy}} because I think it does exactly 
what you describe. 
But what you want to achieve by first install for all modules, then clean and 
deploy? Why do you want to do an install first?
Looks like you want MNG-5666

> Allow for building of the whole project multiple times (with different 
> phases/goals/lifecycles) but with one command
> 
>
> Key: MNG-6319
> URL: https://issues.apache.org/jira/browse/MNG-6319
> Project: Maven
>  Issue Type: Sub-task
>  Components: FDPFC, Plugins and Lifecycle
>Reporter: Daniel Cruver
>Priority: Trivial
> Fix For: 3.x / Backlog
>
>
> Most of the use cases I can think of deal with the iterative process of 
> development, make a change, clean all modules, install all modules etc
> Regardless it could serve some usefulness in CI or release management 
> regardless.  
> So say you wanted to clean all modules, you could do a mvn clean followed by 
> a mvn install in a script or on the command line but what if you could just 
> provided this in one command.
> For example mvn {{clean install,clean deploy}} where it would actually clean 
> and install all modules, then if that succeeded it would then clean and 
> deploy all projects.  Obviously there are some semantics that are unclear 
> like if the second deploy could reuse the previous builds outputs (if clean 
> wasn't done) etc.
> Unfortunately I can see that the syntax might be confusing and consideration 
> to how it would be escaped on different consoles/platforms might be 
> troublesome.  It might be just that we should stick to scripted process with 
> separate executions of the maven binary if we really need this functionality.



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

[jira] [Commented] (MNG-5885) Optimize execution when phases of same lifecycle are called

[Robert Scholte (JIRA)]

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

Robert Scholte commented on MNG-5885:
-

An error is way too offensive to me. And I expect that the meaning of this 
command gets a new meaning in a multimodule project: run up this phase for 
every module before continuing up until the next phase. I still need to work on 
this...

> Optimize execution when phases of same lifecycle are called
> ---
>
> Key: MNG-5885
> URL: https://issues.apache.org/jira/browse/MNG-5885
> Project: Maven
>  Issue Type: Sub-task
>  Components: Plugins and Lifecycle
>Affects Versions: 3.3.3
>Reporter: Robert Scholte
> Fix For: 3.x / Backlog
>
>
> In case someone calls {{compile package}} there's no need for the separate 
> {{compile}} call. Now the lifecycle is executed twice: once until {{compile}} 
> and once again until {{package}}.
> Note: {{package compile}} is weird due to its order, but should not be 
> optimized. {{compile resources:copy-resources package}} is a bit complicated. 
> Ideally this should call all phases up until {{compile}}, followed by 
> {{resources:copy-resources}}, followed by the {{process-classes}} to 
> {{package}} phases.



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

[jira] [Created] (MINSTALL-139) Maven 3.3.9 builds stop working on 12/6/17

[Howard vanfleet (JIRA)]

Howard vanfleet created MINSTALL-139:


 Summary: Maven 3.3.9 builds stop working on 12/6/17
 Key: MINSTALL-139
 URL: https://issues.apache.org/jira/browse/MINSTALL-139
 Project: Maven Install Plugin
  Issue Type: Bug
  Components: install:install
Affects Versions: 2.5.2
 Environment: Linux RedHat 7
Reporter: Howard vanfleet
 Attachments: Maven_3.3.9_error_log.txt

All our builds using maven 3.3.9 stopped working on 12/6/17.
If we change our maven version back to version 3.5.x the builds are successful.

I'm not sure it's the maven.install plugin. If we run "mvn clean package" and 
not "mvn clean install" then the maven 3.3.9 build is successful.






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

[jira] [Commented] (MJAVADOC-501) Plugin breaks source code that contains anonymous instantiation of inner class

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16284233#comment-16284233
 ] 

Michael Osipov commented on MJAVADOC-501:
-

Please provide a sample project.

> Plugin breaks source code that contains anonymous instantiation of inner class
> --
>
> Key: MJAVADOC-501
> URL: https://issues.apache.org/jira/browse/MJAVADOC-501
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 2.10.4
> Environment: Maven home: /usr/local/Cellar/maven/3.5.0/libexec
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.1", arch: "x86_64", family: "mac"
>Reporter: Jan-Willem Gmelig Meyling
>Priority: Minor
>
> I have a very weird case where the plugin alters my generated sources in such 
> a way that the code doesn't even compile anymore, and then fails to generate 
> a Javadoc report. Not sure if this is caused by the plugin or Javadoc itself.
> My code is as follows:
> *A.java*
> {code:java}
> public class A {
>  @AllArgsConstructor public class B {
>  String s;
>  }
> }
> {code}
> *C.java*
> {code:java}
> public class C {
>  @Value public class D {
> A a;
> public B test(String s) {
>return a.new B(s) {} // This compiles perfectly fine
> }
>  }
> }
> {code}
> The problem is within *C.java*, where its contents get replaced with
> {code:java}
> public class C {
>  @Value public class D {
> A a;
> public B test(String s) {
>return new B(a<*nullchk*>, s) {} // This is the part that 
> won't compile
> }
>  }
> }
> {code}
> Which its somewhat similar to the underlying bytecode but certainly not 
> correct code! I am also quite surprised that the plugin seems to alter my 
> generated source code files.



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

[jira] [Closed] (SCM-856) use objects as String without calling the toString method

[Michael Osipov (JIRA)]

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

Michael Osipov closed SCM-856.
--
Resolution: Not A Problem

The {{File}} will be coerced to string automatically by calling its 
{{toString}} method. I see no reson to add the obvious to the code.

> use objects as String without calling the toString method
> -
>
> Key: SCM-856
> URL: https://issues.apache.org/jira/browse/SCM-856
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-plugin
>Affects Versions: 1.9.5
>Reporter: songwanging
>Priority: Minor
>
> Our tool DeepTect has detected two buggy code snippets, in which the code 
> prints out an object without calling the toString method:
> Path: 
> maven-scm/maven-scm-plugin/src/main/java/org/apache/maven/scm/plugin/ExportMojo.java
> {code:java}
> this.exportDirectory = new File( this.getBasedir(), "target/export" );
> ...
> this.getLog().info( "Removing " + this.exportDirectory );
> ...
>  throw new MojoExecutionException( "Cannot create " + this.exportDirectory );
> {code}



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

[jira] [Updated] (MJAVADOC-503) Links from package-info.java to classes do no longer work

[Michael Osipov (JIRA)]

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

Michael Osipov updated MJAVADOC-503:

Summary: Links from package-info.java to classes do no longer work   (was: 
link from package-info.java to classes do no longer work )

> Links from package-info.java to classes do no longer work 
> --
>
> Key: MJAVADOC-503
> URL: https://issues.apache.org/jira/browse/MJAVADOC-503
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 3.0.0
> Environment: linux
>Reporter: Ernst Reissner
>
> This bug has been introduced in version 3.0.0, definitively not present in 
> 3.0;0.-M1: 
> {@link ClassName} within package-info.java no longer works for ClassName in 
> the same package. 



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

[jira] [Commented] (MJAVADOC-503) link from package-info.java to classes do no longer work

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16284245#comment-16284245
 ] 

Michael Osipov commented on MJAVADOC-503:
-

Sample project would be nice to turn into an IT.

> link from package-info.java to classes do no longer work 
> -
>
> Key: MJAVADOC-503
> URL: https://issues.apache.org/jira/browse/MJAVADOC-503
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 3.0.0
> Environment: linux
>Reporter: Ernst Reissner
>
> This bug has been introduced in version 3.0.0, definitively not present in 
> 3.0;0.-M1: 
> {@link ClassName} within package-info.java no longer works for ClassName in 
> the same package. 



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

[jira] [Commented] (SUREFIRE-1451) Surefire Booter compatibility with NetBSD ps(1) output

[Michael Osipov (JIRA)]

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

Michael Osipov commented on SUREFIRE-1451:
--

[~tnn], I consider this to be a bug in NetBSD's {{ps(1)}} implementation. We 
have tested it with FreeBSD's one. The 
[manpage|http://netbsd.gw.com/cgi-bin/man-cgi?ps++NetBSD-current] says: "etime  
 elapsed time since the process was started, in the form 
\[\[dd-\]hh:\]mm:ss". You should report an issue with NetBSD and have it fixed 
in {{CURRENT}} and then MFCed to {{STABLE}}. Though, some leniency is fine 
here. The [FreeBSD 
code|https://github.com/freebsd/freebsd/blob/master/bin/ps/print.c#L581-L603] 
seems to be idiot-proof.

> Surefire Booter compatibility with NetBSD ps(1) output
> --
>
> Key: SUREFIRE-1451
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1451
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1
> Environment: NetBSD
>Reporter: Tobias Nygren
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 2.21.0.Jigsaw
>
>
> On NetBSD The /bin/ps command reports time as 0:01 rather than 00:01 for 
> intervals shorter than 10 minutes.
> The pattern as used [here in SureFire 
> Booter|https://github.com/apache/maven-surefire/commit/c343cc412b986fd9da839696c709542d03679d68#diff-33826e7c2cc48fb008e88914fd841d10R71]
>  to parse ps(1) output does not take this into account.
> printf(3) logic for ps(1) can be found in the [ps 
> source|https://github.com/NetBSD/src/blob/9160f3e067c6f959b9ecb4296771d8a6ae9b3ee6/bin/ps/print.c#L832].
> The following patterns are possible and need to be accounted for:
> * m:ss
> * mm:ss
> * h:mm:ss
> * hh:mm:ss
> * d-hh:mm:ss
> * dd-hh:mm:ss



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

[jira] [Commented] (WAGON-493) Maven wagon-scm documentation is erroneous

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/WAGON-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16284262#comment-16284262
 ] 

Michael Osipov commented on WAGON-493:
--

I'd be happy to merge a PR!

> Maven wagon-scm documentation is erroneous
> --
>
> Key: WAGON-493
> URL: https://issues.apache.org/jira/browse/WAGON-493
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-scm
>Affects Versions: 3.0.0
>Reporter: Charlie Mordant
>Priority: Critical
>
> The documentation stated many wrong things:
> * Using extensions for providers does not work with maven-site-pg: you should 
> use site-plugin dependency section instead
> * The scmVersionType and scmVersion tags on settings shall be enclosed by a 
> {code:xml}
> 
> {code}
> Section.
> Regards,
>  



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

[jira] [Commented] (MRESOLVER-36) SLFJ - remove LoggerFactory from dependency injection

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16284267#comment-16284267
 ] 

Michael Osipov commented on MRESOLVER-36:
-

Makes sense! Willing to merge a PR.

> SLFJ - remove LoggerFactory from dependency injection
> -
>
> Key: MRESOLVER-36
> URL: https://issues.apache.org/jira/browse/MRESOLVER-36
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: resolver
>Affects Versions: Maven Artifact Resolver 1.1.1
>Reporter: Sylwester Lachiewicz
>Priority: Minor
>
> Because Maven moved to SL4J as the primary login structure we can remove 
> {{NullLoggerFactory}} class and replace {{loggerFactory}} variables with 
> {{LoggerFactory.getLogger}}
> To maintain compatibility constructors will be Deprecated



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

[jira] [Commented] (WAGON-492) Using Wagon component with Spring

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/WAGON-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16284270#comment-16284270
 ] 

Michael Osipov commented on WAGON-492:
--

Can you provide a sample project, XML beans or Java beans?

> Using Wagon component with Spring
> -
>
> Key: WAGON-492
> URL: https://issues.apache.org/jira/browse/WAGON-492
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-provider-api
>Affects Versions: 2.12
>Reporter: Laurent Granié
> Attachments: DownloaderBean.java
>
>
> I'm using Wagon with Spring.
> With version 2.10 it's ok. But since version 2.12 I can not load component 
> into Spring.
> You can find my DownloaderServiceBean attached.
> The error is like :
> Unsatisfied dependency expressed through field 'downloader': Error
> creating bean with name 'downloaderBean': Invocation of init method
> failed; nested exception is java.lang.NoSuchMethodError:
> org.codehaus.plexus.configuration.PlexusConfiguration.setName(Ljava/lang/String;)V;
> nested exception is
> org.springframework.beans.factory.BeanCreationException: Error
> creating bean with name 'downloaderBean': Invocation of init method
> failed; nested exception is java.lang.NoSuchMethodError:
> org.codehaus.plexus.configuration.PlexusConfiguration.setName(Ljava/lang/String;)V



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

[GitHub] maven-scm issue #57: [SCM-853] Bootstrap-changes-for-checkout-and-update

[michael-o]

Github user michael-o commented on the issue:

https://github.com/apache/maven-scm/pull/57
  
Please squash.


---

[jira] [Commented] (SCM-853) Bootstrap changes for checkout and update.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16284272#comment-16284272
 ] 

ASF GitHub Bot commented on SCM-853:


Github user michael-o commented on the issue:

https://github.com/apache/maven-scm/pull/57
  
Please squash.


> Bootstrap changes for checkout and update.
> --
>
> Key: SCM-853
> URL: https://issues.apache.org/jira/browse/SCM-853
> Project: Maven SCM
>  Issue Type: Improvement
>  Components: maven-plugin
>Affects Versions: 1.9.6
>Reporter: Yerko Israel Pino Garay
>Priority: Minor
>
> The changes in the bootstrap functionality includes: execute the goals with 
> an update if checkout directory exists or just execute the goals without 
> checkout or update.



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

[jira] [Commented] (MPLUGIN-328) ArrayIndexOutOfBoundsException: 48188

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPLUGIN-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16284274#comment-16284274
 ] 

Michael Osipov commented on MPLUGIN-328:


Sample project please.

> ArrayIndexOutOfBoundsException: 48188 
> --
>
> Key: MPLUGIN-328
> URL: https://issues.apache.org/jira/browse/MPLUGIN-328
> Project: Maven Plugin Tools
>  Issue Type: Bug
>  Components: Plugin Plugin
>Affects Versions: 3.5
> Environment: 
> :\Users\fandre\Documents\MXW\MI\MI-4.1.1\Installer>C:\ASF\apache-maven-3.5.0\bin\mvn
>  -version
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 
> 2017-04-03T21:39:06+02:00)
> Maven home: C:\ASF\apache-maven-3.5.0\bin\..
> Java version: 1.8.0_141, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_141\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: zosrothko
>
> Hi
> Got a ArrayIndexOutOfBoundsException on the maven-plugin-plugin:3.5 with an 
> empty execution element
> {code:java}
> maven-plugin-plugin
> 3.5
>  
>   
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor 
> (default-descriptor) on project scortes-maven-plugin: Execution 
> default-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188 -> 
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor 
> (default-descriptor) on project scortes-maven-plugin: Execution 
> default-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188
> 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:993)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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.PluginExecutionException: Execution 
> default-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188
> at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 20 more
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 48188
> at org.objectweb.asm.ClassReader.readClass(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at 
> org.apache.maven.tools.plugin.extractor.annotations.scanner.DefaultMojoAnnotationsScanner.analyzeClassStream(DefaultMojoAnnotationsScanner.java:215)
> at 
> org.apache.maven.tools.plugin.extractor.annotations.scanner.DefaultMojoAnnotationsScanner.scanArchive(DefaultMojoAnnotationsScanner.java:145)
> at 
> org.apache.maven.tools.plugin.extractor.annotations.scanner.DefaultMojoAnnotationsScanner.scan(DefaultMojoAnnotationsScanner.java:112)
>

[jira] [Updated] (MNG-6300) Multi module release creates empty directories in war file instead of jars

[Robert Scholte (JIRA)]

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

Robert Scholte updated MNG-6300:

Fix Version/s: 3.5.3

> Multi module release creates empty directories in war file instead of jars
> --
>
> Key: MNG-6300
> URL: https://issues.apache.org/jira/browse/MNG-6300
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.2
> Environment: Linux, Oracle java 1.8.0_152
>Reporter: Andreas Kurth
>Priority: Critical
> Fix For: 3.5.3
>
> Attachments: build.log, mm.zip
>
>
> After updating to maven 3.5.2 we encounter the following reproducible bug 
> with multi module builds.
> If one of the modules is a war module and depends on another module, the 
> dependency module will not be included as a jar file in WEB-INF/lib of the 
> war file, but as an empty directory instead. Non module dependencies will be 
> included correctly.
> This bug does occur when the following conditions are met:
> - running release:prepare/release:perform
> -  element is present, so that release goals 
> are "deploy site-deploy"
> -  element contains javadoc-maven-plugin
> Please note that when running "mvn install" or "mvn deploy" the resulting war 
> file is ok, while "mvn release:perform" creates corrupt files as described. 
> Also, if javadoc-maven-plugin is not present in  block, the war 
> file is fine, too.
> I have no idea whether this bug is maven core or rather release-plugin or 
> even javadoc-plugin related, so I file it here. I prepared a minimal self 
> contained example and attach it as mm.zip. To run the example, the following 
> steps are needed:
> {code}
> cd /tmp
> unzip /path/to/mm.zip
> cd mm
> git init
> git add pom.xml mm-lib mm-war .gitignore
> git commit
> mvn release:prepare
> mvn release:perform
> {code}
> After building the resulting corrupt war file can be found here:
> repo/com/example/mm/mm-war/1.0.0/mm-war-1.0.0.war



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

[jira] [Commented] (MNG-6300) Multi module release creates empty directories in war file instead of jars

[Robert Scholte (JIRA)]

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

Robert Scholte commented on MNG-6300:
-

It was kind of tricky to discover the issue, because it looks like any plugin 
interaction might already change the result.

But this seems to be the root cause:
{noformat}
be223808939d75152d7157db33d45f230114555e is the first bad commit
commit be223808939d75152d7157db33d45f230114555e
Author: Anton Tanasenko 
Date:   Wed May 18 18:40:28 2016 +0300

Add a ProjectArtifactsCache similar to PluginArtifactsCache

Signed-off-by: Jason van Zyl 
{noformat}

Must be fixed with the next release.

> Multi module release creates empty directories in war file instead of jars
> --
>
> Key: MNG-6300
> URL: https://issues.apache.org/jira/browse/MNG-6300
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.2
> Environment: Linux, Oracle java 1.8.0_152
>Reporter: Andreas Kurth
>Priority: Critical
> Fix For: 3.5.3
>
> Attachments: build.log, mm.zip
>
>
> After updating to maven 3.5.2 we encounter the following reproducible bug 
> with multi module builds.
> If one of the modules is a war module and depends on another module, the 
> dependency module will not be included as a jar file in WEB-INF/lib of the 
> war file, but as an empty directory instead. Non module dependencies will be 
> included correctly.
> This bug does occur when the following conditions are met:
> - running release:prepare/release:perform
> -  element is present, so that release goals 
> are "deploy site-deploy"
> -  element contains javadoc-maven-plugin
> Please note that when running "mvn install" or "mvn deploy" the resulting war 
> file is ok, while "mvn release:perform" creates corrupt files as described. 
> Also, if javadoc-maven-plugin is not present in  block, the war 
> file is fine, too.
> I have no idea whether this bug is maven core or rather release-plugin or 
> even javadoc-plugin related, so I file it here. I prepared a minimal self 
> contained example and attach it as mm.zip. To run the example, the following 
> steps are needed:
> {code}
> cd /tmp
> unzip /path/to/mm.zip
> cd mm
> git init
> git add pom.xml mm-lib mm-war .gitignore
> git commit
> mvn release:prepare
> mvn release:perform
> {code}
> After building the resulting corrupt war file can be found here:
> repo/com/example/mm/mm-war/1.0.0/mm-war-1.0.0.war



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

[jira] [Created] (MGPG-60) Outdated issue track URL

[JIRA]

Víctor A. Rodríguez created MGPG-60:
---

 Summary: Outdated issue track URL
 Key: MGPG-60
 URL: https://issues.apache.org/jira/browse/MGPG-60
 Project: Maven GPG Plugin
  Issue Type: Bug
Reporter: Víctor A. Rodríguez
Priority: Trivial


At https://maven.apache.org/plugins/maven-gpg-plugin/issue-tracking.html the 
current issue tracker URL is http://jira.codehaus.org/browse/MGPG, being the 
right one https://issues.apache.org/jira/browse/MGPG



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

[jira] [Created] (MGPG-61) Missing profile id at usage page

[JIRA]

Víctor A. Rodríguez created MGPG-61:
---

 Summary: Missing profile id at usage page
 Key: MGPG-61
 URL: https://issues.apache.org/jira/browse/MGPG-61
 Project: Maven GPG Plugin
  Issue Type: Bug
Reporter: Víctor A. Rodríguez
Priority: Trivial


At https://maven.apache.org/plugins/maven-gpg-plugin/usage.html bottom is shown 
settings.xml file to discover the passphrase via the keyname. It doesn't work 
because the id property is missing :

{noformat}

  

  true

[...]

{noformat}

Should be


{noformat}

  
my_profile_id

  true

[...]

{noformat}



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

[jira] [Commented] (SCM-856) use objects as String without calling the toString method

[Niclas Hedhman (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16284615#comment-16284615
 ] 

Niclas Hedhman commented on SCM-856:


Additionally, IF the object is 'null' a toString() cause an NPE. And doing 
Objects.toString(x) is just so ugly.

> use objects as String without calling the toString method
> -
>
> Key: SCM-856
> URL: https://issues.apache.org/jira/browse/SCM-856
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-plugin
>Affects Versions: 1.9.5
>Reporter: songwanging
>Priority: Minor
>
> Our tool DeepTect has detected two buggy code snippets, in which the code 
> prints out an object without calling the toString method:
> Path: 
> maven-scm/maven-scm-plugin/src/main/java/org/apache/maven/scm/plugin/ExportMojo.java
> {code:java}
> this.exportDirectory = new File( this.getBasedir(), "target/export" );
> ...
> this.getLog().info( "Removing " + this.exportDirectory );
> ...
>  throw new MojoExecutionException( "Cannot create " + this.exportDirectory );
> {code}



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