Hi Karl-Heinz,
the current situation is that if you haven't defined plugin versions, the
version as defined in Maven will be used. So if I use a different version
of Maven, other versions of the plugins might kick in with a different
result.
By moving it to the "packaging" plugin, at least the same versions of
plugins will be used, no matter the version of Maven.
This way there's no such thing as "custom" packaging plugin anymore, they
are all treated the same.
So if the packaging type is jar, the maven-jar-plugin will decide which
versions of resources-, compiler- and other plugins will be used. These
will be the defaults, it is still better to define the versions of these
plugins within every pom.
bq. > maven-install-plugin will define install phase for jar life cycle
maven-jar-plugin will define the package phase for jar life cycle ..
Only the latter. The maven-jar-plugin defines the lifecycle and which
plugins arebound to the phases.
Otherwise there are multiple definitions of the build-lifecycle.
Hervé also said something interesting: by moving lifecycles to the
corresponding plugin, the plugin should be specified with version +
extension=true (as required for custom lifecycles). Maven doesn't isn't
aware of the lifecycles anymore, which is not developer-friendly. So we
still need a mapping from packaging to plugin, and it must be extendable.
Anyhow, we need to copy these things first to the packaging-plugins. Once
these plugins contain the lifecycle mapping we can start adjusting Maven.
thanks,
Robert
On Wed, 20 Apr 2016 20:11:58 +0200, Karl Heinz Marbaise
<[email protected]> wrote:
Hi Robert,
On 4/20/16 9:48 AM, Robert Scholte wrote:
https://issues.apache.org/jira/browse/MJAR-183 should also be good to do
now.
that is: *copy* the lifecycle from core to the plugin.
IIRC it was Igor who told me this was safe to do, Maven has a clear
strategy how to resolve lifecycle handlers, having definitions in both
Maven and the plugin shouldn't be an issue.
I don't have time to test this within the next couple of days, unless we
take some extra time to go through such issues (since this is the 3.0.0
version)
If i correctly understand this means:
<component>
<role>org.apache.maven.artifact.handler.ArtifactHandler</role>
<role-hint>jar</role-hint>
<implementation>org.apache.maven.artifact.handler.DefaultArtifactHandler</implementation>
<configuration>
<type>jar</type>
<language>java</language>
<addedToClasspath>true</addedToClasspath>
</configuration>
</component>
and the following in the artifacts-handler.xml in
src/main/resources/META-INF/plexus/ ....
<component>
<role>org.apache.maven.lifecycle.mapping.LifecycleMapping</role>
<role-hint>jar</role-hint>
<implementation>org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping</implementation>
<configuration>
<lifecycles>
<lifecycle>
<id>default</id>
<!-- START SNIPPET: jar-lifecycle -->
<phases>
<package>
org.apache.maven.plugins:maven-jar-plugin:${project.version}:jar
</package>
</phases>
<!-- END SNIPPET: jar-lifecycle -->
</lifecycle>
</lifecycles>
</configuration>
</component>
But one point i don't understand is of this....for example
if the whole life cycle should be defined by having several plugins
participate into for example the jar life cycle...but the question is:
Do i need to define the whole life cycle with all plugins within the
maven-jar-plugin or should the appropriate plugin only define it's part
of the life cycle ?
Is there a kind of merge for this life cycle mapping if two or more
plugins define parts of the above ...for example:
maven-install-plugin will define install phase for jar life cycle
maven-jar-plugin will define the package phase for jar life cycle ..>
Any ideas / Explanations ?
Kind regards
Karl Heinz Marbaise
Robert
On Tue, 19 Apr 2016 21:27:38 +0200, Robert Scholte
<[email protected]> wrote:
Hi,
Not sure if this is the right moment, but I'd like to make finalName
readonly for all packaging plugins.
The reason: for some new features I probably need to know the name of
the generated (main) artifact, preferably without having to analyze
plugin configuration. Instead, users should use the
project.build.finalName to set its value.
thanks,
Robert
On Tue, 19 Apr 2016 20:46:12 +0200, <[email protected]> wrote:
Author: khmarbaise
Date: Tue Apr 19 18:46:11 2016
New Revision: 1739979
URL: http://svn.apache.org/viewvc?rev=1739979&view=rev
Log:
[MJAR-209] Remove param properties that doesn't make sense for CLI
usage
o Removed the following properties:
- maven.jar.finalName
- maven.jar.skipIfEmpty
- maven.jar.classifier
- maven.jar.testClassifier
Modified:
maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java
maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugins/jar/JarMojo.java
maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugins/jar/TestJarMojo.java
Modified:
maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java
URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java?rev=1739979&r1=1739978&r2=1739979&view=diff
==============================================================================
---
maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java
(original)
+++
maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java
Tue Apr 19 18:46:11 2016
@@ -72,7 +72,7 @@ public abstract class AbstractJarMojo
* Starting with <b>3.0.0</b> the property has been renamed from
<code>jar.finalName</code> to
* <code>maven.jar.finalName</code>.
*/
- @Parameter( property = "maven.jar.finalName", defaultValue =
"${project.build.finalName}" )
+ @Parameter( defaultValue = "${project.build.finalName}" )
private String finalName;
/**
@@ -135,7 +135,7 @@ public abstract class AbstractJarMojo
* Starting with <b>3.0.0</b> the property has been renamed from
<code>jar.skipIfEmpty</code> to
* <code>maven.jar.skipIfEmpty</code>.
*/
- @Parameter( property = "maven.jar.skipIfEmpty", defaultValue =
"false" )
+ @Parameter( defaultValue = "false" )
private boolean skipIfEmpty;
/**
Modified:
maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugins/jar/JarMojo.java
URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugins/jar/JarMojo.java?rev=1739979&r1=1739978&r2=1739979&view=diff
==============================================================================
---
maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugins/jar/JarMojo.java
(original)
+++
maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugins/jar/JarMojo.java
Tue Apr 19 18:46:11 2016
@@ -49,7 +49,7 @@ public class JarMojo
* If not given this will create the main artifact which is the
default behavior.
* If you try to do that a second time without using a
classifier the build will fail.
*/
- @Parameter( property = "maven.jar.classifier" )
+ @Parameter
private String classifier;
protected String getClassifier()
Modified:
maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugins/jar/TestJarMojo.java
URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugins/jar/TestJarMojo.java?rev=1739979&r1=1739978&r2=1739979&view=diff
==============================================================================
---
maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugins/jar/TestJarMojo.java
(original)
+++
maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugins/jar/TestJarMojo.java
Tue Apr 19 18:46:11 2016
@@ -55,7 +55,7 @@ public class TestJarMojo
/**
* Classifier to used for {@code test-jar}.
*/
- @Parameter( property = "maven.jar.testClassifier", defaultValue
= "tests" )
+ @Parameter( defaultValue = "tests" )
private String classifier;
protected String getClassifier()
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
