Re: Maven 3.4.0 Release

[Hervé BOUTEMY]

+1 also

Regards,

Hervé

Le lundi 19 décembre 2016, 20:36:48 CET Robert Scholte a écrit :
> +100
> 
> On Mon, 19 Dec 2016 20:12:33 +0100, Stephen Connolly
> 
>  wrote:
> > We need to get the project back in the habit of releasing.
> > 
> > My vote is the we rebuild master with a clean history. keep current
> > master
> > as a reference branch, and cherry-pick as we go.
> > 
> > The aim should be kept tight in scope and focus on the aether replacement
> > only. Minimum change for aether replacement.
> > 
> > Then we can start bringing in bug fixes.
> > 
> > If we need to break things, we can go 3.6.x or 4.x.y I only request that
> > 5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
> > (which is what my proposals are aiming to help us flesh out... though my
> > proposals may not be selected by committers in the end, hopefully they
> > will
> > allow us to have a reasoned debate)
> > 
> > Wdyt?
> > 
> > On Mon 19 Dec 2016 at 17:41, Robert Scholte  wrote:
> >> We're already trying to push a new release for quite some time. And it
> >> 
> >> seems the discussion is not over yet.
> >> 
> >> There are a lot of improvements which deserve a release, so personally
> >> I'd
> >> 
> >> like to push the discussion to 3.5.0
> >> 
> >> 
> >> 
> >> Robert
> >> 
> >> 
> >> 
> >> On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
> >> 
> >>  wrote:
> >> > Isn't that postponing the discussion we're having here on those
> >> > 
> >> > controversial changes? I'd rather give it an extra effort rather than
> >> > 
> >> > pushing it back and loosing all the context once we have to tackle
> >> 
> >> 3.5.
> >> 
> >> > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
> >> > 
> >> > stephen.alan.conno...@gmail.com> wrote:
> >> >> I like that plan, but let's call that 3.4.0 and let these other
> >> 
> >> changes
> >> 
> >> >> go
> >> >> 
> >> >> for either 3.5.0
> >> >> 
> >> >> 
> >> >> 
> >> >> Does someone want to take a stab at forking master from an earlier
> >> 
> >> point
> >> 
> >> >> (perhaps get infra to let us rewrite master back to the fork point
> >> 
> >> and
> >> 
> >> >> push
> >> >> 
> >> >> the current state to a branch?)
> >> >> 
> >> >> 
> >> >> 
> >> >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko 
> >> 
> >> wrote:
> >> >> > No, I meant just eclipse->apache move, not all changes that went
> >> 
> >> into
> >> 
> >> >> > maven-resolver. The idea is to have a release branch we can
> >> 
> >> maintain
> >> 
> >> >> > while things stabilize in master.
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > --
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > Regards,
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > Igor
> >> >> > 
> >> >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
> >> >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
> >> >> > > > I wonder if it makes sense to release 3.3.10 with just the new
> >> >> 
> >> >> aether
> >> >> 
> >> >> > > > and give 3.4 more time to bake on master.
> >> >> > > 
> >> >> > > Changing a dependency with so many changes recently in a fix
> >> >> 
> >> >> version?
> >> >> 
> >> >> > > Doesn't sound right to me.
> >> >> > > 
> >> >> > > 
> >> >> > > 
> >> >> > > 
> >> >> > > 
> >> >> > > 
> >> >> > > 
> >> >> > > M
> >> >> 
> >> >> -
> >> >> 
> >> >> > > 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
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > --
> >> >> 
> >> >> 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
> 
> -
> 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: Maven 3.4.0 Release

[Manfred Moser]

Sure... but as close to be ready to release as possible. At a minimum passing 
ITs... 

Gary Gregory wrote on 2016-12-19 11:39:

> On Mon, Dec 19, 2016 at 11:24 AM, Manfred Moser 
> wrote:
> 
>> Totally agree. Master should be ready to release all the time imho.
>> Nothing that isnt tested well and proven to at least pass all IT's should
>> be merged into master. Experimentation should happen in feature branches..
>>
> 
> I think it's OK to have a master branch that is not ready to release at a
> moment's notice but it MUST be the case that all tests pass all the time.
> 
> Gary
> 
> 
>>
>> Just my 2c.
>>
>> Manfred
>>
>> Stephen Connolly wrote on 2016-12-19 11:12:
>>
>> > We need to get the project back in the habit of releasing.
>> >
>> > My vote is the we rebuild master with a clean history. keep current
>> master
>> > as a reference branch, and cherry-pick as we go.
>> >
>> > The aim should be kept tight in scope and focus on the aether replacement
>> > only. Minimum change for aether replacement.
>> >
>> > Then we can start bringing in bug fixes.
>> >
>> > If we need to break things, we can go 3.6.x or 4.x.y I only request that
>> > 5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
>> > (which is what my proposals are aiming to help us flesh out... though my
>> > proposals may not be selected by committers in the end, hopefully they
>> will
>> > allow us to have a reasoned debate)
>> >
>> > Wdyt?
>> >
>> > On Mon 19 Dec 2016 at 17:41, Robert Scholte 
>> wrote:
>> >
>> >> We're already trying to push a new release for quite some time. And it
>> >>
>> >> seems the discussion is not over yet.
>> >>
>> >> There are a lot of improvements which deserve a release, so personally
>> I'd
>> >>
>> >> like to push the discussion to 3.5.0
>> >>
>> >>
>> >>
>> >> Robert
>> >>
>> >>
>> >>
>> >> On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
>> >>
>> >>  wrote:
>> >>
>> >>
>> >>
>> >> > Isn't that postponing the discussion we're having here on those
>> >>
>> >> > controversial changes? I'd rather give it an extra effort rather than
>> >>
>> >> > pushing it back and loosing all the context once we have to tackle
>> 3.5.
>> >>
>> >> >
>> >>
>> >> > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
>> >>
>> >> > stephen.alan.conno...@gmail.com> wrote:
>> >>
>> >> >
>> >>
>> >> >> I like that plan, but let's call that 3.4.0 and let these other
>> changes
>> >>
>> >> >> go
>> >>
>> >> >> for either 3.5.0
>> >>
>> >> >>
>> >>
>> >> >> Does someone want to take a stab at forking master from an earlier
>> point
>> >>
>> >> >> (perhaps get infra to let us rewrite master back to the fork point
>> and
>> >>
>> >> >> push
>> >>
>> >> >> the current state to a branch?)
>> >>
>> >> >>
>> >>
>> >> >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko 
>> >> wrote:
>> >>
>> >> >>
>> >>
>> >> >> > No, I meant just eclipse->apache move, not all changes that went
>> into
>> >>
>> >> >> >
>> >>
>> >> >> > maven-resolver. The idea is to have a release branch we can
>> maintain
>> >>
>> >> >> >
>> >>
>> >> >> > while things stabilize in master.
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> > --
>> >>
>> >> >> >
>> >>
>> >> >> > Regards,
>> >>
>> >> >> >
>> >>
>> >> >> > Igor
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
>> >>
>> >> >> >
>> >>
>> >> >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
>> >>
>> >> >> >
>> >>
>> >> >> > > > I wonder if it makes sense to release 3.3.10 with just the new
>> >>
>> >> >> aether
>> >>
>> >> >> >
>> >>
>> >> >> > > > and give 3.4 more time to bake on master.
>> >>
>> >> >> >
>> >>
>> >> >> > >
>> >>
>> >> >> >
>> >>
>> >> >> > > Changing a dependency with so many changes recently in a fix
>> >>
>> >> >> version?
>> >>
>> >> >> >
>> >>
>> >> >> > > Doesn't sound right to me.
>> >>
>> >> >> >
>> >>
>> >> >> > >
>> >>
>> >> >> >
>> >>
>> >> >> > > M
>> >>
>> >> >> >
>> >>
>> >> >> > >
>> >>
>> >> >> >
>> >>
>> >> >> > >
>> >>
>> >> >> >
>> >>
>> >> >> > >
>> >>
>> >> >> 
>> -
>> >>
>> >> >> >
>> >>
>> >> >> > > 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
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> > --
>> >>
>> >> >> Sent from my phone
>> >>
>> >>
>> >>
>> >> -
>> >>
>> 

Re: Maven 3.4.0 Release

[Gary Gregory]

On Mon, Dec 19, 2016 at 11:24 AM, Manfred Moser 
wrote:

> Totally agree. Master should be ready to release all the time imho.
> Nothing that isnt tested well and proven to at least pass all IT's should
> be merged into master. Experimentation should happen in feature branches..
>

I think it's OK to have a master branch that is not ready to release at a
moment's notice but it MUST be the case that all tests pass all the time.

Gary


>
> Just my 2c.
>
> Manfred
>
> Stephen Connolly wrote on 2016-12-19 11:12:
>
> > We need to get the project back in the habit of releasing.
> >
> > My vote is the we rebuild master with a clean history. keep current
> master
> > as a reference branch, and cherry-pick as we go.
> >
> > The aim should be kept tight in scope and focus on the aether replacement
> > only. Minimum change for aether replacement.
> >
> > Then we can start bringing in bug fixes.
> >
> > If we need to break things, we can go 3.6.x or 4.x.y I only request that
> > 5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
> > (which is what my proposals are aiming to help us flesh out... though my
> > proposals may not be selected by committers in the end, hopefully they
> will
> > allow us to have a reasoned debate)
> >
> > Wdyt?
> >
> > On Mon 19 Dec 2016 at 17:41, Robert Scholte 
> wrote:
> >
> >> We're already trying to push a new release for quite some time. And it
> >>
> >> seems the discussion is not over yet.
> >>
> >> There are a lot of improvements which deserve a release, so personally
> I'd
> >>
> >> like to push the discussion to 3.5.0
> >>
> >>
> >>
> >> Robert
> >>
> >>
> >>
> >> On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
> >>
> >>  wrote:
> >>
> >>
> >>
> >> > Isn't that postponing the discussion we're having here on those
> >>
> >> > controversial changes? I'd rather give it an extra effort rather than
> >>
> >> > pushing it back and loosing all the context once we have to tackle
> 3.5.
> >>
> >> >
> >>
> >> > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
> >>
> >> > stephen.alan.conno...@gmail.com> wrote:
> >>
> >> >
> >>
> >> >> I like that plan, but let's call that 3.4.0 and let these other
> changes
> >>
> >> >> go
> >>
> >> >> for either 3.5.0
> >>
> >> >>
> >>
> >> >> Does someone want to take a stab at forking master from an earlier
> point
> >>
> >> >> (perhaps get infra to let us rewrite master back to the fork point
> and
> >>
> >> >> push
> >>
> >> >> the current state to a branch?)
> >>
> >> >>
> >>
> >> >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko 
> >> wrote:
> >>
> >> >>
> >>
> >> >> > No, I meant just eclipse->apache move, not all changes that went
> into
> >>
> >> >> >
> >>
> >> >> > maven-resolver. The idea is to have a release branch we can
> maintain
> >>
> >> >> >
> >>
> >> >> > while things stabilize in master.
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> > --
> >>
> >> >> >
> >>
> >> >> > Regards,
> >>
> >> >> >
> >>
> >> >> > Igor
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
> >>
> >> >> >
> >>
> >> >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
> >>
> >> >> >
> >>
> >> >> > > > I wonder if it makes sense to release 3.3.10 with just the new
> >>
> >> >> aether
> >>
> >> >> >
> >>
> >> >> > > > and give 3.4 more time to bake on master.
> >>
> >> >> >
> >>
> >> >> > >
> >>
> >> >> >
> >>
> >> >> > > Changing a dependency with so many changes recently in a fix
> >>
> >> >> version?
> >>
> >> >> >
> >>
> >> >> > > Doesn't sound right to me.
> >>
> >> >> >
> >>
> >> >> > >
> >>
> >> >> >
> >>
> >> >> > > M
> >>
> >> >> >
> >>
> >> >> > >
> >>
> >> >> >
> >>
> >> >> > >
> >>
> >> >> >
> >>
> >> >> > >
> >>
> >> >> 
> -
> >>
> >> >> >
> >>
> >> >> > > 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
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> > --
> >>
> >> >> 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
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

Re: Maven 3.4.0 Release

[Robert Scholte]

+100

On Mon, 19 Dec 2016 20:12:33 +0100, Stephen Connolly  
 wrote:



We need to get the project back in the habit of releasing.

My vote is the we rebuild master with a clean history. keep current  
master

as a reference branch, and cherry-pick as we go.

The aim should be kept tight in scope and focus on the aether replacement
only. Minimum change for aether replacement.

Then we can start bringing in bug fixes.

If we need to break things, we can go 3.6.x or 4.x.y I only request that
5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
(which is what my proposals are aiming to help us flesh out... though my
proposals may not be selected by committers in the end, hopefully they  
will

allow us to have a reasoned debate)

Wdyt?

On Mon 19 Dec 2016 at 17:41, Robert Scholte  wrote:


We're already trying to push a new release for quite some time. And it

seems the discussion is not over yet.

There are a lot of improvements which deserve a release, so personally  
I'd


like to push the discussion to 3.5.0



Robert



On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll

 wrote:



> Isn't that postponing the discussion we're having here on those

