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> A consumer pom will be a fully resolved pom with all parent relationships removed. There will be no build section, no <properties> just GAV and <dependencies> with runtime scope for a 4.0.0 modelVersion. Exclusions will be applied within the <dependencies> to ensure that the expected classpath matches as close as possible that which was computed at deploy time from the builder pom. No profiles as they are undefined behaviour for activation as a dependency. So there is a very clear transformation rule: gav -> gav unchanged. deps -> deps with all properties substituted in, all wildcard exclusions and exclusions resulting from the <provides> transitive tree as of the time of generation in order to give a 4.0.0 consumer as close as possible to the correct dependencies. Part of the reason for these choices is that once there is a modelVersion 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. 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 pom... if that is not what you are doing, my bad. If that is what you want 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 lock-down in 4.0.0 modelVersion poms that we will need to apply or else we will have to go in search of a different term On 3 March 2014 11:31, Jörg Hohwiller <jo...@j-hohwiller.de> wrote: > 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 > havock with the reactor being unable to resolve coordinates that only exist > after the consumer pom is instantiated. > > The idea of a consumer pom is that it is a stripped down pom with the > same coordinates... you can;t have the consumer pom idea pre-model version > 5... what you are attempting is just a fancier version of shade... > > I do not really get what you mean. Maybe you have great thoughts in mind > 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 > 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 > 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. > > 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. > > 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 > problem in a solid way without consumer-maven-plugin, please let me know > and I will just drop it. > > However, I do not want to wait for maven 4 or maven 5 or whatever. I am > 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 > of the idea that will come with later maven versions and we can put our > 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 > may like it and can be ignored by all others. > > Best regards > Jörg >
