[jira] [Commented] (MNG-6347) Support custom module lifecycle

2018-02-08 Thread JIRA

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

Hervé Boutemy commented on MNG-6347:


I fixed the typo in issue description: np.

adding generic {{pre-}} and {{post-}} support could be a good idea: worth 
adding this to the work we'll do when working on phases improvements

> Support custom module lifecycle
> ---
>
> Key: MNG-6347
> URL: https://issues.apache.org/jira/browse/MNG-6347
> Project: Maven
>  Issue Type: New Feature
>  Components: core
>Reporter: Romain Manni-Bucau
>Priority: Major
>
> With front builds wired to maven it starts to be challenging to have a 
> functional lifecycle,
> common workaround is to use {{generate-sources}} to setup the node 
> environment (install node + npm install), {{process-sources}} to enrich it 
> with project specific data ({{cp myjslib src/main/frontend/node_module}}), 
> {{generate-resources}} to generate the application (npm build) and 
> build-helper-maven-plugin to add the generated folder 
> ({{src/main/frontend/dist}}) in {{META-INF/resources}} of the produced jar.
> This is just a simple example but it can be much more complex and it is 
> harder and harder to insert steps with the limited phases of the default 
> lifecycle. Also the fact you cannot define the same plugin N times (without 
> having a warning) means it is sometimes not possible to have the right 
> execution order.
> To solve that it would be nice to have a way to specify the order of the 
> executions or add custom phases in between existing ones directly into the 
> project - without having to do it in a plugin/extension.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (WAGON-495) checkoutDirectory leak

2018-02-08 Thread Ilya Basin (JIRA)
Ilya Basin created WAGON-495:


 Summary: checkoutDirectory leak
 Key: WAGON-495
 URL: https://issues.apache.org/jira/browse/WAGON-495
 Project: Maven Wagon
  Issue Type: Bug
  Components: wagon-scm
Affects Versions: 3.0.0, 3.0.1
Reporter: Ilya Basin


During deploy artifacts to SVN an instance of ScmWagon is initialized and 
artifact metadata is downloaded to a local folder. After that maven tries to 
upload the jar file. ScmWagon.put(File,String) is called which internally 
overwrites the checkoutDirectory field and checks out the repo again to another 
temporary folder. The original folder is forgotten.

Maven uploads jars, poms, checksums and for each file ScmWagon checks out a new 
directory.

In the end the closeConnection() method is called which removes the last used 
folder.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (MNG-6347) Support custom module lifecycle

2018-02-08 Thread JIRA

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

Hervé Boutemy updated MNG-6347:
---
Description: 
With front builds wired to maven it starts to be challenging to have a 
functional lifecycle,
common workaround is to use {{generate-sources}} to setup the node environment 
(install node + npm install), {{process-sources}} to enrich it with project 
specific data ({{cp myjslib src/main/frontend/node_module}}), 
{{generate-resources}} to generate the application (npm build) and 
build-helper-maven-plugin to add the generated folder 
({{src/main/frontend/dist}}) in {{META-INF/resources}} of the produced jar.

This is just a simple example but it can be much more complex and it is harder 
and harder to insert steps with the limited phases of the default lifecycle. 
Also the fact you cannot define the same plugin N times (without having a 
warning) means it is sometimes not possible to have the right execution order.

To solve that it would be nice to have a way to specify the order of the 
executions or add custom phases in between existing ones directly into the 
project - without having to do it in a plugin/extension.

  was:
With front builds wired to maven it starts to be challenging to have a 
functional lifecycle,
common workaround is to use {{generate-sources}} to setup the node environment 
(install node + npm install), {{process-sources}} to enrich it with project 
specific data ({{cp myjslib src/main/frontend/node_module}}), 
{{generate-resources}} to generate the application (npm build) and 
build-helper-maven-plugin to add the generated folder 
({{src/main/frontend/dist}}) in {{META-INF/resources}} of the produced jar.

This is just a simple example but it can be much more complex and it is harder 
and harder to insert steps with the limited phases of the default lifecycle. 
Also the fact you can define the same plugin N times without having a warning 
means it is sometimes not possible to have the right execution order.

To solve that it would be nice to have a way to specify the order of the 
executions or add custom phases in between existing ones directly into the 
project - without having to do it in a plugin/extension.