> controversial changes? I'd rather give it an extra effort rather than

> pushing it back and loosing all the context once we have to tackle  
3.5.


>

> On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <

> stephen.alan.conno...@gmail.com> wrote:

>

>> I like that plan, but let's call that 3.4.0 and let these other  
changes


>> go

>> for either 3.5.0

>>

>> Does someone want to take a stab at forking master from an earlier  
point


>> (perhaps get infra to let us rewrite master back to the fork point  
and


>> push

>> the current state to a branch?)

>>

>> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko 
wrote:

>>

>> > No, I meant just eclipse->apache move, not all changes that went  
into


>> >

>> > maven-resolver. The idea is to have a release branch we can  
maintain


>> >

>> > while things stabilize in master.

>> >

>> >

>> >

>> > --

>> >

>> > Regards,

>> >

>> > Igor

>> >

>> >

>> >

>> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:

>> >

>> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:

>> >

>> > > > I wonder if it makes sense to release 3.3.10 with just the new

>> aether

>> >

>> > > > and give 3.4 more time to bake on master.

>> >

>> > >

>> >

>> > > Changing a dependency with so many changes recently in a fix

>> version?

>> >

>> > > Doesn't sound right to me.

>> >

>> > >

>> >

>> > > M

>> >

>> > >

>> >

>> > >

>> >

>> > >

>> -

>> >

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

>> >

>> >

>> >

>> > --

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


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

Re: Maven 3.4.0 Release

[Manfred Moser]

Totally agree. Master should be ready to release all the time imho. Nothing 
that isnt tested well and proven to at least pass all IT's should be merged 
into master. Experimentation should happen in feature branches.. 

Just my 2c. 

Manfred

Stephen Connolly wrote on 2016-12-19 11:12:

> We need to get the project back in the habit of releasing.
> 
> My vote is the we rebuild master with a clean history. keep current master
> as a reference branch, and cherry-pick as we go.
> 
> The aim should be kept tight in scope and focus on the aether replacement
> only. Minimum change for aether replacement.
> 
> Then we can start bringing in bug fixes.
> 
> If we need to break things, we can go 3.6.x or 4.x.y I only request that
> 5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
> (which is what my proposals are aiming to help us flesh out... though my
> proposals may not be selected by committers in the end, hopefully they will
> allow us to have a reasoned debate)
> 
> Wdyt?
> 
> On Mon 19 Dec 2016 at 17:41, Robert Scholte  wrote:
> 
>> We're already trying to push a new release for quite some time. And it
>>
>> seems the discussion is not over yet.
>>
>> There are a lot of improvements which deserve a release, so personally I'd
>>
>> like to push the discussion to 3.5.0
>>
>>
>>
>> Robert
>>
>>
>>
>> On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
>>
>>  wrote:
>>
>>
>>
>> > Isn't that postponing the discussion we're having here on those
>>
>> > controversial changes? I'd rather give it an extra effort rather than
>>
>> > pushing it back and loosing all the context once we have to tackle 3.5.
>>
>> >
>>
>> > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
>>
>> > stephen.alan.conno...@gmail.com> wrote:
>>
>> >
>>
>> >> I like that plan, but let's call that 3.4.0 and let these other changes
>>
>> >> go
>>
>> >> for either 3.5.0
>>
>> >>
>>
>> >> Does someone want to take a stab at forking master from an earlier point
>>
>> >> (perhaps get infra to let us rewrite master back to the fork point and
>>
>> >> push
>>
>> >> the current state to a branch?)
>>
>> >>
>>
>> >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko 
>> wrote:
>>
>> >>
>>
>> >> > No, I meant just eclipse->apache move, not all changes that went into
>>
>> >> >
>>
>> >> > maven-resolver. The idea is to have a release branch we can maintain
>>
>> >> >
>>
>> >> > while things stabilize in master.
>>
>> >> >
>>
>> >> >
>>
>> >> >
>>
>> >> > --
>>
>> >> >
>>
>> >> > Regards,
>>
>> >> >
>>
>> >> > Igor
>>
>> >> >
>>
>> >> >
>>
>> >> >
>>
>> >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
>>
>> >> >
>>
>> >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
>>
>> >> >
>>
>> >> > > > I wonder if it makes sense to release 3.3.10 with just the new
>>
>> >> aether
>>
>> >> >
>>
>> >> > > > and give 3.4 more time to bake on master.
>>
>> >> >
>>
>> >> > >
>>
>> >> >
>>
>> >> > > Changing a dependency with so many changes recently in a fix
>>
>> >> version?
>>
>> >> >
>>
>> >> > > Doesn't sound right to me.
>>
>> >> >
>>
>> >> > >
>>
>> >> >
>>
>> >> > > M
>>
>> >> >
>>
>> >> > >
>>
>> >> >
>>
>> >> > >
>>
>> >> >
>>
>> >> > >
>>
>> >> -
>>
>> >> >
>>
>> >> > > 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
>>
>> >> >
>>
>> >> >
>>
>> >> >
>>
>> >> > --
>>
>> >> 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
> 


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

Re: Maven 3.4.0 Release

[Gary Gregory]

On Mon, Dec 19, 2016 at 11:12 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> We need to get the project back in the habit of releasing.
>

+1!

Gary


>
> My vote is the we rebuild master with a clean history. keep current master
> as a reference branch, and cherry-pick as we go.
>
> The aim should be kept tight in scope and focus on the aether replacement
> only. Minimum change for aether replacement.
>
> Then we can start bringing in bug fixes.
>
> If we need to break things, we can go 3.6.x or 4.x.y I only request that
> 5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
> (which is what my proposals are aiming to help us flesh out... though my
> proposals may not be selected by committers in the end, hopefully they will
> allow us to have a reasoned debate)
>
> Wdyt?
>
> On Mon 19 Dec 2016 at 17:41, Robert Scholte  wrote:
>
> > We're already trying to push a new release for quite some time. And it
> >
> > seems the discussion is not over yet.
> >
> > There are a lot of improvements which deserve a release, so personally
> I'd
> >
> > like to push the discussion to 3.5.0
> >
> >
> >
> > Robert
> >
> >
> >
> > On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
> >
> >  wrote:
> >
> >
> >
> > > Isn't that postponing the discussion we're having here on those
> >
> > > controversial changes? I'd rather give it an extra effort rather than
> >
> > > pushing it back and loosing all the context once we have to tackle 3.5.
> >
> > >
> >
> > > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
> >
> > > stephen.alan.conno...@gmail.com> wrote:
> >
> > >
> >
> > >> I like that plan, but let's call that 3.4.0 and let these other
> changes
> >
> > >> go
> >
> > >> for either 3.5.0
> >
> > >>
> >
> > >> Does someone want to take a stab at forking master from an earlier
> point
> >
> > >> (perhaps get infra to let us rewrite master back to the fork point and
> >
> > >> push
> >
> > >> the current state to a branch?)
> >
> > >>
> >
> > >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko 
> > wrote:
> >
> > >>
> >
> > >> > No, I meant just eclipse->apache move, not all changes that went
> into
> >
> > >> >
> >
> > >> > maven-resolver. The idea is to have a release branch we can maintain
> >
> > >> >
> >
> > >> > while things stabilize in master.
> >
> > >> >
> >
> > >> >
> >
> > >> >
> >
> > >> > --
> >
> > >> >
> >
> > >> > Regards,
> >
> > >> >
> >
> > >> > Igor
> >
> > >> >
> >
> > >> >
> >
> > >> >
> >
> > >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
> >
> > >> >
> >
> > >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
> >
> > >> >
> >
> > >> > > > I wonder if it makes sense to release 3.3.10 with just the new
> >
> > >> aether
> >
> > >> >
> >
> > >> > > > and give 3.4 more time to bake on master.
> >
> > >> >
> >
> > >> > >
> >
> > >> >
> >
> > >> > > Changing a dependency with so many changes recently in a fix
> >
> > >> version?
> >
> > >> >
> >
> > >> > > Doesn't sound right to me.
> >
> > >> >
> >
> > >> > >
> >
> > >> >
> >
> > >> > > M
> >
> > >> >
> >
> > >> > >
> >
> > >> >
> >
> > >> > >
> >
> > >> >
> >
> > >> > >
> >
> > >> -
> >
> > >> >
> >
> > >> > > 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
> >
> > >> >
> >
> > >> >
> >
> > >> >
> >
> > >> > --
> >
> > >> 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
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: 

Re: Maven 3.4.0 Release

[Stephen Connolly]

We need to get the project back in the habit of releasing.

My vote is the we rebuild master with a clean history. keep current master
as a reference branch, and cherry-pick as we go.

The aim should be kept tight in scope and focus on the aether replacement
only. Minimum change for aether replacement.

Then we can start bringing in bug fixes.

If we need to break things, we can go 3.6.x or 4.x.y I only request that
5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
(which is what my proposals are aiming to help us flesh out... though my
proposals may not be selected by committers in the end, hopefully they will
allow us to have a reasoned debate)

Wdyt?

On Mon 19 Dec 2016 at 17:41, Robert Scholte  wrote:

> We're already trying to push a new release for quite some time. And it
>
> seems the discussion is not over yet.
>
> There are a lot of improvements which deserve a release, so personally I'd
>
> like to push the discussion to 3.5.0
>
>
>
> Robert
>
>
>
> On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
>
>  wrote:
>
>
>
> > Isn't that postponing the discussion we're having here on those
>
> > controversial changes? I'd rather give it an extra effort rather than
>
> > pushing it back and loosing all the context once we have to tackle 3.5.
>
> >
>
> > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
>
> > stephen.alan.conno...@gmail.com> wrote:
>
> >
>
> >> I like that plan, but let's call that 3.4.0 and let these other changes
>
> >> go
>
> >> for either 3.5.0
>
> >>
>
> >> Does someone want to take a stab at forking master from an earlier point
>
> >> (perhaps get infra to let us rewrite master back to the fork point and
>
> >> push
>
> >> the current state to a branch?)
>
> >>
>
> >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko 
> wrote:
>
> >>
>
> >> > No, I meant just eclipse->apache move, not all changes that went into
>
> >> >
>
> >> > maven-resolver. The idea is to have a release branch we can maintain
>
> >> >
>
> >> > while things stabilize in master.
>
> >> >
>
> >> >
>
> >> >
>
> >> > --
>
> >> >
>
> >> > Regards,
>
> >> >
>
> >> > Igor
>
> >> >
>
> >> >
>
> >> >
>
> >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
>
> >> >
>
> >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
>
> >> >
>
> >> > > > I wonder if it makes sense to release 3.3.10 with just the new
>
> >> aether
>
> >> >
>
> >> > > > and give 3.4 more time to bake on master.
>
> >> >
>
> >> > >
>
> >> >
>
> >> > > Changing a dependency with so many changes recently in a fix
>
> >> version?
>
> >> >
>
> >> > > Doesn't sound right to me.
>
> >> >
>
> >> > >
>
> >> >
>
> >> > > M
>
> >> >
>
> >> > >
>
> >> >
>
> >> > >
>
> >> >
>
> >> > >
>
> >> -
>
> >> >
>
> >> > > 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
>
> >> >
>
> >> >
>
> >> >
>
> >> > --
>
> >> 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

Re: Maven 3.4.0 Release

[Robert Scholte]

We're already trying to push a new release for quite some time. And it  
seems the discussion is not over yet.
There are a lot of improvements which deserve a release, so personally I'd  
like to push the discussion to 3.5.0


Robert

On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll  
 wrote:



Isn't that postponing the discussion we're having here on those
controversial changes? I'd rather give it an extra effort rather than
pushing it back and loosing all the context once we have to tackle 3.5.

On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

I like that plan, but let's call that 3.4.0 and let these other changes  
go

for either 3.5.0

Does someone want to take a stab at forking master from an earlier point
(perhaps get infra to let us rewrite master back to the fork point and  
push

the current state to a branch?)

On Sun 18 Dec 2016 at 19:45, Igor Fedorenko  wrote:

> No, I meant just eclipse->apache move, not all changes that went into
>
> maven-resolver. The idea is to have a release branch we can maintain
>
> while things stabilize in master.
>
>
>
> --
>
> Regards,
>
> Igor
>
>
>
> On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
>
> > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
>
> > > I wonder if it makes sense to release 3.3.10 with just the new  
aether

>
> > > and give 3.4 more time to bake on master.
>
> >
>
> > Changing a dependency with so many changes recently in a fix  
version?

>
> > Doesn't sound right to me.
>
> >
>
> > M
>
> >
>
> >
>
> >  
-

>
> > 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
>
>
>
> --
Sent from my phone


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

Re: Maven 3.4.0 Release

[Stephane Nicoll]

Isn't that postponing the discussion we're having here on those
controversial changes? I'd rather give it an extra effort rather than
pushing it back and loosing all the context once we have to tackle 3.5.

