Re: Timeline for 3.5.0-alpha-2 / MNG-6057

[Christian Schulte]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Timeline for 3.5.0-alpha-2 / MNG-6057

[Karl Heinz Marbaise]

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 
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 


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  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 

Re: Timeline for 3.5.0-alpha-2 / MNG-6057

[Karl Heinz Marbaise]

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  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 


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  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 

Re: Timeline for 3.5.0-alpha-2 / MNG-6057

[Hervé BOUTEMY]

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  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 
> > 
> > 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  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
> > 

Re: merging MNG-6115-2 branch to master

[Hervé BOUTEMY]

MNG-6186 created to track the issue

https://issues.apache.org/jira/browse/MNG-6186

Le dimanche 12 mars 2017, 17:18:06 CET Hervé BOUTEMY a écrit :
> Le samedi 11 mars 2017, 15:05:18 CET Stephen Connolly a écrit :
> > +1 from me.
> > 
> > Obviously would be better if upstream was fixed that we didn't need the
> > copy but pragmatism says this is the fix for 3.5.0
> > 
> > Extra brownie points for raising the issue upstream and fencing the
> > additions with comments to say "TODO rework/remove when jansi fixes
> > XYZ-123"
> I'm trying to work with HawtJNI project to improve the lib: beginning with
> simpler issues before digging into this more complex update of the lib.
> But showing the integration of native libs done with this banch to HawtJNI
> people should help them understand the idea to have the direct feature in
> HawtJNI: it's a question of chicken and egg :)
> 
> Regards,
> 
> Hervé
> 
> > On Sat 11 Mar 2017 at 14:48, Hervé BOUTEMY  wrote:
> > > there has been some discussion about the way to solve temp file creation
> > > for
> > > native libs used by JAnsi
> > > https://issues.apache.org/jira/browse/MNG-6115
> > > 
> > > Is it ok to merge MNG-6115-2 branch with this commit
> > > http://git-wip-us.apache.org/repos/asf/maven/commit/c36cf425
> > > to master?
> > > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > 
> > > --
> > 
> > Sent from my phone
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Retrospective on Maven 3.5.0-alpha-1

[Hervé BOUTEMY]

my own topics:

What is working well:
1. we're managing to do releases with confidence on what's inside
2. there are some discussions (even if not in an efficient way: IMHO, some 
changes should become proposals in the Wiki)
3. Jenkins hook to check branches (even if not perfect, it works sufficiently 
well and was absolutely necessary for our RTC workflow)

What is not working well:
1. git history is messed with "git merge" commits and originating branches: 
IMHO we should avoid it
2. commits@ is messed with rebase messages: hard to track really useful 
changes
3. I fear once 3.5.0 is out we're back to wild: the process to discuss new 
features, or even non-trivial changes, is not yet strong

Thank you for animating the discussion: it's hard but useful

Regards,

Hervé

Le samedi 11 mars 2017, 21:56:14 CET Stephen Connolly a écrit :
> Hi all,
> 
> I think it is a good thing if we take stock of where we are and how we are
> doing. I would really appreciate if everyone could take a few minutes to
> respond with their top three of two areas:
> 
> * What is working well
> 
> * What is not working well
> 
> I'll consolidate the responses after 72h and see if there are any themes
> that can be identified
> 
> On the stuff that is not working well, I'll try and pick the three most
> popular themes, we can then have a round of discussion on those three
> themes to see if anyone has any ideas to improve those aspects of how we
> work and hopefully we can have some votes to change things for the better.
> 
> By the way, this is open to anyone in any way what so ever involved with
> the Maven 3.5.0-alpha-1 effort (assuming you are paying attention to the
> dev list ;-) )
> 
> Thanks in advance for your time,
> 
> -Stephen
> 
> P.S. As alpha-2 is near, I'll probably wait until after 3.5.0 before I try
> this again (assuming people like this idea)



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: merging MNG-6115-2 branch to master

[Hervé BOUTEMY]

Le samedi 11 mars 2017, 15:05:18 CET Stephen Connolly a écrit :
> +1 from me.
> 
> Obviously would be better if upstream was fixed that we didn't need the
> copy but pragmatism says this is the fix for 3.5.0
> 
> Extra brownie points for raising the issue upstream and fencing the
> additions with comments to say "TODO rework/remove when jansi fixes XYZ-123"
I'm trying to work with HawtJNI project to improve the lib: beginning with 
simpler issues before digging into this more complex update of the lib.
But showing the integration of native libs done with this banch to HawtJNI 
people should help them understand the idea to have the direct feature in 
HawtJNI: it's a question of chicken and egg :)

Regards,

Hervé