> Support custom module lifecycle
> ---
>
> Key: MNG-6347
> URL: https://issues.apache.org/jira/browse/MNG-6347
> Project: Maven
>  Issue Type: New Feature
>  Components: core
>Reporter: Romain Manni-Bucau
>Priority: Major
>
> With front builds wired to maven it starts to be challenging to have a 
> functional lifecycle,
> common workaround is to use {{generate-sources}} to setup the node 
> environment (install node + npm install), {{process-sources}} to enrich it 
> with project specific data ({{cp myjslib src/main/frontend/node_module}}), 
> {{generate-resources}} to generate the application (npm build) and 
> build-helper-maven-plugin to add the generated folder 
> ({{src/main/frontend/dist}}) in {{META-INF/resources}} of the produced jar.
> This is just a simple example but it can be much more complex and it is 
> harder and harder to insert steps with the limited phases of the default 
> lifecycle. Also the fact you cannot define the same plugin N times (without 
> having a warning) means it is sometimes not possible to have the right 
> execution order.
> To solve that it would be nice to have a way to specify the order of the 
> executions or add custom phases in between existing ones directly into the 
> project - without having to do it in a plugin/extension.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (MSOURCES-107) documentation of configuration

2018-02-08 Thread Ernst Reissner (JIRA)
Ernst Reissner created MSOURCES-107:
---

 Summary: documentation of configuration 
 Key: MSOURCES-107
 URL: https://issues.apache.org/jira/browse/MSOURCES-107
 Project: Maven Source Plugin
  Issue Type: Bug
Affects Versions: 3.0.1
Reporter: Ernst Reissner


Seems as if includes also work. So the documentation for the plugin is 
incomplete.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (MNG-5992) Git passwords are exposed as the Super POM still uses Maven Release Plugin 2.3.2

2018-02-08 Thread JIRA

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

Hervé Boutemy closed MNG-5992.
--
   Resolution: Fixed
 Assignee: Hervé Boutemy
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
   3.5.3

https://git-wip-us.apache.org/repos/asf?p=maven.git=commit=085ee9f27508f29ff5cbe418eff0eabc98ad1a95

> Git passwords are exposed as the Super POM still uses Maven Release Plugin 
> 2.3.2
> 
>
> Key: MNG-5992
> URL: https://issues.apache.org/jira/browse/MNG-5992
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap  Build, Plugins and Lifecycle, POM
>Affects Versions: 3.3.3, 3.3.9
> Environment: All
>Reporter: Ryan J. McDonough
>Assignee: Hervé Boutemy
>Priority: Critical
>  Labels: security
> Fix For: 3.5.3
>
>
> The super POM defines version 2.3.2 of the Maven Release plugin. When using 
> HTTP/HTTPS Git SCM URIs, Maven will printout the password in the logs. Thus, 
> any CI system such as Jenkins, TravisCI, etc. will have the passwords exposed 
> in the logs and in the console output. In the case of TravisCI, this will be 
> publicly visible. 
> The [Maven Release Plugin fixed this issue in 
> MRELEASE-846|https://issues.apache.org/jira/browse/MRELEASE-846], but Maven 
> core is still pointing at an exposed version of the Maven Release plugin. I 
> have a test case that demonstrates the issue here:
> https://github.com/damnhandy/maven-publish-issue
> If you run the same build and explicitly define 2.5.3, the password is no 
> longer displayed. This should be the default. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MTOOLCHAINS-18) toolchain.xml file should support environment variables

2018-02-08 Thread Javier A. Ortiz (JIRA)

[ 
https://issues.apache.org/jira/browse/MTOOLCHAINS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16357508#comment-16357508
 ] 

Javier A. Ortiz commented on MTOOLCHAINS-18:


I completely agree. I tried this and was surprised to see it doesn't work like 
any other maven configuration file.

Kind of beats the purpose if it needs to be updated as well as the environment 
variables.

