> The flatten-maven-plugin solution appears to me like a workaround for
> some missing support in Maven core. Also a good reason to split build
> pom from deployed pom. Maybe all of this better be postponed to model
> version 5.0.0?
splitting build pom from deployed (or consumer) pom IMHO is:
1. not a workaround
2. exactly what we need *before* working on model 5.0.0
Regards,
Hervé
Le lundi 13 mars 2017, 02:00:24 CET Christian Schulte a écrit :
> Am 03/12/17 um 15:36 schrieb Karl Heinz Marbaise:
> > Hi,
> >
> > So after I finalized the implementation which seemed to be ok for
> > now...the IT's are currently not working based on particular reason
> > (explanations later).
> >
> > I would like to know the opinion of the Maven DEV's about this:
> >
> > The following scenario:
> >
> > This feature has been introduced in Maven 3.2.1 but with some issues
> > (ordering in reactor etc.).
> >
> > By using this branch MNG-6057 (MNG-6090, MNG-5895) you can use things
> > like ${revision}, ${sha1} and/or ${changelist} in your version tag of
> > your pom.
> > This means you can define the revision by simply using it for the whole
> > multi module build (also for a single project) and you can defined a
> > revision of your artifacts by simply using a property in your pom file
> > (only a single one). Take a look at an example[1].
> >
> > You can build everything. It is also possible to overwrite the revision
> > via command line like this: mvn clean package -Drevision=2.4.5 or using
> > .mvn/maven.config file..for this instead of using the pom file property.
> >
> > The only thing which is cirtical from my point of view if you will do an
> > mvn install or mvn deploy...
> >
> > The problem is simply that at the moment the pom's which will be
> > installed into local cache or in a remote repository having the
> > ${revision} etc. in their version tag and the placeholders
> > revision,sha1,changelist are not being replaced with the current literal
> > version.
>
> This is a very long standing issue. Quite a lot of people gave up on
> some "feature" because it lead to non-deployable projects.
>
> > This can be solved by using the flatten-maven-plugin (I think this
> > should be integrated into Maven itself in the furture maybe in Maven
> > 3.6.0?? but this is a different story.).
> >
> > If you take this change you can define the version of your build
> > artifacts either by command line or with a single property which several
> > people asked for...which would make it very convenient to build
> > different branches by using different versions ...etc.
> >
> > This leaves some questions from my side:
> >
> > 1. How can I use the flatten-maven-plugin inside the IT's ? (It looks
> > like I oversight something here).
> >
> > 2. WDYT about? Should I postpone that and improve the solution?
>
> I would go for improving this until everything has landed in Maven core
> and Maven gets the job done automatically without anyone having to setup
> some special plugins changing the in memory effective model temporarily.
> The flatten-maven-plugin solution appears to me like a workaround for
> some missing support in Maven core. Also a good reason to split build
> pom from deployed pom. Maybe all of this better be postponed to model
> version 5.0.0?
>
> > 3. Should I integrate the current state into the current 3.5.0-alpha-2 ?
>
> Commit it now, and you will never have a chance to improve the solution
> later. Once released, it's nearly impossible to even fix a simple bug
> ;-) If it got released with Maven 3.3.9, things already are messed up
> and I wonder how this could get released when even simple bugfixes were
> reverted lately.
>
> Regards,
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
