Hi Hervé,
On 12/03/17 19:40, Hervé BOUTEMY wrote:
IIUC
You can publish such poms with ${revision}, ${sha1} and/or ${changelist} in
central from the early begining: even MNG-5576 just removed a warning
I didn't remember on that...Thanks for pointing out this.
Then the new commit just make it work better, in more complex multi-module
situations: looks reasonable
I just pushed 2 commits: the first one is to be squashed with previous commit,
since there is some formatting changes that just add unwanted complexity when
reviewing the change.
The other one is just to use the new constants in model validator change done
in MNG-5576
Thank you for cleaning this up...
Kind regards
Karl Heinz
I think this is a fix that could go in alpha-2
Regards,
Hervé
Le dimanche 12 mars 2017, 15:56:09 CET Stephen Connolly a écrit :
On Sun 12 Mar 2017 at 14:36, Karl Heinz Marbaise <[email protected]> wrote:
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 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).
I think you just need to pull it in with one of the bootstrap projects,
then it will. E available
2. WDYT about? Should I postpone that and improve the solution?
If you cannot *consume* published artifacts with this feature *after* your
change... that would be a no... if the situation is same as 3.3.9 for
consumers in a different reactor, the question becomes have you fixed bugs?
3. Should I integrate the current state into the current 3.5.0-alpha-2 ?
If you are adding a feature, -alpha-2 is your last chance to land in 3.5.0,
-beta-1 is only if we need bug-fixes on alpha-2 (or have to revert a
feature that we cannot fix in time)
If you are fixing bugs, and you feel the risk of adding new bugs is low,
then we can consider merging.
The question is really: how is this change making 3.5.0 different from 3.3.9
Kind regards
Karl Heinz Marbaise
[1|: https://github.com/khmarbaise/javaee/tree/mvn321
On 10/03/17 08:26, Stephen Connolly wrote:
Ok no problem
On Fri 10 Mar 2017 at 06:22, Karl Heinz Marbaise <[email protected]>
wrote:
On 10/03/17 00:29, Stephen Connolly wrote:
How are we doing?
Are we ready to freeze?
Can we wait until monday..
I would like to integrate MNG-6170 (which is ready) and currently
working on IT's for MNG-6057, MNG-6090, MNG-5895 which I would like to
integrate into 3.5.0-alpha-2...
So I can work on the IT's over the weekend...
(Unfortunately I can't take a look into JIRA at the moment seemed to
unavailable currently; INFRA knows already about it.)...
Kind regards
Karl Heinz Marbaise
On Sat 4 Mar 2017 at 19:40, Christian Schulte <[email protected]> wrote:
Am 03/04/17 um 18:54 schrieb Hervé BOUTEMY:
I have one question, which is recurring for every issue: what is the
impact?
I understand the logic: it should fix a bug (that is told introduced
in
Maven
3.3.1), and the bug is explained by the logic behind the javadoc.
But no pointer to any code using this method, and that shows that
Maven
3.3.1
does not work any more, when previous version were ok.
Then what is explained here as a bugfix could cause issues for
others.
I'm -1 unless I have some details on the impact
Please see the linked issues. The reporter did a great job finding
out
about when the issue got introduced. His findings are consistent with
<https://issues.apache.org/jira/browse/MNG-5775>
and his analysis also is consistent with
<https://issues.apache.org/jira/browse/MNG-5582>
What impact the changes have, I cannot tell. That's why we should
take
this to JIRA.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