> toolchain.xml file should support environment variables
> ---
>
> Key: MTOOLCHAINS-18
> URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-18
> Project: Maven Toolchains Plugin
>  Issue Type: Improvement
>Affects Versions: 1.1
> Environment: Windows 7 64bit
>Reporter: Nicolas Radde
>Priority: Minor
>
> When the toolchain.xml file is configured as follow :
> {code:xml}
> 
> jdk
> 
>   1.8
>   sun
> 
> 
>   ${env.JDK_HOME_8}
> 
> 
> {code}
> The execution of a maven compile fail with the following error :
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-toolchains-plugin:
> 1.1:toolchain (default) on project monitoring-mq-web: Misconfigured 
> toolchains.
> Non-existing JDK home configuration at 
> L:\test-monitoring-mq\${env.JDK_HOME_8} -> [Help 1]
> {noformat}
> While the environment variable *JDK_HOME_8* exist.
> Using environment variable is a very convenient way to have the same 
> toolchain.xml file for all developers or jenkins slaves and would be a nice 
> addition to the plugin.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (MNG-6352) Printout version information at the end of the build

2018-02-08 Thread Karl Heinz Marbaise (JIRA)

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

Karl Heinz Marbaise edited comment on MNG-6352 at 2/8/18 7:45 PM:
--

Aggregator looks like this:
{code}
[INFO] Apache Maven Dependency Plugin . SUCCESS [  0.818 s]
[INFO] Apache Maven GPG Plugin  SUCCESS [  0.015 s]
[INFO] Apache Maven Plugins Aggregator  SUCCESS [  0.011 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO]
[INFO] Version Summary:
[INFO]
[INFO] Apache Maven Plugins Aggregator [1-SNAPSHOT]
[INFO] Apache Maven ACR Plugin [3.0.1-SNAPSHOT]
[INFO] Apache Maven AntRun Plugin  [3.0.0-SNAPSHOT]
[INFO] Apache Maven Changelog Plugin [2.4-SNAPSHOT]
[INFO] Apache Maven Changes Plugin [3.0.0-SNAPSHOT]
[INFO] Apache Maven Clean Plugin   [3.0.1-SNAPSHOT]
[INFO] Apache Maven Compiler Plugin[3.7.1-SNAPSHOT]
[INFO] Apache Maven Deploy Plugin  [3.0.0-SNAPSHOT]
[INFO] Apache Maven Documentation Checker Plugin [1.2-SNAPSHOT]
[INFO] Apache Maven EAR Plugin [3.0.0-SNAPSHOT]
[INFO] Apache Maven EJB Plugin [3.0.1-SNAPSHOT]
[INFO] Apache Maven Help Plugin[3.0.0-SNAPSHOT]
[INFO] Apache Maven Install Plugin [3.0.0-SNAPSHOT]
[INFO] Apache Maven Jarsigner Plugin [1.5-SNAPSHOT]
[INFO] Apache Maven JDeps Plugin   [3.1.1-SNAPSHOT]
[INFO] Apache Maven Linkcheck Plugin [1.3-SNAPSHOT]
[INFO] Apache Maven Patch Plugin [1.3-SNAPSHOT]
[INFO] Apache Maven PDF Plugin   [1.4-SNAPSHOT]
[INFO] Apache Maven RAR Plugin [3.0.0-SNAPSHOT]
[INFO] Apache Maven Repository Plugin[2.5-SNAPSHOT]
[INFO] Apache Maven Resources Plugin   [3.0.3-SNAPSHOT]
[INFO] Apache Maven Site Plugin  [3.7-SNAPSHOT]
[INFO] Apache Maven Source Plugin  [3.0.2-SNAPSHOT]
[INFO] Apache Maven Stage Plugin [1.1-SNAPSHOT]
[INFO] Apache Maven Toolchains Plugin  [3.0.0-SNAPSHOT]
[INFO] Apache Maven Verifier Plugin[3.0.0-SNAPSHOT]
[INFO] Apache Maven WAR Plugin [3.2.1-SNAPSHOT]
[INFO] Apache Maven DOAP Plugin  [1.3-SNAPSHOT]
[INFO] Apache Maven Invoker Plugin [3.0.2-SNAPSHOT]
[INFO] Apache Maven JAR Plugin [3.0.3-SNAPSHOT]
[INFO] Apache Maven Assembly Plugin[3.1.1-SNAPSHOT]
[INFO] Apache Maven Checkstyle Plugin  [3.0.0-SNAPSHOT]
[INFO] Apache Maven Javadoc Plugin [3.0.0-SNAPSHOT]
[INFO] Apache Maven PMD Plugin   [3.9-SNAPSHOT]
[INFO] Apache Maven JLink Plugin   [3.0.0-alpha-2-SNAPSHOT]
[INFO] Apache Maven JMod Plugin[3.0.0-alpha-2-SNAPSHOT]
[INFO] Apache Maven Project Info Reports Plugin [2.10-SNAPSHOT]
[INFO] Apache Maven Remote Resources Plugin  [1.6-SNAPSHOT]
[INFO] Apache Maven Shade Plugin   [3.1.1-SNAPSHOT]
[INFO] Apache Maven SCM Publish Plugin   [1.2-SNAPSHOT]
[INFO] Apache Maven Dependency Plugin  [3.0.3-SNAPSHOT]
[INFO] Apache Maven GPG Plugin   [1.7-SNAPSHOT]
[INFO] 
[INFO] Total time: 17.639 s
[INFO] Finished at: 2018-02-08T20:22:41+01:00
[INFO] 
{code}
The result will look like this where we have the same version in reactor:
{code}
[INFO] Reactor Summary:
[INFO]
[INFO] parent . SUCCESS [  0.239 s]
[INFO] domain . SUCCESS [  0.002 s]
[INFO] service-client . SUCCESS [  0.002 s]
[INFO] webgui . SUCCESS [  0.002 s]
[INFO] service  SUCCESS [  0.002 s]
[INFO] app  SUCCESS [  0.003 s]
[INFO] appasm 