> On Sat 11 Mar 2017 at 14:48, Hervé BOUTEMY  wrote:
> > there has been some discussion about the way to solve temp file creation
> > for
> > native libs used by JAnsi
> > https://issues.apache.org/jira/browse/MNG-6115
> > 
> > Is it ok to merge MNG-6115-2 branch with this commit
> > http://git-wip-us.apache.org/repos/asf/maven/commit/c36cf425
> > to master?
> > 
> > Regards,
> > 
> > Hervé
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> > 
> > --
> 
> Sent from my phone



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Timeline for 3.5.0-alpha-2 / MNG-6057

[Stephen Connolly]

On Sun 12 Mar 2017 at 14:36, Karl Heinz Marbaise  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 
> 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  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
> 
>  
> 
>  and his analysis also is consistent with
> 
>  
> 
>  What impact the changes have, I cannot tell. That's why we should take
>  this to JIRA.
> 
> 
>  

Re: [DISCUSS] Retrospective on Maven 3.5.0-alpha-1

[Arnaud Héritier]

Let's try ...

* What is working well

1. Automations/Processes improvements with Jenkins
2. Many more interactions to get the release out (it revivified the dev
community)
3. After so many years we have coloured logging !!! LOL

* What is not working well

1. Our SCM notifications are really not manageable with Git :( (Too much
noise)
2. Deciding what was in scope/out of scope felt like chaos (but it was
highly required)
3. This release is technically a baby step, now let's really move forward
the project (new POM version ...)

Cheers

On Sun, Mar 12, 2017 at 7:59 AM, Robert Scholte 
wrote:

> Let me kick off with my list:
>
> What is working well:
> 1. It looks like we're going to have a new official Maven release soon.
> 2. Some take their responsibility to start a discussion. It is good to
> rate the impact of changes if we want to stay one of the worlds standards.
> 3. We're all passionate, wanting to do the best.
>
> What is not working well:
> 1. Reviewing commits has become too hard with all the "unnecessary"
> commits pulled from master.
> 2. Not enough consensus, some discussions just keep on going without
> ending, either by majority or a solution which works for all parties.
> 3. Number of (active) committers is too low for this huge project.
>
> thanks,
> Robert
>
>
> On Sat, 11 Mar 2017 22:56:14 +0100, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> Hi all,
>>
>> I think it is a good thing if we take stock of where we are and how we are
>> doing. I would really appreciate if everyone could take a few minutes to
>> respond with their top three of two areas:
>>
>> * What is working well
>>
>> * What is not working well
>>
>> I'll consolidate the responses after 72h and see if there are any themes
>> that can be identified
>>
>> On the stuff that is not working well, I'll try and pick the three most
>> popular themes, we can then have a round of discussion on those three
>> themes to see if anyone has any ideas to improve those aspects of how we
>> work and hopefully we can have some votes to change things for the better.
>>
>> By the way, this is open to anyone in any way what so ever involved with
>> the Maven 3.5.0-alpha-1 effort (assuming you are paying attention to the
>> dev list ;-) )
>>
>> Thanks in advance for your time,
>>
>> -Stephen
>>
>> P.S. As alpha-2 is near, I'll probably wait until after 3.5.0 before I try
>> this again (assuming people like this idea)
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: [DISCUSS] Retrospective on Maven 3.5.0-alpha-1

[Stephen Connolly]

Here's my list:

Working well:

1. Jenkinsfile and multibranch
2. Actually discussing changes before merging
3. We got a release at last with coloured logging

Needs improvement:

1. I was not happy at all with the chaos in trying to plan out the scope of
3.5.0
2. Very difficult to determine which branches are in-flight for 3.5.0 vs
future versions and who owns the branches, esp when looking from Jenkins
3. Seems to have been an excessive amount of (seemingly needless) rebasing
of branches, with an impact on our capacity to review commits


On Sat 11 Mar 2017 at 21:56, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Hi all,
>
> I think it is a good thing if we take stock of where we are and how we are
> doing. I would really appreciate if everyone could take a few minutes to
> respond with their top three of two areas:
>
> * What is working well
>
> * What is not working well
>
> I'll consolidate the responses after 72h and see if there are any themes
> that can be identified
>
> On the stuff that is not working well, I'll try and pick the three most
> popular themes, we can then have a round of discussion on those three
> themes to see if anyone has any ideas to improve those aspects of how we
> work and hopefully we can have some votes to change things for the better.
>
> By the way, this is open to anyone in any way what so ever involved with
> the Maven 3.5.0-alpha-1 effort (assuming you are paying attention to the
> dev list ;-) )
>
> Thanks in advance for your time,
>
> -Stephen
>
> P.S. As alpha-2 is near, I'll probably wait until after 3.5.0 before I try
> this again (assuming people like this idea)
>
-- 
Sent from my phone

