You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Karl Heinz Marbaise <kh...@gmx.de> on 2017/03/12 14:36:08 UTC
Re: Timeline for 3.5.0-alpha-2 / MNG-6057
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).
2. WDYT about? Should I postpone that and improve the solution?
3. Should I integrate the current state into the current 3.5.0-alpha-2 ?
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 <kh...@gmx.de> 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 <cs...@schulte.it> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>> --
>>> Sent from my phone
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> --
> Sent from my phone
>
Mit freundlichem Gru�
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz Marbaise USt.IdNr: DE191347579
Hauptstrasse 177
52146 W�rselen http://www.soebes.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Timeline for 3.5.0-alpha-2 / MNG-6057
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
So if no one has objections against this change I would like to do the
merge to master monday evening...
I will wait for the IT's results first ...
Kind regards
Karl Heinz Marbaise
On 12/03/17 19:47, Karl Heinz Marbaise wrote:
> 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 <kh...@gmx.de>
>>> 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 <kh...@gmx.de>
>>>>
>>>> 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 <cs...@schulte.it> 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: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>> --
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Timeline for 3.5.0-alpha-2 / MNG-6057
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
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 <kh...@gmx.de> 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 <kh...@gmx.de>
>>>
>>> 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 <cs...@schulte.it> 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: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>> --
>>>>>>
>>>>>> Sent from my phone
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>> --
>>>>
>>>> Sent from my phone
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Timeline for 3.5.0-alpha-2 / MNG-6057
Posted by Hervé BOUTEMY <he...@free.fr>.
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
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
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 <kh...@gmx.de> 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 <kh...@gmx.de>
> >
> > 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 <cs...@schulte.it> 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: dev-unsubscribe@maven.apache.org
> > >>>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>>
> > >>>> --
> > >>>
> > >>> Sent from my phone
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >>
> > >> --
> > >
> > > Sent from my phone
> >
> > Mit freundlichem Gruß
> > Karl-Heinz Marbaise
> > --
> > SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
> > Dipl.Ing.(FH) Karl-Heinz Marbaise USt.IdNr: DE191347579
> > Hauptstrasse 177
> > 52146 Würselen http://www.soebes.de
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > --
>
> Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Timeline for 3.5.0-alpha-2 / MNG-6057
Posted by Christian Schulte <cs...@schulte.it>.
Am 03/13/17 um 08:33 schrieb Herv BOUTEMY:
>> 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
I did not object to anything. I am just wondering how compatible that is
to that "the model version 4.0.0 ship has sailed" statement. If a pom
gets deployed to central using a version expression, no one can consume
such a project. The warnings about "version must be a constant" were
there for a reason. Allowing just a few expressions is not different to
allowing all kinds of expressions. We could allow expressions in
versions like in Maven 2 again and make that a supported feature, if
Maven core can deal with it correctly (by never allowing anything like
that to appear in any repository).
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Timeline for 3.5.0-alpha-2 / MNG-6057
Posted by Hervé BOUTEMY <he...@free.fr>.
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Timeline for 3.5.0-alpha-2 / MNG-6057
Posted by Christian Schulte <cs...@schulte.it>.
Am 03/14/17 um 21:24 schrieb Stephen Connolly:
> Not so easy. Was attempted before and hit issues with gpg signing.
Can you remember what issues that were? It will sign the temporary pom
java.io.File the same way the install plugin will install that and the
deploy plugin will deploy that. Completely transparent to the plugins.
Only issue I see could be with release:prepare. It would get the
temporary file as it's input and then maybe would update the wrong files
on disk. Either the causing issue is that the in-memory model with the
version expressions interpolated does not exist as a java.io.File
anywhere so that plugins processing the model based on java.io.File
could get confused or the causing issue is the plugins not processing
the in-memory effective model but the raw java.io.File.
>
> Not in scope for 3.5.0
Ok.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Timeline for 3.5.0-alpha-2 / MNG-6057
Posted by Stephen Connolly <st...@gmail.com>.
Not so easy. Was attempted before and hit issues with gpg signing.
Not in scope for 3.5.0
On Tue 14 Mar 2017 at 18:58, Christian Schulte <cs...@schulte.it> wrote:
> Am 12.03.2017 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...
>
> Looking at those changes, I think the solution to this is very
> straightforward. We could easily serialize the raw model with just the
> interpolated versions to a temporary file and continue with that. Would
> this work? Just a few lines of code FIX-3.5.0 without the need of the
> flatten-maven-plugin for anything. We just serialize a temporary
> deleteOnExit pom and make the core provide that file instead of the
> original one.
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
Sent from my phone
Re: Timeline for 3.5.0-alpha-2 / MNG-6057
Posted by Christian Schulte <cs...@schulte.it>.
Am 12.03.2017 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...
Looking at those changes, I think the solution to this is very
straightforward. We could easily serialize the raw model with just the
interpolated versions to a temporary file and continue with that. Would
this work? Just a few lines of code FIX-3.5.0 without the need of the
flatten-maven-plugin for anything. We just serialize a temporary
deleteOnExit pom and make the core provide that file instead of the
original one.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Timeline for 3.5.0-alpha-2 / MNG-6057
Posted by Christian Schulte <cs...@schulte.it>.
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,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Timeline for 3.5.0-alpha-2 / MNG-6057
Posted by Stephen Connolly <st...@gmail.com>.
On Sun 12 Mar 2017 at 14:36, Karl Heinz Marbaise <kh...@gmx.de> 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 <kh...@gmx.de>
> 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 <cs...@schulte.it> 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: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>> --
> >>> Sent from my phone
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> --
> > Sent from my phone
> >
>
>
> Mit freundlichem Gruß
> Karl-Heinz Marbaise
> --
> SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
> Dipl.Ing.(FH) Karl-Heinz Marbaise USt.IdNr: DE191347579
> Hauptstrasse 177
> 52146 Würselen http://www.soebes.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
Sent from my phone