[jira] [Commented] (MNG-6352) Printout version information at the end of the build

2018-02-08 Thread Karl Heinz Marbaise (JIRA)

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

Karl Heinz Marbaise commented on MNG-6352:
--

{code}
[INFO] Apache Maven Dependency Plugin . SUCCESS [  0.818 s]
[INFO] Apache Maven GPG Plugin  SUCCESS [  0.015 s]
[INFO] Apache Maven Plugins Aggregator  SUCCESS [  0.011 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO]
[INFO] Version Summary:
[INFO]
[INFO] Apache Maven Plugins Aggregator [1-SNAPSHOT]
[INFO] Apache Maven ACR Plugin [3.0.1-SNAPSHOT]
[INFO] Apache Maven AntRun Plugin  [3.0.0-SNAPSHOT]
[INFO] Apache Maven Changelog Plugin [2.4-SNAPSHOT]
[INFO] Apache Maven Changes Plugin [3.0.0-SNAPSHOT]
[INFO] Apache Maven Clean Plugin   [3.0.1-SNAPSHOT]
[INFO] Apache Maven Compiler Plugin[3.7.1-SNAPSHOT]
[INFO] Apache Maven Deploy Plugin  [3.0.0-SNAPSHOT]
[INFO] Apache Maven Documentation Checker Plugin [1.2-SNAPSHOT]
[INFO] Apache Maven EAR Plugin [3.0.0-SNAPSHOT]
[INFO] Apache Maven EJB Plugin [3.0.1-SNAPSHOT]
[INFO] Apache Maven Help Plugin[3.0.0-SNAPSHOT]
[INFO] Apache Maven Install Plugin [3.0.0-SNAPSHOT]
[INFO] Apache Maven Jarsigner Plugin [1.5-SNAPSHOT]
[INFO] Apache Maven JDeps Plugin   [3.1.1-SNAPSHOT]
[INFO] Apache Maven Linkcheck Plugin [1.3-SNAPSHOT]
[INFO] Apache Maven Patch Plugin [1.3-SNAPSHOT]
[INFO] Apache Maven PDF Plugin   [1.4-SNAPSHOT]
[INFO] Apache Maven RAR Plugin [3.0.0-SNAPSHOT]
[INFO] Apache Maven Repository Plugin[2.5-SNAPSHOT]
[INFO] Apache Maven Resources Plugin   [3.0.3-SNAPSHOT]
[INFO] Apache Maven Site Plugin  [3.7-SNAPSHOT]
[INFO] Apache Maven Source Plugin  [3.0.2-SNAPSHOT]
[INFO] Apache Maven Stage Plugin [1.1-SNAPSHOT]
[INFO] Apache Maven Toolchains Plugin  [3.0.0-SNAPSHOT]
[INFO] Apache Maven Verifier Plugin[3.0.0-SNAPSHOT]
[INFO] Apache Maven WAR Plugin [3.2.1-SNAPSHOT]
[INFO] Apache Maven DOAP Plugin  [1.3-SNAPSHOT]
[INFO] Apache Maven Invoker Plugin [3.0.2-SNAPSHOT]
[INFO] Apache Maven JAR Plugin [3.0.3-SNAPSHOT]
[INFO] Apache Maven Assembly Plugin[3.1.1-SNAPSHOT]
[INFO] Apache Maven Checkstyle Plugin  [3.0.0-SNAPSHOT]
[INFO] Apache Maven Javadoc Plugin [3.0.0-SNAPSHOT]
[INFO] Apache Maven PMD Plugin   [3.9-SNAPSHOT]
[INFO] Apache Maven JLink Plugin   [3.0.0-alpha-2-SNAPSHOT]
[INFO] Apache Maven JMod Plugin[3.0.0-alpha-2-SNAPSHOT]
[INFO] Apache Maven Project Info Reports Plugin [2.10-SNAPSHOT]
[INFO] Apache Maven Remote Resources Plugin  [1.6-SNAPSHOT]
[INFO] Apache Maven Shade Plugin   [3.1.1-SNAPSHOT]
[INFO] Apache Maven SCM Publish Plugin   [1.2-SNAPSHOT]
[INFO] Apache Maven Dependency Plugin  [3.0.3-SNAPSHOT]
[INFO] Apache Maven GPG Plugin   [1.7-SNAPSHOT]
[INFO] 
[INFO] Total time: 17.639 s
[INFO] Finished at: 2018-02-08T20:22:41+01:00
[INFO] 
{code}
The result will look like this where we have the same version in reactor:
{code}
[INFO] Reactor Summary:
[INFO]
[INFO] parent . SUCCESS [  0.239 s]
[INFO] domain . SUCCESS [  0.002 s]
[INFO] service-client . SUCCESS [  0.002 s]
[INFO] webgui . SUCCESS [  0.002 s]
[INFO] service  SUCCESS [  0.002 s]
[INFO] app  SUCCESS [  0.003 s]
[INFO] appasm . SUCCESS [  0.002 s]
[INFO] shade 