On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I like that plan, but let's call that 3.4.0 and let these other changes go
> for either 3.5.0
>
> Does someone want to take a stab at forking master from an earlier point
> (perhaps get infra to let us rewrite master back to the fork point and push
> the current state to a branch?)
>
> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko  wrote:
>
> > No, I meant just eclipse->apache move, not all changes that went into
> >
> > maven-resolver. The idea is to have a release branch we can maintain
> >
> > while things stabilize in master.
> >
> >
> >
> > --
> >
> > Regards,
> >
> > Igor
> >
> >
> >
> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
> >
> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
> >
> > > > I wonder if it makes sense to release 3.3.10 with just the new aether
> >
> > > > and give 3.4 more time to bake on master.
> >
> > >
> >
> > > Changing a dependency with so many changes recently in a fix version?
> >
> > > Doesn't sound right to me.
> >
> > >
> >
> > > M
> >
> > >
> >
> > >
> >
> > > -
> >
> > > 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
> >
> >
> >
> > --
> Sent from my phone
>

Re: Maven 3.4.0 Release

[Stephen Connolly]

I like that plan, but let's call that 3.4.0 and let these other changes go
for either 3.5.0

Does someone want to take a stab at forking master from an earlier point
(perhaps get infra to let us rewrite master back to the fork point and push
the current state to a branch?)

On Sun 18 Dec 2016 at 19:45, Igor Fedorenko  wrote:

> No, I meant just eclipse->apache move, not all changes that went into
>
> maven-resolver. The idea is to have a release branch we can maintain
>
> while things stabilize in master.
>
>
>
> --
>
> Regards,
>
> Igor
>
>
>
> On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
>
> > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
>
> > > I wonder if it makes sense to release 3.3.10 with just the new aether
>
> > > and give 3.4 more time to bake on master.
>
> >
>
> > Changing a dependency with so many changes recently in a fix version?
>
> > Doesn't sound right to me.
>
> >
>
> > M
>
> >
>
> >
>
> > -
>
> > 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
>
>
>
> --
Sent from my phone

Re: Maven 3.4.0 Release

[Igor Fedorenko]

No, I meant just eclipse->apache move, not all changes that went into
maven-resolver. The idea is to have a release branch we can maintain
while things stabilize in master.

-- 
Regards,
Igor

On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
> Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
> > I wonder if it makes sense to release 3.3.10 with just the new aether
> > and give 3.4 more time to bake on master.
> 
> Changing a dependency with so many changes recently in a fix version?
> Doesn't sound right to me.
> 
> M
> 
> 
> -
> 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: Maven 3.4.0 Release

[Michael Osipov]

Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:

I wonder if it makes sense to release 3.3.10 with just the new aether
and give 3.4 more time to bake on master.


Changing a dependency with so many changes recently in a fix version?
Doesn't sound right to me.

M


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

Re: Maven 3.4.0 Release

[Igor Fedorenko]

I wonder if it makes sense to release 3.3.10 with just the new aether
and give 3.4 more time to bake on master.

-- 
Regards,
Igor

On Sun, Dec 18, 2016, at 07:33 AM, Robert Scholte wrote:
> I did investigate some time in this request. The conclusion is that the  
> discussion should be in the open and not in the private list of the Maven 
> PMC.
> 
> What I see are good intended changes, but the results are a chain of  
> commits where every change fixes one thing but at the same time breaks a  
> couple of other things.
> 
> I really had hoped we'd reached a point where it was a matter of the last 
> couple of changes to be able to push 3.4.0, but instead new changes are  
> introduced and is changing the behavior of Maven a lot. Right now I don't 
> have a good feeling about this release. Even worse, with every new
> attempt  
> to continue this path by new commits will reduce my confidence in Maven  
> 3.4.0
> 
> To be able to push Maven 3.4.0 out of the door some critical decisions  
> need to be made. I might need to call a vote on those options, need to  
> find the rights wordings though.
> 
> thanks,
> Robert
> 
> On Sat, 10 Dec 2016 17:42:46 +0100, Michael Osipov   
> wrote:
> 
> > Am 2016-12-10 um 16:18 schrieb Christian Schulte:
> >> It would be cool if someone could answer the questions I raised in this
> >> 
> >> thread. I would still need to remove those system properties from the
> >> 'DefaultModelBuilder', for example.
> >>
> >> 
> >> 
> >>
> >> IMHO, introduce that damn 'include' scope in 3.4, and be done with it.
> >> We cannot change the 'import' scope behaviour for model version 4.0.0
> >> that way but most of the users using that 'import' scope find it useless
> >> sooner or later and will probably upgrade to use the 'include' scope
> >> sometime in the future, when that is available. Just someone answer the
> >> questions. Maybe discuss this at PMC level because the reporters
> >
> > +1 if PMCs having a problem making import scope work as advertised. I  
> > still think is that if this is broken -- against the spec -- it must be  
> > fixed.
> >
> > Michael
> >
> >
> > -
> > 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
> 

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

Re: Maven 3.4.0 Release

[Robert Scholte]

I did investigate some time in this request. The conclusion is that the  
discussion should be in the open and not in the private list of the Maven  
PMC.


What I see are good intended changes, but the results are a chain of  
commits where every change fixes one thing but at the same time breaks a  
couple of other things.


I really had hoped we'd reached a point where it was a matter of the last  
couple of changes to be able to push 3.4.0, but instead new changes are  
introduced and is changing the behavior of Maven a lot. Right now I don't  
have a good feeling about this release. Even worse, with every new attempt  
to continue this path by new commits will reduce my confidence in Maven  
3.4.0


To be able to push Maven 3.4.0 out of the door some critical decisions  
need to be made. I might need to call a vote on those options, need to  
find the rights wordings though.


thanks,
Robert

On Sat, 10 Dec 2016 17:42:46 +0100, Michael Osipov   
wrote:



Am 2016-12-10 um 16:18 schrieb Christian Schulte:

It would be cool if someone could answer the questions I raised in this

thread. I would still need to remove those system properties from the
'DefaultModelBuilder', for example.




IMHO, introduce that damn 'include' scope in 3.4, and be done with it.
We cannot change the 'import' scope behaviour for model version 4.0.0
that way but most of the users using that 'import' scope find it useless
sooner or later and will probably upgrade to use the 'include' scope
sometime in the future, when that is available. Just someone answer the
questions. Maybe discuss this at PMC level because the reporters


+1 if PMCs having a problem making import scope work as advertised. I  
still think is that if this is broken -- against the spec -- it must be  
fixed.


Michael


-
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: Maven 3.4.0 Release

[Christian Schulte]

Am 12/17/16 um 05:17 schrieb Christian Schulte:
> Am 12/12/16 um 00:51 schrieb Igor Fedorenko:
>> I'm traveling until next weekend and won't be able to review your changes 
>> properly until I'm back. I do want to stress that maven plugins are not 
>> dependencies, they are resolved the same way as  projects.
> 
> Master does it that way now. I may need to revert an update to an IT
> tomorrow. Let's see. Please note that direct 'test' and 'provided'
> dependencies of a plugin are now resolved and can lead to different
> resolution results as before where they have not been resolved. So the
> conflict resolver sees them now and may decide differently. The issues I
> ran into this were all bugs in plugin POMs. Someone added 'commons-lang'
> as a 'test' dependency to a plugin although that dependency was a
> transitive dependency in 'compile' scope already, for example. That
> 'commons-lang' will now disappear completely from the plugin's classpath
> because it will be resolved (nearest wins) and then later get filtered
> out. You may need to tun Maven with -X and diff the resolution trees
> from the debug messages when running into problems.
> 

I solved things like this like: Remove all 'test' and 'provided'
dependencies from a plugin's POM so they do not override any transitive
dependency from another scope and then verify no transitive dependency
gets resolved which was in the POM before.



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

Re: Maven 3.4.0 Release

[Christian Schulte]

Am 12/12/16 um 00:51 schrieb Igor Fedorenko:
> I'm traveling until next weekend and won't be able to review your changes 
> properly until I'm back. I do want to stress that maven plugins are not 
> dependencies, they are resolved the same way as  projects.

Master does it that way now. I may need to revert an update to an IT
tomorrow. Let's see. Please note that direct 'test' and 'provided'
dependencies of a plugin are now resolved and can lead to different
resolution results as before where they have not been resolved. So the
conflict resolver sees them now and may decide differently. The issues I
ran into this were all bugs in plugin POMs. Someone added 'commons-lang'
as a 'test' dependency to a plugin although that dependency was a
transitive dependency in 'compile' scope already, for example. That
'commons-lang' will now disappear completely from the plugin's classpath
because it will be resolved (nearest wins) and then later get filtered
out. You may need to tun Maven with -X and diff the resolution trees
from the debug messages when running into problems.

Regards,
-- 
Christian


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

Re: Maven 3.4.0 Release

[Christian Schulte]

Am 12/14/16 um 01:05 schrieb Christian Schulte:
> That a direct optional dependency 

That should read: That a transitive optional dependency...


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

Re: Maven 3.4.0 Release

[Christian Schulte]

Am 12/12/16 um 00:51 schrieb Igor Fedorenko:
> I'm traveling until next weekend and won't be able to review your changes 
> properly until I'm back. I do want to stress that maven plugins are not 
> dependencies, they are resolved the same way as  projects.

Coming back to this. Currently plugins are resolved the same way as
dependencies. That a direct optional dependency was part of the
resolution result has been a bug in the resolver. Should I update the
core to really resolve plugins the same way as POMs? The easy part of
this would be this change:

+++
b/maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginDependenciesResolver.java
@@ -182,7 +182,7 @@ private DependencyNode resolveInternal( Plugin
plugin, Artifact pluginArtifact,
 CollectRequest request = new CollectRequest();
 request.setRequestContext( REPOSITORY_CONTEXT );
 request.setRepositories( repositories );
-request.setRoot( new org.eclipse.aether.graph.Dependency(
pluginArtifact, null ) );
+request.setRootArtifact( pluginArtifact );
 for ( Dependency dependency : plugin.getDependencies() )
 {
 org.eclipse.aether.graph.Dependency pluginDep =

In addition, the plugin POM needs to be resolved in that class as well
and all dependencies from that POM would need to be added to the collect
request. That would make Maven resolve plugins the same way it resolves
projects. Yes or no?

Regards,
-- 
Christian


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

Re: Maven 3.4.0 Release

[Christian Schulte]

Am 12/12/16 um 22:55 schrieb Michael Osipov:
> Am 2016-12-12 um 02:48 schrieb Christian Schulte:
>> Am 12/11/16 um 22:56 schrieb Michael Osipov:
>>> I just ran ITs with current master, only one IT fails:
>>
>> Should be fixed now.
> 
> Are you certain about this? I cannot confirm. 
> 723b942ad10ab471dfbc5d81ed1071891573dc01 fixes MNG-5227 IT but the IT 
> failing ist for MNG-4347.
> 

It's a bug in the core introduced a few releases ago and uncovered now
due to the changes to the import scope. Not sure the 'ModelResolver'
really should replace 'externalRepositories'. Will take some time
solving that. At least I know what's causing this.


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

Re: Maven 3.4.0 Release

[Christian Schulte]

Am 12/12/16 um 22:55 schrieb Michael Osipov:
> Am 2016-12-12 um 02:48 schrieb Christian Schulte:
>> Am 12/11/16 um 22:56 schrieb Michael Osipov:
>>> I just ran ITs with current master, only one IT fails:
>>
>> Should be fixed now.
> 
> Are you certain about this? I cannot confirm. 
> 723b942ad10ab471dfbc5d81ed1071891573dc01 fixes MNG-5227 IT but the IT 
> failing ist for MNG-4347.
> 

Still looking into it. Does not seem to be an issue with maven core but
the resolver. Currently reviewing all commits since


Regards,
-- 
Christian


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

Re: Maven 3.4.0 Release

[Michael Osipov]

Am 2016-12-12 um 02:48 schrieb Christian Schulte:

Am 12/11/16 um 22:56 schrieb Michael Osipov:

I just ran ITs with current master, only one IT fails:


Should be fixed now.


Are you certain about this? I cannot confirm. 
723b942ad10ab471dfbc5d81ed1071891573dc01 fixes MNG-5227 IT but the IT 
failing ist for MNG-4347.


Michael


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

Re: Maven 3.4.0 Release

[Christian Schulte]

Am 12/11/16 um 22:56 schrieb Michael Osipov:
> I just ran ITs with current master, only one IT fails:

Should be fixed now.

Regards,
-- 
Christian


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

Re: Maven 3.4.0 Release

[Christian Schulte]

Am 12/12/16 um 00:51 schrieb Igor Fedorenko:
> I'm traveling until next weekend and won't be able to review your changes 
> properly until I'm back. I do want to stress that maven plugins are not 
> dependencies, they are resolved the same way as  projects.

Yes. I agree to that. It's not implemented that way in the core.
Currently they are resolved the same way as dependencies :-o . So the
core needs updating to resolve plugins the same way as projects (POMs).
If we agree to this, I'll change it.

Regards,
-- 
Christian


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

Re: Maven 3.4.0 Release

[Igor Fedorenko]

I'm traveling until next weekend and won't be able to review your changes 
properly until I'm back. I do want to stress that maven plugins are not 
dependencies, they are resolved the same way as  projects.


--
Regards,
Igor



On December 11, 2016 1:59:39 PM Christian Schulte  wrote:


Am 12/11/16 um 03:29 schrieb Igor Fedorenko:

Why do you say Dependency A is transitive? Maven plugin directly depends
on Dependency A, so I expect it to be present on the plugin classpath.
This is consistent with how project direct optional dependencies are
always present on classpath.


Yes. That's the POM resolution case. The plugin resolution is performed
exactly the same way dependency resolution is performed. See below. If
what you say is the intented behaviour (plugins need to be resolved the
same way as POMs) then the core needs to be updated to actually perform
the resolution that way. I am glad you are coming up with this.



Note that the project does not *depend* on the plugin. From dependency
resolution point of view, the plugin is standalone "top-level" entity at
the same level as the project.



That means plugins need to be resolved the same way as POMs. And that
means direct 'test', 'provided' and 'optional' dependencies need to be
resolved as well. Last time I updated the core to do exactly that, it
lead to issues like:




Currently only 'optional' direct dependencies are resolved. And that is
due to a bug.



Easy to spot. I'll revert the changes to 'ScopeDependencySelector' and
'OptionalDependencySelector' in a few hours locally and the tests in
'DefaultDependencyCollectorTest' need to still pass. If one of the tests
starts failing, the fix to MRESOLVER-8 is correct. There is no reason
for the two classes to behave differently. The 'ScopeDependencySelector'
handles the POM resolution vs. dependency resolution case correctly but
differently to the 'OptionalDependencySelector'. That can't be correct.
There is no way to handle plugin resolution differently than dependency
resolution. So either 'OptionalDependencySelector' behaves incorrectly
for dependency resolution of incorrectly for plugin resolution.

Maybe we'll need to update classes 'ScopeDependencySelector' and
'OptionalDependencySelector' to make the mode of operation (transitive
vs. direct) a property we can set from the core to make plugin
resolution behave the same way it did before the fix (filtering out
direct 'test' and 'provided' dependencies but not direct 'optional'
dependencies to make that IT lacking any kind of meaningful - why? -
description pass). Let's see.

Regards,
--
Christian


-
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: Maven 3.4.0 Release

[Christian Schulte]

Thanks. Noticed this myself yesterday. Wanted to wait for Jenkins to
finish all pending jobs. Haven't expected any IT to fail. Will have a look.

Am 12/11/16 um 22:56 schrieb Michael Osipov:
> Am 2016-12-10 um 16:06 schrieb Christian Schulte:
>> If it's happening just due to the upgrade of the resolver, then it's a
>> resolver bugfix the IT hasn't been updated to reflect. I discussed this
>> issue with Jason in december last year when upgrading the resolver to
>> 1.1 needed to be reverted.
>>
>> 
>>
>> Also part of:
>>
>> 
>>
>> This was lacking test cases badly. I am the author of the corresponding
>> test cases in the resolver. A few months later I had to correct those
>> tests to match the 1.0.x behaviour exactly.
>>
>> 
>>
>> That IT would need to be updated to no longer run with Maven 3.4+ and a
>> new one needs to be created in parallel running with 3.4+, IMHO. The
>> bugfix also has an impact on how 'test' scope dependencies are resolved.
>> In short: If the scope of a transitive dependency is managed to 'test'
>> that dependency will no longer be resolved as the test scope is not
>> transitive.
> 
> I just ran ITs with current master, only one IT fails:
> 
> ---
> Tests run: 797, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 
> 1,306.697 sec <<< FAILURE! - in org.apache.maven.it.IntegrationTestSuite
> testit(org.apache.maven.it.MavenITmng4347ImportScopeWithSettingsProfilesTest) 
>   Time elapsed: 1.174 sec  <<< ERROR!
> org.apache.maven.it.VerificationException: Exit code was non-zero: 1; 
> command line and log =
> D:\Entwicklung\Programme\apache-maven-3.4.0-SNAPSHOT\bin\..\bin\mvn 
> --global-settings 
> D:\Entwicklung\Projekte\maven-integration-testing\core-it-suite\target\test-classes\settings.xml
>  
> -s settings.xml -e --batch-mode 
> -Dmaven.repo.local=C:\Users\mosipov\.m2\repository validate
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building consumer 1
> [INFO] 
> 
> [INFO] Downloading: 
> file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-4347/remote-repository/org/apache/maven/it/mng4347/dep-with-import/1/dep-with-import-1.pom
> [INFO] Downloaded: 
> file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-4347/remote-repository/org/apache/maven/it/mng4347/dep-with-import/1/dep-with-import-1.pom
>  
> (1.7 kB at 109 kB/s)
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 0.181 s
> [INFO] Finished at: 2016-12-11T22:37:08+01:00
> [INFO] Final Memory: 8M/241M
> [INFO] 
> 
> [ERROR] Failed to execute goal on project consumer: Could not resolve 
> dependencies for project org.apache.maven.it.mng4347:consumer:jar:1: 
> Failed to collect dependencies at 
> org.apache.maven.it.mng4347:dep-with-import:jar:1: Failed to read 
> artifact descriptor for 
> org.apache.maven.it.mng4347:dep-with-import:jar:1: Could not find 
> artifact org.apache.maven.it.mng4347:import-dep:pom:1-SNAPSHOT -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to 
> execute goal on project consumer: Could not resolve dependencies for 
> project org.apache.maven.it.mng4347:consumer:jar:1: Failed to collect 
> dependencies at org.apache.maven.it.mng4347:dep-with-import:jar:1
>   at 
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:249)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:145)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:247)
> ...
> Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could 
> not find artifact org.apache.maven.it.mng4347:import-dep:pom:1-SNAPSHOT
>   at 
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:412)
>   ... 42 more
> 
> Michael
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Re: Maven 3.4.0 Release

[Michael Osipov]

Am 2016-12-10 um 16:06 schrieb Christian Schulte:

If it's happening just due to the upgrade of the resolver, then it's a
resolver bugfix the IT hasn't been updated to reflect. I discussed this
issue with Jason in december last year when upgrading the resolver to
1.1 needed to be reverted.



Also part of:



This was lacking test cases badly. I am the author of the corresponding
test cases in the resolver. A few months later I had to correct those
tests to match the 1.0.x behaviour exactly.



That IT would need to be updated to no longer run with Maven 3.4+ and a
new one needs to be created in parallel running with 3.4+, IMHO. The
bugfix also has an impact on how 'test' scope dependencies are resolved.
In short: If the scope of a transitive dependency is managed to 'test'
that dependency will no longer be resolved as the test scope is not
transitive.


I just ran ITs with current master, only one IT fails:

---
Tests run: 797, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 
1,306.697 sec <<< FAILURE! - in org.apache.maven.it.IntegrationTestSuite
testit(org.apache.maven.it.MavenITmng4347ImportScopeWithSettingsProfilesTest) 
 Time elapsed: 1.174 sec  <<< ERROR!
org.apache.maven.it.VerificationException: Exit code was non-zero: 1; 
command line and log =
D:\Entwicklung\Programme\apache-maven-3.4.0-SNAPSHOT\bin\..\bin\mvn 
--global-settings 
D:\Entwicklung\Projekte\maven-integration-testing\core-it-suite\target\test-classes\settings.xml 
-s settings.xml -e --batch-mode 
-Dmaven.repo.local=C:\Users\mosipov\.m2\repository validate

[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] 


[INFO] Building consumer 1
[INFO] 

[INFO] Downloading: 
file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-4347/remote-repository/org/apache/maven/it/mng4347/dep-with-import/1/dep-with-import-1.pom
[INFO] Downloaded: 
file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-4347/remote-repository/org/apache/maven/it/mng4347/dep-with-import/1/dep-with-import-1.pom 
(1.7 kB at 109 kB/s)
[INFO] 


[INFO] BUILD FAILURE
[INFO] 


[INFO] Total time: 0.181 s
[INFO] Finished at: 2016-12-11T22:37:08+01:00
[INFO] Final Memory: 8M/241M
[INFO] 

[ERROR] Failed to execute goal on project consumer: Could not resolve 
dependencies for project org.apache.maven.it.mng4347:consumer:jar:1: 
Failed to collect dependencies at 
org.apache.maven.it.mng4347:dep-with-import:jar:1: Failed to read 
artifact descriptor for 
org.apache.maven.it.mng4347:dep-with-import:jar:1: Could not find 
artifact org.apache.maven.it.mng4347:import-dep:pom:1-SNAPSHOT -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to 
execute goal on project consumer: Could not resolve dependencies for 
project org.apache.maven.it.mng4347:consumer:jar:1: Failed to collect 
dependencies at org.apache.maven.it.mng4347:dep-with-import:jar:1
	at 
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:249)
	at 
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:145)
	at 
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:247)

...
Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could 
not find artifact org.apache.maven.it.mng4347:import-dep:pom:1-SNAPSHOT
	at 
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:412)

... 42 more

Michael


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

Re: Maven 3.4.0 Release

[Christian Schulte]

Am 12/11/16 um 03:29 schrieb Igor Fedorenko:
> Why do you say Dependency A is transitive? Maven plugin directly depends
> on Dependency A, so I expect it to be present on the plugin classpath.
> This is consistent with how project direct optional dependencies are
> always present on classpath.

Yes. That's the POM resolution case. The plugin resolution is performed
exactly the same way dependency resolution is performed. See below. If
what you say is the intented behaviour (plugins need to be resolved the
same way as POMs) then the core needs to be updated to actually perform
the resolution that way. I am glad you are coming up with this.

> 
> Note that the project does not *depend* on the plugin. From dependency
> resolution point of view, the plugin is standalone "top-level" entity at
> the same level as the project.
> 

That means plugins need to be resolved the same way as POMs. And that
means direct 'test', 'provided' and 'optional' dependencies need to be
resolved as well. Last time I updated the core to do exactly that, it
lead to issues like:




Currently only 'optional' direct dependencies are resolved. And that is
due to a bug.



Easy to spot. I'll revert the changes to 'ScopeDependencySelector' and
'OptionalDependencySelector' in a few hours locally and the tests in
'DefaultDependencyCollectorTest' need to still pass. If one of the tests
starts failing, the fix to MRESOLVER-8 is correct. There is no reason
for the two classes to behave differently. The 'ScopeDependencySelector'
handles the POM resolution vs. dependency resolution case correctly but
differently to the 'OptionalDependencySelector'. That can't be correct.
There is no way to handle plugin resolution differently than dependency
resolution. So either 'OptionalDependencySelector' behaves incorrectly
for dependency resolution of incorrectly for plugin resolution.

Maybe we'll need to update classes 'ScopeDependencySelector' and
'OptionalDependencySelector' to make the mode of operation (transitive
vs. direct) a property we can set from the core to make plugin
resolution behave the same way it did before the fix (filtering out
direct 'test' and 'provided' dependencies but not direct 'optional'
dependencies to make that IT lacking any kind of meaningful - why? -
description pass). Let's see.

Regards,
-- 
Christian


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

Re: Maven 3.4.0 Release

[Igor Fedorenko]

Why do you say Dependency A is transitive? Maven plugin directly depends
on Dependency A, so I expect it to be present on the plugin classpath.
This is consistent with how project direct optional dependencies are
always present on classpath.

Note that the project does not *depend* on the plugin. From dependency
resolution point of view, the plugin is standalone "top-level" entity at
the same level as the project.

-- 
Regards,
Igor

On Sat, Dec 10, 2016, at 06:26 PM, Christian Schulte wrote:
> Am 12/10/16 um 13:39 schrieb Hervé BOUTEMY:
> > I just tested the patch associated to MNG-6110 - Upgrade Aether to Maven 
> > Resolver 1.2, and it caused one failure in ITs
> > testit(org.apache.maven.it.MavenITmng4721OptionalPluginDependencyTest)  
> > Time 
> > elapsed: 0.185 sec  <<< FAILURE!
> > junit.framework.AssertionFailedError: expected:<1> but was:<0>
> > 
> > Is it only me?
> 
> No. If you take a look at MNG-4721, it's not quite clear what that test
> case is testing. I verified the resolver is behaving correctly. That is
> - it correctly does not resolve any plugin dependency with optional set
> to 'true'. Here is the difference:
> 
> Maven with the Resolver < 1.2.0:
> 
> maven-plugin
> |-> optional dependency A
>   |-> optional dependency B
> 
> Dependency A will be resolved, although an optional transitive
> dependency. Dependency B will not be resolved and that is correct,
> because it also is an optional transitive dependency.
> 
> Maven with the Resolver >= 1.2.0:
> 
> maven-plugin
> |-> optional dependency A
>   |-> optional dependency B
> 
> Dependency A is no longer resolved because it is a transitive optional
> dependency. That's the bugfix due to MRESOLVER-8. That IT should just be
> updated to no longer run with Maven 3.4+ and a new one created running
> with 3.4+ testing the correct behaviour. It only affects optional plugin
> dependency resolution which isn't quite right in the resolver < 1.2.0.
> Will do that.
> 
> > Fixing MNG-6110 is the first step before doing more changes, IMHO
> 
> I've just committed this to master now.
> 
> Regards,
> -- 
> Christian
> 
> 
> -
> 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: Maven 3.4.0 Release

[Christian Schulte]

Corrected IT in this commit.




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

Re: Maven 3.4.0 Release

[Christian Schulte]