Re: [DISCUSS] Retrospective on Maven 3.5.0-alpha-1

[Stephen Connolly]

Thanks Robert for seeding contributions .

On Sun 12 Mar 2017 at 11:59, Robert Scholte  wrote:

> Let me kick off with my list:
>
> What is working well:
> 1. It looks like we're going to have a new official Maven release soon.
> 2. Some take their responsibility to start a discussion. It is good to
> rate the impact of changes if we want to stay one of the worlds standards.
> 3. We're all passionate, wanting to do the best.
>
> What is not working well:
> 1. Reviewing commits has become too hard with all the "unnecessary"
> commits pulled from master.
> 2. Not enough consensus, some discussions just keep on going without
> ending, either by majority or a solution which works for all parties.
> 3. Number of (active) committers is too low for this huge project.
>
> thanks,
> Robert
>
> On Sat, 11 Mar 2017 22:56:14 +0100, Stephen Connolly
>  wrote:
>
> > Hi all,
> >
> > I think it is a good thing if we take stock of where we are and how we
> > are
> > doing. I would really appreciate if everyone could take a few minutes to
> > respond with their top three of two areas:
> >
> > * What is working well
> >
> > * What is not working well
> >
> > I'll consolidate the responses after 72h and see if there are any themes
> > that can be identified
> >
> > On the stuff that is not working well, I'll try and pick the three most
> > popular themes, we can then have a round of discussion on those three
> > themes to see if anyone has any ideas to improve those aspects of how we
> > work and hopefully we can have some votes to change things for the
> > better.
> >
> > By the way, this is open to anyone in any way what so ever involved with
> > the Maven 3.5.0-alpha-1 effort (assuming you are paying attention to the
> > dev list ;-) )
> >
> > Thanks in advance for your time,
> >
> > -Stephen
> >
> > P.S. As alpha-2 is near, I'll probably wait until after 3.5.0 before I
> > try
> > this again (assuming people like this idea)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: Timeline for 3.5.0-alpha-2 / MNG-6057

[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 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  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  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



and his analysis also is consistent with



What impact the changes have, I cannot tell. That's why we should take
this to JIRA.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

--

Sent from my phone




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

--

Sent from my phone




Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen   http://www.soebes.de

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Retrospective on Maven 3.5.0-alpha-1

[Robert Scholte]

Let me kick off with my list:

What is working well:
1. It looks like we're going to have a new official Maven release soon.
2. Some take their responsibility to start a discussion. It is good to  
rate the impact of changes if we want to stay one of the worlds standards.

3. We're all passionate, wanting to do the best.

What is not working well:
1. Reviewing commits has become too hard with all the "unnecessary"  
commits pulled from master.
2. Not enough consensus, some discussions just keep on going without  
ending, either by majority or a solution which works for all parties.

3. Number of (active) committers is too low for this huge project.

thanks,
Robert

On Sat, 11 Mar 2017 22:56:14 +0100, Stephen Connolly  
 wrote:



Hi all,

I think it is a good thing if we take stock of where we are and how we  
are

doing. I would really appreciate if everyone could take a few minutes to
respond with their top three of two areas:

* What is working well

* What is not working well

I'll consolidate the responses after 72h and see if there are any themes
that can be identified

On the stuff that is not working well, I'll try and pick the three most
popular themes, we can then have a round of discussion on those three
themes to see if anyone has any ideas to improve those aspects of how we
work and hopefully we can have some votes to change things for the  
better.


By the way, this is open to anyone in any way what so ever involved with
the Maven 3.5.0-alpha-1 effort (assuming you are paying attention to the
dev list ;-) )

Thanks in advance for your time,

-Stephen

P.S. As alpha-2 is near, I'll probably wait until after 3.5.0 before I  
try

this again (assuming people like this idea)


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[ANN] GitPubSub multi-branch notification now working on builds.apache.org

[Stephen Connolly]

My weekend project: https://github.com/stephenc/asf-gitpubsub-jenkins-plugin
was a success

(Need to find a home for it at the ASF (as it doesn't make sense at Jenkins
/ outside of ASF)

Now when you push a change to maven.git the branch / commit should trigger
a build within seconds.

There are still some fine-tunings to further optimize the process, but that
should shave off the average 7.5 minutes / max 15 minutes we had to wait as
well as significantly reducing the load on the ASF infra.

This same GitPubSub is available to any multibranch based project running
off Git hosted on ASF hardware, so if we add Jenkinsfile to surefire, etc
they will get it too

(Next project is getting better email notification and JIRA integration for
pipeline jobs)

-Stephen