[jira] [Created] (MJAR-244) Missing documentation: unsatisfied link

2018-02-08 Thread Ernst Reissner (JIRA)
Ernst Reissner created MJAR-244:
---

 Summary: Missing documentation: unsatisfied link 
 Key: MJAR-244
 URL: https://issues.apache.org/jira/browse/MJAR-244
 Project: Maven JAR Plugin
  Issue Type: Bug
  Components: site
Affects Versions: 3.0.2
Reporter: Ernst Reissner


On homepage [https://maven.apache.org/plugins/maven-jar-plugin/]

the link "Creating an executable jar file" is not satisfied.

Is this no longer possible? Then this has to be removed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MNG-6352) Printout version information at the end of the build

2018-02-08 Thread Robert Scholte (JIRA)

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

Robert Scholte commented on MNG-6352:
-

This is not what I expected. This will generate much more output. Why not put 
the version directly after the name in the reactor summary?

> Printout version information at the end of the build
> 
>
> Key: MNG-6352
> URL: https://issues.apache.org/jira/browse/MNG-6352
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.5.2
>Reporter: Karl Heinz Marbaise
>Priority: Trivial
> Fix For: 3.5.3
>
>
> At the end of the buid in particular of a mutli module build we should print 
> the information about the versions of modules (in case of aggregators) or 
> only a single version in case of a multi module build as an information for 
> the user.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (MJAR-245) Additional attached jar: role of classifyer

2018-02-08 Thread Ernst Reissner (JIRA)
Ernst Reissner created MJAR-245:
---

 Summary: Additional attached jar: role of classifyer 
 Key: MJAR-245
 URL: https://issues.apache.org/jira/browse/MJAR-245
 Project: Maven JAR Plugin
  Issue Type: Bug
  Components: site
Affects Versions: 3.0.2
Reporter: Ernst Reissner


On 
[https://maven.apache.org/plugins/maven-jar-plugin/examples/attached-jar.html,]

a classifier is given.

Missing information: creates a jar file:

project-version-classifier.jar.

This is vital.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MNG-6347) Support custom module lifecycle