Am 12/10/16 um 13:39 schrieb Hervé BOUTEMY:
> I just tested the patch associated to MNG-6110 - Upgrade Aether to Maven 
> Resolver 1.2, and it caused one failure in ITs
> testit(org.apache.maven.it.MavenITmng4721OptionalPluginDependencyTest)  Time 
> elapsed: 0.185 sec  <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> 
> Is it only me?

No. If you take a look at MNG-4721, it's not quite clear what that test
case is testing. I verified the resolver is behaving correctly. That is
- it correctly does not resolve any plugin dependency with optional set
to 'true'. Here is the difference:

Maven with the Resolver < 1.2.0:

maven-plugin
|-> optional dependency A
  |-> optional dependency B

Dependency A will be resolved, although an optional transitive
dependency. Dependency B will not be resolved and that is correct,
because it also is an optional transitive dependency.

Maven with the Resolver >= 1.2.0:

maven-plugin
|-> optional dependency A
  |-> optional dependency B

Dependency A is no longer resolved because it is a transitive optional
dependency. That's the bugfix due to MRESOLVER-8. That IT should just be
updated to no longer run with Maven 3.4+ and a new one created running
with 3.4+ testing the correct behaviour. It only affects optional plugin
dependency resolution which isn't quite right in the resolver < 1.2.0.
Will do that.

> Fixing MNG-6110 is the first step before doing more changes, IMHO

I've just committed this to master now.

Regards,
-- 
Christian


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

Re: Maven 3.4.0 Release

[Christian Schulte]

Am 12/10/16 um 17:48 schrieb Michael Osipov:
> Can you create a proper branch with fixed ITs? I'd like to run those.
>  From my point of view, we can release Resolver 1.2 and roll an RC for 
> Maven 3.4.

Let's just switch maven master to the resolver snapshot and continue
from there on. That branch is useless for anyone not having updated
maven core to use the resolver snapshot. I am not sure the IT would need
to be updated. As far as I recall maven core needs to be updated to
reflect MRESOLVER-8. That would take just a few minutes.

+1 for releasing resolver 1.2.
-1 for releasing an RC without the import scope feature sorted out. See
my other mail. That needs to be clarified. Updating the model builder to
reflect any decision is a matter of a few minutes work.


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

Re: Maven 3.4.0 Release

[Michael Osipov]

Am 2016-12-10 um 16:06 schrieb Christian Schulte:

If it's happening just due to the upgrade of the resolver, then it's a
resolver bugfix the IT hasn't been updated to reflect. I discussed this
issue with Jason in december last year when upgrading the resolver to
1.1 needed to be reverted.



Also part of:



This was lacking test cases badly. I am the author of the corresponding
test cases in the resolver. A few months later I had to correct those
tests to match the 1.0.x behaviour exactly.



That IT would need to be updated to no longer run with Maven 3.4+ and a
new one needs to be created in parallel running with 3.4+, IMHO. The
bugfix also has an impact on how 'test' scope dependencies are resolved.
In short: If the scope of a transitive dependency is managed to 'test'
that dependency will no longer be resolved as the test scope is not
transitive.


+1

Can you create a proper branch with fixed ITs? I'd like to run those.
From my point of view, we can release Resolver 1.2 and roll an RC for 
Maven 3.4.


Michael


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

Re: Maven 3.4.0 Release

[Michael Osipov]

Am 2016-12-10 um 16:18 schrieb Christian Schulte:

It would be cool if someone could answer the questions I raised in this

thread. I would still need to remove those system properties from the
'DefaultModelBuilder', for example.




IMHO, introduce that damn 'include' scope in 3.4, and be done with it.
We cannot change the 'import' scope behaviour for model version 4.0.0
that way but most of the users using that 'import' scope find it useless
sooner or later and will probably upgrade to use the 'include' scope
sometime in the future, when that is available. Just someone answer the
questions. Maybe discuss this at PMC level because the reporters


+1 if PMCs having a problem making import scope work as advertised. I 
still think is that if this is broken -- against the spec -- it must be 
fixed.


Michael


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

Re: Maven 3.4.0 Release

[Christian Schulte]

Wait. That maybe a different story. MRESOLVER-8.



The changes to 'OptionalDependencySelector' made it behave the same way
the 'ScopeDependencySelector' and other selectors are implemented. It's
a bit sad there have not been any test cases for this. The test cases
are testing the correct 1.0.x behaviour. That selector needed fixing to
behave the same way as the other selectors. That's what you get when you
cannot finish a task you started to work on a year ago. Hard to remember
where to catch up after having left things WIP for a year. The plugin
repository session in core may need to be reviewed and maybe need to be
changed to no longer make use of that optional selector to get that IT
pass. Maybe it's time to switch core to the resolver now and let Jenkins
start doing it's job. I will look into that IT once the core is using
the resolver snapshot finally. Makes no sense for everyone having to
update the POMs locally.

Am 10.12.2016 um 13:39 schrieb Hervé BOUTEMY:
> I just tested the patch associated to MNG-6110 - Upgrade Aether to Maven 
> Resolver 1.2, and it caused one failure in ITs
> testit(org.apache.maven.it.MavenITmng4721OptionalPluginDependencyTest)  Time 
> elapsed: 0.185 sec  <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> 
> Is it only me?
> Fixing MNG-6110 is the first step before doing more changes, IMHO
> 
> Regards,
> 
> Hervé
> 
> Le vendredi 9 décembre 2016, 11:56:01 CET Michael Osipov a écrit :
>> Am 2016-12-06 um 22:46 schrieb Robert Scholte:
>>> Hi,
>>>
>>> what is the status on this? Can we expect a release this year?
>>>
>>> I think the open issues are:
>>> is maven-resolver ready to replace aether?
>>> AFAIK some dependency management changes have been reverted, are all
>>> others indeed bugfixes and safe to keep in this release?
>>
>> There is basically Resolver left, one good improvement is MNG-5896 along
>> with the PR, but I cannot review it since I am not really familiar with
>> the Resolver code. If someone is able to review MRESOLVER-7, please do
>> and merge it. We could go on with Resolver 1.2 and continue with Maven
>> 3.4 release.
>>
>> Michael
>>
>>
>> -
>> 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
> 

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

Re: Maven 3.4.0 Release

[Christian Schulte]

It would be cool if someone could answer the questions I raised in this

thread. I would still need to remove those system properties from the
'DefaultModelBuilder', for example.




IMHO, introduce that damn 'include' scope in 3.4, and be done with it.
We cannot change the 'import' scope behaviour for model version 4.0.0
that way but most of the users using that 'import' scope find it useless
sooner or later and will probably upgrade to use the 'include' scope
sometime in the future, when that is available. Just someone answer the
questions. Maybe discuss this at PMC level because the reporters
requesting to change the 'import' scope are PMC members themselves.

