Re: [mojo-dev] consumer-maven-plugin added to sandbox

[Jörg Hohwiller]

Hi there,


> - name
> - description
> - url
> - inceptionyear
> - scm



Best regards
  Jörg

Am 03.03.2014 23:07, schrieb Robert Scholte:

as suggested by Robert, I removed these options in the POM generated by the plugin: Is there anything else to do? Who can have a look and decide whether we can keep the name and follow the same ideas or if we have to rename the plugin? I do not care about the name, but I would love to get this out of sandbox and have an initial release. From all my tests this is providing a workaround for various problems reported. Therefore I already added comments to ~5 JIRA issues with the link to the plugin. Hopefully some people can test it early on and give feedback...

Based on my interpretation of http://markmail.org/message/mvorlh6cg6yi3zbg I would say that Jörg wants the consumer-pom 4.0.0. The discussion about this pom started as the "effective pom". However, such pom also contains all build information, so I didn't accept this proposal. If the Apache team (that includes me) wants to claim the term "consumer pom", we could rename the result from this plugin to something like "flatten-pom" (http://jira.codehaus.org/browse/MDEPLOY-173)

Robert

Op Mon, 03 Mar 2014 13:32:09 +0100 schreef Stephen Connolly <stephen.alan.conno...@gmail.com>:

The idea of the consumer/builder pom split is that the GAV coordinates
remain the same.

The consumer pom will actually be two poms.

One modelVersion 4.0.0 for the old consumers

One modelVersion 5.0.0+ for the new consumers

They will both be generated from the builder pom.

The builder pom will not be deployed, unless it has
<packaging>pom</packaging>


removed. There will be no build section, no <properties> just GAV and

matches as close as possible that which was computed at deploy time from

as a dependency.


deps with all properties substituted in, all wildcard exclusions and

generation in order to give a 4.0.0 consumer as close as possible to the
correct dependencies.


5.0.0 we only have to have the consumer pom have a classpath for 4.0.0
consumers as close as possible to what the modelVersion 5.0.0 classpath
is... so we can ignore profiles injecting dependencies because it's evil
and wrong... doing this for 4.0.0 "builder" poms does not allow for the
full set of transformations.

A consumer pom will be a fully resolved pom with all parent relationships <dependencies> with runtime scope for a 4.0.0 modelVersion. Exclusions will be applied within the <dependencies> to ensure that the expected classpath the builder pom. No profiles as they are undefined behaviour for activation So there is a very clear transformation rule: gav -> gav unchanged. deps -> exclusions resulting from the <provides> transitive tree as of the time of Part of the reason for these choices is that once there is a modelVersion What you seem to be doing from the comments I read is something akin to the http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#shadedArtifactIdwhereby

the derived pom is published at a different GAV from the builder

to do, fine...

please do not pollute the term "consumer pom" before we even have it off
the ground... otherwise either our hands will be tied in terms of the

will have to go in search of a different term


On 3 March 2014 11:31, Jörg Hohwiller <jo...@j-hohwiller.de> wrote:

pom... if that is not what you are doing, my bad. If that is what you want lock-down in 4.0.0 modelVersion poms that we will need to apply or else we

 Hi Stephen,

Am 28.02.2014 23:59, schrieb Stephen Connolly:

On 28 February 2014 22:48, Jörg Hohwiller <jo...@j-hohwiller.de> wrote:

Am 27.02.2014 22:12, schrieb Robert Scholte:

Hi Jörg,

Hi Robert,

 I think I found the solution without the Interpolator.
I've written several IT's to confirm this.
If there's a case which isn't coeverd, let me know.

There are cases where your approach does not work. You can also use
variables in groupId and artifactId.

 That is not what the consumer pom is about. Plus you will then play

after the consumer pom is instantiated.

 The idea of a consumer pom is that it is a stripped down pom with the

5... what you are attempting is just a fancier version of shade...


that I can not follow from your statements.
First of all, I was having a discussion about some problems with
maintenance of large maven projects where IMHO no real solution is

this is somewhat what is called a consumer POM and pointed me to the
discsussion about model 5.0.0.
We exchanged some ideas and I wanted to make progress and started with
consumer-maven-plugin.



2. I can not see what the plugin has to do with maven-shade-plugin

3. If there is any other solution yet available for maven to solve my

and I will just drop it.

However, I do not want to wait for maven 4 or maven 5 or whatever. I am

of the idea that will come with later maven versions and we can put our

may like it and can be ignored by all others.

Best regards
  Jörg

havock with the reactor being unable to resolve coordinates that only exist same coordinates... you can;t have the consumer pom idea pre-model version I do not really get what you mean. Maybe you have great thoughts in mind available yet. My idea was to install and deploy a POM that is decoupled from the parent POMs and could also be "minified". Robert Scholte said that 1. if the name is odd, because the plugin is trying something other than what the majority calls a consumer POM, we could just rename the plugin. problem in a solid way without consumer-maven-plugin, please let me know having a real pain with maven for years that can be perfectly solved with consumer-maven-plugin. There are various JIRA issues about the maintenance of module versions in large maven projects that could as a workaround be solved with consumer-maven-plugin. So far I thought that this is a subset ideas together to get consumer-maven-plugin in the right direction and have it as a reduced and intermediate solution for what is to come in the future. If that is not the case, then it is just a workaround for some guys that

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

smime.p7s
Description: S/MIME Cryptographic Signature