2018-02-08 Thread Romain Manni-Bucau (JIRA)

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

Romain Manni-Bucau commented on MNG-6347:
-

For the multiple plugin thing: you are right, sorry for the typo.


About "each project will configure his own little local phase": this is sadly 
what is today development. It touches 10% of modules from my experience but you 
are just locked in these 10%. Best case the build is simple and you can 
workaround the lifecycle like I explained but in some cases you just cant.

What about supporting - generalizing - pre/post phases. This way we could use 
pre-generate-sources, post-generate-sources and potentially support N levels 
like pre-pre-generate-sources. It is not the most sexy but has several not 
negligible advantages:

1. it stays standard
2. it encourages to keep the lifecycle the default one and just decorate it 
when needed versus adding dead phases 
3. it is easy to optimize at maven level since it can be skipped when not used
4. it is extensible by design and solves that issue.



> Support custom module lifecycle
> ---
>
> Key: MNG-6347
> URL: https://issues.apache.org/jira/browse/MNG-6347
> Project: Maven
>  Issue Type: New Feature
>  Components: core
>Reporter: Romain Manni-Bucau
>Priority: Major
>
> With front builds wired to maven it starts to be challenging to have a 
> functional lifecycle,
> common workaround is to use {{generate-sources}} to setup the node 
> environment (install node + npm install), {{process-sources}} to enrich it 
> with project specific data ({{cp myjslib src/main/frontend/node_module}}), 
> {{generate-resources}} to generate the application (npm build) and 
> build-helper-maven-plugin to add the generated folder 
> ({{src/main/frontend/dist}}) in {{META-INF/resources}} of the produced jar.
> This is just a simple example but it can be much more complex and it is 
> harder and harder to insert steps with the limited phases of the default 
> lifecycle. Also the fact you can define the same plugin N times without 
> having a warning means it is sometimes not possible to have the right 
> execution order.
> To solve that it would be nice to have a way to specify the order of the 
> executions or add custom phases in between existing ones directly into the 
> project - without having to do it in a plugin/extension.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MWAR-353) Manifest still not written to exploded location

2018-02-08 Thread Jakub Bochenski (JIRA)

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

Jakub Bochenski commented on MWAR-353:
--

{quote}Workaround doesn't work with 3.1.0 as manifest goal was removed{quote}

[~khmarbaise] any chance you could post the "MavenArchiver configuration" that 
can be used to replace the lost functionality?

> Manifest still not written to exploded location
> ---
>
> Key: MWAR-353
> URL: https://issues.apache.org/jira/browse/MWAR-353
> Project: Maven WAR Plugin
>  Issue Type: Bug
>  Components: manifest
>Affects Versions: 2.6
>Reporter: Jakub Bochenski
>Priority: Major
> Fix For: 2.6
>
>
> If I have no manifest files I don't get anything in the exploded location.
> If I put a {{MANIFEST.MF}} under webapp folder's {{META-INF/MANIFEST.MF}} I 
> just get the static file.
> If I set {{archive/manifestFile}} to point at some file I just get the static 
> file.
> Workaround: change
> {code:xml}
>  
>   exploded 
> 
> {code}
> to
> {code:xml}
>  
>   manifest 
>   exploded 
> 
> {code}
>  
> and add the generated files to SCM ignore.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MWAR-379) manifest goal violates general Maven principle and creates file into src/main/..

2018-02-08 Thread Jakub Bochenski (JIRA)

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

Jakub Bochenski commented on MWAR-379:
--

This broke the workaround for MWAR-353. Maybe that bug could get some attention 
then?

> manifest goal violates general Maven principle and creates file into 
> src/main/..
> 
>
> Key: MWAR-379
> URL: https://issues.apache.org/jira/browse/MWAR-379
> Project: Maven WAR Plugin
>  Issue Type: Bug
>  Components: manifest
>Affects Versions: 2.6
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Fix For: 3.0.0
>
>
> Currently the {{manifest}} goal of the war plugin will generate a file 
> {{MANIFEST.MF}} into {{src/main/webapp}} folder and violates Maven principle 
> (cause those folders are under version control). Either the generation should 
> be done into a folder like {{target/WhatEver...}} or the whole goal should be 
> removed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)