Am 06.12.2016 um 22:46 schrieb Robert Scholte:
> Hi,
> 
> what is the status on this? Can we expect a release this year?
> 
> I think the open issues are:
> is maven-resolver ready to replace aether?
> AFAIK some dependency management changes have been reverted, are all  
> others indeed bugfixes and safe to keep in this release?
> 
> Here are the current release notes:
> 
> 
> Release Notes - Maven - Version 3.4.0
> 
> ** Bug
>  * [MNG-4463] - Dependency management import should support version  
> ranges.
>  * [MNG-5359] - Declared execution in PluginMgmt gets bound to  
> lifecycle (regression)
>  * [MNG-5368] - UnsupportedOperationException thrown when version range  
> is not correct in dependencyManagement definitions
>  * [MNG-5387] - Add ability to replace an artifact in mid-build
>  * [MNG-5527] - Dependency management import should support relocations.
>  * [MNG-5538] - mvn start script causes cygwin warning
>  * [MNG-5567] - Zip files are not included in classpaths at all
>  * [MNG-5629] - ClosedChannelException from  
> DefaultUpdateCheckManager.read
>  * [MNG-5815] - "mvn.cmd" does not indicate failure properly when using  
> "&&"
>  * [MNG-5823] - mvnDebug doesn't work with M2_HOME with spaces -  
> missing quotes
>  * [MNG-5836] - logging config is overwritten by $M2_HOME/lib/ext/*.jar
>  * [MNG-5837] - Syntax error in bin/mvn on Solaris SPARC
>  * [MNG-5849] - maven can not be found when current directory is  
> drive/root at least on windows 7 64bit
>  * [MNG-5852] - "mvn" script invokes /bin/sh but requires /bin/bash  
> functions
>  * [MNG-5863] - default pom's release-profile should invoke source  
> plugin with goal "jar-no-fork" instead of "jar"
>  * [MNG-5868] - Adding serval times the same artifact via  
> MavenProjectHelper (attachArtifact) does not produce a failure
>  * [MNG-5935] - Optional true getting lost in managed dependencies when  
> transitive
>  * [MNG-5939] - Problem doing release when sources are generate as well
>  * [MNG-5958] - java.lang.String cannot be cast to  
> org.apache.maven.lifecycle.mapping.LifecyclePhase
>  * [MNG-5961] - Maven possibly not aware of log4j2
>  * [MNG-5962] - mvn fails when the current directory has spaces in  
> between
>  * [MNG-5963] - mvn.cmd does not return ERROR_CODE
>  * [MNG-5971] - Imported dependencies should be available to  
> inheritance processing
>  * [MNG-5981] - Plexus lifecycle could be activated too late during  
> overlapping parallel requests
>  * [MNG-5984] - Maven core extension resolution ignores repositories  
>  from activeByDefault profiles in settings.xml
>  * [MNG-6022] - mvn.cmd fails if directory contains an ampersand (&)
>  * [MNG-6029] - Duplicate conditional and body in  
> MetadataResolutionResult.java
>  * [MNG-6041] - Option -l does not disable colorized output
>  * [MNG-6043] - Colorization is disabled too late in batch mode
>  * [MNG-6053] - Unsafe System Properties copy in  
> MavenRepositorySystemUtils, causing NPEs
>  * [MNG-6057] - Problem with CI friendly usage of ${..} reactor order  
> is changed
>  * [MNG-6079] - 3.4 regression: cannot override version of a  
> dependencyManagement in a submodule any more
>  * [MNG-6109] - PluginDescriptor doesn't read since value of parameter
>  * [MNG-6112] - Central repository in the 4.0.0 super POM should  
> declare update policy 'never'.
>  * [MNG-6114] - Elements from the global settings should be ordered  
> before elements from the user settings.
>  * [MNG-6117] - ${session.parallel} not correctly set
>  * [MNG-6127] - Fix plugin execution configuration interference
> 
> ** Dependency upgrade
>  * [MNG-5967] - Dependency updates.
>  * [MNG-6110] - Upgrade Aether to Maven Resolver 1.2
> 
> ** Improvement
>  * [MNG-4508] - No way to avoid adding artifactId to site urls
>  * [MNG-5457] - Show repository id when downloading or uploading  
> from/to a remote repository
>  * [MNG-5579] - Unify error output/check logic from shell and batch  

Re: Maven 3.4.0 Release

[Christian Schulte]

If it's happening just due to the upgrade of the resolver, then it's a
resolver bugfix the IT hasn't been updated to reflect. I discussed this
issue with Jason in december last year when upgrading the resolver to
1.1 needed to be reverted.



Also part of:



This was lacking test cases badly. I am the author of the corresponding
test cases in the resolver. A few months later I had to correct those
tests to match the 1.0.x behaviour exactly.



That IT would need to be updated to no longer run with Maven 3.4+ and a
new one needs to be created in parallel running with 3.4+, IMHO. The
bugfix also has an impact on how 'test' scope dependencies are resolved.
In short: If the scope of a transitive dependency is managed to 'test'
that dependency will no longer be resolved as the test scope is not
transitive.


Am 10.12.2016 um 13:39 schrieb Hervé BOUTEMY:
> I just tested the patch associated to MNG-6110 - Upgrade Aether to Maven 
> Resolver 1.2, and it caused one failure in ITs
> testit(org.apache.maven.it.MavenITmng4721OptionalPluginDependencyTest)  Time 
> elapsed: 0.185 sec  <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> 
> Is it only me?
> Fixing MNG-6110 is the first step before doing more changes, IMHO
> 
> Regards,
> 
> Hervé
> 
> Le vendredi 9 décembre 2016, 11:56:01 CET Michael Osipov a écrit :
>> Am 2016-12-06 um 22:46 schrieb Robert Scholte:
>>> Hi,
>>>
>>> what is the status on this? Can we expect a release this year?
>>>
>>> I think the open issues are:
>>> is maven-resolver ready to replace aether?
>>> AFAIK some dependency management changes have been reverted, are all
>>> others indeed bugfixes and safe to keep in this release?
>>
>> There is basically Resolver left, one good improvement is MNG-5896 along
>> with the PR, but I cannot review it since I am not really familiar with
>> the Resolver code. If someone is able to review MRESOLVER-7, please do
>> and merge it. We could go on with Resolver 1.2 and continue with Maven
>> 3.4 release.
>>
>> Michael
>>
>>
>> -
>> 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
> 

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

Re: Maven 3.4.0 Release

[Michael Osipov]

Am 2016-12-10 um 13:39 schrieb Hervé BOUTEMY:

I just tested the patch associated to MNG-6110 - Upgrade Aether to Maven
Resolver 1.2, and it caused one failure in ITs
testit(org.apache.maven.it.MavenITmng4721OptionalPluginDependencyTest)  Time
elapsed: 0.185 sec  <<< FAILURE!
junit.framework.AssertionFailedError: expected:<1> but was:<0>

Is it only me?
Fixing MNG-6110 is the first step before doing more changes, IMHO


I will try later this day. This may be related to changes in resolution 
by Christian.


Michael


Le vendredi 9 décembre 2016, 11:56:01 CET Michael Osipov a écrit :

Am 2016-12-06 um 22:46 schrieb Robert Scholte:

Hi,

what is the status on this? Can we expect a release this year?

I think the open issues are:
is maven-resolver ready to replace aether?
AFAIK some dependency management changes have been reverted, are all
others indeed bugfixes and safe to keep in this release?


There is basically Resolver left, one good improvement is MNG-5896 along
with the PR, but I cannot review it since I am not really familiar with
the Resolver code. If someone is able to review MRESOLVER-7, please do
and merge it. We could go on with Resolver 1.2 and continue with Maven
3.4 release.

Michael


-
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






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

Re: Maven 3.4.0 Release

[Hervé BOUTEMY]

I just tested the patch associated to MNG-6110 - Upgrade Aether to Maven 
Resolver 1.2, and it caused one failure in ITs
testit(org.apache.maven.it.MavenITmng4721OptionalPluginDependencyTest)  Time 
elapsed: 0.185 sec  <<< FAILURE!
junit.framework.AssertionFailedError: expected:<1> but was:<0>

Is it only me?
Fixing MNG-6110 is the first step before doing more changes, IMHO

Regards,

Hervé

Le vendredi 9 décembre 2016, 11:56:01 CET Michael Osipov a écrit :
> Am 2016-12-06 um 22:46 schrieb Robert Scholte:
> > Hi,
> > 
> > what is the status on this? Can we expect a release this year?
> > 
> > I think the open issues are:
> > is maven-resolver ready to replace aether?
> > AFAIK some dependency management changes have been reverted, are all
> > others indeed bugfixes and safe to keep in this release?
> 
> There is basically Resolver left, one good improvement is MNG-5896 along
> with the PR, but I cannot review it since I am not really familiar with
> the Resolver code. If someone is able to review MRESOLVER-7, please do
> and merge it. We could go on with Resolver 1.2 and continue with Maven
> 3.4 release.
> 
> Michael
> 
> 
> -
> 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: Maven 3.4.0 Release

[Michael Osipov]

Am 2016-12-06 um 22:46 schrieb Robert Scholte:

Hi,

what is the status on this? Can we expect a release this year?

I think the open issues are:
is maven-resolver ready to replace aether?
AFAIK some dependency management changes have been reverted, are all
others indeed bugfixes and safe to keep in this release?


There is basically Resolver left, one good improvement is MNG-5896 along 
with the PR, but I cannot review it since I am not really familiar with 
the Resolver code. If someone is able to review MRESOLVER-7, please do 
and merge it. We could go on with Resolver 1.2 and continue with Maven 
3.4 release.


Michael


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

Re: Maven 3.4.0 Release

[Robert Scholte]

Hi,

what is the status on this? Can we expect a release this year?

I think the open issues are:
is maven-resolver ready to replace aether?
AFAIK some dependency management changes have been reverted, are all  
others indeed bugfixes and safe to keep in this release?


Here are the current release notes:


Release Notes - Maven - Version 3.4.0

** Bug
* [MNG-4463] - Dependency management import should support version  
ranges.
* [MNG-5359] - Declared execution in PluginMgmt gets bound to  
lifecycle (regression)
* [MNG-5368] - UnsupportedOperationException thrown when version range  
is not correct in dependencyManagement definitions

* [MNG-5387] - Add ability to replace an artifact in mid-build
* [MNG-5527] - Dependency management import should support relocations.
* [MNG-5538] - mvn start script causes cygwin warning
* [MNG-5567] - Zip files are not included in classpaths at all
* [MNG-5629] - ClosedChannelException from  
DefaultUpdateCheckManager.read
* [MNG-5815] - "mvn.cmd" does not indicate failure properly when using  
"&&"
* [MNG-5823] - mvnDebug doesn't work with M2_HOME with spaces -  
missing quotes

* [MNG-5836] - logging config is overwritten by $M2_HOME/lib/ext/*.jar
* [MNG-5837] - Syntax error in bin/mvn on Solaris SPARC
* [MNG-5849] - maven can not be found when current directory is  
drive/root at least on windows 7 64bit
* [MNG-5852] - "mvn" script invokes /bin/sh but requires /bin/bash  
functions
* [MNG-5863] - default pom's release-profile should invoke source  
plugin with goal "jar-no-fork" instead of "jar"
* [MNG-5868] - Adding serval times the same artifact via  
MavenProjectHelper (attachArtifact) does not produce a failure
* [MNG-5935] - Optional true getting lost in managed dependencies when  
transitive

* [MNG-5939] - Problem doing release when sources are generate as well
* [MNG-5958] - java.lang.String cannot be cast to  
org.apache.maven.lifecycle.mapping.LifecyclePhase

* [MNG-5961] - Maven possibly not aware of log4j2
* [MNG-5962] - mvn fails when the current directory has spaces in  
between

* [MNG-5963] - mvn.cmd does not return ERROR_CODE
* [MNG-5971] - Imported dependencies should be available to  
inheritance processing
* [MNG-5981] - Plexus lifecycle could be activated too late during  
overlapping parallel requests
* [MNG-5984] - Maven core extension resolution ignores repositories  
from activeByDefault profiles in settings.xml

* [MNG-6022] - mvn.cmd fails if directory contains an ampersand (&)
* [MNG-6029] - Duplicate conditional and body in  
MetadataResolutionResult.java

* [MNG-6041] - Option -l does not disable colorized output
* [MNG-6043] - Colorization is disabled too late in batch mode
* [MNG-6053] - Unsafe System Properties copy in  
MavenRepositorySystemUtils, causing NPEs
* [MNG-6057] - Problem with CI friendly usage of ${..} reactor order  
is changed
* [MNG-6079] - 3.4 regression: cannot override version of a  
dependencyManagement in a submodule any more

* [MNG-6109] - PluginDescriptor doesn't read since value of parameter
* [MNG-6112] - Central repository in the 4.0.0 super POM should  
declare update policy 'never'.
* [MNG-6114] - Elements from the global settings should be ordered  
before elements from the user settings.

* [MNG-6117] - ${session.parallel} not correctly set
* [MNG-6127] - Fix plugin execution configuration interference

** Dependency upgrade
* [MNG-5967] - Dependency updates.
* [MNG-6110] - Upgrade Aether to Maven Resolver 1.2

** Improvement
* [MNG-4508] - No way to avoid adding artifactId to site urls
* [MNG-5457] - Show repository id when downloading or uploading  
from/to a remote repository
* [MNG-5579] - Unify error output/check logic from shell and batch  
scripts

* [MNG-5600] - Dependency management import should support exclusions.
* [MNG-5607] - Don't use M2_HOME in mvn shell/command scripts anymore
* [MNG-5883] - Silence unnecessary legacy local repository warning
* [MNG-5889] - .mvn directory should be picked when using --file
* [MNG-5896] - Download dependency POMs in parallel
* [MNG-5904] - Remove the whole Ant Build
* [MNG-5931] - Fixing documentation
* [MNG-5934] - String handling issues identified by PMD
* [MNG-5940] - Change the maven-source-plugin jar goal into  
jar-no-fork in Maven Super POM
* [MNG-5946] - Fix links etc. in README.txt which is part of the  
delivery

* [MNG-5951] - add an option to avoid path addition to inherited URLs
* [MNG-5968] - Default plugin version updates.
* [MNG-5975] - Use Java 7's SimpleDateFormat in  
CLIReportingUtils#formatTimestamp
* [MNG-5977] - Improve output readability of our MavenTransferListener  
implementations
* [MNG-5992] - Git passwords are exposed as the Super POM still uses  
Maven Release Plugin 2.3.2
* [MNG-5993] - Confusing 

Re: Maven 3.4.0 Release

[Robert Scholte]

On Mon, 10 Oct 2016 11:08:52 +0200, Stephen Connolly  
 wrote:



On 10 October 2016 at 09:40, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:



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

I would argue that the behaviour change in MNG-5971 should not be
introduced at the same time as a refactoring to move to the new "code
formerly known as Eclipse Aether but now at Apache under a different  
name"

codebase.

So, in short, I think of the 10 issues, only one "potentially" qualifies
as perhaps maybe requiring a modelVersion bump, and I would not want  
that

included with the other changes for 3.4.x anyway



Reading carefully through this issue I am inclined to lean towards
Stéphane's opinion that it is more of a bug fix than an RFE that has been
reported. That does not mean that the suggested implementation of the fix
is a bug fix or an RFE.

The real root problem here is that import scope was introduced without a
clear specification and there is no clear documentation on how exactly
import scope should work.

We have the principle that anything I declare in my pom wins.
After my pom, the next priority is my parent pom, followed by  
grandparent,

etc.
Only after that do we start looking at things defined in dependencies  
which

will win over anything defined in dependencyManagement...
Finally when resolving conflicts in dependency trees, only at that point  
do

we start getting complex and consider the tree depth... which closest
winning and finally pom order being used to resolve the case where tree
depth is equal (this last one is IMHO a mistake... rather we should fail
the build if pom order is the only way to resolve a conflict as pom order
is magic to most people... at least for inheritance purposes)

ASIDE: why is pom order unclear? Well if I have a  in my
parent and   in my pom, which entries come first...  
parent's
or child's? if the parent's then the parent wins and that breaks  
things...
if the child's then that is counter-intuitive for most people... never  
mind

that this important decision is not documented anywhere... oh and
help:effective-pom shows that the parent entries come first... which is  
at

odds with the child being able to override the parent... so if the child
needs to change the "pom-order" of dependencies inherited from its
parent... sorry out of luck

So what would I expect from scope=import... I would expect it to be an
in-place substitution of the  from the imported pom
(modulo duplicate removal)

In the situation of a lack of specification, fixing the behaviour to work
that way would be a bug fix... a bug fix with big consequences... but  
still

a bug fix within the scope of what we have called modelVersion 4.0.0
(because we added import scope without a clear specification)... it is  
not
furthering the mistake of adding import scope, rather it is clarifying  
the

(non-existing) specification of import scope.

I would not make such a change in 3.4.x though as it would conflate other
important changes that we need people to feel safe adopting so that we  
can

start to move forward again.

But that is my opinion... and I reserve the right to disagree with my own
opinion and to change my mind mid-sentence... especially in the light of  
a

better line of argument... just not seen one yet ;-)


Even if it is a bug, we know there are projects which rely on this  
behavoir for a long time. And for that reason I wouldn't fix it in 3.4.0.  
It would be nice if we could help projects relying on this bug by giving  
them a warning during build, but I can imagine that's hard to identify.


I personally would never set or change elements in a managed dependency  
which have a default value, because it can be confusing in the modules and  
childs using it. But since those elements are there in the model, they can  
be used. So maybe it is just my advice, and for those who want to use  
them, well, they can.


Robert

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

Re: Maven 3.4.0 Release

[Stephen Connolly]

On 10 October 2016 at 09:40, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

>
> https://issues.apache.org/jira/browse/MNG-5971
>
> I would argue that the behaviour change in MNG-5971 should not be
> introduced at the same time as a refactoring to move to the new "code
> formerly known as Eclipse Aether but now at Apache under a different name"
> codebase.
>
> So, in short, I think of the 10 issues, only one "potentially" qualifies
> as perhaps maybe requiring a modelVersion bump, and I would not want that
> included with the other changes for 3.4.x anyway
>
>
Reading carefully through this issue I am inclined to lean towards
Stéphane's opinion that it is more of a bug fix than an RFE that has been
reported. That does not mean that the suggested implementation of the fix
is a bug fix or an RFE.

The real root problem here is that import scope was introduced without a
clear specification and there is no clear documentation on how exactly
import scope should work.

We have the principle that anything I declare in my pom wins.
After my pom, the next priority is my parent pom, followed by grandparent,
etc.
Only after that do we start looking at things defined in dependencies which
will win over anything defined in dependencyManagement...
Finally when resolving conflicts in dependency trees, only at that point do
we start getting complex and consider the tree depth... which closest
winning and finally pom order being used to resolve the case where tree
depth is equal (this last one is IMHO a mistake... rather we should fail
the build if pom order is the only way to resolve a conflict as pom order
is magic to most people... at least for inheritance purposes)

ASIDE: why is pom order unclear? Well if I have a  in my
parent and   in my pom, which entries come first... parent's
or child's? if the parent's then the parent wins and that breaks things...
if the child's then that is counter-intuitive for most people... never mind
that this important decision is not documented anywhere... oh and
help:effective-pom shows that the parent entries come first... which is at
odds with the child being able to override the parent... so if the child
needs to change the "pom-order" of dependencies inherited from its
parent... sorry out of luck

So what would I expect from scope=import... I would expect it to be an
in-place substitution of the  from the imported pom
(modulo duplicate removal)

In the situation of a lack of specification, fixing the behaviour to work
that way would be a bug fix... a bug fix with big consequences... but still
a bug fix within the scope of what we have called modelVersion 4.0.0
(because we added import scope without a clear specification)... it is not
furthering the mistake of adding import scope, rather it is clarifying the
(non-existing) specification of import scope.

I would not make such a change in 3.4.x though as it would conflate other
important changes that we need people to feel safe adopting so that we can
start to move forward again.

But that is my opinion... and I reserve the right to disagree with my own
opinion and to change my mind mid-sentence... especially in the light of a
better line of argument... just not seen one yet ;-)

Re: Maven 3.4.0 Release

[Stephen Connolly]

The following issues IMHO all affect build time behaviour and do not affect
dependency consumption.
As such they do not require a modelVersion bump

https://issues.apache.org/jira/browse/MNG-6054
https://issues.apache.org/jira/browse/MNG-5992
https://issues.apache.org/jira/browse/MNG-5968
https://issues.apache.org/jira/browse/MNG-5940
https://issues.apache.org/jira/browse/MNG-4645
https://issues.apache.org/jira/browse/MNG-2478

The following issues affect dependency consumption, but IMHO could be
considered as bug fixes rather than RFEs. Strictly speaking they involve
behaviours that we have never specified and thus it is questionable as to
whether they are deviating from the original intent (in which case they
would be RFEs and warrant a modelVersion bump) or whether they align with
the original intent (which makes them bugs and not requiring of a
modelVersion bump)

https://issues.apache.org/jira/browse/MNG-5527 - clearly a bug
https://issues.apache.org/jira/browse/MNG-4463 - clearly a bug
https://issues.apache.org/jira/browse/MNG-5600 - less clear, import scope
itself should probably have required a modelVersion bump or at least a
clear specification, but that ship has sailed... this new behaviour aligns
with the unspecifiied expectations I would have of how a scope and
exclusions would work, so IMHO that makes it a bug

That just leaves:

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

I would argue that the behaviour change in MNG-5971 should not be
introduced at the same time as a refactoring to move to the new "code
formerly known as Eclipse Aether but now at Apache under a different name"
codebase.

So, in short, I think of the 10 issues, only one "potentially" qualifies as
perhaps maybe requiring a modelVersion bump, and I would not want that
included with the other changes for 3.4.x anyway

On 10 October 2016 at 09:26, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On 10 October 2016 at 01:38, Christian Schulte  wrote:
>
>> Am 10/09/16 um 21:44 schrieb Stephen Connolly:
>> > Open issues bound to 3.4.0
>> >
>> > * Introduction of model version 4.1.0.
>> >   https://issues.apache.org/jira/browse/MNG-6082
>> > 
>> >   assignee: Christian Schulte (reporter: Christian Schulte)
>> >
>> >
>> > I am -1 on this change as I understand it as it will break central for
>> > older consumers.
>>
>> That's why I asked what I should do about it. I can easily
>> revert/disable things. I thought we are not going to release 3.4 but 4.0
>> with the new model version and PDT support, no? So there will be a 3.4
>> release? Please see all the issues MNG-6082 is linked to. Not bumping
>> the model version means disabling almost all of the changes done for
>> those issues. I'd really would not want to do that. Yes. Model version
>> 4.1.0 will never get released. I got that. I thought we are already
>> working on model version 5.0.0 / PDT and that will make shipping those
>> changes possible.
>>
>
> Well we need to decide what to do now about cutting a release with the
> code formerly known as Eclipse Aether at its new home... which AIUI is what
> 3.4.0 would be.
>
> We cannot ship anything that deploys a pom with a modelVersion other than
> 4.0.0 IMHO as that would require forking the central repository.
>
> There is still some work to be done on getting the proposals for how to
> move forward safely... and I am not seeing much engagement with the work I
> have been trying to do... which scares me somewhat...
>
> If we need to unwind some of the changes you made that required a
> modelVersion bump then I think we need to do that... but I am not seeing
> others chime in on this topic either...
>
>
>>
>> Regards,
>> --
>> Christian
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>

Re: Maven 3.4.0 Release

[Stephen Connolly]

On 10 October 2016 at 01:38, Christian Schulte  wrote:

> Am 10/09/16 um 21:44 schrieb Stephen Connolly:
> > Open issues bound to 3.4.0
> >
> > * Introduction of model version 4.1.0.
> >   https://issues.apache.org/jira/browse/MNG-6082
> > 
> >   assignee: Christian Schulte (reporter: Christian Schulte)
> >
> >
> > I am -1 on this change as I understand it as it will break central for
> > older consumers.
>
> That's why I asked what I should do about it. I can easily
> revert/disable things. I thought we are not going to release 3.4 but 4.0
> with the new model version and PDT support, no? So there will be a 3.4
> release? Please see all the issues MNG-6082 is linked to. Not bumping
> the model version means disabling almost all of the changes done for
> those issues. I'd really would not want to do that. Yes. Model version
> 4.1.0 will never get released. I got that. I thought we are already
> working on model version 5.0.0 / PDT and that will make shipping those
> changes possible.
>

Well we need to decide what to do now about cutting a release with the code
formerly known as Eclipse Aether at its new home... which AIUI is what
3.4.0 would be.

We cannot ship anything that deploys a pom with a modelVersion other than
4.0.0 IMHO as that would require forking the central repository.

There is still some work to be done on getting the proposals for how to
move forward safely... and I am not seeing much engagement with the work I
have been trying to do... which scares me somewhat...

If we need to unwind some of the changes you made that required a
modelVersion bump then I think we need to do that... but I am not seeing
others chime in on this topic either...


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

Re: Maven 3.4.0 Release

[Hervé BOUTEMY]

Le lundi 10 octobre 2016 02:47:36 Christian Schulte a écrit :
> Am 10/09/16 um 14:10 schrieb Jason van Zyl:
> > The preparation of detailed released notes to be reviewed. The last
> > release was almost a year ago, and an enormous number of behavioral
> > changes have been made in that time-frame. There’s zero documentation
> > outlining these changes thus far in the site as far as I can tell. That’s
> > the only requirement I see.
> I deferred writing documentation (maven site) until things have been
> sorted out. Maybe the list of behavioral changes will soon become much
> smaller maybe even zero.
notice that we also have the Wiki and RFC [1] or Proposals [2] space to 
organize documentation on features while work in progress: this may be a good 
place

Regards,

Hervé

[1] https://cwiki.apache.org/confluence/display/MAVEN/Requests+for+Comment

[2] https://cwiki.apache.org/confluence/display/MAVEN/Proposals


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

Re: Maven 3.4.0 Release

[Hervé BOUTEMY]

Le lundi 10 octobre 2016 00:25:26 Michael Osipov a écrit :
> Am 2016-10-09 um 23:51 schrieb Hervé BOUTEMY:
> > Le dimanche 9 octobre 2016 21:11:03 Michael Osipov a écrit :
> >> Am 2016-10-09 um 20:41 schrieb Robert Scholte:
> >>> Open issues bound to 3.4.0
> >>> 
> >>> * Document how to configure Gossip
> >>> 
> >>>   https://issues.apache.org/jira/browse/MNG-6044
> >>>   assignee: - (reporter: Michael Osipov)
> >> 
> >> I am not able to properly solve this issue because I have no idea about
> >> Gossip. This should really come from Jason Dillon.
> > 
> > I suppose we can read the doc and test ourselves
> > But apart from documentation, there was some complaints about some
> > features
> > available in slf4j-simple that is not available in gossip: I don't know
> > how
> > much people will really have such issue
> 
> Which are? Have you raised them with Jason Dillon?
see "relative timestamp" in 
http://mail-archives.apache.org/mod_mbox/maven-dev/201607.mbox/%3CCAK8jvqxYNK4weM2Frp4Brg3J7EybyjBiCsSRdGuNMQhYAG728Q%40mail.gmail.com%3E

> 
> > an option I tried (and need to finish) is MNG-6093, ie do a little
> > modification of slf4j-simple to add color to the little necessary places.
> > Is such an option, which is not ideal either, better than changing the
> > overall knowledge of people have with slf4j-simple?
> > Any thought?
> 
> A very good idea. Having this upstream in a mainstream library is
> definitively boost acceptance.
now that it works (TM), I'll change the code to be a (little) patch to the 
slf4j-simple source for the official release

> 
> Michael
> 
> 
> -
> 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: Maven 3.4.0 Release

[Tibor Digana]

I would add MNG-5889 to 3.4 after proper testing.

On Sun, Oct 9, 2016 at 8:41 PM, Robert Scholte  wrote:

> Open issues bound to 3.4.0
>
> * Introduction of model version 4.1.0.
>   https://issues.apache.org/jira/browse/MNG-6082
>   assignee: Christian Schulte (reporter: Christian Schulte)
> * Document how to configure Gossip
>   https://issues.apache.org/jira/browse/MNG-6044
>   assignee: - (reporter: Michael Osipov)
> * Document Jansi's native support limitation
>   https://issues.apache.org/jira/browse/MNG-6045
>   assignee: - (reporter: Michael Osipov)
> * after forked execution success, add an empty line
>   https://issues.apache.org/jira/browse/MNG-6088
>   assignee: Hervé Boutemy (reporter: Hervé Boutemy)
> * Introduce maven.conf in m2.conf
>   https://issues.apache.org/jira/browse/MNG-6102
>   assignee: Michael Osipov (reporter: Michael Osipov)
>
> Assignees and reporter are all Maven teammembers, so they should all be
> able to either fix it or push it to a next version.
>
> My biggest concerns are about the changed behavior of dependency
> resolution regarding dependency management which will break backwards
> compatibility:
>
> * Imported dependencies should be available to inheritance processing
>   https://issues.apache.org/jira/browse/MNG-5971
>   Based on the comment there are projects which will break due to this
> change.
>
> * Increase the model validation level to the next minor level version.
>   https://issues.apache.org/jira/browse/MNG-6075
>   Jira issue is missing an explicit list of the changes and a link the the
> revision.
>
> * Make 'optional' flag of a dependency manageable.
>   https://issues.apache.org/jira/browse/MNG-5227
>
> There are more changes done, but from what I can see those should be safe.
> IMHO these changes have too much impact for a 3.4 and I think we can fix
> them with the introduction of the PDT file.
>
> We should indeed start with release candidates and set a date until we
> expect feedback (e.g +15 days). Any negative response should be
> investigated and if it is valid it should be fixed and the release
> candidate process should starts over again asap. This way we should be able
> to push a new solid version out this year.
>
> thanks,
> Robert
>
>
>
> On Sun, 09 Oct 2016 13:58:29 +0200, Karl Heinz Marbaise 
> wrote:
>
> Hi to all,
>>
>> I would like to know what prevents us currently from releasing Maven
>> 3.4.0 ?
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> -
>> 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
>
>


-- 
Cheers
Tibor

Re: Maven 3.4.0 Release

[Christian Schulte]

Am 10/09/16 um 14:10 schrieb Jason van Zyl:
> The preparation of detailed released notes to be reviewed. The last release 
> was almost a year ago, and an enormous number of behavioral changes have been 
> made in that time-frame. There’s zero documentation outlining these changes 
> thus far in the site as far as I can tell. That’s the only requirement I see. 

I deferred writing documentation (maven site) until things have been
sorted out. Maybe the list of behavioral changes will soon become much
smaller maybe even zero.

Regards,
-- 
Christian


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

Re: Maven 3.4.0 Release

[Christian Schulte]

Am 10/09/16 um 21:44 schrieb Stephen Connolly:
> Open issues bound to 3.4.0
> 
> * Introduction of model version 4.1.0.
>   https://issues.apache.org/jira/browse/MNG-6082
> 
>   assignee: Christian Schulte (reporter: Christian Schulte)
> 
> 
> I am -1 on this change as I understand it as it will break central for
> older consumers.

That's why I asked what I should do about it. I can easily
revert/disable things. I thought we are not going to release 3.4 but 4.0
with the new model version and PDT support, no? So there will be a 3.4
release? Please see all the issues MNG-6082 is linked to. Not bumping
the model version means disabling almost all of the changes done for
those issues. I'd really would not want to do that. Yes. Model version
4.1.0 will never get released. I got that. I thought we are already
working on model version 5.0.0 / PDT and that will make shipping those
changes possible.

Regards,
-- 
Christian


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

Re: Maven 3.4.0 Release

[Michael Osipov]

Am 2016-10-09 um 23:51 schrieb Hervé BOUTEMY:

Le dimanche 9 octobre 2016 21:11:03 Michael Osipov a écrit :

Am 2016-10-09 um 20:41 schrieb Robert Scholte:

Open issues bound to 3.4.0

* Document how to configure Gossip

  https://issues.apache.org/jira/browse/MNG-6044
  assignee: - (reporter: Michael Osipov)


I am not able to properly solve this issue because I have no idea about
Gossip. This should really come from Jason Dillon.

I suppose we can read the doc and test ourselves
But apart from documentation, there was some complaints about some features
available in slf4j-simple that is not available in gossip: I don't know how
much people will really have such issue


Which are? Have you raised them with Jason Dillon?


an option I tried (and need to finish) is MNG-6093, ie do a little
modification of slf4j-simple to add color to the little necessary places.
Is such an option, which is not ideal either, better than changing the overall
knowledge of people have with slf4j-simple?
Any thought?


A very good idea. Having this upstream in a mainstream library is 
definitively boost acceptance.


Michael


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

Re: Maven 3.4.0 Release

[Hervé BOUTEMY]

Le dimanche 9 octobre 2016 21:11:03 Michael Osipov a écrit :
> Am 2016-10-09 um 20:41 schrieb Robert Scholte:
> > Open issues bound to 3.4.0
> > 
> > * Document how to configure Gossip
> > 
> >   https://issues.apache.org/jira/browse/MNG-6044
> >   assignee: - (reporter: Michael Osipov)
> 
> I am not able to properly solve this issue because I have no idea about
> Gossip. This should really come from Jason Dillon.
I suppose we can read the doc and test ourselves
But apart from documentation, there was some complaints about some features 
available in slf4j-simple that is not available in gossip: I don't know how 
much people will really have such issue

an option I tried (and need to finish) is MNG-6093, ie do a little 
modification of slf4j-simple to add color to the little necessary places.
Is such an option, which is not ideal either, better than changing the overall 
knowledge of people have with slf4j-simple?
Any thought?

> Moreover, the Gossip
> configuration is actually embedded in the one JAR file of Maven. Not
> very handy when we agreed to use ${maven.conf}/logging for that.
+1 need to do something about that

Regards,

Hervé

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

Re: Maven 3.4.0 Release

[Hervé BOUTEMY]

Le dimanche 9 octobre 2016 21:11:03 Michael Osipov a écrit :
> > * Document Jansi's native support limitation
> > 
> >   https://issues.apache.org/jira/browse/MNG-6045
> >   assignee: - (reporter: Michael Osipov)
> 
> Funny thing is that I have reached out to the devs of Jansi to fix some
> issues like have a default support for FreeBSD, even after several
> pings, no reaction.
> 
> I am not willing to give people support for our stuff when third party
> components we use have issues and the authors of it do not react within
> months. [1], [2]
> 
> [1] https://github.com/fusesource/jansi-native/issues/5
> [2] https://github.com/fusesource/jansi/issues/56
at the beginning, under FreeBSD (or any other OS without native lib, like 
Solaris or AIX), JAnsi simply made the Maven run blow up: our patch was 
integrated [3]

Now, on an Unix without native lib, not having a native lib does not make ANSI 
color failure: it just doesn't give isatty() function to try to detect stdout 
redirection, which even when available does not detect well when redirection 
are used.

Yes, from a pure logical perspective, have more native libs would be a plus. 
But this is not so critical.
Yes, JAnsi maintainers don't apply every PR immediately and it's sometime hard 
to get their attention: hey, that reminds me some recent complaints on our ML.

JAnsi works well currently for Maven and for a lot of others: if you find a 
better alternative, don't hesitate to point us to it.

Regards,

Hervé


[3] https://github.com/fusesource/jansi/pull/54


> 
> Michael
> 
> 
> -
> 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: Maven 3.4.0 Release

[Hervé Boutemy]

Le dimanche 9 octobre 2016 20:41:13 Robert Scholte a écrit :
> Open issues bound to 3.4.0
> 
> * after forked execution success, add an empty line
>https://issues.apache.org/jira/browse/MNG-6088
>assignee: Hervé Boutemy (reporter: Hervé Boutemy)
I just closed this issue, which I had already fixed


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

Re: Maven 3.4.0 Release

[Jason van Zyl]

I believe we definitely need RCs in this case. 

> On Oct 9, 2016, at 1:17 PM, Michael Osipov  wrote:
> 
> Am 2016-10-09 um 14:10 schrieb Jason van Zyl:
>> The preparation of detailed released notes to be reviewed. The last
>> release was almost a year ago, and an enormous number of behavioral
>> changes have been made in that time-frame. There’s zero documentation
>> outlining these changes thus far in the site as far as I can tell.
>> That’s the only requirement I see.
> 
> More than that. We have changed so much stuff in a minor (!) release -- too 
> much for my taste -- that I would rather expect a release candidate for that.
> 
> I completely miss documentation on Gossip.
> 
> Michael
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: Maven 3.4.0 Release

[Stephen Connolly]

On Sunday 9 October 2016, Robert Scholte  wrote:

> Open issues bound to 3.4.0
>
> * Introduction of model version 4.1.0.
>   https://issues.apache.org/jira/browse/MNG-6082
>   assignee: Christian Schulte (reporter: Christian Schulte)


I am -1 on this change as I understand it as it will break central for
older consumers.


> * Document how to configure Gossip
>   https://issues.apache.org/jira/browse/MNG-6044
>   assignee: - (reporter: Michael Osipov)
> * Document Jansi's native support limitation
>   https://issues.apache.org/jira/browse/MNG-6045
>   assignee: - (reporter: Michael Osipov)
> * after forked execution success, add an empty line
>   https://issues.apache.org/jira/browse/MNG-6088
>   assignee: Hervé Boutemy (reporter: Hervé Boutemy)
> * Introduce maven.conf in m2.conf
>   https://issues.apache.org/jira/browse/MNG-6102
>   assignee: Michael Osipov (reporter: Michael Osipov)
>
> Assignees and reporter are all Maven teammembers, so they should all be
> able to either fix it or push it to a next version.
>
> My biggest concerns are about the changed behavior of dependency
> resolution regarding dependency management which will break backwards
> compatibility:
>
> * Imported dependencies should be available to inheritance processing
>   https://issues.apache.org/jira/browse/MNG-5971
>   Based on the comment there are projects which will break due to this
> change.
>
> * Increase the model validation level to the next minor level version.
>   https://issues.apache.org/jira/browse/MNG-6075
>   Jira issue is missing an explicit list of the changes and a link the the
> revision.
>
> * Make 'optional' flag of a dependency manageable.
>   https://issues.apache.org/jira/browse/MNG-5227
>
> There are more changes done, but from what I can see those should be safe.
> IMHO these changes have too much impact for a 3.4 and I think we can fix
> them with the introduction of the PDT file.
>
> We should indeed start with release candidates and set a date until we
> expect feedback (e.g +15 days). Any negative response should be
> investigated and if it is valid it should be fixed and the release
> candidate process should starts over again asap. This way we should be able
> to push a new solid version out this year.
>
> thanks,
> Robert
>
>
> On Sun, 09 Oct 2016 13:58:29 +0200, Karl Heinz Marbaise 
> wrote:
>
> Hi to all,
>>
>> I would like to know what prevents us currently from releasing Maven
>> 3.4.0 ?
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> -
>> 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
>
>

-- 
Sent from my phone

Re: Maven 3.4.0 Release

[Michael Osipov]

Am 2016-10-09 um 20:41 schrieb Robert Scholte:

Open issues bound to 3.4.0

* Document how to configure Gossip
  https://issues.apache.org/jira/browse/MNG-6044
  assignee: - (reporter: Michael Osipov)


I am not able to properly solve this issue because I have no idea about 
Gossip. This should really come from Jason Dillon. Moreover, the Gossip 
configuration is actually embedded in the one JAR file of Maven. Not 
very handy when we agreed to use ${maven.conf}/logging for that.



* Document Jansi's native support limitation
  https://issues.apache.org/jira/browse/MNG-6045
  assignee: - (reporter: Michael Osipov)


Funny thing is that I have reached out to the devs of Jansi to fix some 
issues like have a default support for FreeBSD, even after several 
pings, no reaction.


I am not willing to give people support for our stuff when third party 
components we use have issues and the authors of it do not react within 
months. [1], [2]


[1] https://github.com/fusesource/jansi-native/issues/5
[2] https://github.com/fusesource/jansi/issues/56

Michael


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

Re: Maven 3.4.0 Release

[Robert Scholte]

Open issues bound to 3.4.0

* Introduction of model version 4.1.0.
  https://issues.apache.org/jira/browse/MNG-6082
  assignee: Christian Schulte (reporter: Christian Schulte)
* Document how to configure Gossip
  https://issues.apache.org/jira/browse/MNG-6044
  assignee: - (reporter: Michael Osipov)
* Document Jansi's native support limitation
  https://issues.apache.org/jira/browse/MNG-6045
  assignee: - (reporter: Michael Osipov)
* after forked execution success, add an empty line
  https://issues.apache.org/jira/browse/MNG-6088
  assignee: Hervé Boutemy (reporter: Hervé Boutemy)
* Introduce maven.conf in m2.conf
  https://issues.apache.org/jira/browse/MNG-6102
  assignee: Michael Osipov (reporter: Michael Osipov)

Assignees and reporter are all Maven teammembers, so they should all be  
able to either fix it or push it to a next version.


My biggest concerns are about the changed behavior of dependency  
resolution regarding dependency management which will break backwards  
compatibility:


* Imported dependencies should be available to inheritance processing
  https://issues.apache.org/jira/browse/MNG-5971
  Based on the comment there are projects which will break due to this  
change.


* Increase the model validation level to the next minor level version.
  https://issues.apache.org/jira/browse/MNG-6075
  Jira issue is missing an explicit list of the changes and a link the the  
revision.


* Make 'optional' flag of a dependency manageable.
  https://issues.apache.org/jira/browse/MNG-5227

There are more changes done, but from what I can see those should be safe.
IMHO these changes have too much impact for a 3.4 and I think we can fix  
them with the introduction of the PDT file.


We should indeed start with release candidates and set a date until we  
expect feedback (e.g +15 days). Any negative response should be  
investigated and if it is valid it should be fixed and the release  
candidate process should starts over again asap. This way we should be  
able to push a new solid version out this year.


thanks,
Robert


On Sun, 09 Oct 2016 13:58:29 +0200, Karl Heinz Marbaise  
 wrote:



Hi to all,

I would like to know what prevents us currently from releasing Maven  
3.4.0 ?


Kind regards
Karl Heinz Marbaise

-
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: Maven 3.4.0 Release

[Michael Osipov]

Am 2016-10-09 um 14:10 schrieb Jason van Zyl:

The preparation of detailed released notes to be reviewed. The last
release was almost a year ago, and an enormous number of behavioral
changes have been made in that time-frame. There’s zero documentation
outlining these changes thus far in the site as far as I can tell.
That’s the only requirement I see.


More than that. We have changed so much stuff in a minor (!) release -- 
too much for my taste -- that I would rather expect a release candidate 
for that.


I completely miss documentation on Gossip.

Michael


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

Re: Maven 3.4.0 Release

[Stephen Connolly]

Did we revert the modelVersion bump?

On Sunday 9 October 2016, Karl Heinz Marbaise  wrote:

> Hi Jason,
>
>
> On 09/10/16 14:10, Jason van Zyl wrote:
>
>> The preparation of detailed released notes to be reviewed.
>>
> > The last release was almost a year ago, and an enormous number
> >  of behavioral changes have been made in that time-frame.
> >  There’s zero documentation outlining these changes thus far in
> >  the site as far as I can tell.
> >  That’s the only requirement I see.
>
> yes the release notes I see as a real requirement...
>
> which I started a longer time ago...which needs to be updated of course...
>
> https://github.com/khmarbaise/maven-release-notes/blob/maste
> r/content/markdown/docs/3.4.0/release-notes.md
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
>> On Oct 9, 2016, at 6:58 AM, Karl Heinz Marbaise 
>>> wrote:
>>>
>>> Hi to all,
>>>
>>> I would like to know what prevents us currently from releasing Maven
>>> 3.4.0 ?
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>> -
>>> 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
>
>

-- 
Sent from my phone

Re: Maven 3.4.0 Release

[Karl Heinz Marbaise]

Hi Jason,


On 09/10/16 14:10, Jason van Zyl wrote:

The preparation of detailed released notes to be reviewed.

> The last release was almost a year ago, and an enormous number
>  of behavioral changes have been made in that time-frame.
>  There’s zero documentation outlining these changes thus far in
>  the site as far as I can tell.
>  That’s the only requirement I see.

yes the release notes I see as a real requirement...

which I started a longer time ago...which needs to be updated of course...

https://github.com/khmarbaise/maven-release-notes/blob/master/content/markdown/docs/3.4.0/release-notes.md

Kind regards
Karl Heinz Marbaise





On Oct 9, 2016, at 6:58 AM, Karl Heinz Marbaise  wrote:

Hi to all,

I would like to know what prevents us currently from releasing Maven 3.4.0 ?

Kind regards
Karl Heinz Marbaise

-
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: Maven 3.4.0 Release

[Jason van Zyl]

The preparation of detailed released notes to be reviewed. The last release was 
almost a year ago, and an enormous number of behavioral changes have been made 
in that time-frame. There’s zero documentation outlining these changes thus far 
in the site as far as I can tell. That’s the only requirement I see. 

> On Oct 9, 2016, at 6:58 AM, Karl Heinz Marbaise  wrote:
> 
> Hi to all,
> 
> I would like to know what prevents us currently from releasing Maven 3.4.0 ?
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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