Re: [CANCELLED] [VOTE] Release Apache Maven 3.5.1

[Dawid Weiss]

It's a pity these two didn't make it in:

https://issues.apache.org/jira/browse/MNG-6261
https://issues.apache.org/jira/browse/MNG-6262

These are true showstoppers for Windows users (like us).

Dawid


On Tue, Oct 17, 2017 at 8:15 PM, Stephen Connolly
 wrote:
> This vote, despite being successful, is being cancelled.
>
> As release manager for this vote I have made the decision is that releasing
> with the two issues:
>
> MNG-6275
> MNG-6209
>
> Would present an unnecessary risk to users.
>
> We're going to revert those to allow for less risky fixes to be developed.
>
> I'll call a vote on 3.5.2 once I get it spun.
>
> -Stephen
>
> On 10 September 2017 at 16:39, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> Hi,
>>
>> We solved 25 issues:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> version=12338964=Text=12316922
>>
>> There are 350 issues left in JIRA for Maven core:
>> https://issues.apache.org/jira/issues/?jql=project%20%
>> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
>> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1364/
>>
>> The distributable binaries and sources can be found here:
>> https://repository.apache.org/content/repositories/maven-
>> 1364/org/apache/maven/apache-maven/3.5.1/
>>
>> Specifically the zip, tarball and source archives can be found here:
>> https://repository.apache.org/content/repositories/maven-
>> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
>> https://repository.apache.org/content/repositories/maven-
>> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
>> https://repository.apache.org/content/repositories/maven-
>> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
>> https://repository.apache.org/content/repositories/maven-
>> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
>>
>> Source release checksum(s):
>> apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
>> bd2059560d
>> apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab69e698eb0e
>>
>> Git tag:
>> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
>> 094e4e31a5af55bb17be87675da41d9aeca062f3
>>
>> Staging site:
>> https://maven.apache.org/components/ref/3-LATEST/
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> Thanks,
>>
>> Stephen.
>>

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

[CANCELLED] [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

This vote, despite being successful, is being cancelled.

As release manager for this vote I have made the decision is that releasing
with the two issues:

MNG-6275
MNG-6209

Would present an unnecessary risk to users.

We're going to revert those to allow for less risky fixes to be developed.

I'll call a vote on 3.5.2 once I get it spun.

-Stephen

On 10 September 2017 at 16:39, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Hi,
>
> We solved 25 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> version=12338964=Text=12316922
>
> There are 350 issues left in JIRA for Maven core:
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1364/
>
> The distributable binaries and sources can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/
>
> Specifically the zip, tarball and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
>
> Source release checksum(s):
> apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
> bd2059560d
> apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab69e698eb0e
>
> Git tag:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> 094e4e31a5af55bb17be87675da41d9aeca062f3
>
> Staging site:
> https://maven.apache.org/components/ref/3-LATEST/
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Thanks,
>
> Stephen.
>

Re: [VOTE] Release Apache Maven 3.5.1

[Karl Heinz Marbaise]

Hi,

On 12/10/17 08:21, Stephen Connolly wrote:

Ok as release manager I am cancelling this vote. I’ll see about spinning
3.5.2


could we make such thing a little bit more obvious like prefixing the 
subject with "[CANCELED]..." so it becomes more clear that the VOTE has 
been canceled...it's better to identify in the thread view


Kind regards
Karl Heinz Marbaise



On Thu 12 Oct 2017 at 02:51, Hervé BOUTEMY  wrote:


Le mercredi 11 octobre 2017, 23:47:54 CEST Robert Scholte a écrit :

I think the conclusion is: 3.5.1 is not correct

it should either be:
3.5.2 without the 2 classloader related issues.

ideally with an option to activate the classloader changes (for people
knowing
what they are doing or wanting to test mode more widely)


or
3.6.0 including the classloader related issues, but probably improved

with

a system property to switch back to the 3.5.0-behavior. We also need to
improve ITs and documentation.

Since we need to make a new release anyway I would like to suggest to go
for the first option, because some claim 3.5.0 is corrupt and the related
issue is already fixed for quite some time.

+1 (sadly)

Regards,

Hervé


This should give us more time have a better look at these classloader
issues.

Robert

On Wed, 11 Oct 2017 09:46:25 +0200, Stephen Connolly

 wrote:

I’d really like if somebody could draft the release notes for the two
different classloader changes. It will make it easier to decide whether
to
roll with this or bump minor with (if I recall correctly) the
corresponding
drop of Java 7 per our policy on JVMs with minor version bump

On Wed 11 Oct 2017 at 07:33, Hervé BOUTEMY 

wrote:

+1
eventually adding a flag or system property to activate the new
behaviour

this remembers me of the idea regarding flags to support new beta
features

Regards,

Hervé

Le mercredi 11 octobre 2017, 08:13:13 CEST Anders Hammar a écrit :

I'm feeling stronger and stronger about not having this change in a


bugfix


release. Why not go for v3.6.0 if we decide that the class loading


change


is the way to go? And keep bugfix releases for just bugfixes.

/Anders

On Wed, Oct 11, 2017 at 3:43 AM, Hervé BOUTEMY <

herve.bout...@free.fr>


wrote:

perhaps we should create a Wiki page for


java.lang.ClassNotFoundException


and
list the plugins with known issues and minimum fixed version

to be added in




https://cwiki.apache.org/confluence/display/MAVEN/Errors+and+Solutions



Regards,

Hervé

Le mercredi 11 octobre 2017, 02:52:53 CEST Hervé BOUTEMY a écrit :

IIUC, it's MDEPLOY-221 about


net.flexmojos.oss:flexmojos-maven-plugin


https://issues.apache.org/jira/browse/MDEPLOY-221

Regards,

Hervé

Le mardi 10 octobre 2017, 20:48:13 CEST Robert Scholte a écrit :

FYI, MDEPLOY-121 mentions another plugin being hit by the


classloader


changes.

Robert


On Tue, 03 Oct 2017 20:22:18 +0200, Arnaud Héritier <


aherit...@gmail.com>


wrote:

Thanks Stephen

On Tue, Oct 3, 2017 at 8:18 PM, Stephen Connolly <

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

I am hoping I can find some time to do a final round of


experiments


and


then close the vote with success and publish.

On Tue 3 Oct 2017 at 11:13, Arnaud Héritier <


aherit...@gmail.com>


wrote:

@Stephen What should we do now ?


On Tue, Sep 19, 2017 at 3:14 AM, Olivier Lamy <


ol...@apache.org>


wrote:

Hi
Sorry a bit out of time ATM for testing this.
Well I trust Arnaud testing that especially if this


improve
the


performance
of this very great/awesome/users oriented plugin :P

On 13 September 2017 at 22:19, Arnaud Héritier


wrote:

Damned, can't we be anonymous on Github ?
I maintain it is a big word, I'm trying to fix more

bugs


than


I
add


new


ones
I added Oleg in the loop as he contributed a lot on it


too


I did a quick test to build on Jenkins 2.60.3 our

maven


core


with


the


Evil


Maven plugin 2.17 on a local SSH agent and it is ok
But it is really a quick test ...

Cheers



On Wed, Sep 13, 2017 at 10:07 AM, Stephen Connolly <

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

On 13 September 2017 at 01:05, Stephen Connolly <

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

On 13 September 2017 at 00:26, Anders Hammar



wrote:

On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly

<


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

Have we got any feedback from the embedder


integrations


yet?


I haven't heard anything from the m2e people.

Maybe


we


need to


ping


them


directly. I can contact Fred Bricon.

/Anders


Please do, also if anyone has a contact in netbeans


or


intellij


and


could


let them know we'd like either feedback or "we're

ok


if


MNG-6275


makes


trouble for us, go ahead and release". I'd like to


close


the


vote
on


Friday


13:00 UTC.


Olivier / Arnaud, have either of you had a chance to


test


this


with


the


evil project type[1] as you two seem to be the

Re: [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

Ok as release manager I am cancelling this vote. I’ll see about spinning
3.5.2

On Thu 12 Oct 2017 at 02:51, Hervé BOUTEMY  wrote:

> Le mercredi 11 octobre 2017, 23:47:54 CEST Robert Scholte a écrit :
> > I think the conclusion is: 3.5.1 is not correct
> >
> > it should either be:
> > 3.5.2 without the 2 classloader related issues.
> ideally with an option to activate the classloader changes (for people
> knowing
> what they are doing or wanting to test mode more widely)
>
> > or
> > 3.6.0 including the classloader related issues, but probably improved
> with
> > a system property to switch back to the 3.5.0-behavior. We also need to
> > improve ITs and documentation.
> >
> > Since we need to make a new release anyway I would like to suggest to go
> > for the first option, because some claim 3.5.0 is corrupt and the related
> > issue is already fixed for quite some time.
> +1 (sadly)
>
> Regards,
>
> Hervé
>
> > This should give us more time have a better look at these classloader
> > issues.
> >
> > Robert
> >
> > On Wed, 11 Oct 2017 09:46:25 +0200, Stephen Connolly
> >
> >  wrote:
> > > I’d really like if somebody could draft the release notes for the two
> > > different classloader changes. It will make it easier to decide whether
> > > to
> > > roll with this or bump minor with (if I recall correctly) the
> > > corresponding
> > > drop of Java 7 per our policy on JVMs with minor version bump
> > >
> > > On Wed 11 Oct 2017 at 07:33, Hervé BOUTEMY 
> wrote:
> > >> +1
> > >> eventually adding a flag or system property to activate the new
> > >> behaviour
> > >>
> > >> this remembers me of the idea regarding flags to support new beta
> > >> features
> > >>
> > >> Regards,
> > >>
> > >> Hervé
> > >>
> > >> Le mercredi 11 octobre 2017, 08:13:13 CEST Anders Hammar a écrit :
> > >> > I'm feeling stronger and stronger about not having this change in a
> > >>
> > >> bugfix
> > >>
> > >> > release. Why not go for v3.6.0 if we decide that the class loading
> > >>
> > >> change
> > >>
> > >> > is the way to go? And keep bugfix releases for just bugfixes.
> > >> >
> > >> > /Anders
> > >> >
> > >> > On Wed, Oct 11, 2017 at 3:43 AM, Hervé BOUTEMY <
> herve.bout...@free.fr>
> > >> >
> > >> > wrote:
> > >> > > perhaps we should create a Wiki page for
> > >>
> > >> java.lang.ClassNotFoundException
> > >>
> > >> > > and
> > >> > > list the plugins with known issues and minimum fixed version
> > >> > >
> > >> > > to be added in
> > >>
> > >>
> https://cwiki.apache.org/confluence/display/MAVEN/Errors+and+Solutions
> > >>
> > >> > > Regards,
> > >> > >
> > >> > > Hervé
> > >> > >
> > >> > > Le mercredi 11 octobre 2017, 02:52:53 CEST Hervé BOUTEMY a écrit :
> > >> > > > IIUC, it's MDEPLOY-221 about
> > >>
> > >> net.flexmojos.oss:flexmojos-maven-plugin
> > >>
> > >> > > > https://issues.apache.org/jira/browse/MDEPLOY-221
> > >> > > >
> > >> > > > Regards,
> > >> > > >
> > >> > > > Hervé
> > >> > > >
> > >> > > > Le mardi 10 octobre 2017, 20:48:13 CEST Robert Scholte a écrit :
> > >> > > > > FYI, MDEPLOY-121 mentions another plugin being hit by the
> > >>
> > >> classloader
> > >>
> > >> > > > > changes.
> > >> > > > >
> > >> > > > > Robert
> > >> > > > >
> > >> > > > >
> > >> > > > > On Tue, 03 Oct 2017 20:22:18 +0200, Arnaud Héritier <
> > >> > >
> > >> > > aherit...@gmail.com>
> > >> > >
> > >> > > > > wrote:
> > >> > > > > > Thanks Stephen
> > >> > > > > >
> > >> > > > > > On Tue, Oct 3, 2017 at 8:18 PM, Stephen Connolly <
> > >> > > > > >
> > >> > > > > > stephen.alan.conno...@gmail.com> wrote:
> > >> > > > > >> I am hoping I can find some time to do a final round of
> > >>
> > >> experiments
> > >>
> > >> > > and
> > >> > >
> > >> > > > > >> then close the vote with success and publish.
> > >> > > > > >>
> > >> > > > > >> On Tue 3 Oct 2017 at 11:13, Arnaud Héritier <
> > >>
> > >> aherit...@gmail.com>
> > >>
> > >> > > wrote:
> > >> > > > > >> > @Stephen What should we do now ?
> > >> > > > > >> >
> > >> > > > > >> >
> > >> > > > > >> > On Tue, Sep 19, 2017 at 3:14 AM, Olivier Lamy <
> > >>
> > >> ol...@apache.org>
> > >>
> > >> > > > > >> wrote:
> > >> > > > > >> >> Hi
> > >> > > > > >> >> Sorry a bit out of time ATM for testing this.
> > >> > > > > >> >> Well I trust Arnaud testing that especially if this
> > >>
> > >> improve
> > >> the
> > >>
> > >> > > > > >> >> performance
> > >> > > > > >> >> of this very great/awesome/users oriented plugin :P
> > >> > > > > >> >>
> > >> > > > > >> >> On 13 September 2017 at 22:19, Arnaud Héritier
> > >> > > > > >> >> 
> > >> > > > > >> >>
> > >> > > > > >> >> wrote:
> > >> > > > > >> >> > Damned, can't we be anonymous on Github ?
> > >> > > > > >> >> > I maintain it is a big word, I'm trying to fix more
> bugs
> > >>
> > >> than
> > >>
> > >> > > > > >> >> > I
> > >> > > > > >> >> > add
> > >> > > > > >>
> > >> > > > > >> new
> > >> > > > > >>
> > >> > > > > >> >> > ones
> > >> 

Re: [VOTE] Release Apache Maven 3.5.1

[Hervé BOUTEMY]

Le mercredi 11 octobre 2017, 23:47:54 CEST Robert Scholte a écrit :
> I think the conclusion is: 3.5.1 is not correct
> 
> it should either be:
> 3.5.2 without the 2 classloader related issues.
ideally with an option to activate the classloader changes (for people knowing 
what they are doing or wanting to test mode more widely)

> or
> 3.6.0 including the classloader related issues, but probably improved with
> a system property to switch back to the 3.5.0-behavior. We also need to
> improve ITs and documentation.
> 
> Since we need to make a new release anyway I would like to suggest to go
> for the first option, because some claim 3.5.0 is corrupt and the related
> issue is already fixed for quite some time.
+1 (sadly)

Regards,

Hervé

> This should give us more time have a better look at these classloader
> issues.
> 
> Robert
> 
> On Wed, 11 Oct 2017 09:46:25 +0200, Stephen Connolly
> 
>  wrote:
> > I’d really like if somebody could draft the release notes for the two
> > different classloader changes. It will make it easier to decide whether
> > to
> > roll with this or bump minor with (if I recall correctly) the
> > corresponding
> > drop of Java 7 per our policy on JVMs with minor version bump
> > 
> > On Wed 11 Oct 2017 at 07:33, Hervé BOUTEMY  wrote:
> >> +1
> >> eventually adding a flag or system property to activate the new
> >> behaviour
> >> 
> >> this remembers me of the idea regarding flags to support new beta
> >> features
> >> 
> >> Regards,
> >> 
> >> Hervé
> >> 
> >> Le mercredi 11 octobre 2017, 08:13:13 CEST Anders Hammar a écrit :
> >> > I'm feeling stronger and stronger about not having this change in a
> >> 
> >> bugfix
> >> 
> >> > release. Why not go for v3.6.0 if we decide that the class loading
> >> 
> >> change
> >> 
> >> > is the way to go? And keep bugfix releases for just bugfixes.
> >> > 
> >> > /Anders
> >> > 
> >> > On Wed, Oct 11, 2017 at 3:43 AM, Hervé BOUTEMY 
> >> > 
> >> > wrote:
> >> > > perhaps we should create a Wiki page for
> >> 
> >> java.lang.ClassNotFoundException
> >> 
> >> > > and
> >> > > list the plugins with known issues and minimum fixed version
> >> > > 
> >> > > to be added in
> >> 
> >> https://cwiki.apache.org/confluence/display/MAVEN/Errors+and+Solutions
> >> 
> >> > > Regards,
> >> > > 
> >> > > Hervé
> >> > > 
> >> > > Le mercredi 11 octobre 2017, 02:52:53 CEST Hervé BOUTEMY a écrit :
> >> > > > IIUC, it's MDEPLOY-221 about
> >> 
> >> net.flexmojos.oss:flexmojos-maven-plugin
> >> 
> >> > > > https://issues.apache.org/jira/browse/MDEPLOY-221
> >> > > > 
> >> > > > Regards,
> >> > > > 
> >> > > > Hervé
> >> > > > 
> >> > > > Le mardi 10 octobre 2017, 20:48:13 CEST Robert Scholte a écrit :
> >> > > > > FYI, MDEPLOY-121 mentions another plugin being hit by the
> >> 
> >> classloader
> >> 
> >> > > > > changes.
> >> > > > > 
> >> > > > > Robert
> >> > > > > 
> >> > > > > 
> >> > > > > On Tue, 03 Oct 2017 20:22:18 +0200, Arnaud Héritier <
> >> > > 
> >> > > aherit...@gmail.com>
> >> > > 
> >> > > > > wrote:
> >> > > > > > Thanks Stephen
> >> > > > > > 
> >> > > > > > On Tue, Oct 3, 2017 at 8:18 PM, Stephen Connolly <
> >> > > > > > 
> >> > > > > > stephen.alan.conno...@gmail.com> wrote:
> >> > > > > >> I am hoping I can find some time to do a final round of
> >> 
> >> experiments
> >> 
> >> > > and
> >> > > 
> >> > > > > >> then close the vote with success and publish.
> >> > > > > >> 
> >> > > > > >> On Tue 3 Oct 2017 at 11:13, Arnaud Héritier <
> >> 
> >> aherit...@gmail.com>
> >> 
> >> > > wrote:
> >> > > > > >> > @Stephen What should we do now ?
> >> > > > > >> > 
> >> > > > > >> > 
> >> > > > > >> > On Tue, Sep 19, 2017 at 3:14 AM, Olivier Lamy <
> >> 
> >> ol...@apache.org>
> >> 
> >> > > > > >> wrote:
> >> > > > > >> >> Hi
> >> > > > > >> >> Sorry a bit out of time ATM for testing this.
> >> > > > > >> >> Well I trust Arnaud testing that especially if this
> >> 
> >> improve
> >> the
> >> 
> >> > > > > >> >> performance
> >> > > > > >> >> of this very great/awesome/users oriented plugin :P
> >> > > > > >> >> 
> >> > > > > >> >> On 13 September 2017 at 22:19, Arnaud Héritier
> >> > > > > >> >> 
> >> > > > > >> >> 
> >> > > > > >> >> wrote:
> >> > > > > >> >> > Damned, can't we be anonymous on Github ?
> >> > > > > >> >> > I maintain it is a big word, I'm trying to fix more bugs
> >> 
> >> than
> >> 
> >> > > > > >> >> > I
> >> > > > > >> >> > add
> >> > > > > >> 
> >> > > > > >> new
> >> > > > > >> 
> >> > > > > >> >> > ones
> >> > > > > >> >> > I added Oleg in the loop as he contributed a lot on it
> >> 
> >> too
> >> 
> >> > > > > >> >> > I did a quick test to build on Jenkins 2.60.3 our maven
> >> 
> >> core
> >> 
> >> > > with
> >> > > 
> >> > > > > >> the
> >> > > > > >> 
> >> > > > > >> >> Evil
> >> > > > > >> >> 
> >> > > > > >> >> > Maven plugin 2.17 on a local SSH agent and it is ok
> >> > > > > >> >> > But it is really a quick test ...

Re: [VOTE] Release Apache Maven 3.5.1

[Robert Scholte]

I think the conclusion is: 3.5.1 is not correct

it should either be:
3.5.2 without the 2 classloader related issues.
or
3.6.0 including the classloader related issues, but probably improved with  
a system property to switch back to the 3.5.0-behavior. We also need to  
improve ITs and documentation.


Since we need to make a new release anyway I would like to suggest to go  
for the first option, because some claim 3.5.0 is corrupt and the related  
issue is already fixed for quite some time.
This should give us more time have a better look at these classloader  
issues.


Robert

On Wed, 11 Oct 2017 09:46:25 +0200, Stephen Connolly  
 wrote:



I’d really like if somebody could draft the release notes for the two
different classloader changes. It will make it easier to decide whether  
to
roll with this or bump minor with (if I recall correctly) the  
corresponding

drop of Java 7 per our policy on JVMs with minor version bump

On Wed 11 Oct 2017 at 07:33, Hervé BOUTEMY  wrote:


+1
eventually adding a flag or system property to activate the new  
behaviour


this remembers me of the idea regarding flags to support new beta  
features


Regards,

Hervé

Le mercredi 11 octobre 2017, 08:13:13 CEST Anders Hammar a écrit :
> I'm feeling stronger and stronger about not having this change in a
bugfix
> release. Why not go for v3.6.0 if we decide that the class loading  
change

> is the way to go? And keep bugfix releases for just bugfixes.
>
> /Anders
>
> On Wed, Oct 11, 2017 at 3:43 AM, Hervé BOUTEMY 
>
> wrote:
> > perhaps we should create a Wiki page for
java.lang.ClassNotFoundException
> > and
> > list the plugins with known issues and minimum fixed version
> >
> > to be added in
> >
> >
https://cwiki.apache.org/confluence/display/MAVEN/Errors+and+Solutions
> >
> > Regards,
> >
> > Hervé
> >
> > Le mercredi 11 octobre 2017, 02:52:53 CEST Hervé BOUTEMY a écrit :
> > > IIUC, it's MDEPLOY-221 about  
net.flexmojos.oss:flexmojos-maven-plugin

> > >
> > > https://issues.apache.org/jira/browse/MDEPLOY-221
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le mardi 10 octobre 2017, 20:48:13 CEST Robert Scholte a écrit :
> > > > FYI, MDEPLOY-121 mentions another plugin being hit by the
classloader
> > > > changes.
> > > >
> > > > Robert
> > > >
> > > >
> > > > On Tue, 03 Oct 2017 20:22:18 +0200, Arnaud Héritier <
> >
> > aherit...@gmail.com>
> >
> > > > wrote:
> > > > > Thanks Stephen
> > > > >
> > > > > On Tue, Oct 3, 2017 at 8:18 PM, Stephen Connolly <
> > > > >
> > > > > stephen.alan.conno...@gmail.com> wrote:
> > > > >> I am hoping I can find some time to do a final round of
experiments
> >
> > and
> >
> > > > >> then close the vote with success and publish.
> > > > >>
> > > > >> On Tue 3 Oct 2017 at 11:13, Arnaud Héritier <
aherit...@gmail.com>
> >
> > wrote:
> > > > >> > @Stephen What should we do now ?
> > > > >> >
> > > > >> >
> > > > >> > On Tue, Sep 19, 2017 at 3:14 AM, Olivier Lamy <
ol...@apache.org>
> > > > >>
> > > > >> wrote:
> > > > >> >> Hi
> > > > >> >> Sorry a bit out of time ATM for testing this.
> > > > >> >> Well I trust Arnaud testing that especially if this  
improve

the
> > > > >> >> performance
> > > > >> >> of this very great/awesome/users oriented plugin :P
> > > > >> >>
> > > > >> >> On 13 September 2017 at 22:19, Arnaud Héritier
> > > > >> >> 
> > > > >> >>
> > > > >> >> wrote:
> > > > >> >> > Damned, can't we be anonymous on Github ?
> > > > >> >> > I maintain it is a big word, I'm trying to fix more bugs
than
> > > > >> >> > I
> > > > >> >> > add
> > > > >>
> > > > >> new
> > > > >>
> > > > >> >> > ones
> > > > >> >> > I added Oleg in the loop as he contributed a lot on it  
too

> > > > >> >> > I did a quick test to build on Jenkins 2.60.3 our maven
core
> >
> > with
> >
> > > > >> the
> > > > >>
> > > > >> >> Evil
> > > > >> >>
> > > > >> >> > Maven plugin 2.17 on a local SSH agent and it is ok
> > > > >> >> > But it is really a quick test ...
> > > > >> >> >
> > > > >> >> > Cheers
> > > > >> >> >
> > > > >> >> >
> > > > >> >> >
> > > > >> >> > On Wed, Sep 13, 2017 at 10:07 AM, Stephen Connolly <
> > > > >> >> >
> > > > >> >> > stephen.alan.conno...@gmail.com> wrote:
> > > > >> >> > > On 13 September 2017 at 01:05, Stephen Connolly <
> > > > >> >> > >
> > > > >> >> > > stephen.alan.conno...@gmail.com> wrote:
> > > > >> >> > >> On 13 September 2017 at 00:26, Anders Hammar
> > > > >> >> > >> 
> > > > >> >>
> > > > >> >> wrote:
> > > > >> >> > >>> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> > > > >> >> > >>>
> > > > >> >> > >>> stephen.alan.conno...@gmail.com> wrote:
> > > > >> >> > >>> > Have we got any feedback from the embedder
integrations
> >
> > yet?
> >
> > > > >> >> > >>> I haven't heard anything from the m2e people. Maybe  
we

> >
> > need to
> >
> > > > >> ping
> > > > >>
> > > > >> >> > them
> > > > >> >> >
> > > > >> >> > >>> directly. I 

Re: [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

I’d really like if somebody could draft the release notes for the two
different classloader changes. It will make it easier to decide whether to
roll with this or bump minor with (if I recall correctly) the corresponding
drop of Java 7 per our policy on JVMs with minor version bump

On Wed 11 Oct 2017 at 07:33, Hervé BOUTEMY  wrote:

> +1
> eventually adding a flag or system property to activate the new behaviour
>
> this remembers me of the idea regarding flags to support new beta features
>
> Regards,
>
> Hervé
>
> Le mercredi 11 octobre 2017, 08:13:13 CEST Anders Hammar a écrit :
> > I'm feeling stronger and stronger about not having this change in a
> bugfix
> > release. Why not go for v3.6.0 if we decide that the class loading change
> > is the way to go? And keep bugfix releases for just bugfixes.
> >
> > /Anders
> >
> > On Wed, Oct 11, 2017 at 3:43 AM, Hervé BOUTEMY 
> >
> > wrote:
> > > perhaps we should create a Wiki page for
> java.lang.ClassNotFoundException
> > > and
> > > list the plugins with known issues and minimum fixed version
> > >
> > > to be added in
> > >
> > >
> https://cwiki.apache.org/confluence/display/MAVEN/Errors+and+Solutions
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le mercredi 11 octobre 2017, 02:52:53 CEST Hervé BOUTEMY a écrit :
> > > > IIUC, it's MDEPLOY-221 about net.flexmojos.oss:flexmojos-maven-plugin
> > > >
> > > > https://issues.apache.org/jira/browse/MDEPLOY-221
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > Le mardi 10 octobre 2017, 20:48:13 CEST Robert Scholte a écrit :
> > > > > FYI, MDEPLOY-121 mentions another plugin being hit by the
> classloader
> > > > > changes.
> > > > >
> > > > > Robert
> > > > >
> > > > >
> > > > > On Tue, 03 Oct 2017 20:22:18 +0200, Arnaud Héritier <
> > >
> > > aherit...@gmail.com>
> > >
> > > > > wrote:
> > > > > > Thanks Stephen
> > > > > >
> > > > > > On Tue, Oct 3, 2017 at 8:18 PM, Stephen Connolly <
> > > > > >
> > > > > > stephen.alan.conno...@gmail.com> wrote:
> > > > > >> I am hoping I can find some time to do a final round of
> experiments
> > >
> > > and
> > >
> > > > > >> then close the vote with success and publish.
> > > > > >>
> > > > > >> On Tue 3 Oct 2017 at 11:13, Arnaud Héritier <
> aherit...@gmail.com>
> > >
> > > wrote:
> > > > > >> > @Stephen What should we do now ?
> > > > > >> >
> > > > > >> >
> > > > > >> > On Tue, Sep 19, 2017 at 3:14 AM, Olivier Lamy <
> ol...@apache.org>
> > > > > >>
> > > > > >> wrote:
> > > > > >> >> Hi
> > > > > >> >> Sorry a bit out of time ATM for testing this.
> > > > > >> >> Well I trust Arnaud testing that especially if this improve
> the
> > > > > >> >> performance
> > > > > >> >> of this very great/awesome/users oriented plugin :P
> > > > > >> >>
> > > > > >> >> On 13 September 2017 at 22:19, Arnaud Héritier
> > > > > >> >> 
> > > > > >> >>
> > > > > >> >> wrote:
> > > > > >> >> > Damned, can't we be anonymous on Github ?
> > > > > >> >> > I maintain it is a big word, I'm trying to fix more bugs
> than
> > > > > >> >> > I
> > > > > >> >> > add
> > > > > >>
> > > > > >> new
> > > > > >>
> > > > > >> >> > ones
> > > > > >> >> > I added Oleg in the loop as he contributed a lot on it too
> > > > > >> >> > I did a quick test to build on Jenkins 2.60.3 our maven
> core
> > >
> > > with
> > >
> > > > > >> the
> > > > > >>
> > > > > >> >> Evil
> > > > > >> >>
> > > > > >> >> > Maven plugin 2.17 on a local SSH agent and it is ok
> > > > > >> >> > But it is really a quick test ...
> > > > > >> >> >
> > > > > >> >> > Cheers
> > > > > >> >> >
> > > > > >> >> >
> > > > > >> >> >
> > > > > >> >> > On Wed, Sep 13, 2017 at 10:07 AM, Stephen Connolly <
> > > > > >> >> >
> > > > > >> >> > stephen.alan.conno...@gmail.com> wrote:
> > > > > >> >> > > On 13 September 2017 at 01:05, Stephen Connolly <
> > > > > >> >> > >
> > > > > >> >> > > stephen.alan.conno...@gmail.com> wrote:
> > > > > >> >> > >> On 13 September 2017 at 00:26, Anders Hammar
> > > > > >> >> > >> 
> > > > > >> >>
> > > > > >> >> wrote:
> > > > > >> >> > >>> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> > > > > >> >> > >>>
> > > > > >> >> > >>> stephen.alan.conno...@gmail.com> wrote:
> > > > > >> >> > >>> > Have we got any feedback from the embedder
> integrations
> > >
> > > yet?
> > >
> > > > > >> >> > >>> I haven't heard anything from the m2e people. Maybe we
> > >
> > > need to
> > >
> > > > > >> ping
> > > > > >>
> > > > > >> >> > them
> > > > > >> >> >
> > > > > >> >> > >>> directly. I can contact Fred Bricon.
> > > > > >> >> > >>>
> > > > > >> >> > >>> /Anders
> > > > > >> >> > >>
> > > > > >> >> > >> Please do, also if anyone has a contact in netbeans or
> > >
> > > intellij
> > >
> > > > > >> and
> > > > > >>
> > > > > >> >> > could
> > > > > >> >> >
> > > > > >> >> > >> let them know we'd like either feedback or "we're ok if
> > > > > >> >> > >> MNG-6275
> > > > > >> >>
> > > > > >> >> makes
> > > > > >> >>
> 

Re: [VOTE] Release Apache Maven 3.5.1

[Hervé BOUTEMY]

+1
eventually adding a flag or system property to activate the new behaviour

this remembers me of the idea regarding flags to support new beta features

Regards,

Hervé

Le mercredi 11 octobre 2017, 08:13:13 CEST Anders Hammar a écrit :
> I'm feeling stronger and stronger about not having this change in a bugfix
> release. Why not go for v3.6.0 if we decide that the class loading change
> is the way to go? And keep bugfix releases for just bugfixes.
> 
> /Anders
> 
> On Wed, Oct 11, 2017 at 3:43 AM, Hervé BOUTEMY 
> 
> wrote:
> > perhaps we should create a Wiki page for java.lang.ClassNotFoundException
> > and
> > list the plugins with known issues and minimum fixed version
> > 
> > to be added in
> > 
> >  https://cwiki.apache.org/confluence/display/MAVEN/Errors+and+Solutions
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le mercredi 11 octobre 2017, 02:52:53 CEST Hervé BOUTEMY a écrit :
> > > IIUC, it's MDEPLOY-221 about net.flexmojos.oss:flexmojos-maven-plugin
> > > 
> > > https://issues.apache.org/jira/browse/MDEPLOY-221
> > > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > > Le mardi 10 octobre 2017, 20:48:13 CEST Robert Scholte a écrit :
> > > > FYI, MDEPLOY-121 mentions another plugin being hit by the classloader
> > > > changes.
> > > > 
> > > > Robert
> > > > 
> > > > 
> > > > On Tue, 03 Oct 2017 20:22:18 +0200, Arnaud Héritier <
> > 
> > aherit...@gmail.com>
> > 
> > > > wrote:
> > > > > Thanks Stephen
> > > > > 
> > > > > On Tue, Oct 3, 2017 at 8:18 PM, Stephen Connolly <
> > > > > 
> > > > > stephen.alan.conno...@gmail.com> wrote:
> > > > >> I am hoping I can find some time to do a final round of experiments
> > 
> > and
> > 
> > > > >> then close the vote with success and publish.
> > > > >> 
> > > > >> On Tue 3 Oct 2017 at 11:13, Arnaud Héritier 
> > 
> > wrote:
> > > > >> > @Stephen What should we do now ?
> > > > >> > 
> > > > >> > 
> > > > >> > On Tue, Sep 19, 2017 at 3:14 AM, Olivier Lamy 
> > > > >> 
> > > > >> wrote:
> > > > >> >> Hi
> > > > >> >> Sorry a bit out of time ATM for testing this.
> > > > >> >> Well I trust Arnaud testing that especially if this improve the
> > > > >> >> performance
> > > > >> >> of this very great/awesome/users oriented plugin :P
> > > > >> >> 
> > > > >> >> On 13 September 2017 at 22:19, Arnaud Héritier
> > > > >> >> 
> > > > >> >> 
> > > > >> >> wrote:
> > > > >> >> > Damned, can't we be anonymous on Github ?
> > > > >> >> > I maintain it is a big word, I'm trying to fix more bugs than
> > > > >> >> > I
> > > > >> >> > add
> > > > >> 
> > > > >> new
> > > > >> 
> > > > >> >> > ones
> > > > >> >> > I added Oleg in the loop as he contributed a lot on it too
> > > > >> >> > I did a quick test to build on Jenkins 2.60.3 our maven core
> > 
> > with
> > 
> > > > >> the
> > > > >> 
> > > > >> >> Evil
> > > > >> >> 
> > > > >> >> > Maven plugin 2.17 on a local SSH agent and it is ok
> > > > >> >> > But it is really a quick test ...
> > > > >> >> > 
> > > > >> >> > Cheers
> > > > >> >> > 
> > > > >> >> > 
> > > > >> >> > 
> > > > >> >> > On Wed, Sep 13, 2017 at 10:07 AM, Stephen Connolly <
> > > > >> >> > 
> > > > >> >> > stephen.alan.conno...@gmail.com> wrote:
> > > > >> >> > > On 13 September 2017 at 01:05, Stephen Connolly <
> > > > >> >> > > 
> > > > >> >> > > stephen.alan.conno...@gmail.com> wrote:
> > > > >> >> > >> On 13 September 2017 at 00:26, Anders Hammar
> > > > >> >> > >> 
> > > > >> >> 
> > > > >> >> wrote:
> > > > >> >> > >>> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> > > > >> >> > >>> 
> > > > >> >> > >>> stephen.alan.conno...@gmail.com> wrote:
> > > > >> >> > >>> > Have we got any feedback from the embedder integrations
> > 
> > yet?
> > 
> > > > >> >> > >>> I haven't heard anything from the m2e people. Maybe we
> > 
> > need to
> > 
> > > > >> ping
> > > > >> 
> > > > >> >> > them
> > > > >> >> > 
> > > > >> >> > >>> directly. I can contact Fred Bricon.
> > > > >> >> > >>> 
> > > > >> >> > >>> /Anders
> > > > >> >> > >> 
> > > > >> >> > >> Please do, also if anyone has a contact in netbeans or
> > 
> > intellij
> > 
> > > > >> and
> > > > >> 
> > > > >> >> > could
> > > > >> >> > 
> > > > >> >> > >> let them know we'd like either feedback or "we're ok if
> > > > >> >> > >> MNG-6275
> > > > >> >> 
> > > > >> >> makes
> > > > >> >> 
> > > > >> >> > >> trouble for us, go ahead and release". I'd like to close
> > > > >> >> > >> the
> > > > >> 
> > > > >> vote
> > > > >> on
> > > > >> 
> > > > >> >> > Friday
> > > > >> >> > 
> > > > >> >> > >> 13:00 UTC.
> > > > >> >> > > 
> > > > >> >> > > Olivier / Arnaud, have either of you had a chance to test
> > 
> > this
> > 
> > > > >> with
> > > > >> 
> > > > >> >> the
> > > > >> >> 
> > > > >> >> > > evil project type[1] as you two seem to be the active
> > > > >> 
> > > > >> maintainers[2]
> > > > >> 
> > > > >> >> > > [1]: https://javaadventure.blogspot.ie/2013/11/jenkins-> >>
> > > > >> >> > > 
> 

Re: [VOTE] Release Apache Maven 3.5.1

[Anders Hammar]

I'm feeling stronger and stronger about not having this change in a bugfix
release. Why not go for v3.6.0 if we decide that the class loading change
is the way to go? And keep bugfix releases for just bugfixes.

/Anders

On Wed, Oct 11, 2017 at 3:43 AM, Hervé BOUTEMY 
wrote:

> perhaps we should create a Wiki page for java.lang.ClassNotFoundException
> and
> list the plugins with known issues and minimum fixed version
>
> to be added in
>  https://cwiki.apache.org/confluence/display/MAVEN/Errors+and+Solutions
>
> Regards,
>
> Hervé
>
> Le mercredi 11 octobre 2017, 02:52:53 CEST Hervé BOUTEMY a écrit :
> > IIUC, it's MDEPLOY-221 about net.flexmojos.oss:flexmojos-maven-plugin
> >
> > https://issues.apache.org/jira/browse/MDEPLOY-221
> >
> > Regards,
> >
> > Hervé
> >
> > Le mardi 10 octobre 2017, 20:48:13 CEST Robert Scholte a écrit :
> > > FYI, MDEPLOY-121 mentions another plugin being hit by the classloader
> > > changes.
> > >
> > > Robert
> > >
> > >
> > > On Tue, 03 Oct 2017 20:22:18 +0200, Arnaud Héritier <
> aherit...@gmail.com>
> > >
> > > wrote:
> > > > Thanks Stephen
> > > >
> > > > On Tue, Oct 3, 2017 at 8:18 PM, Stephen Connolly <
> > > >
> > > > stephen.alan.conno...@gmail.com> wrote:
> > > >> I am hoping I can find some time to do a final round of experiments
> and
> > > >> then close the vote with success and publish.
> > > >>
> > > >> On Tue 3 Oct 2017 at 11:13, Arnaud Héritier 
> wrote:
> > > >> > @Stephen What should we do now ?
> > > >> >
> > > >> >
> > > >> > On Tue, Sep 19, 2017 at 3:14 AM, Olivier Lamy 
> > > >>
> > > >> wrote:
> > > >> >> Hi
> > > >> >> Sorry a bit out of time ATM for testing this.
> > > >> >> Well I trust Arnaud testing that especially if this improve the
> > > >> >> performance
> > > >> >> of this very great/awesome/users oriented plugin :P
> > > >> >>
> > > >> >> On 13 September 2017 at 22:19, Arnaud Héritier
> > > >> >> 
> > > >> >>
> > > >> >> wrote:
> > > >> >> > Damned, can't we be anonymous on Github ?
> > > >> >> > I maintain it is a big word, I'm trying to fix more bugs than I
> > > >> >> > add
> > > >>
> > > >> new
> > > >>
> > > >> >> > ones
> > > >> >> > I added Oleg in the loop as he contributed a lot on it too
> > > >> >> > I did a quick test to build on Jenkins 2.60.3 our maven core
> with
> > > >>
> > > >> the
> > > >>
> > > >> >> Evil
> > > >> >>
> > > >> >> > Maven plugin 2.17 on a local SSH agent and it is ok
> > > >> >> > But it is really a quick test ...
> > > >> >> >
> > > >> >> > Cheers
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> > On Wed, Sep 13, 2017 at 10:07 AM, Stephen Connolly <
> > > >> >> >
> > > >> >> > stephen.alan.conno...@gmail.com> wrote:
> > > >> >> > > On 13 September 2017 at 01:05, Stephen Connolly <
> > > >> >> > >
> > > >> >> > > stephen.alan.conno...@gmail.com> wrote:
> > > >> >> > >> On 13 September 2017 at 00:26, Anders Hammar
> > > >> >> > >> 
> > > >> >>
> > > >> >> wrote:
> > > >> >> > >>> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> > > >> >> > >>>
> > > >> >> > >>> stephen.alan.conno...@gmail.com> wrote:
> > > >> >> > >>> > Have we got any feedback from the embedder integrations
> yet?
> > > >> >> > >>>
> > > >> >> > >>> I haven't heard anything from the m2e people. Maybe we
> need to
> > > >>
> > > >> ping
> > > >>
> > > >> >> > them
> > > >> >> >
> > > >> >> > >>> directly. I can contact Fred Bricon.
> > > >> >> > >>>
> > > >> >> > >>> /Anders
> > > >> >> > >>
> > > >> >> > >> Please do, also if anyone has a contact in netbeans or
> intellij
> > > >>
> > > >> and
> > > >>
> > > >> >> > could
> > > >> >> >
> > > >> >> > >> let them know we'd like either feedback or "we're ok if
> > > >> >> > >> MNG-6275
> > > >> >>
> > > >> >> makes
> > > >> >>
> > > >> >> > >> trouble for us, go ahead and release". I'd like to close the
> > > >>
> > > >> vote
> > > >> on
> > > >>
> > > >> >> > Friday
> > > >> >> >
> > > >> >> > >> 13:00 UTC.
> > > >> >> > >
> > > >> >> > > Olivier / Arnaud, have either of you had a chance to test
> this
> > > >>
> > > >> with
> > > >>
> > > >> >> the
> > > >> >>
> > > >> >> > > evil project type[1] as you two seem to be the active
> > > >>
> > > >> maintainers[2]
> > > >>
> > > >> >> > > [1]: https://javaadventure.blogspot.ie/2013/11/jenkins-> >>
> >> >
> > > >> >> > > > maven-job-type-considered-evil.html [2]:
> > > >> >> > > https://github.com/jenkinsci/maven-plugin/commits/master
> > > >> >> >
> > > >> >> > --
> > > >> >> >
> > > >> >> > Arnaud
> > > >> >>
> > > >> >> --
> > > >> >> Olivier Lamy
> > > >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> > > >> >
> > > >> > --
> > > >> > -
> > > >> > Arnaud Héritier
> > > >> > http://aheritier.net
> > > >> > Mail/GTalk: aheritier AT gmail DOT com
> > > >> > Twitter/Skype : aheritier
> > > >>
> > > >> --
> > > >> Sent from my phone
> > >
> > > -
> > 

Re: [VOTE] Release Apache Maven 3.5.1

[Hervé BOUTEMY]

perhaps we should create a Wiki page for java.lang.ClassNotFoundException and 
list the plugins with known issues and minimum fixed version

to be added in
 https://cwiki.apache.org/confluence/display/MAVEN/Errors+and+Solutions

Regards,

Hervé

Le mercredi 11 octobre 2017, 02:52:53 CEST Hervé BOUTEMY a écrit :
> IIUC, it's MDEPLOY-221 about net.flexmojos.oss:flexmojos-maven-plugin
> 
> https://issues.apache.org/jira/browse/MDEPLOY-221
> 
> Regards,
> 
> Hervé
> 
> Le mardi 10 octobre 2017, 20:48:13 CEST Robert Scholte a écrit :
> > FYI, MDEPLOY-121 mentions another plugin being hit by the classloader
> > changes.
> > 
> > Robert
> > 
> > 
> > On Tue, 03 Oct 2017 20:22:18 +0200, Arnaud Héritier 
> > 
> > wrote:
> > > Thanks Stephen
> > > 
> > > On Tue, Oct 3, 2017 at 8:18 PM, Stephen Connolly <
> > > 
> > > stephen.alan.conno...@gmail.com> wrote:
> > >> I am hoping I can find some time to do a final round of experiments and
> > >> then close the vote with success and publish.
> > >> 
> > >> On Tue 3 Oct 2017 at 11:13, Arnaud Héritier  
wrote:
> > >> > @Stephen What should we do now ?
> > >> > 
> > >> > 
> > >> > On Tue, Sep 19, 2017 at 3:14 AM, Olivier Lamy 
> > >> 
> > >> wrote:
> > >> >> Hi
> > >> >> Sorry a bit out of time ATM for testing this.
> > >> >> Well I trust Arnaud testing that especially if this improve the
> > >> >> performance
> > >> >> of this very great/awesome/users oriented plugin :P
> > >> >> 
> > >> >> On 13 September 2017 at 22:19, Arnaud Héritier
> > >> >> 
> > >> >> 
> > >> >> wrote:
> > >> >> > Damned, can't we be anonymous on Github ?
> > >> >> > I maintain it is a big word, I'm trying to fix more bugs than I
> > >> >> > add
> > >> 
> > >> new
> > >> 
> > >> >> > ones
> > >> >> > I added Oleg in the loop as he contributed a lot on it too
> > >> >> > I did a quick test to build on Jenkins 2.60.3 our maven core with
> > >> 
> > >> the
> > >> 
> > >> >> Evil
> > >> >> 
> > >> >> > Maven plugin 2.17 on a local SSH agent and it is ok
> > >> >> > But it is really a quick test ...
> > >> >> > 
> > >> >> > Cheers
> > >> >> > 
> > >> >> > 
> > >> >> > 
> > >> >> > On Wed, Sep 13, 2017 at 10:07 AM, Stephen Connolly <
> > >> >> > 
> > >> >> > stephen.alan.conno...@gmail.com> wrote:
> > >> >> > > On 13 September 2017 at 01:05, Stephen Connolly <
> > >> >> > > 
> > >> >> > > stephen.alan.conno...@gmail.com> wrote:
> > >> >> > >> On 13 September 2017 at 00:26, Anders Hammar
> > >> >> > >> 
> > >> >> 
> > >> >> wrote:
> > >> >> > >>> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> > >> >> > >>> 
> > >> >> > >>> stephen.alan.conno...@gmail.com> wrote:
> > >> >> > >>> > Have we got any feedback from the embedder integrations yet?
> > >> >> > >>> 
> > >> >> > >>> I haven't heard anything from the m2e people. Maybe we need to
> > >> 
> > >> ping
> > >> 
> > >> >> > them
> > >> >> > 
> > >> >> > >>> directly. I can contact Fred Bricon.
> > >> >> > >>> 
> > >> >> > >>> /Anders
> > >> >> > >> 
> > >> >> > >> Please do, also if anyone has a contact in netbeans or intellij
> > >> 
> > >> and
> > >> 
> > >> >> > could
> > >> >> > 
> > >> >> > >> let them know we'd like either feedback or "we're ok if
> > >> >> > >> MNG-6275
> > >> >> 
> > >> >> makes
> > >> >> 
> > >> >> > >> trouble for us, go ahead and release". I'd like to close the
> > >> 
> > >> vote
> > >> on
> > >> 
> > >> >> > Friday
> > >> >> > 
> > >> >> > >> 13:00 UTC.
> > >> >> > > 
> > >> >> > > Olivier / Arnaud, have either of you had a chance to test this
> > >> 
> > >> with
> > >> 
> > >> >> the
> > >> >> 
> > >> >> > > evil project type[1] as you two seem to be the active
> > >> 
> > >> maintainers[2]
> > >> 
> > >> >> > > [1]: https://javaadventure.blogspot.ie/2013/11/jenkins-> >> >> >
> > >> >> > > > maven-job-type-considered-evil.html [2]:
> > >> >> > > https://github.com/jenkinsci/maven-plugin/commits/master
> > >> >> > 
> > >> >> > --
> > >> >> > 
> > >> >> > Arnaud
> > >> >> 
> > >> >> --
> > >> >> Olivier Lamy
> > >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >> > 
> > >> > --
> > >> > -
> > >> > Arnaud Héritier
> > >> > http://aheritier.net
> > >> > Mail/GTalk: aheritier AT gmail DOT com
> > >> > Twitter/Skype : aheritier
> > >> 
> > >> --
> > >> 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



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

Re: [VOTE] Release Apache Maven 3.5.1

[Hervé BOUTEMY]

IIUC, it's MDEPLOY-221 about net.flexmojos.oss:flexmojos-maven-plugin

https://issues.apache.org/jira/browse/MDEPLOY-221

Regards,

Hervé

Le mardi 10 octobre 2017, 20:48:13 CEST Robert Scholte a écrit :
> FYI, MDEPLOY-121 mentions another plugin being hit by the classloader
> changes.
> 
> Robert
> 
> 
> On Tue, 03 Oct 2017 20:22:18 +0200, Arnaud Héritier 
> 
> wrote:
> > Thanks Stephen
> > 
> > On Tue, Oct 3, 2017 at 8:18 PM, Stephen Connolly <
> > 
> > stephen.alan.conno...@gmail.com> wrote:
> >> I am hoping I can find some time to do a final round of experiments and
> >> then close the vote with success and publish.
> >> 
> >> On Tue 3 Oct 2017 at 11:13, Arnaud Héritier  wrote:
> >> > @Stephen What should we do now ?
> >> > 
> >> > 
> >> > On Tue, Sep 19, 2017 at 3:14 AM, Olivier Lamy 
> >> 
> >> wrote:
> >> >> Hi
> >> >> Sorry a bit out of time ATM for testing this.
> >> >> Well I trust Arnaud testing that especially if this improve the
> >> >> performance
> >> >> of this very great/awesome/users oriented plugin :P
> >> >> 
> >> >> On 13 September 2017 at 22:19, Arnaud Héritier 
> >> >> 
> >> >> wrote:
> >> >> > Damned, can't we be anonymous on Github ?
> >> >> > I maintain it is a big word, I'm trying to fix more bugs than I add
> >> 
> >> new
> >> 
> >> >> > ones
> >> >> > I added Oleg in the loop as he contributed a lot on it too
> >> >> > I did a quick test to build on Jenkins 2.60.3 our maven core with
> >> 
> >> the
> >> 
> >> >> Evil
> >> >> 
> >> >> > Maven plugin 2.17 on a local SSH agent and it is ok
> >> >> > But it is really a quick test ...
> >> >> > 
> >> >> > Cheers
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > On Wed, Sep 13, 2017 at 10:07 AM, Stephen Connolly <
> >> >> > 
> >> >> > stephen.alan.conno...@gmail.com> wrote:
> >> >> > > On 13 September 2017 at 01:05, Stephen Connolly <
> >> >> > > 
> >> >> > > stephen.alan.conno...@gmail.com> wrote:
> >> >> > >> On 13 September 2017 at 00:26, Anders Hammar 
> >> >> 
> >> >> wrote:
> >> >> > >>> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> >> >> > >>> 
> >> >> > >>> stephen.alan.conno...@gmail.com> wrote:
> >> >> > >>> > Have we got any feedback from the embedder integrations yet?
> >> >> > >>> 
> >> >> > >>> I haven't heard anything from the m2e people. Maybe we need to
> >> 
> >> ping
> >> 
> >> >> > them
> >> >> > 
> >> >> > >>> directly. I can contact Fred Bricon.
> >> >> > >>> 
> >> >> > >>> /Anders
> >> >> > >> 
> >> >> > >> Please do, also if anyone has a contact in netbeans or intellij
> >> 
> >> and
> >> 
> >> >> > could
> >> >> > 
> >> >> > >> let them know we'd like either feedback or "we're ok if MNG-6275
> >> >> 
> >> >> makes
> >> >> 
> >> >> > >> trouble for us, go ahead and release". I'd like to close the
> >> 
> >> vote
> >> on
> >> 
> >> >> > Friday
> >> >> > 
> >> >> > >> 13:00 UTC.
> >> >> > > 
> >> >> > > Olivier / Arnaud, have either of you had a chance to test this
> >> 
> >> with
> >> 
> >> >> the
> >> >> 
> >> >> > > evil project type[1] as you two seem to be the active
> >> 
> >> maintainers[2]
> >> 
> >> >> > > [1]: https://javaadventure.blogspot.ie/2013/11/jenkins-> >> >> > > 
> >> >> > > maven-job-type-considered-evil.html
> >> >> > > [2]: https://github.com/jenkinsci/maven-plugin/commits/master
> >> >> > 
> >> >> > --
> >> >> > 
> >> >> > Arnaud
> >> >> 
> >> >> --
> >> >> Olivier Lamy
> >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >> > 
> >> > --
> >> > -
> >> > Arnaud Héritier
> >> > http://aheritier.net
> >> > Mail/GTalk: aheritier AT gmail DOT com
> >> > Twitter/Skype : aheritier
> >> 
> >> --
> >> 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: [VOTE] Release Apache Maven 3.5.1

[Robert Scholte]

FYI, MDEPLOY-121 mentions another plugin being hit by the classloader  
changes.


Robert


On Tue, 03 Oct 2017 20:22:18 +0200, Arnaud Héritier   
wrote:



Thanks Stephen

On Tue, Oct 3, 2017 at 8:18 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:


I am hoping I can find some time to do a final round of experiments and
then close the vote with success and publish.


On Tue 3 Oct 2017 at 11:13, Arnaud Héritier  wrote:

> @Stephen What should we do now ?
>
>
> On Tue, Sep 19, 2017 at 3:14 AM, Olivier Lamy   
wrote:

>
>> Hi
>> Sorry a bit out of time ATM for testing this.
>> Well I trust Arnaud testing that especially if this improve the
>> performance
>> of this very great/awesome/users oriented plugin :P
>>
>> On 13 September 2017 at 22:19, Arnaud Héritier 
>> wrote:
>>
>> > Damned, can't we be anonymous on Github ?
>> > I maintain it is a big word, I'm trying to fix more bugs than I add
new
>> > ones
>> > I added Oleg in the loop as he contributed a lot on it too
>> > I did a quick test to build on Jenkins 2.60.3 our maven core with  
the

>> Evil
>> > Maven plugin 2.17 on a local SSH agent and it is ok
>> > But it is really a quick test ...
>> >
>> > Cheers
>> >
>> >
>> >
>> > On Wed, Sep 13, 2017 at 10:07 AM, Stephen Connolly <
>> > stephen.alan.conno...@gmail.com> wrote:
>> >
>> > > On 13 September 2017 at 01:05, Stephen Connolly <
>> > > stephen.alan.conno...@gmail.com> wrote:
>> > >
>> > >> On 13 September 2017 at 00:26, Anders Hammar 
>> wrote:
>> > >>
>> > >>> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
>> > >>> stephen.alan.conno...@gmail.com> wrote:
>> > >>>
>> > >>> > Have we got any feedback from the embedder integrations yet?
>> > >>> >
>> > >>>
>> > >>> I haven't heard anything from the m2e people. Maybe we need to
ping
>> > them
>> > >>> directly. I can contact Fred Bricon.
>> > >>>
>> > >>> /Anders
>> > >>>
>> > >>>
>> > >> Please do, also if anyone has a contact in netbeans or intellij  
and

>> > could
>> > >> let them know we'd like either feedback or "we're ok if MNG-6275
>> makes
>> > >> trouble for us, go ahead and release". I'd like to close the  
vote

on
>> > Friday
>> > >> 13:00 UTC.
>> > >>
>> > >>
>> > >
>> > > Olivier / Arnaud, have either of you had a chance to test this  
with

>> the
>> > > evil project type[1] as you two seem to be the active  
maintainers[2]

>> > >
>> > > [1]: https://javaadventure.blogspot.ie/2013/11/jenkins-
>> > > maven-job-type-considered-evil.html
>> > > [2]: https://github.com/jenkinsci/maven-plugin/commits/master
>> > >
>> >
>> >
>> >
>> > --
>> >
>> > Arnaud
>> >
>>
>>
>>
>> --
>> Olivier Lamy
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>
>
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>
--
Sent from my phone






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

Re: [VOTE] Release Apache Maven 3.5.1

[Arnaud Héritier]

Thanks Stephen

On Tue, Oct 3, 2017 at 8:18 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I am hoping I can find some time to do a final round of experiments and
> then close the vote with success and publish.
>
>
> On Tue 3 Oct 2017 at 11:13, Arnaud Héritier  wrote:
>
> > @Stephen What should we do now ?
> >
> >
> > On Tue, Sep 19, 2017 at 3:14 AM, Olivier Lamy  wrote:
> >
> >> Hi
> >> Sorry a bit out of time ATM for testing this.
> >> Well I trust Arnaud testing that especially if this improve the
> >> performance
> >> of this very great/awesome/users oriented plugin :P
> >>
> >> On 13 September 2017 at 22:19, Arnaud Héritier 
> >> wrote:
> >>
> >> > Damned, can't we be anonymous on Github ?
> >> > I maintain it is a big word, I'm trying to fix more bugs than I add
> new
> >> > ones
> >> > I added Oleg in the loop as he contributed a lot on it too
> >> > I did a quick test to build on Jenkins 2.60.3 our maven core with the
> >> Evil
> >> > Maven plugin 2.17 on a local SSH agent and it is ok
> >> > But it is really a quick test ...
> >> >
> >> > Cheers
> >> >
> >> >
> >> >
> >> > On Wed, Sep 13, 2017 at 10:07 AM, Stephen Connolly <
> >> > stephen.alan.conno...@gmail.com> wrote:
> >> >
> >> > > On 13 September 2017 at 01:05, Stephen Connolly <
> >> > > stephen.alan.conno...@gmail.com> wrote:
> >> > >
> >> > >> On 13 September 2017 at 00:26, Anders Hammar 
> >> wrote:
> >> > >>
> >> > >>> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> >> > >>> stephen.alan.conno...@gmail.com> wrote:
> >> > >>>
> >> > >>> > Have we got any feedback from the embedder integrations yet?
> >> > >>> >
> >> > >>>
> >> > >>> I haven't heard anything from the m2e people. Maybe we need to
> ping
> >> > them
> >> > >>> directly. I can contact Fred Bricon.
> >> > >>>
> >> > >>> /Anders
> >> > >>>
> >> > >>>
> >> > >> Please do, also if anyone has a contact in netbeans or intellij and
> >> > could
> >> > >> let them know we'd like either feedback or "we're ok if MNG-6275
> >> makes
> >> > >> trouble for us, go ahead and release". I'd like to close the vote
> on
> >> > Friday
> >> > >> 13:00 UTC.
> >> > >>
> >> > >>
> >> > >
> >> > > Olivier / Arnaud, have either of you had a chance to test this with
> >> the
> >> > > evil project type[1] as you two seem to be the active maintainers[2]
> >> > >
> >> > > [1]: https://javaadventure.blogspot.ie/2013/11/jenkins-
> >> > > maven-job-type-considered-evil.html
> >> > > [2]: https://github.com/jenkinsci/maven-plugin/commits/master
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> >
> >> > Arnaud
> >> >
> >>
> >>
> >>
> >> --
> >> Olivier Lamy
> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>
> >
> >
> >
> > --
> > -
> > Arnaud Héritier
> > http://aheritier.net
> > Mail/GTalk: aheritier AT gmail DOT com
> > Twitter/Skype : aheritier
> >
> --
> Sent from my phone
>



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

Re: [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

I am hoping I can find some time to do a final round of experiments and
then close the vote with success and publish.


On Tue 3 Oct 2017 at 11:13, Arnaud Héritier  wrote:

> @Stephen What should we do now ?
>
>
> On Tue, Sep 19, 2017 at 3:14 AM, Olivier Lamy  wrote:
>
>> Hi
>> Sorry a bit out of time ATM for testing this.
>> Well I trust Arnaud testing that especially if this improve the
>> performance
>> of this very great/awesome/users oriented plugin :P
>>
>> On 13 September 2017 at 22:19, Arnaud Héritier 
>> wrote:
>>
>> > Damned, can't we be anonymous on Github ?
>> > I maintain it is a big word, I'm trying to fix more bugs than I add new
>> > ones
>> > I added Oleg in the loop as he contributed a lot on it too
>> > I did a quick test to build on Jenkins 2.60.3 our maven core with the
>> Evil
>> > Maven plugin 2.17 on a local SSH agent and it is ok
>> > But it is really a quick test ...
>> >
>> > Cheers
>> >
>> >
>> >
>> > On Wed, Sep 13, 2017 at 10:07 AM, Stephen Connolly <
>> > stephen.alan.conno...@gmail.com> wrote:
>> >
>> > > On 13 September 2017 at 01:05, Stephen Connolly <
>> > > stephen.alan.conno...@gmail.com> wrote:
>> > >
>> > >> On 13 September 2017 at 00:26, Anders Hammar 
>> wrote:
>> > >>
>> > >>> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
>> > >>> stephen.alan.conno...@gmail.com> wrote:
>> > >>>
>> > >>> > Have we got any feedback from the embedder integrations yet?
>> > >>> >
>> > >>>
>> > >>> I haven't heard anything from the m2e people. Maybe we need to ping
>> > them
>> > >>> directly. I can contact Fred Bricon.
>> > >>>
>> > >>> /Anders
>> > >>>
>> > >>>
>> > >> Please do, also if anyone has a contact in netbeans or intellij and
>> > could
>> > >> let them know we'd like either feedback or "we're ok if MNG-6275
>> makes
>> > >> trouble for us, go ahead and release". I'd like to close the vote on
>> > Friday
>> > >> 13:00 UTC.
>> > >>
>> > >>
>> > >
>> > > Olivier / Arnaud, have either of you had a chance to test this with
>> the
>> > > evil project type[1] as you two seem to be the active maintainers[2]
>> > >
>> > > [1]: https://javaadventure.blogspot.ie/2013/11/jenkins-
>> > > maven-job-type-considered-evil.html
>> > > [2]: https://github.com/jenkinsci/maven-plugin/commits/master
>> > >
>> >
>> >
>> >
>> > --
>> >
>> > Arnaud
>> >
>>
>>
>>
>> --
>> Olivier Lamy
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>
>
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>
-- 
Sent from my phone

Re: [VOTE] Release Apache Maven 3.5.1

[Arnaud Héritier]

@Stephen What should we do now ?


On Tue, Sep 19, 2017 at 3:14 AM, Olivier Lamy  wrote:

> Hi
> Sorry a bit out of time ATM for testing this.
> Well I trust Arnaud testing that especially if this improve the performance
> of this very great/awesome/users oriented plugin :P
>
> On 13 September 2017 at 22:19, Arnaud Héritier 
> wrote:
>
> > Damned, can't we be anonymous on Github ?
> > I maintain it is a big word, I'm trying to fix more bugs than I add new
> > ones
> > I added Oleg in the loop as he contributed a lot on it too
> > I did a quick test to build on Jenkins 2.60.3 our maven core with the
> Evil
> > Maven plugin 2.17 on a local SSH agent and it is ok
> > But it is really a quick test ...
> >
> > Cheers
> >
> >
> >
> > On Wed, Sep 13, 2017 at 10:07 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > On 13 September 2017 at 01:05, Stephen Connolly <
> > > stephen.alan.conno...@gmail.com> wrote:
> > >
> > >> On 13 September 2017 at 00:26, Anders Hammar 
> wrote:
> > >>
> > >>> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> > >>> stephen.alan.conno...@gmail.com> wrote:
> > >>>
> > >>> > Have we got any feedback from the embedder integrations yet?
> > >>> >
> > >>>
> > >>> I haven't heard anything from the m2e people. Maybe we need to ping
> > them
> > >>> directly. I can contact Fred Bricon.
> > >>>
> > >>> /Anders
> > >>>
> > >>>
> > >> Please do, also if anyone has a contact in netbeans or intellij and
> > could
> > >> let them know we'd like either feedback or "we're ok if MNG-6275 makes
> > >> trouble for us, go ahead and release". I'd like to close the vote on
> > Friday
> > >> 13:00 UTC.
> > >>
> > >>
> > >
> > > Olivier / Arnaud, have either of you had a chance to test this with the
> > > evil project type[1] as you two seem to be the active maintainers[2]
> > >
> > > [1]: https://javaadventure.blogspot.ie/2013/11/jenkins-
> > > maven-job-type-considered-evil.html
> > > [2]: https://github.com/jenkinsci/maven-plugin/commits/master
> > >
> >
> >
> >
> > --
> >
> > Arnaud
> >
>
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>



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

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Igor Fedorenko]

See inline


On Sun, Sep 24, 2017, at 03:37 PM, Stephen Connolly wrote:
> Right now I have a successful vote to release 3.5.1
> 

[snip]

> Now I see 6209 changing the classloader for plugins that are also build
> extensions... the question here is two fold:
> 
> 1. Is the new behaviour *correct* or just *less wrong*?
> 2. If “less wrong”, is it less wrong on the same side of correct as the
> old
> behaviour, or is it less wrong on the other side of correct?

6209 does not change plugin classloading per se, but it does change TCCL
used when running mojos from extensions=true plugins.

I believe the new *behaviour* is correct, that is, components from
extensions=true plugins should be used consistently with or without
other extensions present. Think of a custom wagon or packaging type,
it'd be very surprising if these component were ignored when running
mojos from other extensions=true plugins.

I also believe changing TCCL is the only way to implement the correct
behaviour given how Sisu locates components, but I am open to other
ideas. I also think that extensions=true plugins are a relative
minority, we only had single problem exposed by the TCCL change (root
cause being a bug in assembly-plugin), so I wonder if we are
otherthinking this.

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

> The other one is 6275 changing the TCCL. We have site documentation
> *stating* that TCCL will be the plugin classloader, and we are changing
> now
> so that TCCL is not.


6275 does not change TCCL, it changes classloader parent hierarchy.
Still a big change, especially for applications that embed Maven, but I
think current implementation falls into "less wrong" category too but it
is likely the best we can do to support ServiceLoaderFactory and java9
(without completely redesigning and reimplementing Maven classloading,
at least).

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

> 3. Which do we need to fix: site or code?
> 4. Are we sure we can guarantee that the plugin classloader is always the
> classloader that loaded the plugin class: what if I have plugin A
> dependends on Plugin B (not what i’d recommend, but users do crazy
> things)
> so we have the mojos in Plugin B coming from a jar dependency of Plugin
> A... so could we then we have layered classloaders in which case when I
> invoke A:mojo-from-b will it be loaded by A’s classloader or a parent of
> A
> that hold the B jar?

I don't believe this behaviour changed in 3.5.1. We don't guarantee
mojos are always loaded from plugin classloader, but we do guarantee
mojos implementation is looked up in plugin classloader first (see
DefaultMavenPluginManager.getConfiguredMojo). We could validate mojo
classloader == plugin classloader and fail the build if that's not the
case, but I don't see the advantages such check would provide.

> Or what if I were to use an extension to provide the mojo but advertising
> the extension’s mojo class via a plugin?

This can only happen the mojo is declared in plugin
META-INF/maven/plugin.xml, which means the plugin authors made
deliberate effort to enable such arrangement and I currently don't see
why we should attempt to block it.

> 
> These are all *really* stupid things in my opinion, but we haven’t said
> “thou shalt not expose mojos from other jar files” so someone *could*
> have
> done it... how are they to get the plugin classloader now that 6275 is
> landing? (I think a component of type classloader with a role-hint of
> “plugin” would make sense to me)
> 
> Alternatively, we document “thou shalt not” and be done with it...
> 
> But these are the kinds of things we need to resolve before I feel I can
> close the 3.5.1 vote one way or another.
> 
> 


-- 
Regards,
Igor


> On Sun 24 Sep 2017 at 20:06, Igor Fedorenko  wrote:
> 
> > Lets decide the agenda first, then who you need to attend (assuming you
> > are driving this discussion/decision), then pick the time that works.
> >
> > From my side, I still don't understand the problems we are trying to
> > solve. If this is the lacking documentation and general "uncomfort" to
> > mess with classloading in bug fix release, then maybe do what Anders
> > suggests (I think), bump the version to 3.6.0, document the behaviour we
> > have on master and move on.
> >
> > --
> > Regards,
> > Igor
> >
> > On Sun, Sep 24, 2017, at 02:28 PM, Stephen Connolly wrote:
> > > I wonder should we do a hangout to decide what you do?
> > >
> > > What times on Monday work best?
> > >
> > > I can maybe do 8:30-9:30pm Irish time
> > >
> > >
> > https://www.timeanddate.com/worldclock/meetingdetails.html?year=2017=9=25=19=30=0=78=37=179
> > >
> > > But we’d need to decide who we need and an actual agenda.
> > >
> > > If Monday is too soon I can see if I have a window later this week
> > >
> > > On Sun 24 Sep 2017 at 18:58, Igor Fedorenko  wrote:
> > >
> > > > See my answers/comments inline
> > > >
> > > >
> > > > On Sun, Sep 24, 2017, at 12:07 PM, Stephen 

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Stephen Connolly]

Right now I have a successful vote to release 3.5.1

I also have two issues changing classloader behaviours in ways that may
surprise people.

I am not against releasing what we have as a bug fix release - if these are
actual bugs.

I am not against fixing inconsistencies with the site documentation - if
the documentation is in error.

But right now what I do not see is a clear expression of how we envision
Maven classloading *should* work.

I expect master is not aligned with what we would want, and 3.5.0 is also
not aligned... but if we say this is an N variable problem and the ideal is
(x,y,z,v,w,...,q) and 3.5.0 is (x-5,y,z-2,v,w,...,q) and 3.5.1 is
(x+3,y-1,z-2,v,w,...,q) which is “closer” to the ideal but has overshot one
factor and actually degraded another... well I don’t want to release that

Otoh if 3.5.1 is (x-4,y,z-1,v,w,...,q) which is moving some aspects closer
but those aspects are still not perfect... i’m fine - as 3.5.1 release
manager - with closing the vote and pushing the release.

Now I see 6209 changing the classloader for plugins that are also build
extensions... the question here is two fold:

1. Is the new behaviour *correct* or just *less wrong*?
2. If “less wrong”, is it less wrong on the same side of correct as the old
behaviour, or is it less wrong on the other side of correct?

The other one is 6275 changing the TCCL. We have site documentation
*stating* that TCCL will be the plugin classloader, and we are changing now
so that TCCL is not.

3. Which do we need to fix: site or code?
4. Are we sure we can guarantee that the plugin classloader is always the
classloader that loaded the plugin class: what if I have plugin A
dependends on Plugin B (not what i’d recommend, but users do crazy things)
so we have the mojos in Plugin B coming from a jar dependency of Plugin
A... so could we then we have layered classloaders in which case when I
invoke A:mojo-from-b will it be loaded by A’s classloader or a parent of A
that hold the B jar?

Or what if I were to use an extension to provide the mojo but advertising
the extension’s mojo class via a plugin?

These are all *really* stupid things in my opinion, but we haven’t said
“thou shalt not expose mojos from other jar files” so someone *could* have
done it... how are they to get the plugin classloader now that 6275 is
landing? (I think a component of type classloader with a role-hint of
“plugin” would make sense to me)

Alternatively, we document “thou shalt not” and be done with it...

But these are the kinds of things we need to resolve before I feel I can
close the 3.5.1 vote one way or another.


On Sun 24 Sep 2017 at 20:06, Igor Fedorenko  wrote:

> Lets decide the agenda first, then who you need to attend (assuming you
> are driving this discussion/decision), then pick the time that works.
>
> From my side, I still don't understand the problems we are trying to
> solve. If this is the lacking documentation and general "uncomfort" to
> mess with classloading in bug fix release, then maybe do what Anders
> suggests (I think), bump the version to 3.6.0, document the behaviour we
> have on master and move on.
>
> --
> Regards,
> Igor
>
> On Sun, Sep 24, 2017, at 02:28 PM, Stephen Connolly wrote:
> > I wonder should we do a hangout to decide what you do?
> >
> > What times on Monday work best?
> >
> > I can maybe do 8:30-9:30pm Irish time
> >
> >
> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2017=9=25=19=30=0=78=37=179
> >
> > But we’d need to decide who we need and an actual agenda.
> >
> > If Monday is too soon I can see if I have a window later this week
> >
> > On Sun 24 Sep 2017 at 18:58, Igor Fedorenko  wrote:
> >
> > > See my answers/comments inline
> > >
> > >
> > > On Sun, Sep 24, 2017, at 12:07 PM, Stephen Connolly wrote:
> > > > https://maven.apache.org/guides/mini/guide-maven-classloading.html
> says:
> > > >
> > > > > When a build plugin is executed, the thread's context classloader
> is
> > > set
> > > > to the plugin classloader.
> > > >
> > > > So we'll need to fix something somewhere...
> > > >
> > > >
> > >
> https://svn.apache.org/repos/infra/websites/production/maven/content/reference/maven-classloading.html
> > > > is unaccessible from the website due to a rewrite rule...
> > > >
> > > > Things that seem to be missing:
> > > >
> > > > * What is the desired classloading for a plugin that is marked as an
> > > > extension? Can a plugin have a META-INF/maven/extension.xml to allow
> > > > exporting classes and artifacts when used as an extension? How
> should the
> > > > classloading look for such a strange beast.
> > >
> > > To me, the key requirement is that @Singleton components and class
> > > static members are singletons when injected in Maven core or in @Mojos.
> > > This implies that there should be single classloader representing an
> > > extensions plugins (MNG-5742).
> > >
> > > META-INF/maven/extension.xml declares what packages of the extension

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Igor Fedorenko]

Lets decide the agenda first, then who you need to attend (assuming you
are driving this discussion/decision), then pick the time that works.

>From my side, I still don't understand the problems we are trying to
solve. If this is the lacking documentation and general "uncomfort" to
mess with classloading in bug fix release, then maybe do what Anders
suggests (I think), bump the version to 3.6.0, document the behaviour we
have on master and move on.

-- 
Regards,
Igor

On Sun, Sep 24, 2017, at 02:28 PM, Stephen Connolly wrote:
> I wonder should we do a hangout to decide what you do?
> 
> What times on Monday work best?
> 
> I can maybe do 8:30-9:30pm Irish time
> 
> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2017=9=25=19=30=0=78=37=179
> 
> But we’d need to decide who we need and an actual agenda.
> 
> If Monday is too soon I can see if I have a window later this week
> 
> On Sun 24 Sep 2017 at 18:58, Igor Fedorenko  wrote:
> 
> > See my answers/comments inline
> >
> >
> > On Sun, Sep 24, 2017, at 12:07 PM, Stephen Connolly wrote:
> > > https://maven.apache.org/guides/mini/guide-maven-classloading.html says:
> > >
> > > > When a build plugin is executed, the thread's context classloader is
> > set
> > > to the plugin classloader.
> > >
> > > So we'll need to fix something somewhere...
> > >
> > >
> > https://svn.apache.org/repos/infra/websites/production/maven/content/reference/maven-classloading.html
> > > is unaccessible from the website due to a rewrite rule...
> > >
> > > Things that seem to be missing:
> > >
> > > * What is the desired classloading for a plugin that is marked as an
> > > extension? Can a plugin have a META-INF/maven/extension.xml to allow
> > > exporting classes and artifacts when used as an extension? How should the
> > > classloading look for such a strange beast.
> >
> > To me, the key requirement is that @Singleton components and class
> > static members are singletons when injected in Maven core or in @Mojos.
> > This implies that there should be single classloader representing an
> > extensions plugins (MNG-5742).
> >
> > META-INF/maven/extension.xml declares what packages of the extension
> > plugin are visible to other (non extension) plugins.
> > META-INF/maven/extension.xml does not affect classloading of the
> > extension plugin nor it affects the "shape" of other classloaders.
> >
> > > * How does one access the plugin classloader if we want TCCL to be other
> > > than that, is it a Dependency Injection or something else?
> >
> > this.getClass().getClassLoader() is the most direct way to access plugin
> > classloader. Why do you think we need anything more elaborate?
> >
> >
> > > * What differentiates a Core extension from a Build extension (is it that
> > > a
> > > build extension lacks a META-INF/maven/extension.xml and was only
> > > declared
> > > in the pom.xml, while a core extension either has a
> > > META-INF/maven/extension.xml - if declared in the pom - or is an
> > > extension
> > > declared in .mvn/extensions.xml)
> >
> > Core extensions are loaded *before* build starts, so they can contribute
> > AbstractMavenLifecycleParticipant#afterSessionStart, for example. They
> > can also export packages visible to all build plugins, including
> > extensions=true. On the flip side, each core extension is effectively
> > singleton, you can't have two different versions of the same Core
> > extension. Core extensions also have direct access to Maven core classes
> > and can do more interesting things there (for better or worse).
> >
> > Build extensions are part of the project build and as such are limited
> > what components they can contribute to the Core and what core classes
> > they have access to.
> >
> > I tried to capture this in the diagram I drew for
> > http://takari.io/book/91-maven-classloading.html.
> >
> > > At this point in time I think we are nearing the point where I may have
> > > to
> > > declare 3.5.1 abandoned as I think the classloading in that is a symptom
> > > of
> > > too many cooks all changing things in different directions. We need a
> > > consistent vision of where we want things to go and - while we need not
> > > get
> > > there in one go - the path presented for others to see.
> >
> > There were two classloading changes in 3.5.1, namely extensions=true
> > plugins now have project realm as TCCL and all realms now use
> > application classloader as the parent. Apart from lacking documentation,
> > what practical problems have been caused by these two changes?
> >
> > >
> > > Things I think we should consider:
> > >
> > > 1. Do we want to formally deprecate Build Extensions and the
> > > /project/build/extensions element (start logging warnings, etc)?
> > > 2. Do we want to formally deprecate plugins as extensions and start
> > > logging
> > > warnings for
> > >
> > /project/build/(pluginManagement|.)/plugins/plugin/extensions[text()==true]
> >
> > I'd keep them both, and maybe fix/remove 

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Anders Hammar]

To add to the topic I think that if we fix/change the class loading, we
shouldn't do that in a bug fix release. I'd rather see a 3.6.0 with it
thought through, fixed and documented (could be in ITs). The arguing being
that a bug fix release shouldn't cause new issues in plugins etc.

/Anders

On Sun, Sep 24, 2017 at 8:28 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I wonder should we do a hangout to decide what you do?
>
> What times on Monday work best?
>
> I can maybe do 8:30-9:30pm Irish time
>
> https://www.timeanddate.com/worldclock/meetingdetails.
> html?year=2017=9=25=19=30=0=78=37=179
>
> But we’d need to decide who we need and an actual agenda.
>
> If Monday is too soon I can see if I have a window later this week
>
> On Sun 24 Sep 2017 at 18:58, Igor Fedorenko  wrote:
>
> > See my answers/comments inline
> >
> >
> > On Sun, Sep 24, 2017, at 12:07 PM, Stephen Connolly wrote:
> > > https://maven.apache.org/guides/mini/guide-maven-classloading.html
> says:
> > >
> > > > When a build plugin is executed, the thread's context classloader is
> > set
> > > to the plugin classloader.
> > >
> > > So we'll need to fix something somewhere...
> > >
> > >
> > https://svn.apache.org/repos/infra/websites/production/
> maven/content/reference/maven-classloading.html
> > > is unaccessible from the website due to a rewrite rule...
> > >
> > > Things that seem to be missing:
> > >
> > > * What is the desired classloading for a plugin that is marked as an
> > > extension? Can a plugin have a META-INF/maven/extension.xml to allow
> > > exporting classes and artifacts when used as an extension? How should
> the
> > > classloading look for such a strange beast.
> >
> > To me, the key requirement is that @Singleton components and class
> > static members are singletons when injected in Maven core or in @Mojos.
> > This implies that there should be single classloader representing an
> > extensions plugins (MNG-5742).
> >
> > META-INF/maven/extension.xml declares what packages of the extension
> > plugin are visible to other (non extension) plugins.
> > META-INF/maven/extension.xml does not affect classloading of the
> > extension plugin nor it affects the "shape" of other classloaders.
> >
> > > * How does one access the plugin classloader if we want TCCL to be
> other
> > > than that, is it a Dependency Injection or something else?
> >
> > this.getClass().getClassLoader() is the most direct way to access plugin
> > classloader. Why do you think we need anything more elaborate?
> >
> >
> > > * What differentiates a Core extension from a Build extension (is it
> that
> > > a
> > > build extension lacks a META-INF/maven/extension.xml and was only
> > > declared
> > > in the pom.xml, while a core extension either has a
> > > META-INF/maven/extension.xml - if declared in the pom - or is an
> > > extension
> > > declared in .mvn/extensions.xml)
> >
> > Core extensions are loaded *before* build starts, so they can contribute
> > AbstractMavenLifecycleParticipant#afterSessionStart, for example. They
> > can also export packages visible to all build plugins, including
> > extensions=true. On the flip side, each core extension is effectively
> > singleton, you can't have two different versions of the same Core
> > extension. Core extensions also have direct access to Maven core classes
> > and can do more interesting things there (for better or worse).
> >
> > Build extensions are part of the project build and as such are limited
> > what components they can contribute to the Core and what core classes
> > they have access to.
> >
> > I tried to capture this in the diagram I drew for
> > http://takari.io/book/91-maven-classloading.html.
> >
> > > At this point in time I think we are nearing the point where I may have
> > > to
> > > declare 3.5.1 abandoned as I think the classloading in that is a
> symptom
> > > of
> > > too many cooks all changing things in different directions. We need a
> > > consistent vision of where we want things to go and - while we need not
> > > get
> > > there in one go - the path presented for others to see.
> >
> > There were two classloading changes in 3.5.1, namely extensions=true
> > plugins now have project realm as TCCL and all realms now use
> > application classloader as the parent. Apart from lacking documentation,
> > what practical problems have been caused by these two changes?
> >
> > >
> > > Things I think we should consider:
> > >
> > > 1. Do we want to formally deprecate Build Extensions and the
> > > /project/build/extensions element (start logging warnings, etc)?
> > > 2. Do we want to formally deprecate plugins as extensions and start
> > > logging
> > > warnings for
> > >
> > /project/build/(pluginManagement|.)/plugins/plugin/extensions[text()==
> true]
> >
> > I'd keep them both, and maybe fix/remove maven2-compat codepath. If I
> > had to choose between the two, however, I'd choose  with
> > extensions=true. Think of a custom packaging 

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Stephen Connolly]

I wonder should we do a hangout to decide what you do?

What times on Monday work best?

I can maybe do 8:30-9:30pm Irish time

https://www.timeanddate.com/worldclock/meetingdetails.html?year=2017=9=25=19=30=0=78=37=179

But we’d need to decide who we need and an actual agenda.

If Monday is too soon I can see if I have a window later this week

On Sun 24 Sep 2017 at 18:58, Igor Fedorenko  wrote:

> See my answers/comments inline
>
>
> On Sun, Sep 24, 2017, at 12:07 PM, Stephen Connolly wrote:
> > https://maven.apache.org/guides/mini/guide-maven-classloading.html says:
> >
> > > When a build plugin is executed, the thread's context classloader is
> set
> > to the plugin classloader.
> >
> > So we'll need to fix something somewhere...
> >
> >
> https://svn.apache.org/repos/infra/websites/production/maven/content/reference/maven-classloading.html
> > is unaccessible from the website due to a rewrite rule...
> >
> > Things that seem to be missing:
> >
> > * What is the desired classloading for a plugin that is marked as an
> > extension? Can a plugin have a META-INF/maven/extension.xml to allow
> > exporting classes and artifacts when used as an extension? How should the
> > classloading look for such a strange beast.
>
> To me, the key requirement is that @Singleton components and class
> static members are singletons when injected in Maven core or in @Mojos.
> This implies that there should be single classloader representing an
> extensions plugins (MNG-5742).
>
> META-INF/maven/extension.xml declares what packages of the extension
> plugin are visible to other (non extension) plugins.
> META-INF/maven/extension.xml does not affect classloading of the
> extension plugin nor it affects the "shape" of other classloaders.
>
> > * How does one access the plugin classloader if we want TCCL to be other
> > than that, is it a Dependency Injection or something else?
>
> this.getClass().getClassLoader() is the most direct way to access plugin
> classloader. Why do you think we need anything more elaborate?
>
>
> > * What differentiates a Core extension from a Build extension (is it that
> > a
> > build extension lacks a META-INF/maven/extension.xml and was only
> > declared
> > in the pom.xml, while a core extension either has a
> > META-INF/maven/extension.xml - if declared in the pom - or is an
> > extension
> > declared in .mvn/extensions.xml)
>
> Core extensions are loaded *before* build starts, so they can contribute
> AbstractMavenLifecycleParticipant#afterSessionStart, for example. They
> can also export packages visible to all build plugins, including
> extensions=true. On the flip side, each core extension is effectively
> singleton, you can't have two different versions of the same Core
> extension. Core extensions also have direct access to Maven core classes
> and can do more interesting things there (for better or worse).
>
> Build extensions are part of the project build and as such are limited
> what components they can contribute to the Core and what core classes
> they have access to.
>
> I tried to capture this in the diagram I drew for
> http://takari.io/book/91-maven-classloading.html.
>
> > At this point in time I think we are nearing the point where I may have
> > to
> > declare 3.5.1 abandoned as I think the classloading in that is a symptom
> > of
> > too many cooks all changing things in different directions. We need a
> > consistent vision of where we want things to go and - while we need not
> > get
> > there in one go - the path presented for others to see.
>
> There were two classloading changes in 3.5.1, namely extensions=true
> plugins now have project realm as TCCL and all realms now use
> application classloader as the parent. Apart from lacking documentation,
> what practical problems have been caused by these two changes?
>
> >
> > Things I think we should consider:
> >
> > 1. Do we want to formally deprecate Build Extensions and the
> > /project/build/extensions element (start logging warnings, etc)?
> > 2. Do we want to formally deprecate plugins as extensions and start
> > logging
> > warnings for
> >
> /project/build/(pluginManagement|.)/plugins/plugin/extensions[text()==true]
>
> I'd keep them both, and maybe fix/remove maven2-compat codepath. If I
> had to choose between the two, however, I'd choose  with
> extensions=true. Think of a custom packaging type with mojos the user
> wants to configure in pom.xml, it'd be more tedious to configure if I
> had to add build/extension and build/plugin.
>
> > 3. What is the difference in classloading for a /project/build/extensions
> > which has a META-INF/maven/extension.xml and one that doesn't?
>
> I think extensions with META-INF/maven/extension.xml should not go
> through maven2-compat codepath. In other words, we need to change the
> current behaviour.
>
> Extensions without META-INF/maven/extension.xml... I am not sure.
> Probably safer to keep the current maven2-compat behaviour.
>
> > I'm keeping the 3.5.1 

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Igor Fedorenko]

See my answers/comments inline


On Sun, Sep 24, 2017, at 12:07 PM, Stephen Connolly wrote:
> https://maven.apache.org/guides/mini/guide-maven-classloading.html says:
> 
> > When a build plugin is executed, the thread's context classloader is set
> to the plugin classloader.
> 
> So we'll need to fix something somewhere...
> 
> https://svn.apache.org/repos/infra/websites/production/maven/content/reference/maven-classloading.html
> is unaccessible from the website due to a rewrite rule...
> 
> Things that seem to be missing:
> 
> * What is the desired classloading for a plugin that is marked as an
> extension? Can a plugin have a META-INF/maven/extension.xml to allow
> exporting classes and artifacts when used as an extension? How should the
> classloading look for such a strange beast.

To me, the key requirement is that @Singleton components and class
static members are singletons when injected in Maven core or in @Mojos.
This implies that there should be single classloader representing an
extensions plugins (MNG-5742).

META-INF/maven/extension.xml declares what packages of the extension
plugin are visible to other (non extension) plugins.
META-INF/maven/extension.xml does not affect classloading of the
extension plugin nor it affects the "shape" of other classloaders.

> * How does one access the plugin classloader if we want TCCL to be other
> than that, is it a Dependency Injection or something else?

this.getClass().getClassLoader() is the most direct way to access plugin
classloader. Why do you think we need anything more elaborate?


> * What differentiates a Core extension from a Build extension (is it that
> a
> build extension lacks a META-INF/maven/extension.xml and was only
> declared
> in the pom.xml, while a core extension either has a
> META-INF/maven/extension.xml - if declared in the pom - or is an
> extension
> declared in .mvn/extensions.xml)

Core extensions are loaded *before* build starts, so they can contribute
AbstractMavenLifecycleParticipant#afterSessionStart, for example. They
can also export packages visible to all build plugins, including
extensions=true. On the flip side, each core extension is effectively
singleton, you can't have two different versions of the same Core
extension. Core extensions also have direct access to Maven core classes
and can do more interesting things there (for better or worse).

Build extensions are part of the project build and as such are limited
what components they can contribute to the Core and what core classes
they have access to.

I tried to capture this in the diagram I drew for
http://takari.io/book/91-maven-classloading.html.

> At this point in time I think we are nearing the point where I may have
> to
> declare 3.5.1 abandoned as I think the classloading in that is a symptom
> of
> too many cooks all changing things in different directions. We need a
> consistent vision of where we want things to go and - while we need not
> get
> there in one go - the path presented for others to see.

There were two classloading changes in 3.5.1, namely extensions=true
plugins now have project realm as TCCL and all realms now use
application classloader as the parent. Apart from lacking documentation,
what practical problems have been caused by these two changes?

> 
> Things I think we should consider:
> 
> 1. Do we want to formally deprecate Build Extensions and the
> /project/build/extensions element (start logging warnings, etc)?
> 2. Do we want to formally deprecate plugins as extensions and start
> logging
> warnings for
> /project/build/(pluginManagement|.)/plugins/plugin/extensions[text()==true]

I'd keep them both, and maybe fix/remove maven2-compat codepath. If I
had to choose between the two, however, I'd choose  with
extensions=true. Think of a custom packaging type with mojos the user
wants to configure in pom.xml, it'd be more tedious to configure if I
had to add build/extension and build/plugin.

> 3. What is the difference in classloading for a /project/build/extensions
> which has a META-INF/maven/extension.xml and one that doesn't?

I think extensions with META-INF/maven/extension.xml should not go
through maven2-compat codepath. In other words, we need to change the
current behaviour.

Extensions without META-INF/maven/extension.xml... I am not sure.
Probably safer to keep the current maven2-compat behaviour.

> I'm keeping the 3.5.1 release in staging until we get a clear vision for
> how we want to have classloading so that I can assess whether the 3.5.1
> actuality is only moving nearer to the vision (ok to release) or has
> moved
> nearer in some ways but further in others (not ok to release)
> 


-- 
Regards,
Igor



> On 20 September 2017 at 12:44, Igor Fedorenko 
> wrote:
> 
> > Real-world scm or wagon  won't trigger maven2-compat code
> > path [1]. To avoid that obscure code path we can either make the test
> > more elaborate (i.e. add dependencies to extjar1/extjar2) or we can use
> > extensions . 

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Robert Scholte]

On Sun, 24 Sep 2017 19:36:15 +0200, Stephen Connolly  
 wrote:



On Sun 24 Sep 2017 at 17:44, Robert Scholte  wrote:


Are these questions we can/should answer within a couple of days?
I'm not aware of somebody hitting the regression as caused by MNG-5742
other than Igor.
However, we've seen a couple of changed behavior clearly caused by
MNG-6209 (not answering if this intended or not)

We could also make the decision to leave MNG-6209 out, do a new release
and complete our investigation directly afterwards.
This change is way too tricky to do additional changes under pressure.



If we drop 3.5.1 i’d be in favour of reverting both MNG-6209 and MNG-6275
(the TCCL one) as I have found documentation stating that TCCL is the
plugin classloader, which makes me wary of changing that in a patch  
release

(but I can be convinced otherwise)



Sure, I can live with that.





thanks,
Robert


On Sun, 24 Sep 2017 18:07:39 +0200, Stephen Connolly
 wrote:

> https://maven.apache.org/guides/mini/guide-maven-classloading.html  
says:

>
>> When a build plugin is executed, the thread's context classloader is  
set

> to the plugin classloader.
>
> So we'll need to fix something somewhere...
>
>
https://svn.apache.org/repos/infra/websites/production/maven/content/reference/maven-classloading.html
> is unaccessible from the website due to a rewrite rule...
>
> Things that seem to be missing:
>
> * What is the desired classloading for a plugin that is marked as an
> extension? Can a plugin have a META-INF/maven/extension.xml to allow
> exporting classes and artifacts when used as an extension? How should  
the

> classloading look for such a strange beast.
>
> * How does one access the plugin classloader if we want TCCL to be  
other

> than that, is it a Dependency Injection or something else?
>
> * What differentiates a Core extension from a Build extension (is it
> that a
> build extension lacks a META-INF/maven/extension.xml and was only
> declared
> in the pom.xml, while a core extension either has a
> META-INF/maven/extension.xml - if declared in the pom - or is an
> extension
> declared in .mvn/extensions.xml)
>
> At this point in time I think we are nearing the point where I may  
have

> to
> declare 3.5.1 abandoned as I think the classloading in that is a  
symptom

> of
> too many cooks all changing things in different directions. We need a
> consistent vision of where we want things to go and - while we need  
not

> get
> there in one go - the path presented for others to see.
>
> Things I think we should consider:
>
> 1. Do we want to formally deprecate Build Extensions and the
> /project/build/extensions element (start logging warnings, etc)?
> 2. Do we want to formally deprecate plugins as extensions and start
> logging
> warnings for
>
/project/build/(pluginManagement|.)/plugins/plugin/extensions[text()==true]
> 3. What is the difference in classloading for a  
/project/build/extensions

> which has a META-INF/maven/extension.xml and one that doesn't?
>
> I'm keeping the 3.5.1 release in staging until we get a clear vision  
for
> how we want to have classloading so that I can assess whether the  
3.5.1

> actuality is only moving nearer to the vision (ok to release) or has
> moved
> nearer in some ways but further in others (not ok to release)
>
> On 20 September 2017 at 12:44, Igor Fedorenko 
> wrote:
>
>> Real-world scm or wagon  won't trigger maven2-compat code
>> path [1]. To avoid that obscure code path we can either make the test
>> more elaborate (i.e. add dependencies to extjar1/extjar2) or we can  
use

>> extensions . Either way I don't think we should spend time on
>> the code path unlikely to be used in real life.
>>
>> [1]
>> https://github.com/apache/maven/blob/maven-3.5.1/maven-
>>
core/src/main/java/org/apache/maven/project/DefaultProjectBuildingHelper.
>> java#L210-L219
>>
>> --
>> Regards,
>> Igor
>>
>> On Wed, Sep 20, 2017, at 03:29 AM, Robert Scholte wrote:
>> > On Wed, 20 Sep 2017 09:12:47 +0200, Stephen Connolly
>> >  wrote:
>> >
>> > > On Wed 20 Sep 2017 at 01:29, Igor Fedorenko 
>> wrote:
>> > >
>> > >> In that case, can I suggest couple of changes to the test  
project

>> > >>
>> > >> * I thinks it makes more sense to configure extjar1 and extjar2  
as

>> > >> extensions  elements in probleN pom.xml files. First,
>> there is
>> > >> no meaningful order between  and  elements.
>> More
>> > >> importantly, though, simple  are treated in special
>> > >> maven2-compat mode and are not representative of likely  
real-world

>> > >> extensions.
>> > >
>> >
>> > Not sure I agree with this. I think there are jars worth sharing
>> across
>> > multiple plugins, but where making the plugin an extension is a bit
>> > weird.
>> > I'm thinking of scm and wagon in this case.
>> >
>> > >
>> > > That sounds like we need 

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Stephen Connolly]

On Sun 24 Sep 2017 at 17:44, Robert Scholte  wrote:

> Are these questions we can/should answer within a couple of days?
> I'm not aware of somebody hitting the regression as caused by MNG-5742
> other than Igor.
> However, we've seen a couple of changed behavior clearly caused by
> MNG-6209 (not answering if this intended or not)
>
> We could also make the decision to leave MNG-6209 out, do a new release
> and complete our investigation directly afterwards.
> This change is way too tricky to do additional changes under pressure.


If we drop 3.5.1 i’d be in favour of reverting both MNG-6209 and MNG-6275
(the TCCL one) as I have found documentation stating that TCCL is the
plugin classloader, which makes me wary of changing that in a patch release
(but I can be convinced otherwise)


>
> thanks,
> Robert
>
>
> On Sun, 24 Sep 2017 18:07:39 +0200, Stephen Connolly
>  wrote:
>
> > https://maven.apache.org/guides/mini/guide-maven-classloading.html says:
> >
> >> When a build plugin is executed, the thread's context classloader is set
> > to the plugin classloader.
> >
> > So we'll need to fix something somewhere...
> >
> >
> https://svn.apache.org/repos/infra/websites/production/maven/content/reference/maven-classloading.html
> > is unaccessible from the website due to a rewrite rule...
> >
> > Things that seem to be missing:
> >
> > * What is the desired classloading for a plugin that is marked as an
> > extension? Can a plugin have a META-INF/maven/extension.xml to allow
> > exporting classes and artifacts when used as an extension? How should the
> > classloading look for such a strange beast.
> >
> > * How does one access the plugin classloader if we want TCCL to be other
> > than that, is it a Dependency Injection or something else?
> >
> > * What differentiates a Core extension from a Build extension (is it
> > that a
> > build extension lacks a META-INF/maven/extension.xml and was only
> > declared
> > in the pom.xml, while a core extension either has a
> > META-INF/maven/extension.xml - if declared in the pom - or is an
> > extension
> > declared in .mvn/extensions.xml)
> >
> > At this point in time I think we are nearing the point where I may have
> > to
> > declare 3.5.1 abandoned as I think the classloading in that is a symptom
> > of
> > too many cooks all changing things in different directions. We need a
> > consistent vision of where we want things to go and - while we need not
> > get
> > there in one go - the path presented for others to see.
> >
> > Things I think we should consider:
> >
> > 1. Do we want to formally deprecate Build Extensions and the
> > /project/build/extensions element (start logging warnings, etc)?
> > 2. Do we want to formally deprecate plugins as extensions and start
> > logging
> > warnings for
> >
> /project/build/(pluginManagement|.)/plugins/plugin/extensions[text()==true]
> > 3. What is the difference in classloading for a /project/build/extensions
> > which has a META-INF/maven/extension.xml and one that doesn't?
> >
> > I'm keeping the 3.5.1 release in staging until we get a clear vision for
> > how we want to have classloading so that I can assess whether the 3.5.1
> > actuality is only moving nearer to the vision (ok to release) or has
> > moved
> > nearer in some ways but further in others (not ok to release)
> >
> > On 20 September 2017 at 12:44, Igor Fedorenko 
> > wrote:
> >
> >> Real-world scm or wagon  won't trigger maven2-compat code
> >> path [1]. To avoid that obscure code path we can either make the test
> >> more elaborate (i.e. add dependencies to extjar1/extjar2) or we can use
> >> extensions . Either way I don't think we should spend time on
> >> the code path unlikely to be used in real life.
> >>
> >> [1]
> >> https://github.com/apache/maven/blob/maven-3.5.1/maven-
> >>
> core/src/main/java/org/apache/maven/project/DefaultProjectBuildingHelper.
> >> java#L210-L219
> >>
> >> --
> >> Regards,
> >> Igor
> >>
> >> On Wed, Sep 20, 2017, at 03:29 AM, Robert Scholte wrote:
> >> > On Wed, 20 Sep 2017 09:12:47 +0200, Stephen Connolly
> >> >  wrote:
> >> >
> >> > > On Wed 20 Sep 2017 at 01:29, Igor Fedorenko 
> >> wrote:
> >> > >
> >> > >> In that case, can I suggest couple of changes to the test project
> >> > >>
> >> > >> * I thinks it makes more sense to configure extjar1 and extjar2 as
> >> > >> extensions  elements in probleN pom.xml files. First,
> >> there is
> >> > >> no meaningful order between  and  elements.
> >> More
> >> > >> importantly, though, simple  are treated in special
> >> > >> maven2-compat mode and are not representative of likely real-world
> >> > >> extensions.
> >> > >
> >> >
> >> > Not sure I agree with this. I think there are jars worth sharing
> >> across
> >> > multiple plugins, but where making the plugin an extension is a bit
> >> > weird.
> >> > I'm thinking of scm and wagon in this case.
> >> 

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Robert Scholte]

Are these questions we can/should answer within a couple of days?
I'm not aware of somebody hitting the regression as caused by MNG-5742  
other than Igor.
However, we've seen a couple of changed behavior clearly caused by  
MNG-6209 (not answering if this intended or not)


We could also make the decision to leave MNG-6209 out, do a new release  
and complete our investigation directly afterwards.

This change is way too tricky to do additional changes under pressure.

thanks,
Robert


On Sun, 24 Sep 2017 18:07:39 +0200, Stephen Connolly  
 wrote:



https://maven.apache.org/guides/mini/guide-maven-classloading.html says:


When a build plugin is executed, the thread's context classloader is set

to the plugin classloader.

So we'll need to fix something somewhere...

https://svn.apache.org/repos/infra/websites/production/maven/content/reference/maven-classloading.html
is unaccessible from the website due to a rewrite rule...

Things that seem to be missing:

* What is the desired classloading for a plugin that is marked as an
extension? Can a plugin have a META-INF/maven/extension.xml to allow
exporting classes and artifacts when used as an extension? How should the
classloading look for such a strange beast.

* How does one access the plugin classloader if we want TCCL to be other
than that, is it a Dependency Injection or something else?

* What differentiates a Core extension from a Build extension (is it  
that a
build extension lacks a META-INF/maven/extension.xml and was only  
declared

in the pom.xml, while a core extension either has a
META-INF/maven/extension.xml - if declared in the pom - or is an  
extension

declared in .mvn/extensions.xml)

At this point in time I think we are nearing the point where I may have  
to
declare 3.5.1 abandoned as I think the classloading in that is a symptom  
of

too many cooks all changing things in different directions. We need a
consistent vision of where we want things to go and - while we need not  
get

there in one go - the path presented for others to see.

Things I think we should consider:

1. Do we want to formally deprecate Build Extensions and the
/project/build/extensions element (start logging warnings, etc)?
2. Do we want to formally deprecate plugins as extensions and start  
logging

warnings for
/project/build/(pluginManagement|.)/plugins/plugin/extensions[text()==true]
3. What is the difference in classloading for a /project/build/extensions
which has a META-INF/maven/extension.xml and one that doesn't?

I'm keeping the 3.5.1 release in staging until we get a clear vision for
how we want to have classloading so that I can assess whether the 3.5.1
actuality is only moving nearer to the vision (ok to release) or has  
moved

nearer in some ways but further in others (not ok to release)

On 20 September 2017 at 12:44, Igor Fedorenko   
wrote:



Real-world scm or wagon  won't trigger maven2-compat code
path [1]. To avoid that obscure code path we can either make the test
more elaborate (i.e. add dependencies to extjar1/extjar2) or we can use
extensions . Either way I don't think we should spend time on
the code path unlikely to be used in real life.

[1]
https://github.com/apache/maven/blob/maven-3.5.1/maven-
core/src/main/java/org/apache/maven/project/DefaultProjectBuildingHelper.
java#L210-L219

--
Regards,
Igor

On Wed, Sep 20, 2017, at 03:29 AM, Robert Scholte wrote:
> On Wed, 20 Sep 2017 09:12:47 +0200, Stephen Connolly
>  wrote:
>
> > On Wed 20 Sep 2017 at 01:29, Igor Fedorenko 
wrote:
> >
> >> In that case, can I suggest couple of changes to the test project
> >>
> >> * I thinks it makes more sense to configure extjar1 and extjar2 as
> >> extensions  elements in probleN pom.xml files. First,  
there is
> >> no meaningful order between  and  elements.  
More

> >> importantly, though, simple  are treated in special
> >> maven2-compat mode and are not representative of likely real-world
> >> extensions.
> >
>
> Not sure I agree with this. I think there are jars worth sharing  
across

> multiple plugins, but where making the plugin an extension is a bit
> weird.
> I'm thinking of scm and wagon in this case.
>
> >
> > That sounds like we need documentation updated then. None of that is
> > obvious to me.
> >
> >
> >>
> >> * I think we should introduce META-INF/maven/extension.xml to the  
test

> >> extensions. This metadata what introduced to configure classpath
> >> visibility, so lets use it.
> >
> >
> > Again, not obvious to me, if that file allows control of classpath
> > visibility then it may be that the only issue *with* 3.5.1 is the  
lack

of
> > documentation... now previous versions would have been adding  
breaking

> > changes from my PoV but that is the past and should not affect the
3.5.1
> > release.
> >
> > PRs for the probe project welcome. I am happy to try and write docs
once
> > I
> > have an understanding of 

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Stephen Connolly]

https://maven.apache.org/guides/mini/guide-maven-classloading.html says:

> When a build plugin is executed, the thread's context classloader is set
to the plugin classloader.

So we'll need to fix something somewhere...

https://svn.apache.org/repos/infra/websites/production/maven/content/reference/maven-classloading.html
is unaccessible from the website due to a rewrite rule...

Things that seem to be missing:

* What is the desired classloading for a plugin that is marked as an
extension? Can a plugin have a META-INF/maven/extension.xml to allow
exporting classes and artifacts when used as an extension? How should the
classloading look for such a strange beast.

* How does one access the plugin classloader if we want TCCL to be other
than that, is it a Dependency Injection or something else?

* What differentiates a Core extension from a Build extension (is it that a
build extension lacks a META-INF/maven/extension.xml and was only declared
in the pom.xml, while a core extension either has a
META-INF/maven/extension.xml - if declared in the pom - or is an extension
declared in .mvn/extensions.xml)

At this point in time I think we are nearing the point where I may have to
declare 3.5.1 abandoned as I think the classloading in that is a symptom of
too many cooks all changing things in different directions. We need a
consistent vision of where we want things to go and - while we need not get
there in one go - the path presented for others to see.

Things I think we should consider:

1. Do we want to formally deprecate Build Extensions and the
/project/build/extensions element (start logging warnings, etc)?
2. Do we want to formally deprecate plugins as extensions and start logging
warnings for
/project/build/(pluginManagement|.)/plugins/plugin/extensions[text()==true]
3. What is the difference in classloading for a /project/build/extensions
which has a META-INF/maven/extension.xml and one that doesn't?

I'm keeping the 3.5.1 release in staging until we get a clear vision for
how we want to have classloading so that I can assess whether the 3.5.1
actuality is only moving nearer to the vision (ok to release) or has moved
nearer in some ways but further in others (not ok to release)

On 20 September 2017 at 12:44, Igor Fedorenko  wrote:

> Real-world scm or wagon  won't trigger maven2-compat code
> path [1]. To avoid that obscure code path we can either make the test
> more elaborate (i.e. add dependencies to extjar1/extjar2) or we can use
> extensions . Either way I don't think we should spend time on
> the code path unlikely to be used in real life.
>
> [1]
> https://github.com/apache/maven/blob/maven-3.5.1/maven-
> core/src/main/java/org/apache/maven/project/DefaultProjectBuildingHelper.
> java#L210-L219
>
> --
> Regards,
> Igor
>
> On Wed, Sep 20, 2017, at 03:29 AM, Robert Scholte wrote:
> > On Wed, 20 Sep 2017 09:12:47 +0200, Stephen Connolly
> >  wrote:
> >
> > > On Wed 20 Sep 2017 at 01:29, Igor Fedorenko 
> wrote:
> > >
> > >> In that case, can I suggest couple of changes to the test project
> > >>
> > >> * I thinks it makes more sense to configure extjar1 and extjar2 as
> > >> extensions  elements in probleN pom.xml files. First, there is
> > >> no meaningful order between  and  elements. More
> > >> importantly, though, simple  are treated in special
> > >> maven2-compat mode and are not representative of likely real-world
> > >> extensions.
> > >
> >
> > Not sure I agree with this. I think there are jars worth sharing across
> > multiple plugins, but where making the plugin an extension is a bit
> > weird.
> > I'm thinking of scm and wagon in this case.
> >
> > >
> > > That sounds like we need documentation updated then. None of that is
> > > obvious to me.
> > >
> > >
> > >>
> > >> * I think we should introduce META-INF/maven/extension.xml to the test
> > >> extensions. This metadata what introduced to configure classpath
> > >> visibility, so lets use it.
> > >
> > >
> > > Again, not obvious to me, if that file allows control of classpath
> > > visibility then it may be that the only issue *with* 3.5.1 is the lack
> of
> > > documentation... now previous versions would have been adding breaking
> > > changes from my PoV but that is the past and should not affect the
> 3.5.1
> > > release.
> > >
> > > PRs for the probe project welcome. I am happy to try and write docs
> once
> > > I
> > > have an understanding of what the expected behaviours are
> > >
> > >
> > >>
> > >> --
> > >> Regards,
> > >> Igor
> > >>
> > >> On Tue, Sep 19, 2017, at 05:12 PM, Stephen Connolly wrote:
> > >> > Yes, the expectations are key. Depending on what they are we may
> > >> either
> > >> > drop 3.5.1 or go ahead as it depends on whether this is more correct
> > >> than
> > >> > 3.5.0 or swapping one fix for a bug
> > >> >
> > >> > On Tue 19 Sep 2017 at 21:39, Igor Fedorenko 
> > >> wrote:
> > >> >
> > >> > > Just to 

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Igor Fedorenko]

Real-world scm or wagon  won't trigger maven2-compat code
path [1]. To avoid that obscure code path we can either make the test
more elaborate (i.e. add dependencies to extjar1/extjar2) or we can use
extensions . Either way I don't think we should spend time on
the code path unlikely to be used in real life.

[1]
https://github.com/apache/maven/blob/maven-3.5.1/maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuildingHelper.java#L210-L219

-- 
Regards,
Igor

On Wed, Sep 20, 2017, at 03:29 AM, Robert Scholte wrote:
> On Wed, 20 Sep 2017 09:12:47 +0200, Stephen Connolly  
>  wrote:
> 
> > On Wed 20 Sep 2017 at 01:29, Igor Fedorenko  wrote:
> >
> >> In that case, can I suggest couple of changes to the test project
> >>
> >> * I thinks it makes more sense to configure extjar1 and extjar2 as
> >> extensions  elements in probleN pom.xml files. First, there is
> >> no meaningful order between  and  elements. More
> >> importantly, though, simple  are treated in special
> >> maven2-compat mode and are not representative of likely real-world
> >> extensions.
> >
> 
> Not sure I agree with this. I think there are jars worth sharing across  
> multiple plugins, but where making the plugin an extension is a bit
> weird.
> I'm thinking of scm and wagon in this case.
> 
> >
> > That sounds like we need documentation updated then. None of that is
> > obvious to me.
> >
> >
> >>
> >> * I think we should introduce META-INF/maven/extension.xml to the test
> >> extensions. This metadata what introduced to configure classpath
> >> visibility, so lets use it.
> >
> >
> > Again, not obvious to me, if that file allows control of classpath
> > visibility then it may be that the only issue *with* 3.5.1 is the lack of
> > documentation... now previous versions would have been adding breaking
> > changes from my PoV but that is the past and should not affect the 3.5.1
> > release.
> >
> > PRs for the probe project welcome. I am happy to try and write docs once  
> > I
> > have an understanding of what the expected behaviours are
> >
> >
> >>
> >> --
> >> Regards,
> >> Igor
> >>
> >> On Tue, Sep 19, 2017, at 05:12 PM, Stephen Connolly wrote:
> >> > Yes, the expectations are key. Depending on what they are we may  
> >> either
> >> > drop 3.5.1 or go ahead as it depends on whether this is more correct  
> >> than
> >> > 3.5.0 or swapping one fix for a bug
> >> >
> >> > On Tue 19 Sep 2017 at 21:39, Igor Fedorenko   
> >> wrote:
> >> >
> >> > > Just to confirm I understand what we are trying to establish here.  
> >> We
> >> > > want to decide the expected/desired component injection behaviour  
> >> and
> >> > > classpath visibility in the absence of package and artifact export
> >> > > configuration (i.e. META-INF/maven/extension.xml file). Did I get  
> >> this
> >> > > right?
> >> > >
> >> > > --
> >> > > Regards,
> >> > > Igor
> >> > >
> >> > > On Tue, Sep 19, 2017, at 03:52 PM, Robert Scholte wrote:
> >> > > > Let's do it like this:
> >> > > >
> >> > >
> >> https://cwiki.apache.org/confluence/download/attachments/2329841/classrealms.pdf?api=v2
> >> > > >
> >> > > > Robert
> >> > > >
> >> > > > On Tue, 19 Sep 2017 21:08:39 +0200, Stephen Connolly
> >> > > >  wrote:
> >> > > >
> >> > > > > I think you will need a link to the PDF as attachments are  
> >> stripped
> >> > > from
> >> > > > > the ML
> >> > > > >
> >> > > > > On Tue 19 Sep 2017 at 19:57, Robert Scholte  
> >> 
> >> > > wrote:
> >> > > > >
> >> > > > >> Attached a single page overview.
> >> > > > >>
> >> > > > >> Per block you'll see in the upper left corner the executed  
> >> plugin
> >> > > > >> The left column contains the extensions and plugin in orderas
> >> > > specified
> >> > > > >> in
> >> > > > >> the pom.xml
> >> > > > >> In every classloadercolumn you'll see numbers which represent  
> >> the
> >> > > order.
> >> > > > >>
> >> > > > >> I hope I didn't make any mistakes.
> >> > > > >> Tomorrow I have enough time to see if I understand what's
> >> happening
> >> > > > >> here.
> >> > > > >>
> >> > > > >> I will come back with my conclusions.
> >> > > > >>
> >> > > > >> Robert
> >> > > > >>
> >> > > > >> On Tue, 19 Sep 2017 06:55:08 +0200, Igor Fedorenko <
> >> > > i...@ifedorenko.com>
> >> > > > >> wrote:
> >> > > > >>
> >> > > > >> > TL;DR your test project exposed two existing bugs, one  
> >> change in
> >> > > > >> > behaviour and one quirk I can't explain
> >> > > > >> >
> >> > > > >> > * Build `` are loaded by two classloaders, which  
> >> is
> >> a
> >> > > bug
> >> > > > >> in
> >> > > > >> > DefaultProjectBuildingHelper#createProjectRealm and explains
> >> why you
> >> > > > >> see
> >> > > > >> > extjar1/extjar2 in the output
> >> > > > >> > * ClassRealm does not allow same foreign-import from multiple
> >> > > > >> > classloaders, which is a bug and explains why it is not
> >> possible to
> >> > > > >> 

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Igor Fedorenko]

Just to be clear, while I agree the documentation is lacking, neither
special-casing "simple"  nor META-INF/maven/extension.xml 
is new behaviour in 3.5.1, both existed since 3.0 alphas iirc. Also,
Hervé did add some extension.xml documentation couple of years ago.

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

-- 
Regards,
Igor

On Wed, Sep 20, 2017, at 03:12 AM, Stephen Connolly wrote:
> On Wed 20 Sep 2017 at 01:29, Igor Fedorenko  wrote:
> 
> > In that case, can I suggest couple of changes to the test project
> >
> > * I thinks it makes more sense to configure extjar1 and extjar2 as
> > extensions  elements in probleN pom.xml files. First, there is
> > no meaningful order between  and  elements. More
> > importantly, though, simple  are treated in special
> > maven2-compat mode and are not representative of likely real-world
> > extensions.
> 
> 
> That sounds like we need documentation updated then. None of that is
> obvious to me.
> 
> 
> >
> > * I think we should introduce META-INF/maven/extension.xml to the test
> > extensions. This metadata what introduced to configure classpath
> > visibility, so lets use it.
> 
> 
> Again, not obvious to me, if that file allows control of classpath
> visibility then it may be that the only issue *with* 3.5.1 is the lack of
> documentation... now previous versions would have been adding breaking
> changes from my PoV but that is the past and should not affect the 3.5.1
> release.
> 
> PRs for the probe project welcome. I am happy to try and write docs once
> I
> have an understanding of what the expected behaviours are
> 
> 
> >
> > --
> > Regards,
> > Igor
> >
> > On Tue, Sep 19, 2017, at 05:12 PM, Stephen Connolly wrote:
> > > Yes, the expectations are key. Depending on what they are we may either
> > > drop 3.5.1 or go ahead as it depends on whether this is more correct than
> > > 3.5.0 or swapping one fix for a bug
> > >
> > > On Tue 19 Sep 2017 at 21:39, Igor Fedorenko  wrote:
> > >
> > > > Just to confirm I understand what we are trying to establish here. We
> > > > want to decide the expected/desired component injection behaviour and
> > > > classpath visibility in the absence of package and artifact export
> > > > configuration (i.e. META-INF/maven/extension.xml file). Did I get this
> > > > right?
> > > >
> > > > --
> > > > Regards,
> > > > Igor
> > > >
> > > > On Tue, Sep 19, 2017, at 03:52 PM, Robert Scholte wrote:
> > > > > Let's do it like this:
> > > > >
> > > >
> > https://cwiki.apache.org/confluence/download/attachments/2329841/classrealms.pdf?api=v2
> > > > >
> > > > > Robert
> > > > >
> > > > > On Tue, 19 Sep 2017 21:08:39 +0200, Stephen Connolly
> > > > >  wrote:
> > > > >
> > > > > > I think you will need a link to the PDF as attachments are stripped
> > > > from
> > > > > > the ML
> > > > > >
> > > > > > On Tue 19 Sep 2017 at 19:57, Robert Scholte 
> > > > wrote:
> > > > > >
> > > > > >> Attached a single page overview.
> > > > > >>
> > > > > >> Per block you'll see in the upper left corner the executed plugin
> > > > > >> The left column contains the extensions and plugin in orderas
> > > > specified
> > > > > >> in
> > > > > >> the pom.xml
> > > > > >> In every classloadercolumn you'll see numbers which represent the
> > > > order.
> > > > > >>
> > > > > >> I hope I didn't make any mistakes.
> > > > > >> Tomorrow I have enough time to see if I understand what's
> > happening
> > > > > >> here.
> > > > > >>
> > > > > >> I will come back with my conclusions.
> > > > > >>
> > > > > >> Robert
> > > > > >>
> > > > > >> On Tue, 19 Sep 2017 06:55:08 +0200, Igor Fedorenko <
> > > > i...@ifedorenko.com>
> > > > > >> wrote:
> > > > > >>
> > > > > >> > TL;DR your test project exposed two existing bugs, one change in
> > > > > >> > behaviour and one quirk I can't explain
> > > > > >> >
> > > > > >> > * Build `` are loaded by two classloaders, which is
> > a
> > > > bug
> > > > > >> in
> > > > > >> > DefaultProjectBuildingHelper#createProjectRealm and explains
> > why you
> > > > > >> see
> > > > > >> > extjar1/extjar2 in the output
> > > > > >> > * ClassRealm does not allow same foreign-import from multiple
> > > > > >> > classloaders, which is a bug and explains why it is not
> > possible to
> > > > > >> load
> > > > > >> > same resource from multiple plugins/extensions
> > > > > >> > * TCCL does not have access to private (i.e. not exported)
> > resources
> > > > > >> of
> > > > > >> > this extensions plugin, which is a change of behaviour
> > introduced by
> > > > > >> > mng-6209 fix
> > > > > >> > * Also, component injection order appears to be backwards, but
> > maybe
> > > > > >> > Stuart can explain why.
> > > > > >> >
> > > > > >> >
> > > > > >> > Below is more detailed explanation of expected and observed
> > > > behaviour
> > > > > >> >
> > > > > >> >
> > > > > >> > ## Component injection depends on the currently running plugin
> > and
> > > > 

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Robert Scholte]

On Wed, 20 Sep 2017 09:12:47 +0200, Stephen Connolly  
 wrote:



On Wed 20 Sep 2017 at 01:29, Igor Fedorenko  wrote:


In that case, can I suggest couple of changes to the test project

* I thinks it makes more sense to configure extjar1 and extjar2 as
extensions  elements in probleN pom.xml files. First, there is
no meaningful order between  and  elements. More
importantly, though, simple  are treated in special
maven2-compat mode and are not representative of likely real-world
extensions.




Not sure I agree with this. I think there are jars worth sharing across  
multiple plugins, but where making the plugin an extension is a bit weird.

I'm thinking of scm and wagon in this case.



That sounds like we need documentation updated then. None of that is
obvious to me.




* I think we should introduce META-INF/maven/extension.xml to the test
extensions. This metadata what introduced to configure classpath
visibility, so lets use it.



Again, not obvious to me, if that file allows control of classpath
visibility then it may be that the only issue *with* 3.5.1 is the lack of
documentation... now previous versions would have been adding breaking
changes from my PoV but that is the past and should not affect the 3.5.1
release.

PRs for the probe project welcome. I am happy to try and write docs once  
I

have an understanding of what the expected behaviours are




--
Regards,
Igor

On Tue, Sep 19, 2017, at 05:12 PM, Stephen Connolly wrote:
> Yes, the expectations are key. Depending on what they are we may  
either
> drop 3.5.1 or go ahead as it depends on whether this is more correct  
than

> 3.5.0 or swapping one fix for a bug
>
> On Tue 19 Sep 2017 at 21:39, Igor Fedorenko   
wrote:

>
> > Just to confirm I understand what we are trying to establish here.  
We
> > want to decide the expected/desired component injection behaviour  
and

> > classpath visibility in the absence of package and artifact export
> > configuration (i.e. META-INF/maven/extension.xml file). Did I get  
this

> > right?
> >
> > --
> > Regards,
> > Igor
> >
> > On Tue, Sep 19, 2017, at 03:52 PM, Robert Scholte wrote:
> > > Let's do it like this:
> > >
> >
https://cwiki.apache.org/confluence/download/attachments/2329841/classrealms.pdf?api=v2
> > >
> > > Robert
> > >
> > > On Tue, 19 Sep 2017 21:08:39 +0200, Stephen Connolly
> > >  wrote:
> > >
> > > > I think you will need a link to the PDF as attachments are  
stripped

> > from
> > > > the ML
> > > >
> > > > On Tue 19 Sep 2017 at 19:57, Robert Scholte  


> > wrote:
> > > >
> > > >> Attached a single page overview.
> > > >>
> > > >> Per block you'll see in the upper left corner the executed  
plugin

> > > >> The left column contains the extensions and plugin in orderas
> > specified
> > > >> in
> > > >> the pom.xml
> > > >> In every classloadercolumn you'll see numbers which represent  
the

> > order.
> > > >>
> > > >> I hope I didn't make any mistakes.
> > > >> Tomorrow I have enough time to see if I understand what's
happening
> > > >> here.
> > > >>
> > > >> I will come back with my conclusions.
> > > >>
> > > >> Robert
> > > >>
> > > >> On Tue, 19 Sep 2017 06:55:08 +0200, Igor Fedorenko <
> > i...@ifedorenko.com>
> > > >> wrote:
> > > >>
> > > >> > TL;DR your test project exposed two existing bugs, one  
change in

> > > >> > behaviour and one quirk I can't explain
> > > >> >
> > > >> > * Build `` are loaded by two classloaders, which  
is

a
> > bug
> > > >> in
> > > >> > DefaultProjectBuildingHelper#createProjectRealm and explains
why you
> > > >> see
> > > >> > extjar1/extjar2 in the output
> > > >> > * ClassRealm does not allow same foreign-import from multiple
> > > >> > classloaders, which is a bug and explains why it is not
possible to
> > > >> load
> > > >> > same resource from multiple plugins/extensions
> > > >> > * TCCL does not have access to private (i.e. not exported)
resources
> > > >> of
> > > >> > this extensions plugin, which is a change of behaviour
introduced by
> > > >> > mng-6209 fix
> > > >> > * Also, component injection order appears to be backwards,  
but

maybe
> > > >> > Stuart can explain why.
> > > >> >
> > > >> >
> > > >> > Below is more detailed explanation of expected and observed
> > behaviour
> > > >> >
> > > >> >
> > > >> > ## Component injection depends on the currently running  
plugin

and
> > the
> > > >> > injection site
> > > >> >
> > > >> > Currently running plugins have access to the following  
component

> > > >> > implementations:
> > > >> >
> > > >> > * Regular plugin has access to components implemented by the
plugin,
> > > >> > project build extensions, if any (via project class realm
foreign
> > > >> > import) and Maven Core.
> > > >> > * Extension plugin has access to components implemented by  
the

> > project
> > > >> > build extensions and Maven Core.
> > > >> > * Without a running plugin 

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Stephen Connolly]

On Wed 20 Sep 2017 at 01:29, Igor Fedorenko  wrote:

> In that case, can I suggest couple of changes to the test project
>
> * I thinks it makes more sense to configure extjar1 and extjar2 as
> extensions  elements in probleN pom.xml files. First, there is
> no meaningful order between  and  elements. More
> importantly, though, simple  are treated in special
> maven2-compat mode and are not representative of likely real-world
> extensions.


That sounds like we need documentation updated then. None of that is
obvious to me.


>
> * I think we should introduce META-INF/maven/extension.xml to the test
> extensions. This metadata what introduced to configure classpath
> visibility, so lets use it.


Again, not obvious to me, if that file allows control of classpath
visibility then it may be that the only issue *with* 3.5.1 is the lack of
documentation... now previous versions would have been adding breaking
changes from my PoV but that is the past and should not affect the 3.5.1
release.

PRs for the probe project welcome. I am happy to try and write docs once I
have an understanding of what the expected behaviours are


>
> --
> Regards,
> Igor
>
> On Tue, Sep 19, 2017, at 05:12 PM, Stephen Connolly wrote:
> > Yes, the expectations are key. Depending on what they are we may either
> > drop 3.5.1 or go ahead as it depends on whether this is more correct than
> > 3.5.0 or swapping one fix for a bug
> >
> > On Tue 19 Sep 2017 at 21:39, Igor Fedorenko  wrote:
> >
> > > Just to confirm I understand what we are trying to establish here. We
> > > want to decide the expected/desired component injection behaviour and
> > > classpath visibility in the absence of package and artifact export
> > > configuration (i.e. META-INF/maven/extension.xml file). Did I get this
> > > right?
> > >
> > > --
> > > Regards,
> > > Igor
> > >
> > > On Tue, Sep 19, 2017, at 03:52 PM, Robert Scholte wrote:
> > > > Let's do it like this:
> > > >
> > >
> https://cwiki.apache.org/confluence/download/attachments/2329841/classrealms.pdf?api=v2
> > > >
> > > > Robert
> > > >
> > > > On Tue, 19 Sep 2017 21:08:39 +0200, Stephen Connolly
> > > >  wrote:
> > > >
> > > > > I think you will need a link to the PDF as attachments are stripped
> > > from
> > > > > the ML
> > > > >
> > > > > On Tue 19 Sep 2017 at 19:57, Robert Scholte 
> > > wrote:
> > > > >
> > > > >> Attached a single page overview.
> > > > >>
> > > > >> Per block you'll see in the upper left corner the executed plugin
> > > > >> The left column contains the extensions and plugin in orderas
> > > specified
> > > > >> in
> > > > >> the pom.xml
> > > > >> In every classloadercolumn you'll see numbers which represent the
> > > order.
> > > > >>
> > > > >> I hope I didn't make any mistakes.
> > > > >> Tomorrow I have enough time to see if I understand what's
> happening
> > > > >> here.
> > > > >>
> > > > >> I will come back with my conclusions.
> > > > >>
> > > > >> Robert
> > > > >>
> > > > >> On Tue, 19 Sep 2017 06:55:08 +0200, Igor Fedorenko <
> > > i...@ifedorenko.com>
> > > > >> wrote:
> > > > >>
> > > > >> > TL;DR your test project exposed two existing bugs, one change in
> > > > >> > behaviour and one quirk I can't explain
> > > > >> >
> > > > >> > * Build `` are loaded by two classloaders, which is
> a
> > > bug
> > > > >> in
> > > > >> > DefaultProjectBuildingHelper#createProjectRealm and explains
> why you
> > > > >> see
> > > > >> > extjar1/extjar2 in the output
> > > > >> > * ClassRealm does not allow same foreign-import from multiple
> > > > >> > classloaders, which is a bug and explains why it is not
> possible to
> > > > >> load
> > > > >> > same resource from multiple plugins/extensions
> > > > >> > * TCCL does not have access to private (i.e. not exported)
> resources
> > > > >> of
> > > > >> > this extensions plugin, which is a change of behaviour
> introduced by
> > > > >> > mng-6209 fix
> > > > >> > * Also, component injection order appears to be backwards, but
> maybe
> > > > >> > Stuart can explain why.
> > > > >> >
> > > > >> >
> > > > >> > Below is more detailed explanation of expected and observed
> > > behaviour
> > > > >> >
> > > > >> >
> > > > >> > ## Component injection depends on the currently running plugin
> and
> > > the
> > > > >> > injection site
> > > > >> >
> > > > >> > Currently running plugins have access to the following component
> > > > >> > implementations:
> > > > >> >
> > > > >> > * Regular plugin has access to components implemented by the
> plugin,
> > > > >> > project build extensions, if any (via project class realm
> foreign
> > > > >> > import) and Maven Core.
> > > > >> > * Extension plugin has access to components implemented by the
> > > project
> > > > >> > build extensions and Maven Core.
> > > > >> > * Without a running plugin (e.g., during project dependency
> > > > >> resolution),
> > > > >> > components implemented by the project 

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Igor Fedorenko]

In that case, can I suggest couple of changes to the test project

* I thinks it makes more sense to configure extjar1 and extjar2 as
extensions  elements in probleN pom.xml files. First, there is
no meaningful order between  and  elements. More
importantly, though, simple  are treated in special
maven2-compat mode and are not representative of likely real-world
extensions.

* I think we should introduce META-INF/maven/extension.xml to the test
extensions. This metadata what introduced to configure classpath
visibility, so lets use it.

-- 
Regards,
Igor

On Tue, Sep 19, 2017, at 05:12 PM, Stephen Connolly wrote:
> Yes, the expectations are key. Depending on what they are we may either
> drop 3.5.1 or go ahead as it depends on whether this is more correct than
> 3.5.0 or swapping one fix for a bug
> 
> On Tue 19 Sep 2017 at 21:39, Igor Fedorenko  wrote:
> 
> > Just to confirm I understand what we are trying to establish here. We
> > want to decide the expected/desired component injection behaviour and
> > classpath visibility in the absence of package and artifact export
> > configuration (i.e. META-INF/maven/extension.xml file). Did I get this
> > right?
> >
> > --
> > Regards,
> > Igor
> >
> > On Tue, Sep 19, 2017, at 03:52 PM, Robert Scholte wrote:
> > > Let's do it like this:
> > >
> > https://cwiki.apache.org/confluence/download/attachments/2329841/classrealms.pdf?api=v2
> > >
> > > Robert
> > >
> > > On Tue, 19 Sep 2017 21:08:39 +0200, Stephen Connolly
> > >  wrote:
> > >
> > > > I think you will need a link to the PDF as attachments are stripped
> > from
> > > > the ML
> > > >
> > > > On Tue 19 Sep 2017 at 19:57, Robert Scholte 
> > wrote:
> > > >
> > > >> Attached a single page overview.
> > > >>
> > > >> Per block you'll see in the upper left corner the executed plugin
> > > >> The left column contains the extensions and plugin in orderas
> > specified
> > > >> in
> > > >> the pom.xml
> > > >> In every classloadercolumn you'll see numbers which represent the
> > order.
> > > >>
> > > >> I hope I didn't make any mistakes.
> > > >> Tomorrow I have enough time to see if I understand what's happening
> > > >> here.
> > > >>
> > > >> I will come back with my conclusions.
> > > >>
> > > >> Robert
> > > >>
> > > >> On Tue, 19 Sep 2017 06:55:08 +0200, Igor Fedorenko <
> > i...@ifedorenko.com>
> > > >> wrote:
> > > >>
> > > >> > TL;DR your test project exposed two existing bugs, one change in
> > > >> > behaviour and one quirk I can't explain
> > > >> >
> > > >> > * Build `` are loaded by two classloaders, which is a
> > bug
> > > >> in
> > > >> > DefaultProjectBuildingHelper#createProjectRealm and explains why you
> > > >> see
> > > >> > extjar1/extjar2 in the output
> > > >> > * ClassRealm does not allow same foreign-import from multiple
> > > >> > classloaders, which is a bug and explains why it is not possible to
> > > >> load
> > > >> > same resource from multiple plugins/extensions
> > > >> > * TCCL does not have access to private (i.e. not exported) resources
> > > >> of
> > > >> > this extensions plugin, which is a change of behaviour introduced by
> > > >> > mng-6209 fix
> > > >> > * Also, component injection order appears to be backwards, but maybe
> > > >> > Stuart can explain why.
> > > >> >
> > > >> >
> > > >> > Below is more detailed explanation of expected and observed
> > behaviour
> > > >> >
> > > >> >
> > > >> > ## Component injection depends on the currently running plugin and
> > the
> > > >> > injection site
> > > >> >
> > > >> > Currently running plugins have access to the following component
> > > >> > implementations:
> > > >> >
> > > >> > * Regular plugin has access to components implemented by the plugin,
> > > >> > project build extensions, if any (via project class realm foreign
> > > >> > import) and Maven Core.
> > > >> > * Extension plugin has access to components implemented by the
> > project
> > > >> > build extensions and Maven Core.
> > > >> > * Without a running plugin (e.g., during project dependency
> > > >> resolution),
> > > >> > components implemented by the project build extensions and Maven
> > Core
> > > >> > are accessible.
> > > >> >
> > > >> > Different injection sites have access to the following component
> > > >> > interfaces:
> > > >> >
> > > >> > * Maven Core has access to component interfaces defined by the core
> > > >> > itself (obviously)
> > > >> > * Project build extensions have access to **public** component
> > > >> > interfaces defined by Maven Core and component interfaces defined by
> > > >> the
> > > >> > build extension itself (there is no way to access component
> > interfaces
> > > >> > defined in other extensions)
> > > >> > * Regular plugins have access to **public** component interfaces
> > > >> defined
> > > >> > by Maven Core, component interfaces **exported** by build extensions
> > > >> and
> > > >> > component interfaces defined in the plugin itself
> > > 

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Stephen Connolly]

Yes, the expectations are key. Depending on what they are we may either
drop 3.5.1 or go ahead as it depends on whether this is more correct than
3.5.0 or swapping one fix for a bug

On Tue 19 Sep 2017 at 21:39, Igor Fedorenko  wrote:

> Just to confirm I understand what we are trying to establish here. We
> want to decide the expected/desired component injection behaviour and
> classpath visibility in the absence of package and artifact export
> configuration (i.e. META-INF/maven/extension.xml file). Did I get this
> right?
>
> --
> Regards,
> Igor
>
> On Tue, Sep 19, 2017, at 03:52 PM, Robert Scholte wrote:
> > Let's do it like this:
> >
> https://cwiki.apache.org/confluence/download/attachments/2329841/classrealms.pdf?api=v2
> >
> > Robert
> >
> > On Tue, 19 Sep 2017 21:08:39 +0200, Stephen Connolly
> >  wrote:
> >
> > > I think you will need a link to the PDF as attachments are stripped
> from
> > > the ML
> > >
> > > On Tue 19 Sep 2017 at 19:57, Robert Scholte 
> wrote:
> > >
> > >> Attached a single page overview.
> > >>
> > >> Per block you'll see in the upper left corner the executed plugin
> > >> The left column contains the extensions and plugin in orderas
> specified
> > >> in
> > >> the pom.xml
> > >> In every classloadercolumn you'll see numbers which represent the
> order.
> > >>
> > >> I hope I didn't make any mistakes.
> > >> Tomorrow I have enough time to see if I understand what's happening
> > >> here.
> > >>
> > >> I will come back with my conclusions.
> > >>
> > >> Robert
> > >>
> > >> On Tue, 19 Sep 2017 06:55:08 +0200, Igor Fedorenko <
> i...@ifedorenko.com>
> > >> wrote:
> > >>
> > >> > TL;DR your test project exposed two existing bugs, one change in
> > >> > behaviour and one quirk I can't explain
> > >> >
> > >> > * Build `` are loaded by two classloaders, which is a
> bug
> > >> in
> > >> > DefaultProjectBuildingHelper#createProjectRealm and explains why you
> > >> see
> > >> > extjar1/extjar2 in the output
> > >> > * ClassRealm does not allow same foreign-import from multiple
> > >> > classloaders, which is a bug and explains why it is not possible to
> > >> load
> > >> > same resource from multiple plugins/extensions
> > >> > * TCCL does not have access to private (i.e. not exported) resources
> > >> of
> > >> > this extensions plugin, which is a change of behaviour introduced by
> > >> > mng-6209 fix
> > >> > * Also, component injection order appears to be backwards, but maybe
> > >> > Stuart can explain why.
> > >> >
> > >> >
> > >> > Below is more detailed explanation of expected and observed
> behaviour
> > >> >
> > >> >
> > >> > ## Component injection depends on the currently running plugin and
> the
> > >> > injection site
> > >> >
> > >> > Currently running plugins have access to the following component
> > >> > implementations:
> > >> >
> > >> > * Regular plugin has access to components implemented by the plugin,
> > >> > project build extensions, if any (via project class realm foreign
> > >> > import) and Maven Core.
> > >> > * Extension plugin has access to components implemented by the
> project
> > >> > build extensions and Maven Core.
> > >> > * Without a running plugin (e.g., during project dependency
> > >> resolution),
> > >> > components implemented by the project build extensions and Maven
> Core
> > >> > are accessible.
> > >> >
> > >> > Different injection sites have access to the following component
> > >> > interfaces:
> > >> >
> > >> > * Maven Core has access to component interfaces defined by the core
> > >> > itself (obviously)
> > >> > * Project build extensions have access to **public** component
> > >> > interfaces defined by Maven Core and component interfaces defined by
> > >> the
> > >> > build extension itself (there is no way to access component
> interfaces
> > >> > defined in other extensions)
> > >> > * Regular plugins have access to **public** component interfaces
> > >> defined
> > >> > by Maven Core, component interfaces **exported** by build extensions
> > >> and
> > >> > component interfaces defined in the plugin itself
> > >> >
> > >> > For injection to work, injection site has to have access to the
> > >> > component interface and the component implementation must be
> > >> accessible
> > >> > through the current context.
> > >> >
> > >> > From what I can tell, in your example all plugins have access to the
> > >> > right components when using current 3.5.2-SNAPSHOT. The injection
> > >> order
> > >> > does appear to be backwards from what I expected, however.
> > >> >
> > >> >
> > >> > ## Resources lookup fully depends on classpath visibility,
> > >> specifically
> > >> >
> > >> > * Regular plugin class realm has access to resources from the plugin
> > >> > itself, from **exported** packages of the project build extensions
> and
> > >> > **public** Maven Core packages
> > >> > * Extensions plugin class realm has access to the resources from the
> > >> > 

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Igor Fedorenko]

Just to confirm I understand what we are trying to establish here. We
want to decide the expected/desired component injection behaviour and
classpath visibility in the absence of package and artifact export
configuration (i.e. META-INF/maven/extension.xml file). Did I get this
right?

-- 
Regards,
Igor

On Tue, Sep 19, 2017, at 03:52 PM, Robert Scholte wrote:
> Let's do it like this:
> https://cwiki.apache.org/confluence/download/attachments/2329841/classrealms.pdf?api=v2
> 
> Robert
> 
> On Tue, 19 Sep 2017 21:08:39 +0200, Stephen Connolly  
>  wrote:
> 
> > I think you will need a link to the PDF as attachments are stripped from
> > the ML
> >
> > On Tue 19 Sep 2017 at 19:57, Robert Scholte  wrote:
> >
> >> Attached a single page overview.
> >>
> >> Per block you'll see in the upper left corner the executed plugin
> >> The left column contains the extensions and plugin in orderas specified  
> >> in
> >> the pom.xml
> >> In every classloadercolumn you'll see numbers which represent the order.
> >>
> >> I hope I didn't make any mistakes.
> >> Tomorrow I have enough time to see if I understand what's happening  
> >> here.
> >>
> >> I will come back with my conclusions.
> >>
> >> Robert
> >>
> >> On Tue, 19 Sep 2017 06:55:08 +0200, Igor Fedorenko 
> >> wrote:
> >>
> >> > TL;DR your test project exposed two existing bugs, one change in
> >> > behaviour and one quirk I can't explain
> >> >
> >> > * Build `` are loaded by two classloaders, which is a bug  
> >> in
> >> > DefaultProjectBuildingHelper#createProjectRealm and explains why you  
> >> see
> >> > extjar1/extjar2 in the output
> >> > * ClassRealm does not allow same foreign-import from multiple
> >> > classloaders, which is a bug and explains why it is not possible to  
> >> load
> >> > same resource from multiple plugins/extensions
> >> > * TCCL does not have access to private (i.e. not exported) resources  
> >> of
> >> > this extensions plugin, which is a change of behaviour introduced by
> >> > mng-6209 fix
> >> > * Also, component injection order appears to be backwards, but maybe
> >> > Stuart can explain why.
> >> >
> >> >
> >> > Below is more detailed explanation of expected and observed behaviour
> >> >
> >> >
> >> > ## Component injection depends on the currently running plugin and the
> >> > injection site
> >> >
> >> > Currently running plugins have access to the following component
> >> > implementations:
> >> >
> >> > * Regular plugin has access to components implemented by the plugin,
> >> > project build extensions, if any (via project class realm foreign
> >> > import) and Maven Core.
> >> > * Extension plugin has access to components implemented by the project
> >> > build extensions and Maven Core.
> >> > * Without a running plugin (e.g., during project dependency  
> >> resolution),
> >> > components implemented by the project build extensions and Maven Core
> >> > are accessible.
> >> >
> >> > Different injection sites have access to the following component
> >> > interfaces:
> >> >
> >> > * Maven Core has access to component interfaces defined by the core
> >> > itself (obviously)
> >> > * Project build extensions have access to **public** component
> >> > interfaces defined by Maven Core and component interfaces defined by  
> >> the
> >> > build extension itself (there is no way to access component interfaces
> >> > defined in other extensions)
> >> > * Regular plugins have access to **public** component interfaces  
> >> defined
> >> > by Maven Core, component interfaces **exported** by build extensions  
> >> and
> >> > component interfaces defined in the plugin itself
> >> >
> >> > For injection to work, injection site has to have access to the
> >> > component interface and the component implementation must be  
> >> accessible
> >> > through the current context.
> >> >
> >> > From what I can tell, in your example all plugins have access to the
> >> > right components when using current 3.5.2-SNAPSHOT. The injection  
> >> order
> >> > does appear to be backwards from what I expected, however.
> >> >
> >> >
> >> > ## Resources lookup fully depends on classpath visibility,  
> >> specifically
> >> >
> >> > * Regular plugin class realm has access to resources from the plugin
> >> > itself, from **exported** packages of the project build extensions and
> >> > **public** Maven Core packages
> >> > * Extensions plugin class realm has access to the resources from the
> >> > extensions plugin itself and from **public** Maven Core packages
> >> > * Project class realm has access to classes and resources **exported**
> >> > by project build extensions and **public** Maven Core packages
> >> >
> >> > I see three problems here
> >> >
> >> > * Maven adds build single-jar `` elements directly to
> >> > project class realm **and** creates separate extensions class realms  
> >> for
> >> > them. Which results in duplicate classes/resources loaded by two
> >> > 

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Robert Scholte]

Let's do it like this:
https://cwiki.apache.org/confluence/download/attachments/2329841/classrealms.pdf?api=v2

Robert

On Tue, 19 Sep 2017 21:08:39 +0200, Stephen Connolly  
 wrote:



I think you will need a link to the PDF as attachments are stripped from
the ML

On Tue 19 Sep 2017 at 19:57, Robert Scholte  wrote:


Attached a single page overview.

Per block you'll see in the upper left corner the executed plugin
The left column contains the extensions and plugin in orderas specified  
in

the pom.xml
In every classloadercolumn you'll see numbers which represent the order.

I hope I didn't make any mistakes.
Tomorrow I have enough time to see if I understand what's happening  
here.


I will come back with my conclusions.

Robert

On Tue, 19 Sep 2017 06:55:08 +0200, Igor Fedorenko 
wrote:

> TL;DR your test project exposed two existing bugs, one change in
> behaviour and one quirk I can't explain
>
> * Build `` are loaded by two classloaders, which is a bug  
in
> DefaultProjectBuildingHelper#createProjectRealm and explains why you  
see

> extjar1/extjar2 in the output
> * ClassRealm does not allow same foreign-import from multiple
> classloaders, which is a bug and explains why it is not possible to  
load

> same resource from multiple plugins/extensions
> * TCCL does not have access to private (i.e. not exported) resources  
of

> this extensions plugin, which is a change of behaviour introduced by
> mng-6209 fix
> * Also, component injection order appears to be backwards, but maybe
> Stuart can explain why.
>
>
> Below is more detailed explanation of expected and observed behaviour
>
>
> ## Component injection depends on the currently running plugin and the
> injection site
>
> Currently running plugins have access to the following component
> implementations:
>
> * Regular plugin has access to components implemented by the plugin,
> project build extensions, if any (via project class realm foreign
> import) and Maven Core.
> * Extension plugin has access to components implemented by the project
> build extensions and Maven Core.
> * Without a running plugin (e.g., during project dependency  
resolution),

> components implemented by the project build extensions and Maven Core
> are accessible.
>
> Different injection sites have access to the following component
> interfaces:
>
> * Maven Core has access to component interfaces defined by the core
> itself (obviously)
> * Project build extensions have access to **public** component
> interfaces defined by Maven Core and component interfaces defined by  
the

> build extension itself (there is no way to access component interfaces
> defined in other extensions)
> * Regular plugins have access to **public** component interfaces  
defined
> by Maven Core, component interfaces **exported** by build extensions  
and

> component interfaces defined in the plugin itself
>
> For injection to work, injection site has to have access to the
> component interface and the component implementation must be  
accessible

> through the current context.
>
> From what I can tell, in your example all plugins have access to the
> right components when using current 3.5.2-SNAPSHOT. The injection  
order

> does appear to be backwards from what I expected, however.
>
>
> ## Resources lookup fully depends on classpath visibility,  
specifically

>
> * Regular plugin class realm has access to resources from the plugin
> itself, from **exported** packages of the project build extensions and
> **public** Maven Core packages
> * Extensions plugin class realm has access to the resources from the
> extensions plugin itself and from **public** Maven Core packages
> * Project class realm has access to classes and resources **exported**
> by project build extensions and **public** Maven Core packages
>
> I see three problems here
>
> * Maven adds build single-jar `` elements directly to
> project class realm **and** creates separate extensions class realms  
for

> them. Which results in duplicate classes/resources loaded by two
> classloaders and explains why you see extjar1/extjar2 output (which  
you

> shouldn't according to the explanation above)
> * ClassRealm does not allow foreign-import of the same package from
> multiple classloaders. This makes it impossible to load the same
> resource from multiple plugins/extensions.
> * Extensions plugins cannot access their own private (i.e. not  
exported)

> resources via TCCL, this is change in behaviour introduced by mng-6209
> fix
>
> Hope this helps

-
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: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Stephen Connolly]

I think you will need a link to the PDF as attachments are stripped from
the ML

On Tue 19 Sep 2017 at 19:57, Robert Scholte  wrote:

> Attached a single page overview.
>
> Per block you'll see in the upper left corner the executed plugin
> The left column contains the extensions and plugin in orderas specified in
> the pom.xml
> In every classloadercolumn you'll see numbers which represent the order.
>
> I hope I didn't make any mistakes.
> Tomorrow I have enough time to see if I understand what's happening here.
>
> I will come back with my conclusions.
>
> Robert
>
> On Tue, 19 Sep 2017 06:55:08 +0200, Igor Fedorenko 
> wrote:
>
> > TL;DR your test project exposed two existing bugs, one change in
> > behaviour and one quirk I can't explain
> >
> > * Build `` are loaded by two classloaders, which is a bug in
> > DefaultProjectBuildingHelper#createProjectRealm and explains why you see
> > extjar1/extjar2 in the output
> > * ClassRealm does not allow same foreign-import from multiple
> > classloaders, which is a bug and explains why it is not possible to load
> > same resource from multiple plugins/extensions
> > * TCCL does not have access to private (i.e. not exported) resources of
> > this extensions plugin, which is a change of behaviour introduced by
> > mng-6209 fix
> > * Also, component injection order appears to be backwards, but maybe
> > Stuart can explain why.
> >
> >
> > Below is more detailed explanation of expected and observed behaviour
> >
> >
> > ## Component injection depends on the currently running plugin and the
> > injection site
> >
> > Currently running plugins have access to the following component
> > implementations:
> >
> > * Regular plugin has access to components implemented by the plugin,
> > project build extensions, if any (via project class realm foreign
> > import) and Maven Core.
> > * Extension plugin has access to components implemented by the project
> > build extensions and Maven Core.
> > * Without a running plugin (e.g., during project dependency resolution),
> > components implemented by the project build extensions and Maven Core
> > are accessible.
> >
> > Different injection sites have access to the following component
> > interfaces:
> >
> > * Maven Core has access to component interfaces defined by the core
> > itself (obviously)
> > * Project build extensions have access to **public** component
> > interfaces defined by Maven Core and component interfaces defined by the
> > build extension itself (there is no way to access component interfaces
> > defined in other extensions)
> > * Regular plugins have access to **public** component interfaces defined
> > by Maven Core, component interfaces **exported** by build extensions and
> > component interfaces defined in the plugin itself
> >
> > For injection to work, injection site has to have access to the
> > component interface and the component implementation must be accessible
> > through the current context.
> >
> > From what I can tell, in your example all plugins have access to the
> > right components when using current 3.5.2-SNAPSHOT. The injection order
> > does appear to be backwards from what I expected, however.
> >
> >
> > ## Resources lookup fully depends on classpath visibility, specifically
> >
> > * Regular plugin class realm has access to resources from the plugin
> > itself, from **exported** packages of the project build extensions and
> > **public** Maven Core packages
> > * Extensions plugin class realm has access to the resources from the
> > extensions plugin itself and from **public** Maven Core packages
> > * Project class realm has access to classes and resources **exported**
> > by project build extensions and **public** Maven Core packages
> >
> > I see three problems here
> >
> > * Maven adds build single-jar `` elements directly to
> > project class realm **and** creates separate extensions class realms for
> > them. Which results in duplicate classes/resources loaded by two
> > classloaders and explains why you see extjar1/extjar2 output (which you
> > shouldn't according to the explanation above)
> > * ClassRealm does not allow foreign-import of the same package from
> > multiple classloaders. This makes it impossible to load the same
> > resource from multiple plugins/extensions.
> > * Extensions plugins cannot access their own private (i.e. not exported)
> > resources via TCCL, this is change in behaviour introduced by mng-6209
> > fix
> >
> > Hope this helps
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org

-- 
Sent from my phone

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Robert Scholte]

Attached a single page overview.

Per block you'll see in the upper left corner the executed plugin
The left column contains the extensions and plugin in orderas specified in  
the pom.xml

In every classloadercolumn you'll see numbers which represent the order.

I hope I didn't make any mistakes.
Tomorrow I have enough time to see if I understand what's happening here.

I will come back with my conclusions.

Robert

On Tue, 19 Sep 2017 06:55:08 +0200, Igor Fedorenko   
wrote:



TL;DR your test project exposed two existing bugs, one change in
behaviour and one quirk I can't explain

* Build `` are loaded by two classloaders, which is a bug in
DefaultProjectBuildingHelper#createProjectRealm and explains why you see
extjar1/extjar2 in the output
* ClassRealm does not allow same foreign-import from multiple
classloaders, which is a bug and explains why it is not possible to load
same resource from multiple plugins/extensions
* TCCL does not have access to private (i.e. not exported) resources of
this extensions plugin, which is a change of behaviour introduced by
mng-6209 fix
* Also, component injection order appears to be backwards, but maybe
Stuart can explain why.


Below is more detailed explanation of expected and observed behaviour


## Component injection depends on the currently running plugin and the
injection site

Currently running plugins have access to the following component
implementations:

* Regular plugin has access to components implemented by the plugin,
project build extensions, if any (via project class realm foreign
import) and Maven Core.
* Extension plugin has access to components implemented by the project
build extensions and Maven Core.
* Without a running plugin (e.g., during project dependency resolution),
components implemented by the project build extensions and Maven Core
are accessible.

Different injection sites have access to the following component
interfaces:

* Maven Core has access to component interfaces defined by the core
itself (obviously)
* Project build extensions have access to **public** component
interfaces defined by Maven Core and component interfaces defined by the
build extension itself (there is no way to access component interfaces
defined in other extensions)
* Regular plugins have access to **public** component interfaces defined
by Maven Core, component interfaces **exported** by build extensions and
component interfaces defined in the plugin itself

For injection to work, injection site has to have access to the
component interface and the component implementation must be accessible
through the current context.

From what I can tell, in your example all plugins have access to the
right components when using current 3.5.2-SNAPSHOT. The injection order
does appear to be backwards from what I expected, however.


## Resources lookup fully depends on classpath visibility, specifically

* Regular plugin class realm has access to resources from the plugin
itself, from **exported** packages of the project build extensions and
**public** Maven Core packages
* Extensions plugin class realm has access to the resources from the
extensions plugin itself and from **public** Maven Core packages
* Project class realm has access to classes and resources **exported**
by project build extensions and **public** Maven Core packages

I see three problems here

* Maven adds build single-jar `` elements directly to
project class realm **and** creates separate extensions class realms for
them. Which results in duplicate classes/resources loaded by two
classloaders and explains why you see extjar1/extjar2 output (which you
shouldn't according to the explanation above)
* ClassRealm does not allow foreign-import of the same package from
multiple classloaders. This makes it impossible to load the same
resource from multiple plugins/extensions.
* Extensions plugins cannot access their own private (i.e. not exported)
resources via TCCL, this is change in behaviour introduced by mng-6209
fix

Hope this helps

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

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Igor Fedorenko]

TL;DR your test project exposed two existing bugs, one change in
behaviour and one quirk I can't explain

* Build `` are loaded by two classloaders, which is a bug in
DefaultProjectBuildingHelper#createProjectRealm and explains why you see
extjar1/extjar2 in the output
* ClassRealm does not allow same foreign-import from multiple
classloaders, which is a bug and explains why it is not possible to load
same resource from multiple plugins/extensions
* TCCL does not have access to private (i.e. not exported) resources of
this extensions plugin, which is a change of behaviour introduced by
mng-6209 fix
* Also, component injection order appears to be backwards, but maybe
Stuart can explain why.


Below is more detailed explanation of expected and observed behaviour


## Component injection depends on the currently running plugin and the
injection site

Currently running plugins have access to the following component
implementations:

* Regular plugin has access to components implemented by the plugin,
project build extensions, if any (via project class realm foreign
import) and Maven Core.
* Extension plugin has access to components implemented by the project
build extensions and Maven Core.
* Without a running plugin (e.g., during project dependency resolution),
components implemented by the project build extensions and Maven Core
are accessible.

Different injection sites have access to the following component
interfaces:

* Maven Core has access to component interfaces defined by the core
itself (obviously)
* Project build extensions have access to **public** component
interfaces defined by Maven Core and component interfaces defined by the
build extension itself (there is no way to access component interfaces
defined in other extensions)
* Regular plugins have access to **public** component interfaces defined
by Maven Core, component interfaces **exported** by build extensions and
component interfaces defined in the plugin itself

For injection to work, injection site has to have access to the
component interface and the component implementation must be accessible
through the current context.

>From what I can tell, in your example all plugins have access to the
right components when using current 3.5.2-SNAPSHOT. The injection order
does appear to be backwards from what I expected, however.


## Resources lookup fully depends on classpath visibility, specifically

* Regular plugin class realm has access to resources from the plugin
itself, from **exported** packages of the project build extensions and
**public** Maven Core packages
* Extensions plugin class realm has access to the resources from the
extensions plugin itself and from **public** Maven Core packages
* Project class realm has access to classes and resources **exported**
by project build extensions and **public** Maven Core packages

I see three problems here

* Maven adds build single-jar `` elements directly to
project class realm **and** creates separate extensions class realms for
them. Which results in duplicate classes/resources loaded by two
classloaders and explains why you see extjar1/extjar2 output (which you
shouldn't according to the explanation above)
* ClassRealm does not allow foreign-import of the same package from
multiple classloaders. This makes it impossible to load the same
resource from multiple plugins/extensions.
* Extensions plugins cannot access their own private (i.e. not exported)
resources via TCCL, this is change in behaviour introduced by mng-6209
fix

Hope this helps

-- 
Regards,
Igor

On Mon, Sep 18, 2017, at 11:46 AM, Stephen Connolly wrote:
> Oh if only... there is some subtleties going on here.
> 
> Classes are managed by the "plexus" / "classworlds" stuff, so you cannot
> override core classes etc.
> 
> The problem is what extensions are visible and from which classloader
> 
> On 18 September 2017 at 08:42, Charles Honton  wrote:
> 
> > From a security perspective, I would expect that core classes can not be
> > overridden by extensions or plugins.  Likewise, extension classes can not
> > be overridden by plugins.
> >
> > Given the use case of defaulting resources, I would expect that the plugin
> > resources are first, followed by plugin specific extensions, followed by
> > global extensions, finally core maven.  (This allows resources to be
> > specialized.)
> >
> > regards,
> > chas
> >
> > > On Sep 18, 2017, at 3:20 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> > >
> > > Hmmm, so I did some experiments:
> > >
> > > If you want to ride along, the experiments are at:
> > >
> > > https://github.com/stephenc/mng-6209
> > >
> > > So basically I have a plugin that does three different tests:
> > >
> > >getLog().info("Injected by @Component:");
> > >for (Lifecycle l : lifecycles) {
> > >if (l.getId().startsWith("mng-6209-")) {
> > >getLog().info("  " + l.getId().substring(9));
> > >}
> > >}
> > >

Re: [VOTE] Release Apache Maven 3.5.1

[Olivier Lamy]

Hi
Sorry a bit out of time ATM for testing this.
Well I trust Arnaud testing that especially if this improve the performance
of this very great/awesome/users oriented plugin :P

On 13 September 2017 at 22:19, Arnaud Héritier  wrote:

> Damned, can't we be anonymous on Github ?
> I maintain it is a big word, I'm trying to fix more bugs than I add new
> ones
> I added Oleg in the loop as he contributed a lot on it too
> I did a quick test to build on Jenkins 2.60.3 our maven core with the Evil
> Maven plugin 2.17 on a local SSH agent and it is ok
> But it is really a quick test ...
>
> Cheers
>
>
>
> On Wed, Sep 13, 2017 at 10:07 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > On 13 September 2017 at 01:05, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> >> On 13 September 2017 at 00:26, Anders Hammar  wrote:
> >>
> >>> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> >>> stephen.alan.conno...@gmail.com> wrote:
> >>>
> >>> > Have we got any feedback from the embedder integrations yet?
> >>> >
> >>>
> >>> I haven't heard anything from the m2e people. Maybe we need to ping
> them
> >>> directly. I can contact Fred Bricon.
> >>>
> >>> /Anders
> >>>
> >>>
> >> Please do, also if anyone has a contact in netbeans or intellij and
> could
> >> let them know we'd like either feedback or "we're ok if MNG-6275 makes
> >> trouble for us, go ahead and release". I'd like to close the vote on
> Friday
> >> 13:00 UTC.
> >>
> >>
> >
> > Olivier / Arnaud, have either of you had a chance to test this with the
> > evil project type[1] as you two seem to be the active maintainers[2]
> >
> > [1]: https://javaadventure.blogspot.ie/2013/11/jenkins-
> > maven-job-type-considered-evil.html
> > [2]: https://github.com/jenkinsci/maven-plugin/commits/master
> >
>
>
>
> --
>
> Arnaud
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Stephen Connolly]

Oh if only... there is some subtleties going on here.

Classes are managed by the "plexus" / "classworlds" stuff, so you cannot
override core classes etc.

The problem is what extensions are visible and from which classloader

On 18 September 2017 at 08:42, Charles Honton  wrote:

> From a security perspective, I would expect that core classes can not be
> overridden by extensions or plugins.  Likewise, extension classes can not
> be overridden by plugins.
>
> Given the use case of defaulting resources, I would expect that the plugin
> resources are first, followed by plugin specific extensions, followed by
> global extensions, finally core maven.  (This allows resources to be
> specialized.)
>
> regards,
> chas
>
> > On Sep 18, 2017, at 3:20 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
> >
> > Hmmm, so I did some experiments:
> >
> > If you want to ride along, the experiments are at:
> >
> > https://github.com/stephenc/mng-6209
> >
> > So basically I have a plugin that does three different tests:
> >
> >getLog().info("Injected by @Component:");
> >for (Lifecycle l : lifecycles) {
> >if (l.getId().startsWith("mng-6209-")) {
> >getLog().info("  " + l.getId().substring(9));
> >}
> >}
> >getLog().info("");
> >getLog().info("On Plugin Class Loader:");
> >try {
> >ClassLoader tccl = ListMojo.class.getClassLoader();
> >for (URL url :
> > Collections.list(tccl.getResources("META-INF/probe.txt"))) {
> >InputStream is = url.openStream();
> >try {
> >getLog().info("  " + IOUtil.toString(is).trim());
> >} finally {
> >is.close();
> >}
> >}
> >} catch (IOException e) {
> >throw new MojoExecutionException(e.getMessage(), e);
> >}
> >getLog().info("");
> >getLog().info("On Thread Context Class Loader:");
> >try {
> >ClassLoader tccl =
> > Thread.currentThread().getContextClassLoader();
> >for (URL url :
> > Collections.list(tccl.getResources("META-INF/probe.txt"))) {
> >InputStream is = url.openStream();
> >try {
> >getLog().info("  " + IOUtil.toString(is).trim());
> >} finally {
> >is.close();
> >}
> >}
> >} catch (IOException e) {
> >throw new MojoExecutionException(e.getMessage(), e);
> >}
> >
> >
> > First off, I hijack the @Component injection with some fake "lifecycles"
> to
> > see what "plexus" exposes to the plugins.
> >
> > Second, I look at the resources visible from the plugin's classloader.
> >
> > Finally, I look at the resources visible from the TCCL.
> >
> > Here's what 3.5.0 outputs:
> >
> > [INFO]
> > 
> > [INFO] Building Both extensions. Order: plugin1, plugin2 1.0-SNAPSHOT
> > [INFO]
> > 
> > [INFO]
> > [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe1 ---
> > [INFO] Injected by @Component:
> > [INFO]   plugin1
> > [INFO]
> > [INFO] On Plugin Class Loader:
> > [INFO]   plugin1
> > [INFO]
> > [INFO] On Thread Context Class Loader:
> > [INFO]   plugin1
> > [INFO]
> > [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe1 ---
> > [INFO] Injected by @Component:
> > [INFO]   plugin2
> > [INFO]
> > [INFO] On Plugin Class Loader:
> > [INFO]   plugin2
> > [INFO]
> > [INFO] On Thread Context Class Loader:
> > [INFO]   plugin2
> > [INFO]
> > [INFO]
> > 
> > [INFO] Building Only plugin1 extensions. Order: plugin1, plugin2
> > 1.0-SNAPSHOT
> > [INFO]
> > 
> > [INFO]
> > [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe2 ---
> > [INFO] Injected by @Component:
> > [INFO]   plugin1
> > [INFO]
> > [INFO] On Plugin Class Loader:
> > [INFO]   plugin1
> > [INFO]
> > [INFO] On Thread Context Class Loader:
> > [INFO]   plugin1
> > [INFO]
> > [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe2 ---
> > [INFO] Injected by @Component:
> > [INFO]   plugin2
> > [INFO]   plugin1
> > [INFO]   extjar2
> > [INFO]   extjar1
> > [INFO]
> > [INFO] On Plugin Class Loader:
> > [INFO]   plugin2
> > [INFO]   extjar2
> > [INFO]   extjar1
> > [INFO]
> > [INFO] On Thread Context Class Loader:
> > [INFO]   plugin2
> > [INFO]   extjar2
> > [INFO]   extjar1
> > [INFO]
> > [INFO]
> > 
> > [INFO] Building Both extensions. Order: plugin2, plugin1 1.0-SNAPSHOT
> > [INFO]
> > 
> > [INFO]
> > [INFO] --- plugin2:1.0-SNAPSHOT:list 

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Charles Honton]

From a security perspective, I would expect that core classes can not be 
overridden by extensions or plugins.  Likewise, extension classes can not be 
overridden by plugins.

Given the use case of defaulting resources, I would expect that the plugin 
resources are first, followed by plugin specific extensions, followed by global 
extensions, finally core maven.  (This allows resources to be specialized.)

regards,
chas

> On Sep 18, 2017, at 3:20 AM, Stephen Connolly 
>  wrote:
> 
> Hmmm, so I did some experiments:
> 
> If you want to ride along, the experiments are at:
> 
> https://github.com/stephenc/mng-6209
> 
> So basically I have a plugin that does three different tests:
> 
>getLog().info("Injected by @Component:");
>for (Lifecycle l : lifecycles) {
>if (l.getId().startsWith("mng-6209-")) {
>getLog().info("  " + l.getId().substring(9));
>}
>}
>getLog().info("");
>getLog().info("On Plugin Class Loader:");
>try {
>ClassLoader tccl = ListMojo.class.getClassLoader();
>for (URL url :
> Collections.list(tccl.getResources("META-INF/probe.txt"))) {
>InputStream is = url.openStream();
>try {
>getLog().info("  " + IOUtil.toString(is).trim());
>} finally {
>is.close();
>}
>}
>} catch (IOException e) {
>throw new MojoExecutionException(e.getMessage(), e);
>}
>getLog().info("");
>getLog().info("On Thread Context Class Loader:");
>try {
>ClassLoader tccl =
> Thread.currentThread().getContextClassLoader();
>for (URL url :
> Collections.list(tccl.getResources("META-INF/probe.txt"))) {
>InputStream is = url.openStream();
>try {
>getLog().info("  " + IOUtil.toString(is).trim());
>} finally {
>is.close();
>}
>}
>} catch (IOException e) {
>throw new MojoExecutionException(e.getMessage(), e);
>}
> 
> 
> First off, I hijack the @Component injection with some fake "lifecycles" to
> see what "plexus" exposes to the plugins.
> 
> Second, I look at the resources visible from the plugin's classloader.
> 
> Finally, I look at the resources visible from the TCCL.
> 
> Here's what 3.5.0 outputs:
> 
> [INFO]
> 
> [INFO] Building Both extensions. Order: plugin1, plugin2 1.0-SNAPSHOT
> [INFO]
> 
> [INFO]
> [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe1 ---
> [INFO] Injected by @Component:
> [INFO]   plugin1
> [INFO]
> [INFO] On Plugin Class Loader:
> [INFO]   plugin1
> [INFO]
> [INFO] On Thread Context Class Loader:
> [INFO]   plugin1
> [INFO]
> [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe1 ---
> [INFO] Injected by @Component:
> [INFO]   plugin2
> [INFO]
> [INFO] On Plugin Class Loader:
> [INFO]   plugin2
> [INFO]
> [INFO] On Thread Context Class Loader:
> [INFO]   plugin2
> [INFO]
> [INFO]
> 
> [INFO] Building Only plugin1 extensions. Order: plugin1, plugin2
> 1.0-SNAPSHOT
> [INFO]
> 
> [INFO]
> [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe2 ---
> [INFO] Injected by @Component:
> [INFO]   plugin1
> [INFO]
> [INFO] On Plugin Class Loader:
> [INFO]   plugin1
> [INFO]
> [INFO] On Thread Context Class Loader:
> [INFO]   plugin1
> [INFO]
> [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe2 ---
> [INFO] Injected by @Component:
> [INFO]   plugin2
> [INFO]   plugin1
> [INFO]   extjar2
> [INFO]   extjar1
> [INFO]
> [INFO] On Plugin Class Loader:
> [INFO]   plugin2
> [INFO]   extjar2
> [INFO]   extjar1
> [INFO]
> [INFO] On Thread Context Class Loader:
> [INFO]   plugin2
> [INFO]   extjar2
> [INFO]   extjar1
> [INFO]
> [INFO]
> 
> [INFO] Building Both extensions. Order: plugin2, plugin1 1.0-SNAPSHOT
> [INFO]
> 
> [INFO]
> [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe3 ---
> [INFO] Injected by @Component:
> [INFO]   plugin2
> [INFO]
> [INFO] On Plugin Class Loader:
> [INFO]   plugin2
> [INFO]
> [INFO] On Thread Context Class Loader:
> [INFO]   plugin2
> [INFO]
> [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe3 ---
> [INFO] Injected by @Component:
> [INFO]   plugin1
> [INFO]
> [INFO] On Plugin Class Loader:
> [INFO]   plugin1
> [INFO]
> [INFO] On Thread Context Class Loader:
> [INFO]   plugin1
> [INFO]
> [INFO]
> 
> [INFO] 

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Stephen Connolly]

Hmmm, so I did some experiments:

If you want to ride along, the experiments are at:

https://github.com/stephenc/mng-6209

So basically I have a plugin that does three different tests:

getLog().info("Injected by @Component:");
for (Lifecycle l : lifecycles) {
if (l.getId().startsWith("mng-6209-")) {
getLog().info("  " + l.getId().substring(9));
}
}
getLog().info("");
getLog().info("On Plugin Class Loader:");
try {
ClassLoader tccl = ListMojo.class.getClassLoader();
for (URL url :
Collections.list(tccl.getResources("META-INF/probe.txt"))) {
InputStream is = url.openStream();
try {
getLog().info("  " + IOUtil.toString(is).trim());
} finally {
is.close();
}
}
} catch (IOException e) {
throw new MojoExecutionException(e.getMessage(), e);
}
getLog().info("");
getLog().info("On Thread Context Class Loader:");
try {
ClassLoader tccl =
Thread.currentThread().getContextClassLoader();
for (URL url :
Collections.list(tccl.getResources("META-INF/probe.txt"))) {
InputStream is = url.openStream();
try {
getLog().info("  " + IOUtil.toString(is).trim());
} finally {
is.close();
}
}
} catch (IOException e) {
throw new MojoExecutionException(e.getMessage(), e);
}


First off, I hijack the @Component injection with some fake "lifecycles" to
see what "plexus" exposes to the plugins.

Second, I look at the resources visible from the plugin's classloader.

Finally, I look at the resources visible from the TCCL.

Here's what 3.5.0 outputs:

[INFO]

[INFO] Building Both extensions. Order: plugin1, plugin2 1.0-SNAPSHOT
[INFO]

[INFO]
[INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe1 ---
[INFO] Injected by @Component:
[INFO]   plugin1
[INFO]
[INFO] On Plugin Class Loader:
[INFO]   plugin1
[INFO]
[INFO] On Thread Context Class Loader:
[INFO]   plugin1
[INFO]
[INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe1 ---
[INFO] Injected by @Component:
[INFO]   plugin2
[INFO]
[INFO] On Plugin Class Loader:
[INFO]   plugin2
[INFO]
[INFO] On Thread Context Class Loader:
[INFO]   plugin2
[INFO]
[INFO]

[INFO] Building Only plugin1 extensions. Order: plugin1, plugin2
1.0-SNAPSHOT
[INFO]

[INFO]
[INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe2 ---
[INFO] Injected by @Component:
[INFO]   plugin1
[INFO]
[INFO] On Plugin Class Loader:
[INFO]   plugin1
[INFO]
[INFO] On Thread Context Class Loader:
[INFO]   plugin1
[INFO]
[INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe2 ---
[INFO] Injected by @Component:
[INFO]   plugin2
[INFO]   plugin1
[INFO]   extjar2
[INFO]   extjar1
[INFO]
[INFO] On Plugin Class Loader:
[INFO]   plugin2
[INFO]   extjar2
[INFO]   extjar1
[INFO]
[INFO] On Thread Context Class Loader:
[INFO]   plugin2
[INFO]   extjar2
[INFO]   extjar1
[INFO]
[INFO]

[INFO] Building Both extensions. Order: plugin2, plugin1 1.0-SNAPSHOT
[INFO]

[INFO]
[INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe3 ---
[INFO] Injected by @Component:
[INFO]   plugin2
[INFO]
[INFO] On Plugin Class Loader:
[INFO]   plugin2
[INFO]
[INFO] On Thread Context Class Loader:
[INFO]   plugin2
[INFO]
[INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe3 ---
[INFO] Injected by @Component:
[INFO]   plugin1
[INFO]
[INFO] On Plugin Class Loader:
[INFO]   plugin1
[INFO]
[INFO] On Thread Context Class Loader:
[INFO]   plugin1
[INFO]
[INFO]

[INFO] Building Both extensions. Order: plugin1, plugin2. Extra dependency
in plugin1 1.0-SNAPSHOT
[INFO]

[INFO]
[INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe4 ---
[INFO] Injected by @Component:
[INFO]   extjar2
[INFO]   plugin1
[INFO]
[INFO] On Plugin Class Loader:
[INFO]   plugin1
[INFO]   extjar2
[INFO]
[INFO] On Thread Context Class Loader:
[INFO]   plugin1
[INFO]   extjar2
[INFO]
[INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe4 ---
[INFO] Injected by @Component:
[INFO]   plugin2
[INFO]
[INFO] On Plugin Class Loader:
[INFO]   plugin2
[INFO]
[INFO] On Thread Context Class Loader:
[INFO]   plugin2
[INFO]


Now if we run 

Re: [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

On Sat 16 Sep 2017 at 10:51, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Sat 16 Sep 2017 at 04:07, Igor Fedorenko  wrote:
>
>> I don't really have much to add, but let me answer anyways :-)
>>
>> 1) I am reasonably confident we can compensate for the new classloader
>> arrangement in m2e without much problems. The new setup does make plugin
>> runtime classpath less stable, so there are likely other scenarios where
>> plugins will behave differently (bad). On the other hand, I don't see
>> any better way to support ServiceLoader. For java 8 it may be possible
>> to use foreign-import of extensions classloader to fix MNG-6275, but
>> that classloader was removed in java 9, unless I am mistaken.
>
>
> Ok so I think the consensus is 6275 is probably a necessary fix for Java 8
> interoperability, but may expose bugs in plugins that made incorrect
> assumptions, and is a breaking change from the PoV of the eclipse
> integration. Netbeans is fine and IntelliJ seems to do its own think (given
> I have an open bug that suggests IntelliJ is ignorant of the extensions
> type mapping)
>
>
>>
>> 2) I believe TCCL is already set to project realm for projects that have
>> extensions (and to plugin realm otherwise) during plugin execution.
>
>
> So my question is why should TCCL *ever* be anything other than project
> realm?
>
> The pom reference says:
>
>- *extensions*: true or false, whether or not to load extensions of
>this plugin. It is by default false. Extensions are covered later in this
>document.
>
> It does not say that this flag affects the classloader of the plugin,
> rather to me says when true the project realm shall include the plugin's
> extensions.
>
> My understanding was that a plugin would always see its own extensions,
> but if you set this flag then the project would be able to see them too...
>
> Now granted my understanding may be incorrect, but this change seems to be
> turning things in an entirely different direction
>

Ok discussed this on #maven-dev

I need to confirm my analysis, but if correct, then the fix for MNG-6209 is
correct... will need careful release noting

>
> Problem is, neither project realm nor any of the plugin realms have
>> access to jvm extensions classloader, so ServiceLoader can't get classes
>> from there.
>
>
> That is another set of issues... but this should have been fixed by 6275
> unless I am mistaken
>
>
>>
>> --
>> Regards,
>> Igor
>>
>> On Fri, Sep 15, 2017, at 12:09 PM, Stephen Connolly wrote:
>> > I'm going to hold off closing the vote over the weekend to give Igor a
>> > chance to:
>> >
>> > 1. comment on whether we need an alternative fix for MNG-6275 (and
>> indeed
>> > ideally provide one ;- );
>> > 2. comment on whether the fix for MNG-6209 is exposing bugs in plugins
>> > that
>> > made incorrect assumptions about TCCL, or whether the fix is invalid or
>> > even incomplete (I wonder if TCCL should always be
>> > project.getClassRealm()
>> > as extensions should be available to all plugins not just those that
>> > declare they are providing extensions - unless I misunderstand)
>> >
>> > Once I have the required information I will be better able to assess
>> > whether we should release 3.5.1 and follow up with a quick 3.5.2 or just
>> > drop 3.5.1 and go straight to 3.5.2.
>> >
>> > -Stephen
>> >
>> > On 15 September 2017 at 05:45, Igor Fedorenko 
>> > wrote:
>> >
>> > > Has anyone tried wiring jvm extensions ClassLoader as foreign import
>> to
>> > > plugin/extensions realms? Jvm extensions classloader is little tricky
>> to
>> > > get to (see how this is done in
>> java.util.ServiceLoader.loadInstalled),
>> > > but I think this will solve ServiceLoader/MNG-6275 without polluting
>> > > plugin classpath too much.
>> > >
>> > > --
>> > > Regards,
>> > > Igor
>> > >
>> > > On Fri, Sep 15, 2017, at 08:32 AM, Mark Derricutt wrote:
>> > > > Would it be possible to handle this in a somewhat similar way to
>> > > > threadSafe
>> > > > mojos - some form of plugin flag that says "extensionSafe" [1],
>> that if
>> > > > the
>> > > > plugin has true declared and doesn't
>> declare
>> > > > itself as being extensionSafe/extensionAware then we log a build
>> warning
>> > > > -
>> > > > it wouldn't solve anything, other than giving some feedback to
>> users some
>> > > > indication of WHY their build fails under 3.5.1 - and to either
>> remove
>> > > >  or fix/update their plugins.
>> > > >
>> > > > [1] Or even just infer the applicability of extensions by the
>> presence of
>> > > > custom lifecycles, or Mojos implementing the extension interfaces (
>> it's
>> > > > midnight, and a hazy tired thought ).
>> > > >
>> > > > --
>> > > > "Great artists are extremely selfish and arrogant things" — Steven
>> > > > Wilson,
>> > > > Porcupine Tree
>> > > >
>> > > > On Sat, Sep 16, 2017 at 12:22 AM, Anders Hammar 
>> > > > wrote:
>> > > >
>> > > > > Based on Igor's feedback I'm 

Re: [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

On Sat 16 Sep 2017 at 04:07, Igor Fedorenko  wrote:

> I don't really have much to add, but let me answer anyways :-)
>
> 1) I am reasonably confident we can compensate for the new classloader
> arrangement in m2e without much problems. The new setup does make plugin
> runtime classpath less stable, so there are likely other scenarios where
> plugins will behave differently (bad). On the other hand, I don't see
> any better way to support ServiceLoader. For java 8 it may be possible
> to use foreign-import of extensions classloader to fix MNG-6275, but
> that classloader was removed in java 9, unless I am mistaken.


Ok so I think the consensus is 6275 is probably a necessary fix for Java 8
interoperability, but may expose bugs in plugins that made incorrect
assumptions, and is a breaking change from the PoV of the eclipse
integration. Netbeans is fine and IntelliJ seems to do its own think (given
I have an open bug that suggests IntelliJ is ignorant of the extensions
type mapping)


>
> 2) I believe TCCL is already set to project realm for projects that have
> extensions (and to plugin realm otherwise) during plugin execution.


So my question is why should TCCL *ever* be anything other than project
realm?

The pom reference says:

   - *extensions*: true or false, whether or not to load extensions of this
   plugin. It is by default false. Extensions are covered later in this
   document.

It does not say that this flag affects the classloader of the plugin,
rather to me says when true the project realm shall include the plugin's
extensions.

My understanding was that a plugin would always see its own extensions, but
if you set this flag then the project would be able to see them too...

Now granted my understanding may be incorrect, but this change seems to be
turning things in an entirely different direction

Problem is, neither project realm nor any of the plugin realms have
> access to jvm extensions classloader, so ServiceLoader can't get classes
> from there.


That is another set of issues... but this should have been fixed by 6275
unless I am mistaken


>
> --
> Regards,
> Igor
>
> On Fri, Sep 15, 2017, at 12:09 PM, Stephen Connolly wrote:
> > I'm going to hold off closing the vote over the weekend to give Igor a
> > chance to:
> >
> > 1. comment on whether we need an alternative fix for MNG-6275 (and indeed
> > ideally provide one ;- );
> > 2. comment on whether the fix for MNG-6209 is exposing bugs in plugins
> > that
> > made incorrect assumptions about TCCL, or whether the fix is invalid or
> > even incomplete (I wonder if TCCL should always be
> > project.getClassRealm()
> > as extensions should be available to all plugins not just those that
> > declare they are providing extensions - unless I misunderstand)
> >
> > Once I have the required information I will be better able to assess
> > whether we should release 3.5.1 and follow up with a quick 3.5.2 or just
> > drop 3.5.1 and go straight to 3.5.2.
> >
> > -Stephen
> >
> > On 15 September 2017 at 05:45, Igor Fedorenko 
> > wrote:
> >
> > > Has anyone tried wiring jvm extensions ClassLoader as foreign import to
> > > plugin/extensions realms? Jvm extensions classloader is little tricky
> to
> > > get to (see how this is done in java.util.ServiceLoader.loadInstalled),
> > > but I think this will solve ServiceLoader/MNG-6275 without polluting
> > > plugin classpath too much.
> > >
> > > --
> > > Regards,
> > > Igor
> > >
> > > On Fri, Sep 15, 2017, at 08:32 AM, Mark Derricutt wrote:
> > > > Would it be possible to handle this in a somewhat similar way to
> > > > threadSafe
> > > > mojos - some form of plugin flag that says "extensionSafe" [1], that
> if
> > > > the
> > > > plugin has true declared and doesn't declare
> > > > itself as being extensionSafe/extensionAware then we log a build
> warning
> > > > -
> > > > it wouldn't solve anything, other than giving some feedback to users
> some
> > > > indication of WHY their build fails under 3.5.1 - and to either
> remove
> > > >  or fix/update their plugins.
> > > >
> > > > [1] Or even just infer the applicability of extensions by the
> presence of
> > > > custom lifecycles, or Mojos implementing the extension interfaces (
> it's
> > > > midnight, and a hazy tired thought ).
> > > >
> > > > --
> > > > "Great artists are extremely selfish and arrogant things" — Steven
> > > > Wilson,
> > > > Porcupine Tree
> > > >
> > > > On Sat, Sep 16, 2017 at 12:22 AM, Anders Hammar 
> > > > wrote:
> > > >
> > > > > Based on Igor's feedback I'm changing my vote to +1.
> > > > >
> > > > > Having this class loader change in a bug fix release is probably
> not
> > > > > (semver) ideal though.
> > > > >
> > > > > /Anders
> > > > >
> > > > > On Fri, Sep 15, 2017 at 2:12 PM, Igor Fedorenko <
> i...@ifedorenko.com>
> > > > > wrote:
> > > > >
> > > > > > I answered in more details on m2e-dev, but I believe we can
> > > compensate
> > > > > > for the 

Re: [VOTE] Release Apache Maven 3.5.1

[Igor Fedorenko]

I don't really have much to add, but let me answer anyways :-)

1) I am reasonably confident we can compensate for the new classloader
arrangement in m2e without much problems. The new setup does make plugin
runtime classpath less stable, so there are likely other scenarios where
plugins will behave differently (bad). On the other hand, I don't see
any better way to support ServiceLoader. For java 8 it may be possible
to use foreign-import of extensions classloader to fix MNG-6275, but
that classloader was removed in java 9, unless I am mistaken.

2) I believe TCCL is already set to project realm for projects that have
extensions (and to plugin realm otherwise) during plugin execution.
Problem is, neither project realm nor any of the plugin realms have
access to jvm extensions classloader, so ServiceLoader can't get classes
from there. 

-- 
Regards,
Igor

On Fri, Sep 15, 2017, at 12:09 PM, Stephen Connolly wrote:
> I'm going to hold off closing the vote over the weekend to give Igor a
> chance to:
> 
> 1. comment on whether we need an alternative fix for MNG-6275 (and indeed
> ideally provide one ;- );
> 2. comment on whether the fix for MNG-6209 is exposing bugs in plugins
> that
> made incorrect assumptions about TCCL, or whether the fix is invalid or
> even incomplete (I wonder if TCCL should always be
> project.getClassRealm()
> as extensions should be available to all plugins not just those that
> declare they are providing extensions - unless I misunderstand)
> 
> Once I have the required information I will be better able to assess
> whether we should release 3.5.1 and follow up with a quick 3.5.2 or just
> drop 3.5.1 and go straight to 3.5.2.
> 
> -Stephen
> 
> On 15 September 2017 at 05:45, Igor Fedorenko 
> wrote:
> 
> > Has anyone tried wiring jvm extensions ClassLoader as foreign import to
> > plugin/extensions realms? Jvm extensions classloader is little tricky to
> > get to (see how this is done in java.util.ServiceLoader.loadInstalled),
> > but I think this will solve ServiceLoader/MNG-6275 without polluting
> > plugin classpath too much.
> >
> > --
> > Regards,
> > Igor
> >
> > On Fri, Sep 15, 2017, at 08:32 AM, Mark Derricutt wrote:
> > > Would it be possible to handle this in a somewhat similar way to
> > > threadSafe
> > > mojos - some form of plugin flag that says "extensionSafe" [1], that if
> > > the
> > > plugin has true declared and doesn't declare
> > > itself as being extensionSafe/extensionAware then we log a build warning
> > > -
> > > it wouldn't solve anything, other than giving some feedback to users some
> > > indication of WHY their build fails under 3.5.1 - and to either remove
> > >  or fix/update their plugins.
> > >
> > > [1] Or even just infer the applicability of extensions by the presence of
> > > custom lifecycles, or Mojos implementing the extension interfaces ( it's
> > > midnight, and a hazy tired thought ).
> > >
> > > --
> > > "Great artists are extremely selfish and arrogant things" — Steven
> > > Wilson,
> > > Porcupine Tree
> > >
> > > On Sat, Sep 16, 2017 at 12:22 AM, Anders Hammar 
> > > wrote:
> > >
> > > > Based on Igor's feedback I'm changing my vote to +1.
> > > >
> > > > Having this class loader change in a bug fix release is probably not
> > > > (semver) ideal though.
> > > >
> > > > /Anders
> > > >
> > > > On Fri, Sep 15, 2017 at 2:12 PM, Igor Fedorenko 
> > > > wrote:
> > > >
> > > > > I answered in more details on m2e-dev, but I believe we can
> > compensate
> > > > > for the change from m2e end. In the worst case we'll bundle hacked
> > > > > version of DefaultClassRealmManager with m2e, not ideal, but not the
> > end
> > > > > of the world either.
> > > > >
> > > > > --
> > > > > Regards,
> > > > > Igor
> > > > >
> > > > > On Fri, Sep 15, 2017, at 07:21 AM, Anders Hammar wrote:
> > > > > > On Fri, Sep 15, 2017 at 8:29 AM, Anders Hammar 
> > > > > wrote:
> > > > > >
> > > > > > > Reporting back from tests of m2e with embedded Maven 3.5.1, we
> > see
> > > > > problem
> > > > > > > with the jaxws-maven-plugin mojo. We're two people seeing the
> > issue
> > > > > > > independently, but unfortunately Fred Bricon hasn't been able to
> > > > > reproduce.
> > > > > > >
> > > > > >
> > > > > > To follow up on this, my tests indicate that Maven 3.5.1 causes
> > changed
> > > > > > class loading that could cause issues for plugins in m2e. I've
> > asked
> > > > for
> > > > > > input from the m2e devs if it is possible to handle in m2e but they
> > > > > > haven't
> > > > > > responded yet.
> > > > > >
> > > > > > /Anders
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > So currently I'm 0 on the voting but I'll investigate some more.
> > > > > > >
> > > > > > > /Anders
> > > > > > >
> > > > > > > On Wed, Sep 13, 2017 at 9:26 AM, Anders Hammar <
> > and...@hammar.net>
> > > > > wrote:
> > > > > > >
> > > > > > >>
> > > > > > >>
> > > > > > >> On Tue, Sep 12, 2017 at 8:54 PM, 

Re: [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

I'm going to hold off closing the vote over the weekend to give Igor a
chance to:

1. comment on whether we need an alternative fix for MNG-6275 (and indeed
ideally provide one ;- );
2. comment on whether the fix for MNG-6209 is exposing bugs in plugins that
made incorrect assumptions about TCCL, or whether the fix is invalid or
even incomplete (I wonder if TCCL should always be project.getClassRealm()
as extensions should be available to all plugins not just those that
declare they are providing extensions - unless I misunderstand)

Once I have the required information I will be better able to assess
whether we should release 3.5.1 and follow up with a quick 3.5.2 or just
drop 3.5.1 and go straight to 3.5.2.

-Stephen

On 15 September 2017 at 05:45, Igor Fedorenko  wrote:

> Has anyone tried wiring jvm extensions ClassLoader as foreign import to
> plugin/extensions realms? Jvm extensions classloader is little tricky to
> get to (see how this is done in java.util.ServiceLoader.loadInstalled),
> but I think this will solve ServiceLoader/MNG-6275 without polluting
> plugin classpath too much.
>
> --
> Regards,
> Igor
>
> On Fri, Sep 15, 2017, at 08:32 AM, Mark Derricutt wrote:
> > Would it be possible to handle this in a somewhat similar way to
> > threadSafe
> > mojos - some form of plugin flag that says "extensionSafe" [1], that if
> > the
> > plugin has true declared and doesn't declare
> > itself as being extensionSafe/extensionAware then we log a build warning
> > -
> > it wouldn't solve anything, other than giving some feedback to users some
> > indication of WHY their build fails under 3.5.1 - and to either remove
> >  or fix/update their plugins.
> >
> > [1] Or even just infer the applicability of extensions by the presence of
> > custom lifecycles, or Mojos implementing the extension interfaces ( it's
> > midnight, and a hazy tired thought ).
> >
> > --
> > "Great artists are extremely selfish and arrogant things" — Steven
> > Wilson,
> > Porcupine Tree
> >
> > On Sat, Sep 16, 2017 at 12:22 AM, Anders Hammar 
> > wrote:
> >
> > > Based on Igor's feedback I'm changing my vote to +1.
> > >
> > > Having this class loader change in a bug fix release is probably not
> > > (semver) ideal though.
> > >
> > > /Anders
> > >
> > > On Fri, Sep 15, 2017 at 2:12 PM, Igor Fedorenko 
> > > wrote:
> > >
> > > > I answered in more details on m2e-dev, but I believe we can
> compensate
> > > > for the change from m2e end. In the worst case we'll bundle hacked
> > > > version of DefaultClassRealmManager with m2e, not ideal, but not the
> end
> > > > of the world either.
> > > >
> > > > --
> > > > Regards,
> > > > Igor
> > > >
> > > > On Fri, Sep 15, 2017, at 07:21 AM, Anders Hammar wrote:
> > > > > On Fri, Sep 15, 2017 at 8:29 AM, Anders Hammar 
> > > > wrote:
> > > > >
> > > > > > Reporting back from tests of m2e with embedded Maven 3.5.1, we
> see
> > > > problem
> > > > > > with the jaxws-maven-plugin mojo. We're two people seeing the
> issue
> > > > > > independently, but unfortunately Fred Bricon hasn't been able to
> > > > reproduce.
> > > > > >
> > > > >
> > > > > To follow up on this, my tests indicate that Maven 3.5.1 causes
> changed
> > > > > class loading that could cause issues for plugins in m2e. I've
> asked
> > > for
> > > > > input from the m2e devs if it is possible to handle in m2e but they
> > > > > haven't
> > > > > responded yet.
> > > > >
> > > > > /Anders
> > > > >
> > > > >
> > > > > >
> > > > > > So currently I'm 0 on the voting but I'll investigate some more.
> > > > > >
> > > > > > /Anders
> > > > > >
> > > > > > On Wed, Sep 13, 2017 at 9:26 AM, Anders Hammar <
> and...@hammar.net>
> > > > wrote:
> > > > > >
> > > > > >>
> > > > > >>
> > > > > >> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> > > > > >> stephen.alan.conno...@gmail.com> wrote:
> > > > > >>
> > > > > >>> Have we got any feedback from the embedder integrations yet?
> > > > > >>>
> > > > > >>
> > > > > >> I haven't heard anything from the m2e people. Maybe we need to
> ping
> > > > them
> > > > > >> directly. I can contact Fred Bricon.
> > > > > >>
> > > > > >> /Anders
> > > > > >>
> > > > > >>
> > > > > >>>
> > > > > >>> On Mon 11 Sep 2017 at 22:57, Hervé BOUTEMY <
> herve.bout...@free.fr>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>> > just for the records: it is Windows + Git Bash (MINGW64) only
> > > > > >>> >
> > > > > >>> > and there is a chance that adding -Djansi.force=true can
> force
> > > > JAnsi
> > > > > >>> > activation (even if JAnsi fails to detect that it should
> > > > auto-activate)
> > > > > >>> >
> > > > > >>> > details on issue in https://issues.apache.org/
> > > jira/browse/MNG-6282
> > > > ,
> > > > > >>> and a
> > > > > >>> > future JAnsi issue...
> > > > > >>> >
> > > > > >>> > Regards,
> > > > > >>> >
> > > > > >>> > Hervé
> > > > > >>> >
> > > > > >>> > Le lundi 11 septembre 2017, 12:53:46 CEST Stephen Connolly 

Re: [VOTE] Release Apache Maven 3.5.1

[Igor Fedorenko]

Has anyone tried wiring jvm extensions ClassLoader as foreign import to
plugin/extensions realms? Jvm extensions classloader is little tricky to
get to (see how this is done in java.util.ServiceLoader.loadInstalled),
but I think this will solve ServiceLoader/MNG-6275 without polluting
plugin classpath too much.

-- 
Regards,
Igor

On Fri, Sep 15, 2017, at 08:32 AM, Mark Derricutt wrote:
> Would it be possible to handle this in a somewhat similar way to
> threadSafe
> mojos - some form of plugin flag that says "extensionSafe" [1], that if
> the
> plugin has true declared and doesn't declare
> itself as being extensionSafe/extensionAware then we log a build warning
> -
> it wouldn't solve anything, other than giving some feedback to users some
> indication of WHY their build fails under 3.5.1 - and to either remove
>  or fix/update their plugins.
> 
> [1] Or even just infer the applicability of extensions by the presence of
> custom lifecycles, or Mojos implementing the extension interfaces ( it's
> midnight, and a hazy tired thought ).
> 
> -- 
> "Great artists are extremely selfish and arrogant things" — Steven
> Wilson,
> Porcupine Tree
> 
> On Sat, Sep 16, 2017 at 12:22 AM, Anders Hammar 
> wrote:
> 
> > Based on Igor's feedback I'm changing my vote to +1.
> >
> > Having this class loader change in a bug fix release is probably not
> > (semver) ideal though.
> >
> > /Anders
> >
> > On Fri, Sep 15, 2017 at 2:12 PM, Igor Fedorenko 
> > wrote:
> >
> > > I answered in more details on m2e-dev, but I believe we can compensate
> > > for the change from m2e end. In the worst case we'll bundle hacked
> > > version of DefaultClassRealmManager with m2e, not ideal, but not the end
> > > of the world either.
> > >
> > > --
> > > Regards,
> > > Igor
> > >
> > > On Fri, Sep 15, 2017, at 07:21 AM, Anders Hammar wrote:
> > > > On Fri, Sep 15, 2017 at 8:29 AM, Anders Hammar 
> > > wrote:
> > > >
> > > > > Reporting back from tests of m2e with embedded Maven 3.5.1, we see
> > > problem
> > > > > with the jaxws-maven-plugin mojo. We're two people seeing the issue
> > > > > independently, but unfortunately Fred Bricon hasn't been able to
> > > reproduce.
> > > > >
> > > >
> > > > To follow up on this, my tests indicate that Maven 3.5.1 causes changed
> > > > class loading that could cause issues for plugins in m2e. I've asked
> > for
> > > > input from the m2e devs if it is possible to handle in m2e but they
> > > > haven't
> > > > responded yet.
> > > >
> > > > /Anders
> > > >
> > > >
> > > > >
> > > > > So currently I'm 0 on the voting but I'll investigate some more.
> > > > >
> > > > > /Anders
> > > > >
> > > > > On Wed, Sep 13, 2017 at 9:26 AM, Anders Hammar 
> > > wrote:
> > > > >
> > > > >>
> > > > >>
> > > > >> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> > > > >> stephen.alan.conno...@gmail.com> wrote:
> > > > >>
> > > > >>> Have we got any feedback from the embedder integrations yet?
> > > > >>>
> > > > >>
> > > > >> I haven't heard anything from the m2e people. Maybe we need to ping
> > > them
> > > > >> directly. I can contact Fred Bricon.
> > > > >>
> > > > >> /Anders
> > > > >>
> > > > >>
> > > > >>>
> > > > >>> On Mon 11 Sep 2017 at 22:57, Hervé BOUTEMY 
> > > > >>> wrote:
> > > > >>>
> > > > >>> > just for the records: it is Windows + Git Bash (MINGW64) only
> > > > >>> >
> > > > >>> > and there is a chance that adding -Djansi.force=true can force
> > > JAnsi
> > > > >>> > activation (even if JAnsi fails to detect that it should
> > > auto-activate)
> > > > >>> >
> > > > >>> > details on issue in https://issues.apache.org/
> > jira/browse/MNG-6282
> > > ,
> > > > >>> and a
> > > > >>> > future JAnsi issue...
> > > > >>> >
> > > > >>> > Regards,
> > > > >>> >
> > > > >>> > Hervé
> > > > >>> >
> > > > >>> > Le lundi 11 septembre 2017, 12:53:46 CEST Stephen Connolly a
> > écrit
> > > :
> > > > >>> > > So that is windows only, or were they lost on other OSes for
> > you.
> > > > >>> > >
> > > > >>> > > I have colours on linux (via docker) and os-x
> > > > >>> > >
> > > > >>> > > On 11 September 2017 at 12:35, dejan2...@gmail.com <
> > > > >>> dejan2...@gmail.com>
> > > > >>> > >
> > > > >>> > > wrote:
> > > > >>> > > > +1 (conditionally).
> > > > >>> > > >
> > > > >>> > > > Tested via project that includes dozen of plugins: 1st tier,
> > > > >>> MojoHaus
> > > > >>> > and
> > > > >>> > > > few 3rd party plugins (so to say).
> > > > >>> > > >
> > > > >>> > > > Everything looks good with one notable regression:
> > > > >>> > > > https://issues.apache.org/jira/browse/MNG-6282 Console
> > output
> > > has
> > > > >>> no
> > > > >>> > > > colors (regression in Maven 3.5.1)
> > > > >>> > > >
> > > > >>> > > > Regards,
> > > > >>> > > > Dejan
> > > > >>> > > >
> > > > >>> > > > On 2017-09-10 17:39, Stephen Connolly <
> > > > >>> stephen.alan.conno...@gmail.com
> > > > >>> > >
> > > > >>> > > >
> > > > >>> > > > 

Re: [VOTE] Release Apache Maven 3.5.1

[Mark Derricutt]

Would it be possible to handle this in a somewhat similar way to threadSafe
mojos - some form of plugin flag that says "extensionSafe" [1], that if the
plugin has true declared and doesn't declare
itself as being extensionSafe/extensionAware then we log a build warning -
it wouldn't solve anything, other than giving some feedback to users some
indication of WHY their build fails under 3.5.1 - and to either remove
 or fix/update their plugins.

[1] Or even just infer the applicability of extensions by the presence of
custom lifecycles, or Mojos implementing the extension interfaces ( it's
midnight, and a hazy tired thought ).

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

On Sat, Sep 16, 2017 at 12:22 AM, Anders Hammar  wrote:

> Based on Igor's feedback I'm changing my vote to +1.
>
> Having this class loader change in a bug fix release is probably not
> (semver) ideal though.
>
> /Anders
>
> On Fri, Sep 15, 2017 at 2:12 PM, Igor Fedorenko 
> wrote:
>
> > I answered in more details on m2e-dev, but I believe we can compensate
> > for the change from m2e end. In the worst case we'll bundle hacked
> > version of DefaultClassRealmManager with m2e, not ideal, but not the end
> > of the world either.
> >
> > --
> > Regards,
> > Igor
> >
> > On Fri, Sep 15, 2017, at 07:21 AM, Anders Hammar wrote:
> > > On Fri, Sep 15, 2017 at 8:29 AM, Anders Hammar 
> > wrote:
> > >
> > > > Reporting back from tests of m2e with embedded Maven 3.5.1, we see
> > problem
> > > > with the jaxws-maven-plugin mojo. We're two people seeing the issue
> > > > independently, but unfortunately Fred Bricon hasn't been able to
> > reproduce.
> > > >
> > >
> > > To follow up on this, my tests indicate that Maven 3.5.1 causes changed
> > > class loading that could cause issues for plugins in m2e. I've asked
> for
> > > input from the m2e devs if it is possible to handle in m2e but they
> > > haven't
> > > responded yet.
> > >
> > > /Anders
> > >
> > >
> > > >
> > > > So currently I'm 0 on the voting but I'll investigate some more.
> > > >
> > > > /Anders
> > > >
> > > > On Wed, Sep 13, 2017 at 9:26 AM, Anders Hammar 
> > wrote:
> > > >
> > > >>
> > > >>
> > > >> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> > > >> stephen.alan.conno...@gmail.com> wrote:
> > > >>
> > > >>> Have we got any feedback from the embedder integrations yet?
> > > >>>
> > > >>
> > > >> I haven't heard anything from the m2e people. Maybe we need to ping
> > them
> > > >> directly. I can contact Fred Bricon.
> > > >>
> > > >> /Anders
> > > >>
> > > >>
> > > >>>
> > > >>> On Mon 11 Sep 2017 at 22:57, Hervé BOUTEMY 
> > > >>> wrote:
> > > >>>
> > > >>> > just for the records: it is Windows + Git Bash (MINGW64) only
> > > >>> >
> > > >>> > and there is a chance that adding -Djansi.force=true can force
> > JAnsi
> > > >>> > activation (even if JAnsi fails to detect that it should
> > auto-activate)
> > > >>> >
> > > >>> > details on issue in https://issues.apache.org/
> jira/browse/MNG-6282
> > ,
> > > >>> and a
> > > >>> > future JAnsi issue...
> > > >>> >
> > > >>> > Regards,
> > > >>> >
> > > >>> > Hervé
> > > >>> >
> > > >>> > Le lundi 11 septembre 2017, 12:53:46 CEST Stephen Connolly a
> écrit
> > :
> > > >>> > > So that is windows only, or were they lost on other OSes for
> you.
> > > >>> > >
> > > >>> > > I have colours on linux (via docker) and os-x
> > > >>> > >
> > > >>> > > On 11 September 2017 at 12:35, dejan2...@gmail.com <
> > > >>> dejan2...@gmail.com>
> > > >>> > >
> > > >>> > > wrote:
> > > >>> > > > +1 (conditionally).
> > > >>> > > >
> > > >>> > > > Tested via project that includes dozen of plugins: 1st tier,
> > > >>> MojoHaus
> > > >>> > and
> > > >>> > > > few 3rd party plugins (so to say).
> > > >>> > > >
> > > >>> > > > Everything looks good with one notable regression:
> > > >>> > > > https://issues.apache.org/jira/browse/MNG-6282 Console
> output
> > has
> > > >>> no
> > > >>> > > > colors (regression in Maven 3.5.1)
> > > >>> > > >
> > > >>> > > > Regards,
> > > >>> > > > Dejan
> > > >>> > > >
> > > >>> > > > On 2017-09-10 17:39, Stephen Connolly <
> > > >>> stephen.alan.conno...@gmail.com
> > > >>> > >
> > > >>> > > >
> > > >>> > > > wrote:
> > > >>> > > > > Hi,
> > > >>> > > > >
> > > >>> > > > > We solved 25 issues:
> > > >>> > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > >>> > > >
> > > >>> > > > version=12338964=Text=12316922
> > > >>> > > >
> > > >>> > > > > There are 350 issues left in JIRA for Maven core:
> > > >>> > > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > >>> > > >
> > > >>> > > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > > >>> > > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > > >>> > > >
> > > >>> > > > > Staging repo:
> > > >>> > > > > https://repository.apache.org/content/repositories/maven-
> > 

Re: [VOTE] Release Apache Maven 3.5.1

[Anders Hammar]

Based on Igor's feedback I'm changing my vote to +1.

Having this class loader change in a bug fix release is probably not
(semver) ideal though.

/Anders

On Fri, Sep 15, 2017 at 2:12 PM, Igor Fedorenko  wrote:

> I answered in more details on m2e-dev, but I believe we can compensate
> for the change from m2e end. In the worst case we'll bundle hacked
> version of DefaultClassRealmManager with m2e, not ideal, but not the end
> of the world either.
>
> --
> Regards,
> Igor
>
> On Fri, Sep 15, 2017, at 07:21 AM, Anders Hammar wrote:
> > On Fri, Sep 15, 2017 at 8:29 AM, Anders Hammar 
> wrote:
> >
> > > Reporting back from tests of m2e with embedded Maven 3.5.1, we see
> problem
> > > with the jaxws-maven-plugin mojo. We're two people seeing the issue
> > > independently, but unfortunately Fred Bricon hasn't been able to
> reproduce.
> > >
> >
> > To follow up on this, my tests indicate that Maven 3.5.1 causes changed
> > class loading that could cause issues for plugins in m2e. I've asked for
> > input from the m2e devs if it is possible to handle in m2e but they
> > haven't
> > responded yet.
> >
> > /Anders
> >
> >
> > >
> > > So currently I'm 0 on the voting but I'll investigate some more.
> > >
> > > /Anders
> > >
> > > On Wed, Sep 13, 2017 at 9:26 AM, Anders Hammar 
> wrote:
> > >
> > >>
> > >>
> > >> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> > >> stephen.alan.conno...@gmail.com> wrote:
> > >>
> > >>> Have we got any feedback from the embedder integrations yet?
> > >>>
> > >>
> > >> I haven't heard anything from the m2e people. Maybe we need to ping
> them
> > >> directly. I can contact Fred Bricon.
> > >>
> > >> /Anders
> > >>
> > >>
> > >>>
> > >>> On Mon 11 Sep 2017 at 22:57, Hervé BOUTEMY 
> > >>> wrote:
> > >>>
> > >>> > just for the records: it is Windows + Git Bash (MINGW64) only
> > >>> >
> > >>> > and there is a chance that adding -Djansi.force=true can force
> JAnsi
> > >>> > activation (even if JAnsi fails to detect that it should
> auto-activate)
> > >>> >
> > >>> > details on issue in https://issues.apache.org/jira/browse/MNG-6282
> ,
> > >>> and a
> > >>> > future JAnsi issue...
> > >>> >
> > >>> > Regards,
> > >>> >
> > >>> > Hervé
> > >>> >
> > >>> > Le lundi 11 septembre 2017, 12:53:46 CEST Stephen Connolly a écrit
> :
> > >>> > > So that is windows only, or were they lost on other OSes for you.
> > >>> > >
> > >>> > > I have colours on linux (via docker) and os-x
> > >>> > >
> > >>> > > On 11 September 2017 at 12:35, dejan2...@gmail.com <
> > >>> dejan2...@gmail.com>
> > >>> > >
> > >>> > > wrote:
> > >>> > > > +1 (conditionally).
> > >>> > > >
> > >>> > > > Tested via project that includes dozen of plugins: 1st tier,
> > >>> MojoHaus
> > >>> > and
> > >>> > > > few 3rd party plugins (so to say).
> > >>> > > >
> > >>> > > > Everything looks good with one notable regression:
> > >>> > > > https://issues.apache.org/jira/browse/MNG-6282 Console output
> has
> > >>> no
> > >>> > > > colors (regression in Maven 3.5.1)
> > >>> > > >
> > >>> > > > Regards,
> > >>> > > > Dejan
> > >>> > > >
> > >>> > > > On 2017-09-10 17:39, Stephen Connolly <
> > >>> stephen.alan.conno...@gmail.com
> > >>> > >
> > >>> > > >
> > >>> > > > wrote:
> > >>> > > > > Hi,
> > >>> > > > >
> > >>> > > > > We solved 25 issues:
> > >>> > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > >>> > > >
> > >>> > > > version=12338964=Text=12316922
> > >>> > > >
> > >>> > > > > There are 350 issues left in JIRA for Maven core:
> > >>> > > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > >>> > > >
> > >>> > > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > >>> > > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > >>> > > >
> > >>> > > > > Staging repo:
> > >>> > > > > https://repository.apache.org/content/repositories/maven-
> 1364/
> > >>> > > > >
> > >>> > > > > The distributable binaries and sources can be found here:
> > >>> > > > > https://repository.apache.org/content/repositories/maven-> >
> > >>> > > > 1364/org/apache/maven/apache-maven/3.5.1/
> > >>> > > >
> > >>> > > > > Specifically the zip, tarball and source archives can be
> found
> > >>> here:
> > >>> > > > > https://repository.apache.org/content/repositories/maven-> >
> > >>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
> > >>> bin.zip
> > >>> > > >
> > >>> > > > > https://repository.apache.org/content/repositories/maven-> >
> > >>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
> > >>> bin.tar.gz
> > >>> > > >
> > >>> > > > > https://repository.apache.org/content/repositories/maven-> >
> > >>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
> > >>> src.zip
> > >>> > > >
> > >>> > > > > https://repository.apache.org/content/repositories/maven-> >
> > >>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
> > >>> src.tar.gz
> > >>> > > >
> 

Re: [VOTE] Release Apache Maven 3.5.1

[Igor Fedorenko]

I answered in more details on m2e-dev, but I believe we can compensate
for the change from m2e end. In the worst case we'll bundle hacked
version of DefaultClassRealmManager with m2e, not ideal, but not the end
of the world either. 

-- 
Regards,
Igor

On Fri, Sep 15, 2017, at 07:21 AM, Anders Hammar wrote:
> On Fri, Sep 15, 2017 at 8:29 AM, Anders Hammar  wrote:
> 
> > Reporting back from tests of m2e with embedded Maven 3.5.1, we see problem
> > with the jaxws-maven-plugin mojo. We're two people seeing the issue
> > independently, but unfortunately Fred Bricon hasn't been able to reproduce.
> >
> 
> To follow up on this, my tests indicate that Maven 3.5.1 causes changed
> class loading that could cause issues for plugins in m2e. I've asked for
> input from the m2e devs if it is possible to handle in m2e but they
> haven't
> responded yet.
> 
> /Anders
> 
> 
> >
> > So currently I'm 0 on the voting but I'll investigate some more.
> >
> > /Anders
> >
> > On Wed, Sep 13, 2017 at 9:26 AM, Anders Hammar  wrote:
> >
> >>
> >>
> >> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> >> stephen.alan.conno...@gmail.com> wrote:
> >>
> >>> Have we got any feedback from the embedder integrations yet?
> >>>
> >>
> >> I haven't heard anything from the m2e people. Maybe we need to ping them
> >> directly. I can contact Fred Bricon.
> >>
> >> /Anders
> >>
> >>
> >>>
> >>> On Mon 11 Sep 2017 at 22:57, Hervé BOUTEMY 
> >>> wrote:
> >>>
> >>> > just for the records: it is Windows + Git Bash (MINGW64) only
> >>> >
> >>> > and there is a chance that adding -Djansi.force=true can force JAnsi
> >>> > activation (even if JAnsi fails to detect that it should auto-activate)
> >>> >
> >>> > details on issue in https://issues.apache.org/jira/browse/MNG-6282 ,
> >>> and a
> >>> > future JAnsi issue...
> >>> >
> >>> > Regards,
> >>> >
> >>> > Hervé
> >>> >
> >>> > Le lundi 11 septembre 2017, 12:53:46 CEST Stephen Connolly a écrit :
> >>> > > So that is windows only, or were they lost on other OSes for you.
> >>> > >
> >>> > > I have colours on linux (via docker) and os-x
> >>> > >
> >>> > > On 11 September 2017 at 12:35, dejan2...@gmail.com <
> >>> dejan2...@gmail.com>
> >>> > >
> >>> > > wrote:
> >>> > > > +1 (conditionally).
> >>> > > >
> >>> > > > Tested via project that includes dozen of plugins: 1st tier,
> >>> MojoHaus
> >>> > and
> >>> > > > few 3rd party plugins (so to say).
> >>> > > >
> >>> > > > Everything looks good with one notable regression:
> >>> > > > https://issues.apache.org/jira/browse/MNG-6282 Console output has
> >>> no
> >>> > > > colors (regression in Maven 3.5.1)
> >>> > > >
> >>> > > > Regards,
> >>> > > > Dejan
> >>> > > >
> >>> > > > On 2017-09-10 17:39, Stephen Connolly <
> >>> stephen.alan.conno...@gmail.com
> >>> > >
> >>> > > >
> >>> > > > wrote:
> >>> > > > > Hi,
> >>> > > > >
> >>> > > > > We solved 25 issues:
> >>> > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> >>> > > >
> >>> > > > version=12338964=Text=12316922
> >>> > > >
> >>> > > > > There are 350 issues left in JIRA for Maven core:
> >>> > > > > https://issues.apache.org/jira/issues/?jql=project%20%
> >>> > > >
> >>> > > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> >>> > > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> >>> > > >
> >>> > > > > Staging repo:
> >>> > > > > https://repository.apache.org/content/repositories/maven-1364/
> >>> > > > >
> >>> > > > > The distributable binaries and sources can be found here:
> >>> > > > > https://repository.apache.org/content/repositories/maven-> >
> >>> > > > 1364/org/apache/maven/apache-maven/3.5.1/
> >>> > > >
> >>> > > > > Specifically the zip, tarball and source archives can be found
> >>> here:
> >>> > > > > https://repository.apache.org/content/repositories/maven-> >
> >>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
> >>> bin.zip
> >>> > > >
> >>> > > > > https://repository.apache.org/content/repositories/maven-> >
> >>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
> >>> bin.tar.gz
> >>> > > >
> >>> > > > > https://repository.apache.org/content/repositories/maven-> >
> >>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
> >>> src.zip
> >>> > > >
> >>> > > > > https://repository.apache.org/content/repositories/maven-> >
> >>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
> >>> src.tar.gz
> >>> > > >
> >>> > > > > Source release checksum(s):
> >>> > > > > apache-maven-3.5.1-src.tar.gz sha1:
> >>> 9eb821f153c7667194aa11ccd099b7
> >>> > > >
> >>> > > > bd2059560d
> >>> > > >
> >>> > > > > apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab
> >>> > > >
> >>> > > > 69e698eb0e
> >>> > > >
> >>> > > > > Git tag:
> >>> > > > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> >>> > > >
> >>> > > > 094e4e31a5af55bb17be87675da41d9aeca062f3
> >>> > > >
> >>> > > > > Staging site:
> >>> 

Re: [VOTE] Release Apache Maven 3.5.1

[Anders Hammar]

On Fri, Sep 15, 2017 at 8:29 AM, Anders Hammar  wrote:

> Reporting back from tests of m2e with embedded Maven 3.5.1, we see problem
> with the jaxws-maven-plugin mojo. We're two people seeing the issue
> independently, but unfortunately Fred Bricon hasn't been able to reproduce.
>

To follow up on this, my tests indicate that Maven 3.5.1 causes changed
class loading that could cause issues for plugins in m2e. I've asked for
input from the m2e devs if it is possible to handle in m2e but they haven't
responded yet.

/Anders


>
> So currently I'm 0 on the voting but I'll investigate some more.
>
> /Anders
>
> On Wed, Sep 13, 2017 at 9:26 AM, Anders Hammar  wrote:
>
>>
>>
>> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>>> Have we got any feedback from the embedder integrations yet?
>>>
>>
>> I haven't heard anything from the m2e people. Maybe we need to ping them
>> directly. I can contact Fred Bricon.
>>
>> /Anders
>>
>>
>>>
>>> On Mon 11 Sep 2017 at 22:57, Hervé BOUTEMY 
>>> wrote:
>>>
>>> > just for the records: it is Windows + Git Bash (MINGW64) only
>>> >
>>> > and there is a chance that adding -Djansi.force=true can force JAnsi
>>> > activation (even if JAnsi fails to detect that it should auto-activate)
>>> >
>>> > details on issue in https://issues.apache.org/jira/browse/MNG-6282 ,
>>> and a
>>> > future JAnsi issue...
>>> >
>>> > Regards,
>>> >
>>> > Hervé
>>> >
>>> > Le lundi 11 septembre 2017, 12:53:46 CEST Stephen Connolly a écrit :
>>> > > So that is windows only, or were they lost on other OSes for you.
>>> > >
>>> > > I have colours on linux (via docker) and os-x
>>> > >
>>> > > On 11 September 2017 at 12:35, dejan2...@gmail.com <
>>> dejan2...@gmail.com>
>>> > >
>>> > > wrote:
>>> > > > +1 (conditionally).
>>> > > >
>>> > > > Tested via project that includes dozen of plugins: 1st tier,
>>> MojoHaus
>>> > and
>>> > > > few 3rd party plugins (so to say).
>>> > > >
>>> > > > Everything looks good with one notable regression:
>>> > > > https://issues.apache.org/jira/browse/MNG-6282 Console output has
>>> no
>>> > > > colors (regression in Maven 3.5.1)
>>> > > >
>>> > > > Regards,
>>> > > > Dejan
>>> > > >
>>> > > > On 2017-09-10 17:39, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com
>>> > >
>>> > > >
>>> > > > wrote:
>>> > > > > Hi,
>>> > > > >
>>> > > > > We solved 25 issues:
>>> > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>> > > >
>>> > > > version=12338964=Text=12316922
>>> > > >
>>> > > > > There are 350 issues left in JIRA for Maven core:
>>> > > > > https://issues.apache.org/jira/issues/?jql=project%20%
>>> > > >
>>> > > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
>>> > > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>>> > > >
>>> > > > > Staging repo:
>>> > > > > https://repository.apache.org/content/repositories/maven-1364/
>>> > > > >
>>> > > > > The distributable binaries and sources can be found here:
>>> > > > > https://repository.apache.org/content/repositories/maven-> >
>>> > > > 1364/org/apache/maven/apache-maven/3.5.1/
>>> > > >
>>> > > > > Specifically the zip, tarball and source archives can be found
>>> here:
>>> > > > > https://repository.apache.org/content/repositories/maven-> >
>>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
>>> bin.zip
>>> > > >
>>> > > > > https://repository.apache.org/content/repositories/maven-> >
>>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
>>> bin.tar.gz
>>> > > >
>>> > > > > https://repository.apache.org/content/repositories/maven-> >
>>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
>>> src.zip
>>> > > >
>>> > > > > https://repository.apache.org/content/repositories/maven-> >
>>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
>>> src.tar.gz
>>> > > >
>>> > > > > Source release checksum(s):
>>> > > > > apache-maven-3.5.1-src.tar.gz sha1:
>>> 9eb821f153c7667194aa11ccd099b7
>>> > > >
>>> > > > bd2059560d
>>> > > >
>>> > > > > apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab
>>> > > >
>>> > > > 69e698eb0e
>>> > > >
>>> > > > > Git tag:
>>> > > > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
>>> > > >
>>> > > > 094e4e31a5af55bb17be87675da41d9aeca062f3
>>> > > >
>>> > > > > Staging site:
>>> > > > > https://maven.apache.org/components/ref/3-LATEST/
>>> > > > >
>>> > > > > Vote open for 72 hours.
>>> > > > >
>>> > > > > [ ] +1
>>> > > > > [ ] +0
>>> > > > > [ ] -1
>>> > > > >
>>> > > > > Thanks,
>>> > > > >
>>> > > > > Stephen.
>>> > > >
>>> > > > 
>>> -
>>> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> > > > For additional commands, e-mail: dev-h...@maven.apache.org
>>> >
>>> >
>>> >
>>> > -
>>> > To 

Re: [VOTE] Release Apache Maven 3.5.1

[dejan2...@gmail.com]

Just to reply to my self and to add +1 (non-binding).

My two cents on regression (https://issues.apache.org/jira/browse/MNG-6282): 
ticket is still open and we (that is: Hervé Boutemy and me) are narrowing the 
gap (no ETA at the moment).

IMHO this issue is not a show-stopper; I volunteer to write a workaround/manual 
(that can be added to release notes).

Regards, 
Dejan Stojadinović

On 2017-09-11 13:35, "dejan2...@gmail.com" wrote: 
> +1 (conditionally).
> 
> Tested via project that includes dozen of plugins: 1st tier, MojoHaus and few 
> 3rd party plugins (so to say).
> 
> Everything looks good with one notable regression:
> https://issues.apache.org/jira/browse/MNG-6282 Console output has no colors 
> (regression in Maven 3.5.1)
> 
> Regards, 
> Dejan
> 
> On 2017-09-10 17:39, Stephen Connolly  
> wrote: 
> > Hi,
> > 
> > We solved 25 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12338964=Text=12316922
> > 
> > There are 350 issues left in JIRA for Maven core:
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > 
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1364/
> > 
> > The distributable binaries and sources can be found here:
> > https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/
> > 
> > Specifically the zip, tarball and source archives can be found here:
> > https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
> > https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
> > https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
> > https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
> > 
> > Source release checksum(s):
> > apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7bd2059560d
> > apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab69e698eb0e
> > 
> > Git tag:
> > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=094e4e31a5af55bb17be87675da41d9aeca062f3
> > 
> > Staging site:
> > https://maven.apache.org/components/ref/3-LATEST/
> > 
> > Vote open for 72 hours.
> > 
> > [ ] +1
> > [ ] +0
> > [ ] -1
> > 
> > Thanks,
> > 
> > Stephen.
> > 
> 
> -
> 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: [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

On 14 September 2017 at 23:55, Michael Osipov  wrote:

> Am 2017-09-15 um 00:50 schrieb Petr Široký:
>
>> I was able to easily fix our plugin by e.g. replacing
>> "Thread.currentThread().getContextClassLoader()" with
>> "this.getClass().getClassLoader()" (in the Mojo class) to get the plugin
>> classloader.
>>
>> I don't know though if the "Thread.currentThread().getCon
>> textClassLoader()"
>> is just misuse on our side or if it's something that more plugins may rely
>> on.
>>
>
> Similar cause in MASSEMBLY: https://issues.apache.org/jira/browse/MNG-6209
>
> I think using TCCL is wrong here.


I agree, I think the TCCL is supposed to be for extension lookup.

If you want the plugin's classloader then that should be
`this.getClass().getClassLoader()` from the Mojo class.

If you want the classloader with all the extensions, that should be TCCL.

What is unclear to me is why we set TCCL to anything other than the project
realm. A pom plugin declaration of true should not
affect the TCCL that the plugin execution sees, so I wonder if the root bug
is that the fix allows the TCCL to be other than project realm?

Igor?


>
>
> On Thu, Sep 14, 2017 at 2:42 PM Petr Široký  wrote:
>>
>> Argh, I forgot to link the plugin source:
>>> https://github.com/kiegroup/droolsjbpm-integration/tree/7.3.
>>> 0.Final/kie-maven-plugin
>>>
>>> On Thu, Sep 14, 2017 at 2:41 PM Petr Široký 
>>> wrote:
>>>
>>> Hello,

 I am seeing a (probably) similar issue with our custom plugin.

 See the reproducer:
 https://github.com/psiroky/reproducers/tree/mvn351-kie-maven-plugin
 (works
 fine with maven 3.5.0, but fails with NPE with the RC of maven 3.5.1).

 I am not yet sure if the plugin is just doing something it's not
 supposed
 to, or if this is a regression in maven itself. I'll will take a deeper
 look.

 Petr


 On Thu, Sep 14, 2017 at 1:53 PM Stephen Connolly <
 stephen.alan.conno...@gmail.com> wrote:

 On 14 September 2017 at 04:43, Mark Derricutt  wrote:
>
> +2 non-binding from Mark!
>>>
>>
>> I was discussing this with a coworker and he made the comment that if
>>
> this
>
>> change could break Mojos, maybe it shouldn't be in a point release -
>>
> whats
>
>> the policy on changes that may potentially break existing plugins?
>>
>>
> Well we need to assess the issue. Right now I don't even have a
> description
> of what went wrong. Any chance you could provide a replication... or
> mail
> me directly if you cannot share it publically and I may be able to
> produce
> a minimal reproduction from it.
>
> If this breaks a mojo that was doing something wrong in the first
> place,
> well that will not stop 3.5.1... OTOH if this exposes a bug in the
> issue
> "fixed" then I'd likely revert and respin.
>
> We really need a reproducer first.
>
>
>
>> --
>> "Great artists are extremely selfish and arrogant things" — Steven
>>
> Wilson,
>
>> Porcupine Tree
>>
>> On Thu, Sep 14, 2017 at 10:29 AM, Mark Derricutt 
>>
> wrote:
>
>>
>> On 14 Sep 2017, at 10:26, Mark Derricutt wrote:
>>>
>>> Calling -2 for vote if not too late.
>>>
>>> Actually - looking at the commit diff, I see in our code we did have
>>> true for the jasmine-maven-plugin which we
>>>
>> don't
>
>> actually need. Removing that from the mojo definition and running my
>>>
>> build
>>
>>> with the staged 3.5.1 release and everything builds fine.
>>>
>>> +2 non-binding from Mark!
>>>
>>> Mark
>>> --
>>>
>>> "The ease with which a change can be implemented has no relevance at
>>>
>> all
>
>> to whether it is the right change for the (Java) Platform for all
>>>
>> time."
>
>> —
>>
>>> Mark Reinhold.
>>>
>>> Mark Derricutt
>>> http://www.theoryinpractice.net
>>> http://www.chaliceofblood.net
>>> http://plus.google.com/+MarkDerricutt
>>> http://twitter.com/talios
>>> http://facebook.com/mderricutt
>>>
>>>
>>
>

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

Re: [VOTE] Release Apache Maven 3.5.1

[Michael Osipov]

Am 2017-09-15 um 00:50 schrieb Petr Široký:

I was able to easily fix our plugin by e.g. replacing
"Thread.currentThread().getContextClassLoader()" with
"this.getClass().getClassLoader()" (in the Mojo class) to get the plugin
classloader.

I don't know though if the "Thread.currentThread().getContextClassLoader()"
is just misuse on our side or if it's something that more plugins may rely
on.


Similar cause in MASSEMBLY: https://issues.apache.org/jira/browse/MNG-6209

I think using TCCL is wrong here.


On Thu, Sep 14, 2017 at 2:42 PM Petr Široký  wrote:


Argh, I forgot to link the plugin source:
https://github.com/kiegroup/droolsjbpm-integration/tree/7.3.0.Final/kie-maven-plugin

On Thu, Sep 14, 2017 at 2:41 PM Petr Široký  wrote:


Hello,

I am seeing a (probably) similar issue with our custom plugin.

See the reproducer:
https://github.com/psiroky/reproducers/tree/mvn351-kie-maven-plugin (works
fine with maven 3.5.0, but fails with NPE with the RC of maven 3.5.1).

I am not yet sure if the plugin is just doing something it's not supposed
to, or if this is a regression in maven itself. I'll will take a deeper
look.

Petr


On Thu, Sep 14, 2017 at 1:53 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:


On 14 September 2017 at 04:43, Mark Derricutt  wrote:


+2 non-binding from Mark!


I was discussing this with a coworker and he made the comment that if

this

change could break Mojos, maybe it shouldn't be in a point release -

whats

the policy on changes that may potentially break existing plugins?



Well we need to assess the issue. Right now I don't even have a
description
of what went wrong. Any chance you could provide a replication... or mail
me directly if you cannot share it publically and I may be able to
produce
a minimal reproduction from it.

If this breaks a mojo that was doing something wrong in the first place,
well that will not stop 3.5.1... OTOH if this exposes a bug in the issue
"fixed" then I'd likely revert and respin.

We really need a reproducer first.




--
"Great artists are extremely selfish and arrogant things" — Steven

Wilson,

Porcupine Tree

On Thu, Sep 14, 2017 at 10:29 AM, Mark Derricutt 

wrote:



On 14 Sep 2017, at 10:26, Mark Derricutt wrote:

Calling -2 for vote if not too late.

Actually - looking at the commit diff, I see in our code we did have
true for the jasmine-maven-plugin which we

don't

actually need. Removing that from the mojo definition and running my

build

with the staged 3.5.1 release and everything builds fine.

+2 non-binding from Mark!

Mark
--

"The ease with which a change can be implemented has no relevance at

all

to whether it is the right change for the (Java) Platform for all

time."

—

Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt













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

Re: [VOTE] Release Apache Maven 3.5.1

[Anders Hammar]

Reporting back from tests of m2e with embedded Maven 3.5.1, we see problem
with the jaxws-maven-plugin mojo. We're two people seeing the issue
independently, but unfortunately Fred Bricon hasn't been able to reproduce.

So currently I'm 0 on the voting but I'll investigate some more.

/Anders

On Wed, Sep 13, 2017 at 9:26 AM, Anders Hammar  wrote:

>
>
> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> Have we got any feedback from the embedder integrations yet?
>>
>
> I haven't heard anything from the m2e people. Maybe we need to ping them
> directly. I can contact Fred Bricon.
>
> /Anders
>
>
>>
>> On Mon 11 Sep 2017 at 22:57, Hervé BOUTEMY  wrote:
>>
>> > just for the records: it is Windows + Git Bash (MINGW64) only
>> >
>> > and there is a chance that adding -Djansi.force=true can force JAnsi
>> > activation (even if JAnsi fails to detect that it should auto-activate)
>> >
>> > details on issue in https://issues.apache.org/jira/browse/MNG-6282 ,
>> and a
>> > future JAnsi issue...
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> > Le lundi 11 septembre 2017, 12:53:46 CEST Stephen Connolly a écrit :
>> > > So that is windows only, or were they lost on other OSes for you.
>> > >
>> > > I have colours on linux (via docker) and os-x
>> > >
>> > > On 11 September 2017 at 12:35, dejan2...@gmail.com <
>> dejan2...@gmail.com>
>> > >
>> > > wrote:
>> > > > +1 (conditionally).
>> > > >
>> > > > Tested via project that includes dozen of plugins: 1st tier,
>> MojoHaus
>> > and
>> > > > few 3rd party plugins (so to say).
>> > > >
>> > > > Everything looks good with one notable regression:
>> > > > https://issues.apache.org/jira/browse/MNG-6282 Console output has
>> no
>> > > > colors (regression in Maven 3.5.1)
>> > > >
>> > > > Regards,
>> > > > Dejan
>> > > >
>> > > > On 2017-09-10 17:39, Stephen Connolly <
>> stephen.alan.conno...@gmail.com
>> > >
>> > > >
>> > > > wrote:
>> > > > > Hi,
>> > > > >
>> > > > > We solved 25 issues:
>> > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> > > >
>> > > > version=12338964=Text=12316922
>> > > >
>> > > > > There are 350 issues left in JIRA for Maven core:
>> > > > > https://issues.apache.org/jira/issues/?jql=project%20%
>> > > >
>> > > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
>> > > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>> > > >
>> > > > > Staging repo:
>> > > > > https://repository.apache.org/content/repositories/maven-1364/
>> > > > >
>> > > > > The distributable binaries and sources can be found here:
>> > > > > https://repository.apache.org/content/repositories/maven-> >
>> > > > 1364/org/apache/maven/apache-maven/3.5.1/
>> > > >
>> > > > > Specifically the zip, tarball and source archives can be found
>> here:
>> > > > > https://repository.apache.org/content/repositories/maven-> >
>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
>> > > >
>> > > > > https://repository.apache.org/content/repositories/maven-> >
>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
>> bin.tar.gz
>> > > >
>> > > > > https://repository.apache.org/content/repositories/maven-> >
>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
>> > > >
>> > > > > https://repository.apache.org/content/repositories/maven-> >
>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
>> src.tar.gz
>> > > >
>> > > > > Source release checksum(s):
>> > > > > apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
>> > > >
>> > > > bd2059560d
>> > > >
>> > > > > apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab
>> > > >
>> > > > 69e698eb0e
>> > > >
>> > > > > Git tag:
>> > > > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
>> > > >
>> > > > 094e4e31a5af55bb17be87675da41d9aeca062f3
>> > > >
>> > > > > Staging site:
>> > > > > https://maven.apache.org/components/ref/3-LATEST/
>> > > > >
>> > > > > Vote open for 72 hours.
>> > > > >
>> > > > > [ ] +1
>> > > > > [ ] +0
>> > > > > [ ] -1
>> > > > >
>> > > > > Thanks,
>> > > > >
>> > > > > Stephen.
>> > > >
>> > > > 
>> -
>> > > > 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: [VOTE] Release Apache Maven 3.5.1

[Petr Široký]

I was able to easily fix our plugin by e.g. replacing
"Thread.currentThread().getContextClassLoader()" with
"this.getClass().getClassLoader()" (in the Mojo class) to get the plugin
classloader.

I don't know though if the "Thread.currentThread().getContextClassLoader()"
is just misuse on our side or if it's something that more plugins may rely
on.

Petr


On Thu, Sep 14, 2017 at 2:42 PM Petr Široký  wrote:

> Argh, I forgot to link the plugin source:
> https://github.com/kiegroup/droolsjbpm-integration/tree/7.3.0.Final/kie-maven-plugin
>
> On Thu, Sep 14, 2017 at 2:41 PM Petr Široký  wrote:
>
>> Hello,
>>
>> I am seeing a (probably) similar issue with our custom plugin.
>>
>> See the reproducer:
>> https://github.com/psiroky/reproducers/tree/mvn351-kie-maven-plugin (works
>> fine with maven 3.5.0, but fails with NPE with the RC of maven 3.5.1).
>>
>> I am not yet sure if the plugin is just doing something it's not supposed
>> to, or if this is a regression in maven itself. I'll will take a deeper
>> look.
>>
>> Petr
>>
>>
>> On Thu, Sep 14, 2017 at 1:53 PM Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>>> On 14 September 2017 at 04:43, Mark Derricutt  wrote:
>>>
>>> > > +2 non-binding from Mark!
>>> >
>>> > I was discussing this with a coworker and he made the comment that if
>>> this
>>> > change could break Mojos, maybe it shouldn't be in a point release -
>>> whats
>>> > the policy on changes that may potentially break existing plugins?
>>> >
>>>
>>> Well we need to assess the issue. Right now I don't even have a
>>> description
>>> of what went wrong. Any chance you could provide a replication... or mail
>>> me directly if you cannot share it publically and I may be able to
>>> produce
>>> a minimal reproduction from it.
>>>
>>> If this breaks a mojo that was doing something wrong in the first place,
>>> well that will not stop 3.5.1... OTOH if this exposes a bug in the issue
>>> "fixed" then I'd likely revert and respin.
>>>
>>> We really need a reproducer first.
>>>
>>>
>>> >
>>> > --
>>> > "Great artists are extremely selfish and arrogant things" — Steven
>>> Wilson,
>>> > Porcupine Tree
>>> >
>>> > On Thu, Sep 14, 2017 at 10:29 AM, Mark Derricutt 
>>> wrote:
>>> >
>>> > > On 14 Sep 2017, at 10:26, Mark Derricutt wrote:
>>> > >
>>> > > Calling -2 for vote if not too late.
>>> > >
>>> > > Actually - looking at the commit diff, I see in our code we did have
>>> > > true for the jasmine-maven-plugin which we
>>> don't
>>> > > actually need. Removing that from the mojo definition and running my
>>> > build
>>> > > with the staged 3.5.1 release and everything builds fine.
>>> > >
>>> > > +2 non-binding from Mark!
>>> > >
>>> > > Mark
>>> > > --
>>> > >
>>> > > "The ease with which a change can be implemented has no relevance at
>>> all
>>> > > to whether it is the right change for the (Java) Platform for all
>>> time."
>>> > —
>>> > > Mark Reinhold.
>>> > >
>>> > > Mark Derricutt
>>> > > http://www.theoryinpractice.net
>>> > > http://www.chaliceofblood.net
>>> > > http://plus.google.com/+MarkDerricutt
>>> > > http://twitter.com/talios
>>> > > http://facebook.com/mderricutt
>>> > >
>>> >
>>>
>>

Re: [VOTE] Release Apache Maven 3.5.1

[Petr Široký]

Argh, I forgot to link the plugin source:
https://github.com/kiegroup/droolsjbpm-integration/tree/7.3.0.Final/kie-maven-plugin

On Thu, Sep 14, 2017 at 2:41 PM Petr Široký  wrote:

> Hello,
>
> I am seeing a (probably) similar issue with our custom plugin.
>
> See the reproducer:
> https://github.com/psiroky/reproducers/tree/mvn351-kie-maven-plugin (works
> fine with maven 3.5.0, but fails with NPE with the RC of maven 3.5.1).
>
> I am not yet sure if the plugin is just doing something it's not supposed
> to, or if this is a regression in maven itself. I'll will take a deeper
> look.
>
> Petr
>
>
> On Thu, Sep 14, 2017 at 1:53 PM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> On 14 September 2017 at 04:43, Mark Derricutt  wrote:
>>
>> > > +2 non-binding from Mark!
>> >
>> > I was discussing this with a coworker and he made the comment that if
>> this
>> > change could break Mojos, maybe it shouldn't be in a point release -
>> whats
>> > the policy on changes that may potentially break existing plugins?
>> >
>>
>> Well we need to assess the issue. Right now I don't even have a
>> description
>> of what went wrong. Any chance you could provide a replication... or mail
>> me directly if you cannot share it publically and I may be able to produce
>> a minimal reproduction from it.
>>
>> If this breaks a mojo that was doing something wrong in the first place,
>> well that will not stop 3.5.1... OTOH if this exposes a bug in the issue
>> "fixed" then I'd likely revert and respin.
>>
>> We really need a reproducer first.
>>
>>
>> >
>> > --
>> > "Great artists are extremely selfish and arrogant things" — Steven
>> Wilson,
>> > Porcupine Tree
>> >
>> > On Thu, Sep 14, 2017 at 10:29 AM, Mark Derricutt 
>> wrote:
>> >
>> > > On 14 Sep 2017, at 10:26, Mark Derricutt wrote:
>> > >
>> > > Calling -2 for vote if not too late.
>> > >
>> > > Actually - looking at the commit diff, I see in our code we did have
>> > > true for the jasmine-maven-plugin which we
>> don't
>> > > actually need. Removing that from the mojo definition and running my
>> > build
>> > > with the staged 3.5.1 release and everything builds fine.
>> > >
>> > > +2 non-binding from Mark!
>> > >
>> > > Mark
>> > > --
>> > >
>> > > "The ease with which a change can be implemented has no relevance at
>> all
>> > > to whether it is the right change for the (Java) Platform for all
>> time."
>> > —
>> > > Mark Reinhold.
>> > >
>> > > Mark Derricutt
>> > > http://www.theoryinpractice.net
>> > > http://www.chaliceofblood.net
>> > > http://plus.google.com/+MarkDerricutt
>> > > http://twitter.com/talios
>> > > http://facebook.com/mderricutt
>> > >
>> >
>>
>

Re: [VOTE] Release Apache Maven 3.5.1

[Petr Široký]

Hello,

I am seeing a (probably) similar issue with our custom plugin.

See the reproducer:
https://github.com/psiroky/reproducers/tree/mvn351-kie-maven-plugin (works
fine with maven 3.5.0, but fails with NPE with the RC of maven 3.5.1).

I am not yet sure if the plugin is just doing something it's not supposed
to, or if this is a regression in maven itself. I'll will take a deeper
look.

Petr

On Thu, Sep 14, 2017 at 1:53 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On 14 September 2017 at 04:43, Mark Derricutt  wrote:
>
> > > +2 non-binding from Mark!
> >
> > I was discussing this with a coworker and he made the comment that if
> this
> > change could break Mojos, maybe it shouldn't be in a point release -
> whats
> > the policy on changes that may potentially break existing plugins?
> >
>
> Well we need to assess the issue. Right now I don't even have a description
> of what went wrong. Any chance you could provide a replication... or mail
> me directly if you cannot share it publically and I may be able to produce
> a minimal reproduction from it.
>
> If this breaks a mojo that was doing something wrong in the first place,
> well that will not stop 3.5.1... OTOH if this exposes a bug in the issue
> "fixed" then I'd likely revert and respin.
>
> We really need a reproducer first.
>
>
> >
> > --
> > "Great artists are extremely selfish and arrogant things" — Steven
> Wilson,
> > Porcupine Tree
> >
> > On Thu, Sep 14, 2017 at 10:29 AM, Mark Derricutt 
> wrote:
> >
> > > On 14 Sep 2017, at 10:26, Mark Derricutt wrote:
> > >
> > > Calling -2 for vote if not too late.
> > >
> > > Actually - looking at the commit diff, I see in our code we did have
> > > true for the jasmine-maven-plugin which we
> don't
> > > actually need. Removing that from the mojo definition and running my
> > build
> > > with the staged 3.5.1 release and everything builds fine.
> > >
> > > +2 non-binding from Mark!
> > >
> > > Mark
> > > --
> > >
> > > "The ease with which a change can be implemented has no relevance at
> all
> > > to whether it is the right change for the (Java) Platform for all
> time."
> > —
> > > Mark Reinhold.
> > >
> > > Mark Derricutt
> > > http://www.theoryinpractice.net
> > > http://www.chaliceofblood.net
> > > http://plus.google.com/+MarkDerricutt
> > > http://twitter.com/talios
> > > http://facebook.com/mderricutt
> > >
> >
>

Re: [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

On 14 September 2017 at 04:43, Mark Derricutt  wrote:

> > +2 non-binding from Mark!
>
> I was discussing this with a coworker and he made the comment that if this
> change could break Mojos, maybe it shouldn't be in a point release - whats
> the policy on changes that may potentially break existing plugins?
>

Well we need to assess the issue. Right now I don't even have a description
of what went wrong. Any chance you could provide a replication... or mail
me directly if you cannot share it publically and I may be able to produce
a minimal reproduction from it.

If this breaks a mojo that was doing something wrong in the first place,
well that will not stop 3.5.1... OTOH if this exposes a bug in the issue
"fixed" then I'd likely revert and respin.

We really need a reproducer first.


>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>
> On Thu, Sep 14, 2017 at 10:29 AM, Mark Derricutt  wrote:
>
> > On 14 Sep 2017, at 10:26, Mark Derricutt wrote:
> >
> > Calling -2 for vote if not too late.
> >
> > Actually - looking at the commit diff, I see in our code we did have
> > true for the jasmine-maven-plugin which we don't
> > actually need. Removing that from the mojo definition and running my
> build
> > with the staged 3.5.1 release and everything builds fine.
> >
> > +2 non-binding from Mark!
> >
> > Mark
> > --
> >
> > "The ease with which a change can be implemented has no relevance at all
> > to whether it is the right change for the (Java) Platform for all time."
> —
> > Mark Reinhold.
> >
> > Mark Derricutt
> > http://www.theoryinpractice.net
> > http://www.chaliceofblood.net
> > http://plus.google.com/+MarkDerricutt
> > http://twitter.com/talios
> > http://facebook.com/mderricutt
> >
>

Re: [VOTE] Release Apache Maven 3.5.1

[Mark Derricutt]

> +2 non-binding from Mark!

I was discussing this with a coworker and he made the comment that if this
change could break Mojos, maybe it shouldn't be in a point release - whats
the policy on changes that may potentially break existing plugins?

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

On Thu, Sep 14, 2017 at 10:29 AM, Mark Derricutt  wrote:

> On 14 Sep 2017, at 10:26, Mark Derricutt wrote:
>
> Calling -2 for vote if not too late.
>
> Actually - looking at the commit diff, I see in our code we did have
> true for the jasmine-maven-plugin which we don't
> actually need. Removing that from the mojo definition and running my build
> with the staged 3.5.1 release and everything builds fine.
>
> +2 non-binding from Mark!
>
> Mark
> --
>
> "The ease with which a change can be implemented has no relevance at all
> to whether it is the right change for the (Java) Platform for all time." —
> Mark Reinhold.
>
> Mark Derricutt
> http://www.theoryinpractice.net
> http://www.chaliceofblood.net
> http://plus.google.com/+MarkDerricutt
> http://twitter.com/talios
> http://facebook.com/mderricutt
>

Re: [VOTE] Release Apache Maven 3.5.1

[Hervé BOUTEMY]

+1
works well in everything I tested, colour on Windows with GitBash or Cygwin or 
any other Unix layer taken apart (in fact anything on WIndows that provides 
"TERM=xterm")

workaround for those Windows users: add -Djansi.force=true to MAVEN_OPTS
the only drawback will only be if you redirect stdout/stderr to a file: ANSI 
escape codes will be present, unless you run "mvn -B" or disable color at 
Maven level

I know, this is a little bit tricky, but not so complex (it may help people 
discover how JAnsi is working and how Maven integrates it): I still need to 
continue investigation in JAnsi, provide a complete analysis with a fix, get it 
merged, have a release, then integrate in Maven...
Maven Jira issue: https://issues.apache.org/jira/browse/MNG-6282
JAnsi GitHub issue: https://github.com/fusesource/jansi/issues/94

Thank you to Dejan Stojadinović for reporting the issue then working with me 
to investigate in detail: such contribution is greatly appreciated.
And thanks in advance to JAnsi team who will surely help me when I'll ping 
them, as they did in the past (cross projects contribution is great!) :)

Regards,

Hervé

Le lundi 11 septembre 2017, 23:56:58 CEST Hervé BOUTEMY a écrit :
> just for the records: it is Windows + Git Bash (MINGW64) only
> 
> and there is a chance that adding -Djansi.force=true can force JAnsi
> activation (even if JAnsi fails to detect that it should auto-activate)
> 
> details on issue in https://issues.apache.org/jira/browse/MNG-6282 , and a
> future JAnsi issue...
> 
> Regards,
> 
> Hervé
> 
> Le lundi 11 septembre 2017, 12:53:46 CEST Stephen Connolly a écrit :
> > So that is windows only, or were they lost on other OSes for you.
> > 
> > I have colours on linux (via docker) and os-x
> > 
> > On 11 September 2017 at 12:35, dejan2...@gmail.com 
> > 
> > wrote:
> > > +1 (conditionally).
> > > 
> > > Tested via project that includes dozen of plugins: 1st tier, MojoHaus
> > > and
> > > few 3rd party plugins (so to say).
> > > 
> > > Everything looks good with one notable regression:
> > > https://issues.apache.org/jira/browse/MNG-6282 Console output has no
> > > colors (regression in Maven 3.5.1)
> > > 
> > > Regards,
> > > Dejan
> > > 
> > > On 2017-09-10 17:39, Stephen Connolly 
> > > 
> > > wrote:
> > > > Hi,
> > > > 
> > > > We solved 25 issues:
> > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > 
> > > version=12338964=Text=12316922
> > > 
> > > > There are 350 issues left in JIRA for Maven core:
> > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > 
> > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > > 
> > > > Staging repo:
> > > > https://repository.apache.org/content/repositories/maven-1364/
> > > > 
> > > > The distributable binaries and sources can be found here:
> > > > https://repository.apache.org/content/repositories/maven-> >
> > > 
> > > 1364/org/apache/maven/apache-maven/3.5.1/
> > > 
> > > > Specifically the zip, tarball and source archives can be found here:
> > > > https://repository.apache.org/content/repositories/maven-> >
> > > 
> > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
> > > 
> > > > https://repository.apache.org/content/repositories/maven-> >
> > > 
> > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
> > > 
> > > > https://repository.apache.org/content/repositories/maven-> >
> > > 
> > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
> > > 
> > > > https://repository.apache.org/content/repositories/maven-> >
> > > 
> > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
> > > 
> > > > Source release checksum(s):
> > > > apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
> > > 
> > > bd2059560d
> > > 
> > > > apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab
> > > 
> > > 69e698eb0e
> > > 
> > > > Git tag:
> > > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> > > 
> > > 094e4e31a5af55bb17be87675da41d9aeca062f3
> > > 
> > > > Staging site:
> > > > https://maven.apache.org/components/ref/3-LATEST/
> > > > 
> > > > Vote open for 72 hours.
> > > > 
> > > > [ ] +1
> > > > [ ] +0
> > > > [ ] -1
> > > > 
> > > > Thanks,
> > > > 
> > > > Stephen.
> > > 
> > > -
> > > 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: [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

On Wed 13 Sep 2017 at 23:30, Mark Derricutt  wrote:

> On 14 Sep 2017, at 10:26, Mark Derricutt wrote:
>
> Calling -2 for vote if not too late.
>
> Actually - looking at the commit diff, I see in our code we did have
> true for the jasmine-maven-plugin which we don't
> actually need. Removing that from the mojo definition and running my build
> with the staged 3.5.1 release and everything builds fine.
>
> +2 non-binding from Mark!
>

Have you a description of what went wrong so we can add to the release
notes?

Mark
> --
>
> "The ease with which a change can be implemented has no relevance at all
> to whether it is the right change for the (Java) Platform for all time." —
> Mark Reinhold.
>
> Mark Derricutt
> http://www.theoryinpractice.net
> http://www.chaliceofblood.net
> http://plus.google.com/+MarkDerricutt
> http://twitter.com/talios
> http://facebook.com/mderricutt
>
-- 
Sent from my phone

Re: [VOTE] Release Apache Maven 3.5.1

[Mark Derricutt]

On 14 Sep 2017, at 10:26, Mark Derricutt wrote:

> Calling -2 for vote if not too late.

Actually - looking at the commit diff, I see in our code we did have 
`true` for the `jasmine-maven-plugin` which we don't 
actually need. Removing that from the mojo definition and running my build with 
the staged 3.5.1 release and everything builds fine.

+2 non-binding from Mark!

Mark


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven 3.5.1

[Mark Derricutt]

Calling -2 for vote if not too late.

Have git bisected from 3.5.0 to HEAD and found the commit that introduced the 
behaviour:

ec629f7d511eb910b4e80112a9fbe85ed8786f10 is the first bad commit
commit ec629f7d511eb910b4e80112a9fbe85ed8786f10
Author: Igor Fedorenko 
Date:   Tue Apr 11 07:59:34 2017 -0700

MNG-6209 better executeMojo thread context classloader

Signed-off-by: Igor Fedorenko 

:04 04 570fa9308365b0ee98d57ac3f8006691bd9ade4d 
3c6791665c9d41f0e4a3893ea99621cc50e8b91b M  maven-core


Not exactly sure what/why/how this problem manifests in a testable manner yet 
however.

Mark




On 11 Sep 2017, at 23:19, Mark Derricutt wrote:

> On 11 Sep 2017, at 18:10, Stephen Connolly wrote:
>
>> I wonder if mng-6275 is affecting that plugin
>
> Didn't manage to get a chance to look into this tonight :( Tho that ticket 
> mentions nashorn, phantonjs is a C/native headless browser library, so it 
> doesn't feel like it could be related.
>
> If there's a build available with a fix for that, welcome to give it a bash.
>
> I'll try carve out some time in the morning to see if I can make a simple 
> standalone project...
>
> ---
> "The ease with which a change can be implemented has no relevance at all to 
> whether it is the right change for the (Java) Platform for all time."  
> Mark Reinhold.
>
> Mark Derricutt
> http://www.theoryinpractice.net
> http://www.chaliceofblood.net
> http://plus.google.com/+MarkDerricutt
> http://twitter.com/talios
> http://facebook.com/mderricutt


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven 3.5.1

[jieryn]

+1 non-binding

I tested with OpenJDK Java 8 on Linux x86_64 with a variety of
projects. Everything looks good, the only new behavior I'm seeing is a
warning:

[WARNING] The project <> uses prerequisites which is
only intended for maven-plugin projects but not for non maven-plugin
projects. For such purposes you should use the maven-enforcer-plugin.
See https://maven.apache.org/enforcer/enforcer-rules/requireMavenVersion.html

But it looks like this is intentional and well documented, thank you!


On Wed, Sep 13, 2017 at 8:20 AM, Robert Scholte
<apa...@sourcegrounds.com> wrote:
> Just received the confirmation that netbeans uses the cli, so there should be 
> no issue there.
> Robert
> Verzonden vanaf mijn Samsung Galaxy-smartphone.
>  Oorspronkelijk bericht Van: Stephen Connolly 
> <stephen.alan.conno...@gmail.com> Datum: 13-09-17  10:05  (GMT+01:00) Aan: 
> Maven Developers List <dev@maven.apache.org> Onderwerp: Re: [VOTE] Release 
> Apache Maven 3.5.1
> On 13 September 2017 at 00:26, Anders Hammar <and...@hammar.net> wrote:
>
>> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>> > Have we got any feedback from the embedder integrations yet?
>> >
>>
>> I haven't heard anything from the m2e people. Maybe we need to ping them
>> directly. I can contact Fred Bricon.
>>
>> /Anders
>>
>>
> Please do, also if anyone has a contact in netbeans or intellij and could
> let them know we'd like either feedback or "we're ok if MNG-6275 makes
> trouble for us, go ahead and release". I'd like to close the vote on Friday
> 13:00 UTC.

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

Re: [VOTE] Release Apache Maven 3.5.1

[Robert Scholte]

Just received the confirmation that netbeans uses the cli, so there should be 
no issue there. 
Robert 
Verzonden vanaf mijn Samsung Galaxy-smartphone.
 Oorspronkelijk bericht Van: Stephen Connolly 
<stephen.alan.conno...@gmail.com> Datum: 13-09-17  10:05  (GMT+01:00) Aan: 
Maven Developers List <dev@maven.apache.org> Onderwerp: Re: [VOTE] Release 
Apache Maven 3.5.1 
On 13 September 2017 at 00:26, Anders Hammar <and...@hammar.net> wrote:

> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Have we got any feedback from the embedder integrations yet?
> >
>
> I haven't heard anything from the m2e people. Maybe we need to ping them
> directly. I can contact Fred Bricon.
>
> /Anders
>
>
Please do, also if anyone has a contact in netbeans or intellij and could
let them know we'd like either feedback or "we're ok if MNG-6275 makes
trouble for us, go ahead and release". I'd like to close the vote on Friday
13:00 UTC.

Re: [VOTE] Release Apache Maven 3.5.1

[Robert Scholte]

Just received the confirmation that netbeans uses the cli, so there should be 
no issue there. 
Robert 
Verzonden vanaf mijn Samsung Galaxy-smartphone.
 Oorspronkelijk bericht Van: Stephen Connolly 
<stephen.alan.conno...@gmail.com> Datum: 13-09-17  10:05  (GMT+01:00) Aan: 
Maven Developers List <dev@maven.apache.org> Onderwerp: Re: [VOTE] Release 
Apache Maven 3.5.1 
On 13 September 2017 at 00:26, Anders Hammar <and...@hammar.net> wrote:

> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Have we got any feedback from the embedder integrations yet?
> >
>
> I haven't heard anything from the m2e people. Maybe we need to ping them
> directly. I can contact Fred Bricon.
>
> /Anders
>
>
Please do, also if anyone has a contact in netbeans or intellij and could
let them know we'd like either feedback or "we're ok if MNG-6275 makes
trouble for us, go ahead and release". I'd like to close the vote on Friday
13:00 UTC.

Re: [VOTE] Release Apache Maven 3.5.1

[Arnaud Héritier]

Damned, can't we be anonymous on Github ?
I maintain it is a big word, I'm trying to fix more bugs than I add new ones
I added Oleg in the loop as he contributed a lot on it too
I did a quick test to build on Jenkins 2.60.3 our maven core with the Evil
Maven plugin 2.17 on a local SSH agent and it is ok
But it is really a quick test ...

Cheers



On Wed, Sep 13, 2017 at 10:07 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On 13 September 2017 at 01:05, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> On 13 September 2017 at 00:26, Anders Hammar  wrote:
>>
>>> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
>>> > Have we got any feedback from the embedder integrations yet?
>>> >
>>>
>>> I haven't heard anything from the m2e people. Maybe we need to ping them
>>> directly. I can contact Fred Bricon.
>>>
>>> /Anders
>>>
>>>
>> Please do, also if anyone has a contact in netbeans or intellij and could
>> let them know we'd like either feedback or "we're ok if MNG-6275 makes
>> trouble for us, go ahead and release". I'd like to close the vote on Friday
>> 13:00 UTC.
>>
>>
>
> Olivier / Arnaud, have either of you had a chance to test this with the
> evil project type[1] as you two seem to be the active maintainers[2]
>
> [1]: https://javaadventure.blogspot.ie/2013/11/jenkins-
> maven-job-type-considered-evil.html
> [2]: https://github.com/jenkinsci/maven-plugin/commits/master
>



-- 

Arnaud

Re: [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

On 13 September 2017 at 01:05, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On 13 September 2017 at 00:26, Anders Hammar  wrote:
>
>> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>> > Have we got any feedback from the embedder integrations yet?
>> >
>>
>> I haven't heard anything from the m2e people. Maybe we need to ping them
>> directly. I can contact Fred Bricon.
>>
>> /Anders
>>
>>
> Please do, also if anyone has a contact in netbeans or intellij and could
> let them know we'd like either feedback or "we're ok if MNG-6275 makes
> trouble for us, go ahead and release". I'd like to close the vote on Friday
> 13:00 UTC.
>
>

Olivier / Arnaud, have either of you had a chance to test this with the
evil project type[1] as you two seem to be the active maintainers[2]

[1]:
https://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-type-considered-evil.html
[2]: https://github.com/jenkinsci/maven-plugin/commits/master

Re: [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

On 13 September 2017 at 00:26, Anders Hammar  wrote:

> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Have we got any feedback from the embedder integrations yet?
> >
>
> I haven't heard anything from the m2e people. Maybe we need to ping them
> directly. I can contact Fred Bricon.
>
> /Anders
>
>
Please do, also if anyone has a contact in netbeans or intellij and could
let them know we'd like either feedback or "we're ok if MNG-6275 makes
trouble for us, go ahead and release". I'd like to close the vote on Friday
13:00 UTC.

Re: [VOTE] Release Apache Maven 3.5.1

[Anders Hammar]

On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Have we got any feedback from the embedder integrations yet?
>

I haven't heard anything from the m2e people. Maybe we need to ping them
directly. I can contact Fred Bricon.

/Anders


>
> On Mon 11 Sep 2017 at 22:57, Hervé BOUTEMY  wrote:
>
> > just for the records: it is Windows + Git Bash (MINGW64) only
> >
> > and there is a chance that adding -Djansi.force=true can force JAnsi
> > activation (even if JAnsi fails to detect that it should auto-activate)
> >
> > details on issue in https://issues.apache.org/jira/browse/MNG-6282 ,
> and a
> > future JAnsi issue...
> >
> > Regards,
> >
> > Hervé
> >
> > Le lundi 11 septembre 2017, 12:53:46 CEST Stephen Connolly a écrit :
> > > So that is windows only, or were they lost on other OSes for you.
> > >
> > > I have colours on linux (via docker) and os-x
> > >
> > > On 11 September 2017 at 12:35, dejan2...@gmail.com <
> dejan2...@gmail.com>
> > >
> > > wrote:
> > > > +1 (conditionally).
> > > >
> > > > Tested via project that includes dozen of plugins: 1st tier, MojoHaus
> > and
> > > > few 3rd party plugins (so to say).
> > > >
> > > > Everything looks good with one notable regression:
> > > > https://issues.apache.org/jira/browse/MNG-6282 Console output has no
> > > > colors (regression in Maven 3.5.1)
> > > >
> > > > Regards,
> > > > Dejan
> > > >
> > > > On 2017-09-10 17:39, Stephen Connolly  om
> > >
> > > >
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > We solved 25 issues:
> > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > >
> > > > version=12338964=Text=12316922
> > > >
> > > > > There are 350 issues left in JIRA for Maven core:
> > > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > >
> > > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > > >
> > > > > Staging repo:
> > > > > https://repository.apache.org/content/repositories/maven-1364/
> > > > >
> > > > > The distributable binaries and sources can be found here:
> > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > 1364/org/apache/maven/apache-maven/3.5.1/
> > > >
> > > > > Specifically the zip, tarball and source archives can be found
> here:
> > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
> > > >
> > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
> bin.tar.gz
> > > >
> > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
> > > >
> > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
> src.tar.gz
> > > >
> > > > > Source release checksum(s):
> > > > > apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
> > > >
> > > > bd2059560d
> > > >
> > > > > apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab
> > > >
> > > > 69e698eb0e
> > > >
> > > > > Git tag:
> > > > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> > > >
> > > > 094e4e31a5af55bb17be87675da41d9aeca062f3
> > > >
> > > > > Staging site:
> > > > > https://maven.apache.org/components/ref/3-LATEST/
> > > > >
> > > > > Vote open for 72 hours.
> > > > >
> > > > > [ ] +1
> > > > > [ ] +0
> > > > > [ ] -1
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Stephen.
> > > >
> > > > 
> -
> > > > 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: [VOTE] Release Apache Maven 3.5.1

[Petar Tahchiev]

+1 - go for it.


2017-09-13 9:04 GMT+03:00 Grzegorz Grzybek :

> Hello
>
> +1 (non-binding) - tested Fuse/Karaf/OSGi projects
>
> regards
> Grzegorz Grzybek
>
> 2017-09-13 8:00 GMT+02:00 Thomas Collignon :
>
> > Hello
> >
> > +1 for me
> >
> > 2017-09-12 20:54 GMT+02:00 Stephen Connolly  > com
> > >:
> >
> > > Have we got any feedback from the embedder integrations yet?
> > >
> > > On Mon 11 Sep 2017 at 22:57, Hervé BOUTEMY 
> > wrote:
> > >
> > > > just for the records: it is Windows + Git Bash (MINGW64) only
> > > >
> > > > and there is a chance that adding -Djansi.force=true can force JAnsi
> > > > activation (even if JAnsi fails to detect that it should
> auto-activate)
> > > >
> > > > details on issue in https://issues.apache.org/jira/browse/MNG-6282 ,
> > > and a
> > > > future JAnsi issue...
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > Le lundi 11 septembre 2017, 12:53:46 CEST Stephen Connolly a écrit :
> > > > > So that is windows only, or were they lost on other OSes for you.
> > > > >
> > > > > I have colours on linux (via docker) and os-x
> > > > >
> > > > > On 11 September 2017 at 12:35, dejan2...@gmail.com <
> > > dejan2...@gmail.com>
> > > > >
> > > > > wrote:
> > > > > > +1 (conditionally).
> > > > > >
> > > > > > Tested via project that includes dozen of plugins: 1st tier,
> > MojoHaus
> > > > and
> > > > > > few 3rd party plugins (so to say).
> > > > > >
> > > > > > Everything looks good with one notable regression:
> > > > > > https://issues.apache.org/jira/browse/MNG-6282 Console output
> has
> > no
> > > > > > colors (regression in Maven 3.5.1)
> > > > > >
> > > > > > Regards,
> > > > > > Dejan
> > > > > >
> > > > > > On 2017-09-10 17:39, Stephen Connolly
>  > > com
> > > > >
> > > > > >
> > > > > > wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > We solved 25 issues:
> > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > > > >
> > > > > > version=12338964=Text=12316922
> > > > > >
> > > > > > > There are 350 issues left in JIRA for Maven core:
> > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > > > >
> > > > > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > > > > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > > > > >
> > > > > > > Staging repo:
> > > > > > > https://repository.apache.org/content/repositories/maven-1364/
> > > > > > >
> > > > > > > The distributable binaries and sources can be found here:
> > > > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > > > 1364/org/apache/maven/apache-maven/3.5.1/
> > > > > >
> > > > > > > Specifically the zip, tarball and source archives can be found
> > > here:
> > > > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.
> > 1-bin.zip
> > > > > >
> > > > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.
> > > 1-bin.tar.gz
> > > > > >
> > > > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.
> > 1-src.zip
> > > > > >
> > > > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.
> > > 1-src.tar.gz
> > > > > >
> > > > > > > Source release checksum(s):
> > > > > > > apache-maven-3.5.1-src.tar.gz sha1:
> > 9eb821f153c7667194aa11ccd099b7
> > > > > >
> > > > > > bd2059560d
> > > > > >
> > > > > > > apache-maven-3.5.1-src.zip: sha1:
> 121d54b045380a8a4895eb137970ab
> > > > > >
> > > > > > 69e698eb0e
> > > > > >
> > > > > > > Git tag:
> > > > > > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=
> commit;h=
> > > > > >
> > > > > > 094e4e31a5af55bb17be87675da41d9aeca062f3
> > > > > >
> > > > > > > Staging site:
> > > > > > > https://maven.apache.org/components/ref/3-LATEST/
> > > > > > >
> > > > > > > Vote open for 72 hours.
> > > > > > >
> > > > > > > [ ] +1
> > > > > > > [ ] +0
> > > > > > > [ ] -1
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Stephen.
> > > > > >
> > > > > > 
> > > -
> > > > > > 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
> > >
> >
>



-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 

Re: [VOTE] Release Apache Maven 3.5.1

[Grzegorz Grzybek]

Hello

+1 (non-binding) - tested Fuse/Karaf/OSGi projects

regards
Grzegorz Grzybek

2017-09-13 8:00 GMT+02:00 Thomas Collignon :

> Hello
>
> +1 for me
>
> 2017-09-12 20:54 GMT+02:00 Stephen Connolly  com
> >:
>
> > Have we got any feedback from the embedder integrations yet?
> >
> > On Mon 11 Sep 2017 at 22:57, Hervé BOUTEMY 
> wrote:
> >
> > > just for the records: it is Windows + Git Bash (MINGW64) only
> > >
> > > and there is a chance that adding -Djansi.force=true can force JAnsi
> > > activation (even if JAnsi fails to detect that it should auto-activate)
> > >
> > > details on issue in https://issues.apache.org/jira/browse/MNG-6282 ,
> > and a
> > > future JAnsi issue...
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le lundi 11 septembre 2017, 12:53:46 CEST Stephen Connolly a écrit :
> > > > So that is windows only, or were they lost on other OSes for you.
> > > >
> > > > I have colours on linux (via docker) and os-x
> > > >
> > > > On 11 September 2017 at 12:35, dejan2...@gmail.com <
> > dejan2...@gmail.com>
> > > >
> > > > wrote:
> > > > > +1 (conditionally).
> > > > >
> > > > > Tested via project that includes dozen of plugins: 1st tier,
> MojoHaus
> > > and
> > > > > few 3rd party plugins (so to say).
> > > > >
> > > > > Everything looks good with one notable regression:
> > > > > https://issues.apache.org/jira/browse/MNG-6282 Console output has
> no
> > > > > colors (regression in Maven 3.5.1)
> > > > >
> > > > > Regards,
> > > > > Dejan
> > > > >
> > > > > On 2017-09-10 17:39, Stephen Connolly  > com
> > > >
> > > > >
> > > > > wrote:
> > > > > > Hi,
> > > > > >
> > > > > > We solved 25 issues:
> > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > > >
> > > > > version=12338964=Text=12316922
> > > > >
> > > > > > There are 350 issues left in JIRA for Maven core:
> > > > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > > >
> > > > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > > > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > > > >
> > > > > > Staging repo:
> > > > > > https://repository.apache.org/content/repositories/maven-1364/
> > > > > >
> > > > > > The distributable binaries and sources can be found here:
> > > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > > 1364/org/apache/maven/apache-maven/3.5.1/
> > > > >
> > > > > > Specifically the zip, tarball and source archives can be found
> > here:
> > > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.
> 1-bin.zip
> > > > >
> > > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.
> > 1-bin.tar.gz
> > > > >
> > > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.
> 1-src.zip
> > > > >
> > > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.
> > 1-src.tar.gz
> > > > >
> > > > > > Source release checksum(s):
> > > > > > apache-maven-3.5.1-src.tar.gz sha1:
> 9eb821f153c7667194aa11ccd099b7
> > > > >
> > > > > bd2059560d
> > > > >
> > > > > > apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab
> > > > >
> > > > > 69e698eb0e
> > > > >
> > > > > > Git tag:
> > > > > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> > > > >
> > > > > 094e4e31a5af55bb17be87675da41d9aeca062f3
> > > > >
> > > > > > Staging site:
> > > > > > https://maven.apache.org/components/ref/3-LATEST/
> > > > > >
> > > > > > Vote open for 72 hours.
> > > > > >
> > > > > > [ ] +1
> > > > > > [ ] +0
> > > > > > [ ] -1
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Stephen.
> > > > >
> > > > > 
> > -
> > > > > 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: [VOTE] Release Apache Maven 3.5.1

[Thomas Collignon]

Hello

+1 for me

2017-09-12 20:54 GMT+02:00 Stephen Connolly :

> Have we got any feedback from the embedder integrations yet?
>
> On Mon 11 Sep 2017 at 22:57, Hervé BOUTEMY  wrote:
>
> > just for the records: it is Windows + Git Bash (MINGW64) only
> >
> > and there is a chance that adding -Djansi.force=true can force JAnsi
> > activation (even if JAnsi fails to detect that it should auto-activate)
> >
> > details on issue in https://issues.apache.org/jira/browse/MNG-6282 ,
> and a
> > future JAnsi issue...
> >
> > Regards,
> >
> > Hervé
> >
> > Le lundi 11 septembre 2017, 12:53:46 CEST Stephen Connolly a écrit :
> > > So that is windows only, or were they lost on other OSes for you.
> > >
> > > I have colours on linux (via docker) and os-x
> > >
> > > On 11 September 2017 at 12:35, dejan2...@gmail.com <
> dejan2...@gmail.com>
> > >
> > > wrote:
> > > > +1 (conditionally).
> > > >
> > > > Tested via project that includes dozen of plugins: 1st tier, MojoHaus
> > and
> > > > few 3rd party plugins (so to say).
> > > >
> > > > Everything looks good with one notable regression:
> > > > https://issues.apache.org/jira/browse/MNG-6282 Console output has no
> > > > colors (regression in Maven 3.5.1)
> > > >
> > > > Regards,
> > > > Dejan
> > > >
> > > > On 2017-09-10 17:39, Stephen Connolly  com
> > >
> > > >
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > We solved 25 issues:
> > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > >
> > > > version=12338964=Text=12316922
> > > >
> > > > > There are 350 issues left in JIRA for Maven core:
> > > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > >
> > > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > > >
> > > > > Staging repo:
> > > > > https://repository.apache.org/content/repositories/maven-1364/
> > > > >
> > > > > The distributable binaries and sources can be found here:
> > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > 1364/org/apache/maven/apache-maven/3.5.1/
> > > >
> > > > > Specifically the zip, tarball and source archives can be found
> here:
> > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
> > > >
> > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.
> 1-bin.tar.gz
> > > >
> > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
> > > >
> > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.
> 1-src.tar.gz
> > > >
> > > > > Source release checksum(s):
> > > > > apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
> > > >
> > > > bd2059560d
> > > >
> > > > > apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab
> > > >
> > > > 69e698eb0e
> > > >
> > > > > Git tag:
> > > > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> > > >
> > > > 094e4e31a5af55bb17be87675da41d9aeca062f3
> > > >
> > > > > Staging site:
> > > > > https://maven.apache.org/components/ref/3-LATEST/
> > > > >
> > > > > Vote open for 72 hours.
> > > > >
> > > > > [ ] +1
> > > > > [ ] +0
> > > > > [ ] -1
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Stephen.
> > > >
> > > > 
> -
> > > > 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: [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

Have we got any feedback from the embedder integrations yet?

On Mon 11 Sep 2017 at 22:57, Hervé BOUTEMY  wrote:

> just for the records: it is Windows + Git Bash (MINGW64) only
>
> and there is a chance that adding -Djansi.force=true can force JAnsi
> activation (even if JAnsi fails to detect that it should auto-activate)
>
> details on issue in https://issues.apache.org/jira/browse/MNG-6282 , and a
> future JAnsi issue...
>
> Regards,
>
> Hervé
>
> Le lundi 11 septembre 2017, 12:53:46 CEST Stephen Connolly a écrit :
> > So that is windows only, or were they lost on other OSes for you.
> >
> > I have colours on linux (via docker) and os-x
> >
> > On 11 September 2017 at 12:35, dejan2...@gmail.com 
> >
> > wrote:
> > > +1 (conditionally).
> > >
> > > Tested via project that includes dozen of plugins: 1st tier, MojoHaus
> and
> > > few 3rd party plugins (so to say).
> > >
> > > Everything looks good with one notable regression:
> > > https://issues.apache.org/jira/browse/MNG-6282 Console output has no
> > > colors (regression in Maven 3.5.1)
> > >
> > > Regards,
> > > Dejan
> > >
> > > On 2017-09-10 17:39, Stephen Connolly  >
> > >
> > > wrote:
> > > > Hi,
> > > >
> > > > We solved 25 issues:
> > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > >
> > > version=12338964=Text=12316922
> > >
> > > > There are 350 issues left in JIRA for Maven core:
> > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > >
> > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > >
> > > > Staging repo:
> > > > https://repository.apache.org/content/repositories/maven-1364/
> > > >
> > > > The distributable binaries and sources can be found here:
> > > > https://repository.apache.org/content/repositories/maven-> >
> > > 1364/org/apache/maven/apache-maven/3.5.1/
> > >
> > > > Specifically the zip, tarball and source archives can be found here:
> > > > https://repository.apache.org/content/repositories/maven-> >
> > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
> > >
> > > > https://repository.apache.org/content/repositories/maven-> >
> > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
> > >
> > > > https://repository.apache.org/content/repositories/maven-> >
> > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
> > >
> > > > https://repository.apache.org/content/repositories/maven-> >
> > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
> > >
> > > > Source release checksum(s):
> > > > apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
> > >
> > > bd2059560d
> > >
> > > > apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab
> > >
> > > 69e698eb0e
> > >
> > > > Git tag:
> > > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> > >
> > > 094e4e31a5af55bb17be87675da41d9aeca062f3
> > >
> > > > Staging site:
> > > > https://maven.apache.org/components/ref/3-LATEST/
> > > >
> > > > Vote open for 72 hours.
> > > >
> > > > [ ] +1
> > > > [ ] +0
> > > > [ ] -1
> > > >
> > > > Thanks,
> > > >
> > > > Stephen.
> > >
> > > -
> > > 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: [VOTE] Release Apache Maven 3.5.1

[Hervé BOUTEMY]

just for the records: it is Windows + Git Bash (MINGW64) only

and there is a chance that adding -Djansi.force=true can force JAnsi 
activation (even if JAnsi fails to detect that it should auto-activate)

details on issue in https://issues.apache.org/jira/browse/MNG-6282 , and a 
future JAnsi issue...

Regards,

Hervé

Le lundi 11 septembre 2017, 12:53:46 CEST Stephen Connolly a écrit :
> So that is windows only, or were they lost on other OSes for you.
> 
> I have colours on linux (via docker) and os-x
> 
> On 11 September 2017 at 12:35, dejan2...@gmail.com 
> 
> wrote:
> > +1 (conditionally).
> > 
> > Tested via project that includes dozen of plugins: 1st tier, MojoHaus and
> > few 3rd party plugins (so to say).
> > 
> > Everything looks good with one notable regression:
> > https://issues.apache.org/jira/browse/MNG-6282 Console output has no
> > colors (regression in Maven 3.5.1)
> > 
> > Regards,
> > Dejan
> > 
> > On 2017-09-10 17:39, Stephen Connolly 
> > 
> > wrote:
> > > Hi,
> > > 
> > > We solved 25 issues:
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > 
> > version=12338964=Text=12316922
> > 
> > > There are 350 issues left in JIRA for Maven core:
> > > https://issues.apache.org/jira/issues/?jql=project%20%
> > 
> > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > 
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-1364/
> > > 
> > > The distributable binaries and sources can be found here:
> > > https://repository.apache.org/content/repositories/maven-> > 
> > 1364/org/apache/maven/apache-maven/3.5.1/
> > 
> > > Specifically the zip, tarball and source archives can be found here:
> > > https://repository.apache.org/content/repositories/maven-> > 
> > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
> > 
> > > https://repository.apache.org/content/repositories/maven-> > 
> > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
> > 
> > > https://repository.apache.org/content/repositories/maven-> > 
> > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
> > 
> > > https://repository.apache.org/content/repositories/maven-> > 
> > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
> > 
> > > Source release checksum(s):
> > > apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
> > 
> > bd2059560d
> > 
> > > apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab
> > 
> > 69e698eb0e
> > 
> > > Git tag:
> > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> > 
> > 094e4e31a5af55bb17be87675da41d9aeca062f3
> > 
> > > Staging site:
> > > https://maven.apache.org/components/ref/3-LATEST/
> > > 
> > > Vote open for 72 hours.
> > > 
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > > 
> > > Thanks,
> > > 
> > > Stephen.
> > 
> > -
> > 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: [VOTE] Release Apache Maven 3.5.1

[Robert Scholte]

+1

On Sun, 10 Sep 2017 17:39:12 +0200, Stephen Connolly  
 wrote:



Hi,

We solved 25 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12338964=Text=12316922

There are 350 issues left in JIRA for Maven core:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

Staging repo:
https://repository.apache.org/content/repositories/maven-1364/

The distributable binaries and sources can be found here:
https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/

Specifically the zip, tarball and source archives can be found here:
https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz

Source release checksum(s):
apache-maven-3.5.1-src.tar.gz sha1:  
9eb821f153c7667194aa11ccd099b7bd2059560d
apache-maven-3.5.1-src.zip: sha1:  
121d54b045380a8a4895eb137970ab69e698eb0e


Git tag:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=094e4e31a5af55bb17be87675da41d9aeca062f3

Staging site:
https://maven.apache.org/components/ref/3-LATEST/

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

Thanks,

Stephen.


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

Re: [VOTE] Release Apache Maven 3.5.1

[Robert Scholte]

Nice fix

On Mon, 11 Sep 2017 11:31:34 +0200, Stephen Connolly  
 wrote:



http://git-wip-us.apache.org/repos/asf/maven/diff/542a7a89 to defang the
test going forward, with that change on Azul's Zulu JDK 7 I get:

Linux ddf0318b698b 4.9.46-moby #1 SMP Thu Sep 7 02:53:42 UTC 2017 x86_64
x86_64 x86_64 GNU/Linux
Apache Maven 3.5.1 (094e4e31a5af55bb17be87675da41d9aeca062f3;
2017-09-10T12:42:54Z)
Maven home: /work/bin
Java version: 1.7.0_154, vendor: Azul Systems, Inc.
Java home: /usr/lib/jvm/zulu-7-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.9.46-moby", arch: "amd64", family: "unix"

mvn verify => SUCCESS


On 11 September 2017 at 02:00, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:


So Azul's Zulu 7 does not have

com.sun.script.javascript.RhinoScriptEngineFactory or any
ScriptEngineFactory in the base classloader...

Zulu 8 has jdk.nashorn.api.scripting.NashornScriptEngineFactory

So at this point in time, my analysis is that the
DefaultClassRealmManagerTest is not a valid test when the default
classloader does not have any ScriptEngineFactory... I'm going to commit
a fix, but this should not invalidate the 3.5.1 release

On 11 September 2017 at 01:53, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:


With https://github.com/apache/maven-integration-testing/
commit/a08d65bfb5fedec9f684c13bf5a0dccb96f5cc56 I was able to get
Michael's test failures:

Apache Maven 3.5.1 (094e4e31a5af55bb17be87675da41d9aeca062f3;
2017-09-10T12:42:54Z)
Maven home: /work/bin
Java version: 1.7.0_154, vendor: Azul Systems, Inc.
Java home: /usr/lib/jvm/zulu-7-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.9.46-moby", arch: "amd64", family: "unix"



---
Test set: org.apache.maven.classrealm.DefaultClassRealmManagerTest

---
Tests run: 5, Failures: 5, Errors: 0, Skipped: 0, Time elapsed: 2.128  
sec

<<< FAILURE! - in org.apache.maven.classrealm.De
faultClassRealmManagerTest
testMNG6275_mavenApiRealmDefaultParentClassLoader(org.
apache.maven.classrealm.DefaultClassRealmManagerTest)  Time elapsed:
1.12 sec  <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at junit.framework.TestCase.assertTrue(TestCase.java:201)
at org.apache.maven.classrealm.DefaultClassRealmManagerTest.tes
tMNG6275_mavenApiRealmDefaultParentClassLoader(DefaultClassR
ealmManagerTest.java:91)

testMNG6275_coreRealmDefaultParentClassLoader(org.apache.
maven.classrealm.DefaultClassRealmManagerTest)  Time elapsed: 0.271 sec
 <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at junit.framework.TestCase.assertTrue(TestCase.java:201)
at org.apache.maven.classrealm.DefaultClassRealmManagerTest.tes
tMNG6275_coreRealmDefaultParentClassLoader(DefaultClassRealm
ManagerTest.java:99)

testMNG6275_extensionRealmDefaultParentClassLoader(org.
apache.maven.classrealm.DefaultClassRealmManagerTest)  Time elapsed:
0.251 sec  <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at junit.framework.TestCase.assertTrue(TestCase.java:201)
at org.apache.maven.classrealm.DefaultClassRealmManagerTest.tes
tMNG6275_extensionRealmDefaultParentClassLoader(DefaultClass
RealmManagerTest.java:73)

testMNG6275_pluginRealmDefaultParentClassLoader(org.apache.
maven.classrealm.DefaultClassRealmManagerTest)  Time elapsed: 0.244 sec
 <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at junit.framework.TestCase.assertTrue(TestCase.java:201)
at org.apache.maven.classrealm.DefaultClassRealmManagerTest.tes
tMNG6275_pluginRealmDefaultParentClassLoader(DefaultClassRea
lmManagerTest.java:62)

testMNG6275_projectRealmDefaultParentClassLoader(org.apache.
maven.classrealm.DefaultClassRealmManagerTest)  Time elapsed: 0.242 sec
 <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at junit.framework.TestCase.assertTrue(TestCase.java:201)
at org.apache.maven.classrealm.DefaultClassRealmManagerTest.tes
tMNG6275_projectRealmDefaultParentClassLoader(DefaultClassRe
almManagerTest.java:83)

investigating...

On 11 September 2017 at 01:44, Stephen Connolly <

Re: [VOTE] Release Apache Maven 3.5.1

[Stephane Nicoll]

+1

S.

On Sun, Sep 10, 2017 at 5:39 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Hi,
>
> We solved 25 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> version=12338964=Text=12316922
>
> There are 350 issues left in JIRA for Maven core:
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1364/
>
> The distributable binaries and sources can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/
>
> Specifically the zip, tarball and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
>
> Source release checksum(s):
> apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
> bd2059560d
> apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab69e698eb0e
>
> Git tag:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> 094e4e31a5af55bb17be87675da41d9aeca062f3
>
> Staging site:
> https://maven.apache.org/components/ref/3-LATEST/
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Thanks,
>
> Stephen.
>

Re: [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

So that is windows only, or were they lost on other OSes for you.

I have colours on linux (via docker) and os-x

On 11 September 2017 at 12:35, dejan2...@gmail.com 
wrote:

> +1 (conditionally).
>
> Tested via project that includes dozen of plugins: 1st tier, MojoHaus and
> few 3rd party plugins (so to say).
>
> Everything looks good with one notable regression:
> https://issues.apache.org/jira/browse/MNG-6282 Console output has no
> colors (regression in Maven 3.5.1)
>
> Regards,
> Dejan
>
> On 2017-09-10 17:39, Stephen Connolly 
> wrote:
> > Hi,
> >
> > We solved 25 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> version=12338964=Text=12316922
> >
> > There are 350 issues left in JIRA for Maven core:
> > https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1364/
> >
> > The distributable binaries and sources can be found here:
> > https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/
> >
> > Specifically the zip, tarball and source archives can be found here:
> > https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
> > https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
> > https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
> > https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
> >
> > Source release checksum(s):
> > apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
> bd2059560d
> > apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab
> 69e698eb0e
> >
> > Git tag:
> > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> 094e4e31a5af55bb17be87675da41d9aeca062f3
> >
> > Staging site:
> > https://maven.apache.org/components/ref/3-LATEST/
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > Thanks,
> >
> > Stephen.
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven 3.5.1

[dejan2...@gmail.com]

+1 (conditionally).

Tested via project that includes dozen of plugins: 1st tier, MojoHaus and few 
3rd party plugins (so to say).

Everything looks good with one notable regression:
https://issues.apache.org/jira/browse/MNG-6282 Console output has no colors 
(regression in Maven 3.5.1)

Regards, 
Dejan

On 2017-09-10 17:39, Stephen Connolly  wrote: 
> Hi,
> 
> We solved 25 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12338964=Text=12316922
> 
> There are 350 issues left in JIRA for Maven core:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1364/
> 
> The distributable binaries and sources can be found here:
> https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/
> 
> Specifically the zip, tarball and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
> https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
> https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
> 
> Source release checksum(s):
> apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7bd2059560d
> apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab69e698eb0e
> 
> Git tag:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=094e4e31a5af55bb17be87675da41d9aeca062f3
> 
> Staging site:
> https://maven.apache.org/components/ref/3-LATEST/
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> Thanks,
> 
> Stephen.
> 

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

Re: [VOTE] Release Apache Maven 3.5.1

[Mark Derricutt]

On 11 Sep 2017, at 18:10, Stephen Connolly wrote:

> I wonder if mng-6275 is affecting that plugin

Didn't manage to get a chance to look into this tonight :( Tho that ticket 
mentions nashorn, phantonjs is a C/native headless browser library, so it 
doesn't feel like it could be related.

If there's a build available with a fix for that, welcome to give it a bash.

I'll try carve out some time in the morning to see if I can make a simple 
standalone project...

---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

http://git-wip-us.apache.org/repos/asf/maven/diff/542a7a89 to defang the
test going forward, with that change on Azul's Zulu JDK 7 I get:

Linux ddf0318b698b 4.9.46-moby #1 SMP Thu Sep 7 02:53:42 UTC 2017 x86_64
x86_64 x86_64 GNU/Linux
Apache Maven 3.5.1 (094e4e31a5af55bb17be87675da41d9aeca062f3;
2017-09-10T12:42:54Z)
Maven home: /work/bin
Java version: 1.7.0_154, vendor: Azul Systems, Inc.
Java home: /usr/lib/jvm/zulu-7-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.9.46-moby", arch: "amd64", family: "unix"

mvn verify => SUCCESS


On 11 September 2017 at 02:00, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> So Azul's Zulu 7 does not have
>
> com.sun.script.javascript.RhinoScriptEngineFactory or any
> ScriptEngineFactory in the base classloader...
>
> Zulu 8 has jdk.nashorn.api.scripting.NashornScriptEngineFactory
>
> So at this point in time, my analysis is that the
> DefaultClassRealmManagerTest is not a valid test when the default
> classloader does not have any ScriptEngineFactory... I'm going to commit
> a fix, but this should not invalidate the 3.5.1 release
>
> On 11 September 2017 at 01:53, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> With https://github.com/apache/maven-integration-testing/
>> commit/a08d65bfb5fedec9f684c13bf5a0dccb96f5cc56 I was able to get
>> Michael's test failures:
>>
>> Apache Maven 3.5.1 (094e4e31a5af55bb17be87675da41d9aeca062f3;
>> 2017-09-10T12:42:54Z)
>> Maven home: /work/bin
>> Java version: 1.7.0_154, vendor: Azul Systems, Inc.
>> Java home: /usr/lib/jvm/zulu-7-amd64/jre
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "linux", version: "4.9.46-moby", arch: "amd64", family: "unix"
>>
>>
>> 
>> ---
>> Test set: org.apache.maven.classrealm.DefaultClassRealmManagerTest
>> 
>> ---
>> Tests run: 5, Failures: 5, Errors: 0, Skipped: 0, Time elapsed: 2.128 sec
>> <<< FAILURE! - in org.apache.maven.classrealm.De
>> faultClassRealmManagerTest
>> testMNG6275_mavenApiRealmDefaultParentClassLoader(org.
>> apache.maven.classrealm.DefaultClassRealmManagerTest)  Time elapsed:
>> 1.12 sec  <<< FAILURE!
>> junit.framework.AssertionFailedError: null
>> at junit.framework.Assert.fail(Assert.java:55)
>> at junit.framework.Assert.assertTrue(Assert.java:22)
>> at junit.framework.Assert.assertTrue(Assert.java:31)
>> at junit.framework.TestCase.assertTrue(TestCase.java:201)
>> at org.apache.maven.classrealm.DefaultClassRealmManagerTest.tes
>> tMNG6275_mavenApiRealmDefaultParentClassLoader(DefaultClassR
>> ealmManagerTest.java:91)
>>
>> testMNG6275_coreRealmDefaultParentClassLoader(org.apache.
>> maven.classrealm.DefaultClassRealmManagerTest)  Time elapsed: 0.271 sec
>>  <<< FAILURE!
>> junit.framework.AssertionFailedError: null
>> at junit.framework.Assert.fail(Assert.java:55)
>> at junit.framework.Assert.assertTrue(Assert.java:22)
>> at junit.framework.Assert.assertTrue(Assert.java:31)
>> at junit.framework.TestCase.assertTrue(TestCase.java:201)
>> at org.apache.maven.classrealm.DefaultClassRealmManagerTest.tes
>> tMNG6275_coreRealmDefaultParentClassLoader(DefaultClassRealm
>> ManagerTest.java:99)
>>
>> testMNG6275_extensionRealmDefaultParentClassLoader(org.
>> apache.maven.classrealm.DefaultClassRealmManagerTest)  Time elapsed:
>> 0.251 sec  <<< FAILURE!
>> junit.framework.AssertionFailedError: null
>> at junit.framework.Assert.fail(Assert.java:55)
>> at junit.framework.Assert.assertTrue(Assert.java:22)
>> at junit.framework.Assert.assertTrue(Assert.java:31)
>> at junit.framework.TestCase.assertTrue(TestCase.java:201)
>> at org.apache.maven.classrealm.DefaultClassRealmManagerTest.tes
>> tMNG6275_extensionRealmDefaultParentClassLoader(DefaultClass
>> RealmManagerTest.java:73)
>>
>> testMNG6275_pluginRealmDefaultParentClassLoader(org.apache.
>> maven.classrealm.DefaultClassRealmManagerTest)  Time elapsed: 0.244 sec
>>  <<< FAILURE!
>> junit.framework.AssertionFailedError: null
>> at junit.framework.Assert.fail(Assert.java:55)
>> at junit.framework.Assert.assertTrue(Assert.java:22)
>> at junit.framework.Assert.assertTrue(Assert.java:31)
>> at junit.framework.TestCase.assertTrue(TestCase.java:201)
>> at org.apache.maven.classrealm.DefaultClassRealmManagerTest.tes
>> tMNG6275_pluginRealmDefaultParentClassLoader(DefaultClassRea
>> lmManagerTest.java:62)
>>
>> testMNG6275_projectRealmDefaultParentClassLoader(org.apache.
>> maven.classrealm.DefaultClassRealmManagerTest)  Time elapsed: 0.242 sec
>>  <<< FAILURE!
>> junit.framework.AssertionFailedError: null
>> at junit.framework.Assert.fail(Assert.java:55)
>> at junit.framework.Assert.assertTrue(Assert.java:22)
>> at junit.framework.Assert.assertTrue(Assert.java:31)
>> at junit.framework.TestCase.assertTrue(TestCase.java:201)
>> at org.apache.maven.classrealm.DefaultClassRealmManagerTest.tes
>> 

Re: [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

So Azul's Zulu 7 does not have

com.sun.script.javascript.RhinoScriptEngineFactory or any
ScriptEngineFactory in the base classloader...

Zulu 8 has jdk.nashorn.api.scripting.NashornScriptEngineFactory

So at this point in time, my analysis is that the DefaultClassRealmManagerTest
is not a valid test when the default classloader does not have any
ScriptEngineFactory...
I'm going to commit a fix, but this should not invalidate the 3.5.1 release

On 11 September 2017 at 01:53, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> With https://github.com/apache/maven-integration-testing/commit/
> a08d65bfb5fedec9f684c13bf5a0dccb96f5cc56 I was able to get Michael's test
> failures:
>
> Apache Maven 3.5.1 (094e4e31a5af55bb17be87675da41d9aeca062f3;
> 2017-09-10T12:42:54Z)
> Maven home: /work/bin
> Java version: 1.7.0_154, vendor: Azul Systems, Inc.
> Java home: /usr/lib/jvm/zulu-7-amd64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.46-moby", arch: "amd64", family: "unix"
>
>
> 
> ---
> Test set: org.apache.maven.classrealm.DefaultClassRealmManagerTest
> 
> ---
> Tests run: 5, Failures: 5, Errors: 0, Skipped: 0, Time elapsed: 2.128 sec
> <<< FAILURE! - in org.apache.maven.classrealm.DefaultClassRealmManagerTest
> testMNG6275_mavenApiRealmDefaultParentClassLoader(org.apache.maven.
> classrealm.DefaultClassRealmManagerTest)  Time elapsed: 1.12 sec  <<<
> FAILURE!
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at org.apache.maven.classrealm.DefaultClassRealmManagerTest.testMNG6275_
> mavenApiRealmDefaultParentClassLoader(DefaultClassRealmManagerTest.
> java:91)
>
> testMNG6275_coreRealmDefaultParentClassLoader(org.apache.maven.classrealm.DefaultClassRealmManagerTest)
>  Time elapsed: 0.271 sec  <<< FAILURE!
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at org.apache.maven.classrealm.DefaultClassRealmManagerTest.testMNG6275_
> coreRealmDefaultParentClassLoader(DefaultClassRealmManagerTest.java:99)
>
> testMNG6275_extensionRealmDefaultParentClassLoader(org.apache.maven.
> classrealm.DefaultClassRealmManagerTest)  Time elapsed: 0.251 sec  <<<
> FAILURE!
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at org.apache.maven.classrealm.DefaultClassRealmManagerTest.testMNG6275_
> extensionRealmDefaultParentClassLoader(DefaultClassRealmManagerTest.
> java:73)
>
> testMNG6275_pluginRealmDefaultParentClassLoader(org.apache.maven.
> classrealm.DefaultClassRealmManagerTest)  Time elapsed: 0.244 sec  <<<
> FAILURE!
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at org.apache.maven.classrealm.DefaultClassRealmManagerTest.testMNG6275_
> pluginRealmDefaultParentClassLoader(DefaultClassRealmManagerTest.java:62)
>
> testMNG6275_projectRealmDefaultParentClassLoader(org.apache.maven.
> classrealm.DefaultClassRealmManagerTest)  Time elapsed: 0.242 sec  <<<
> FAILURE!
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at org.apache.maven.classrealm.DefaultClassRealmManagerTest.testMNG6275_
> projectRealmDefaultParentClassLoader(DefaultClassRealmManagerTest.java:83)
>
> investigating...
>
> On 11 September 2017 at 01:44, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> Building the source bundles with the binary bundles in the staging repo
>> using the Dockerfile environments in https://github.com/apache/mave
>> n-integration-testing/tree/master/environments
>>
>> Debian JDK 7
>> ===
>>
>> Linux 65fb832dfe43 4.9.46-moby #1 SMP Thu Sep 7 02:53:42 UTC 2017 x86_64
>> GNU/Linux
>> Apache Maven 3.5.1 (094e4e31a5af55bb17be87675da41d9aeca062f3;
>> 2017-09-10T12:42:54Z)
>> Maven home: /work/bin
>> Java version: 1.7.0_151, vendor: Oracle Corporation
>> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
>> Default locale: en, platform encoding: UTF-8
>> OS 

Re: [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

With
https://github.com/apache/maven-integration-testing/commit/a08d65bfb5fedec9f684c13bf5a0dccb96f5cc56
I was able to get Michael's test failures:

Apache Maven 3.5.1 (094e4e31a5af55bb17be87675da41d9aeca062f3;
2017-09-10T12:42:54Z)
Maven home: /work/bin
Java version: 1.7.0_154, vendor: Azul Systems, Inc.
Java home: /usr/lib/jvm/zulu-7-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.9.46-moby", arch: "amd64", family: "unix"


---
Test set: org.apache.maven.classrealm.DefaultClassRealmManagerTest
---
Tests run: 5, Failures: 5, Errors: 0, Skipped: 0, Time elapsed: 2.128 sec
<<< FAILURE! - in org.apache.maven.classrealm.DefaultClassRealmManagerTest
testMNG6275_mavenApiRealmDefaultParentClassLoader(org.apache.maven.classrealm.DefaultClassRealmManagerTest)
 Time elapsed: 1.12 sec  <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at junit.framework.TestCase.assertTrue(TestCase.java:201)
at
org.apache.maven.classrealm.DefaultClassRealmManagerTest.testMNG6275_mavenApiRealmDefaultParentClassLoader(DefaultClassRealmManagerTest.java:91)

testMNG6275_coreRealmDefaultParentClassLoader(org.apache.maven.classrealm.DefaultClassRealmManagerTest)
 Time elapsed: 0.271 sec  <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at junit.framework.TestCase.assertTrue(TestCase.java:201)
at
org.apache.maven.classrealm.DefaultClassRealmManagerTest.testMNG6275_coreRealmDefaultParentClassLoader(DefaultClassRealmManagerTest.java:99)

testMNG6275_extensionRealmDefaultParentClassLoader(org.apache.maven.classrealm.DefaultClassRealmManagerTest)
 Time elapsed: 0.251 sec  <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at junit.framework.TestCase.assertTrue(TestCase.java:201)
at
org.apache.maven.classrealm.DefaultClassRealmManagerTest.testMNG6275_extensionRealmDefaultParentClassLoader(DefaultClassRealmManagerTest.java:73)

testMNG6275_pluginRealmDefaultParentClassLoader(org.apache.maven.classrealm.DefaultClassRealmManagerTest)
 Time elapsed: 0.244 sec  <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at junit.framework.TestCase.assertTrue(TestCase.java:201)
at
org.apache.maven.classrealm.DefaultClassRealmManagerTest.testMNG6275_pluginRealmDefaultParentClassLoader(DefaultClassRealmManagerTest.java:62)

testMNG6275_projectRealmDefaultParentClassLoader(org.apache.maven.classrealm.DefaultClassRealmManagerTest)
 Time elapsed: 0.242 sec  <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at junit.framework.TestCase.assertTrue(TestCase.java:201)
at
org.apache.maven.classrealm.DefaultClassRealmManagerTest.testMNG6275_projectRealmDefaultParentClassLoader(DefaultClassRealmManagerTest.java:83)

investigating...

On 11 September 2017 at 01:44, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Building the source bundles with the binary bundles in the staging repo
> using the Dockerfile environments in https://github.com/apache/
> maven-integration-testing/tree/master/environments
>
> Debian JDK 7
> ===
>
> Linux 65fb832dfe43 4.9.46-moby #1 SMP Thu Sep 7 02:53:42 UTC 2017 x86_64
> GNU/Linux
> Apache Maven 3.5.1 (094e4e31a5af55bb17be87675da41d9aeca062f3;
> 2017-09-10T12:42:54Z)
> Maven home: /work/bin
> Java version: 1.7.0_151, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
> Default locale: en, platform encoding: UTF-8
> OS name: "linux", version: "4.9.46-moby", arch: "amd64", family: "unix"
>
> mvn verify => SUCCESS
>
> Debian JDK 8
> ===
>
> Linux 11ef1c114b6b 4.9.46-moby #1 SMP Thu Sep 7 02:53:42 UTC 2017 x86_64
> GNU/Linux
> Apache Maven 3.5.1 (094e4e31a5af55bb17be87675da41d9aeca062f3;
> 2017-09-10T12:42:54Z)
> Maven home: /work/bin
> Java version: 1.8.0_141, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en, platform encoding: UTF-8
> OS name: "linux", version: "4.9.46-moby", arch: "amd64", family: "unix"
>
> mvn verify => SUCCESS
>
> Fedora JDK 8
> ===
>
> Linux 54211a0e694e 4.9.46-moby #1 SMP Thu Sep 7 02:53:42 UTC 2017 x86_64
> x86_64 x86_64 GNU/Linux
> Apache 

Re: [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

Building the source bundles with the binary bundles in the staging repo
using the Dockerfile environments in
https://github.com/apache/maven-integration-testing/tree/master/environments

Debian JDK 7
===

Linux 65fb832dfe43 4.9.46-moby #1 SMP Thu Sep 7 02:53:42 UTC 2017 x86_64
GNU/Linux
Apache Maven 3.5.1 (094e4e31a5af55bb17be87675da41d9aeca062f3;
2017-09-10T12:42:54Z)
Maven home: /work/bin
Java version: 1.7.0_151, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "4.9.46-moby", arch: "amd64", family: "unix"

mvn verify => SUCCESS

Debian JDK 8
===

Linux 11ef1c114b6b 4.9.46-moby #1 SMP Thu Sep 7 02:53:42 UTC 2017 x86_64
GNU/Linux
Apache Maven 3.5.1 (094e4e31a5af55bb17be87675da41d9aeca062f3;
2017-09-10T12:42:54Z)
Maven home: /work/bin
Java version: 1.8.0_141, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "4.9.46-moby", arch: "amd64", family: "unix"

mvn verify => SUCCESS

Fedora JDK 8
===

Linux 54211a0e694e 4.9.46-moby #1 SMP Thu Sep 7 02:53:42 UTC 2017 x86_64
x86_64 x86_64 GNU/Linux
Apache Maven 3.5.1 (094e4e31a5af55bb17be87675da41d9aeca062f3;
2017-09-10T12:42:54Z)
Maven home: /work/bin
Java version: 1.8.0_144, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.144-5.b01.fc26.x86_64/jre
Default locale: en_US, platform encoding: ANSI_X3.4-1968
OS name: "linux", version: "4.9.46-moby", arch: "amd64", family: "unix"

mvn verify => SUCCESS

IBM JDK 8


Linux 199631edceed 4.9.46-moby #1 SMP Thu Sep 7 02:53:42 UTC 2017 x86_64
x86_64 x86_64 GNU/Linux
Apache Maven 3.5.1 (094e4e31a5af55bb17be87675da41d9aeca062f3;
2017-09-10T12:42:54Z)
Maven home: /work/bin
Java version: 1.8.0, vendor: IBM Corporation
Java home: /opt/ibm/java/jre
Default locale: en_US, platform encoding: ANSI_X3.4-1968
OS name: "linux", version: "4.9.46-moby", arch: "amd64", family: "unix"

mvn verify => SUCCESS

Asul Zulu JDK 8
=

Linux 10e8f4e46138 4.9.46-moby #1 SMP Thu Sep 7 02:53:42 UTC 2017 x86_64
x86_64 x86_64 GNU/Linux
Apache Maven 3.5.1 (094e4e31a5af55bb17be87675da41d9aeca062f3;
2017-09-10T12:42:54Z)
Maven home: /work/bin
Java version: 1.8.0_144, vendor: Azul Systems, Inc.
Java home: /usr/lib/jvm/zulu-8-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.9.46-moby", arch: "amd64", family: "unix"

mvn verify => SUCCESS

If I get time later I'll run the integration tests.

On 11 September 2017 at 00:20, Dan Tran  wrote:

> False alarm, I missed configure global settings.xml, it is missing the
> default repository setup
>
> -D
>
> On Sun, Sep 10, 2017 at 11:47 PM, Tibor Digana <
> tibor.dig...@googlemail.com>
> wrote:
>
> > +1:
> > 3.5.1 works in my project like a charm ;-)
> >
> > On Sun, Sep 10, 2017 at 5:39 PM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > We solved 25 issues:
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > version=12338964=Text=12316922
> > >
> > > There are 350 issues left in JIRA for Maven core:
> > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-1364/
> > >
> > > The distributable binaries and sources can be found here:
> > > https://repository.apache.org/content/repositories/maven-
> > > 1364/org/apache/maven/apache-maven/3.5.1/
> > >
> > > Specifically the zip, tarball and source archives can be found here:
> > > https://repository.apache.org/content/repositories/maven-
> > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
> > > https://repository.apache.org/content/repositories/maven-
> > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
> > > https://repository.apache.org/content/repositories/maven-
> > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
> > > https://repository.apache.org/content/repositories/maven-
> > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
> > >
> > > Source release checksum(s):
> > > apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
> > > bd2059560d
> > > apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab
> > 69e698eb0e
> > >
> > > Git tag:
> > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> > > 094e4e31a5af55bb17be87675da41d9aeca062f3
> > >
> > > Staging site:
> > > https://maven.apache.org/components/ref/3-LATEST/
> > >
> > > Vote open for 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > > Thanks,
> > >
> > > Stephen.
> > >
> >
> >
> >
> > --
> > Cheers
> > Tibor
> >
>

Re: [VOTE] Release Apache Maven 3.5.1

[Dan Tran]

False alarm, I missed configure global settings.xml, it is missing the
default repository setup

-D

On Sun, Sep 10, 2017 at 11:47 PM, Tibor Digana 
wrote:

> +1:
> 3.5.1 works in my project like a charm ;-)
>
> On Sun, Sep 10, 2017 at 5:39 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Hi,
> >
> > We solved 25 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > version=12338964=Text=12316922
> >
> > There are 350 issues left in JIRA for Maven core:
> > https://issues.apache.org/jira/issues/?jql=project%20%
> > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1364/
> >
> > The distributable binaries and sources can be found here:
> > https://repository.apache.org/content/repositories/maven-
> > 1364/org/apache/maven/apache-maven/3.5.1/
> >
> > Specifically the zip, tarball and source archives can be found here:
> > https://repository.apache.org/content/repositories/maven-
> > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
> > https://repository.apache.org/content/repositories/maven-
> > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
> > https://repository.apache.org/content/repositories/maven-
> > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
> > https://repository.apache.org/content/repositories/maven-
> > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
> >
> > Source release checksum(s):
> > apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
> > bd2059560d
> > apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab
> 69e698eb0e
> >
> > Git tag:
> > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> > 094e4e31a5af55bb17be87675da41d9aeca062f3
> >
> > Staging site:
> > https://maven.apache.org/components/ref/3-LATEST/
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > Thanks,
> >
> > Stephen.
> >
>
>
>
> --
> Cheers
> Tibor
>

Re: [VOTE] Release Apache Maven 3.5.1

[Tibor Digana]

+1:
3.5.1 works in my project like a charm ;-)

On Sun, Sep 10, 2017 at 5:39 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Hi,
>
> We solved 25 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> version=12338964=Text=12316922
>
> There are 350 issues left in JIRA for Maven core:
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1364/
>
> The distributable binaries and sources can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/
>
> Specifically the zip, tarball and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
>
> Source release checksum(s):
> apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
> bd2059560d
> apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab69e698eb0e
>
> Git tag:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> 094e4e31a5af55bb17be87675da41d9aeca062f3
>
> Staging site:
> https://maven.apache.org/components/ref/3-LATEST/
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Thanks,
>
> Stephen.
>



-- 
Cheers
Tibor

Re: [VOTE] Release Apache Maven 3.5.1

[Dan Tran]

I have no issue build maven 3.5.2-SNAPSHOT with clean verify at top level,
 but  the following build fails

mvn clean verify -f apache-maven

C:\views\dev\maven\maven>mvn clean verify -f apache-maven
[INFO] Scanning for projects...
[INFO]
[INFO]

[INFO] Building Apache Maven Distribution 3.5.2-SNAPSHOT
[INFO]

[WARNING] The POM for org.apache.maven:maven-embedder:jar:3.5.2-SNAPSHOT is
missing, no dependency information available
[WARNING] The POM for org.apache.maven:maven-core:jar:3.5.2-SNAPSHOT is
missing, no dependency information available
[WARNING] The POM for org.apache.maven:maven-compat:jar:3.5.2-SNAPSHOT is
missing, no dependency information available
[WARNING] The POM for
org.apache.maven:maven-slf4j-provider:jar:3.5.2-SNAPSHOT is missing, no
dependency information available
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 0.788 s
[INFO] Finished at: 2017-09-10T23:29:22-07:00
[INFO] Final Memory: 10M/243M
[INFO]

[ERROR] Failed to execute goal on project apache-maven: Could not resolve
dependencies for project org.apache.maven:apache-maven:pom:3.5.2-SNAPSHOT:
The following artifacts could not be resolved:
org.apache.maven:maven-embedder:jar:3.5.2-SNAPSHOT,
org.apache.maven:maven-core:jar:3.5.2-SNAPSHOT,
org.apache.maven:maven-compat:jar:3.5.2-SNAPSHOT,
org.apache.maven:maven-slf4j-provider:jar:3.5.2-SNAPSHOT: Could not find
artifact org.apache.maven:maven-embedder:jar:3.5.2-SNAPSHOT -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException


no issue with mvn 3.5.0

-Dan

On Sun, Sep 10, 2017 at 11:10 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I wonder if mng-6275 is affecting that plugin
>
> On Mon 11 Sep 2017 at 01:00, Mark Derricutt  wrote:
>
> > +0 non-commital -
> >
> > Tested on our tiles/osgi based projects and all seems to work, but for
> > some reason - one project that uses the
> > org.openqa.selenium.phantomjs.PhantomJSDriverService seems to blowing up
> > when using 3.5.1 - need to do some more digging and see if I can spot
> whats
> > going on.
> >
> > Will try and dig into this after work tonight.
> >
> > Mark
> >
> > On 11 Sep 2017, at 8:01, Arnaud Héritier wrote:
> >
> > Tested on several projects
> >
> > +1
> >
> > On Sun, Sep 10, 2017 at 5:39 PM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > Hi,
> >
> > We solved 25 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > version=12338964=Text=12316922
> >
> > There are 350 issues left in JIRA for Maven core:
> > https://issues.apache.org/jira/issues/?jql=project%20%
> > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1364/
> >
> > The distributable binaries and sources can be found here:
> > https://repository.apache.org/content/repositories/maven-
> > 1364/org/apache/maven/apache-maven/3.5.1/
> >
> > Specifically the zip, tarball and source archives can be found here:
> > https://repository.apache.org/content/repositories/maven-
> > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
> > https://repository.apache.org/content/repositories/maven-
> > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
> > https://repository.apache.org/content/repositories/maven-
> > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
> > https://repository.apache.org/content/repositories/maven-
> > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
> >
> > Source release checksum(s):
> > apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
> > bd2059560d
> > apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab
> 69e698eb0e
> >
> > Git tag:
> > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> > 094e4e31a5af55bb17be87675da41d9aeca062f3
> >
> > Staging site:
> > https://maven.apache.org/components/ref/3-LATEST/
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > Thanks,
> >
> > Stephen.
> >
> > --
> > -
> > Arnaud Héritier
> > http://aheritier.net
> > Mail/GTalk: aheritier AT gmail DOT com
> > Twitter/Skype : aheritier
> >
> > --
> >
> > "The ease with which a change can 

Re: [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

I wonder if mng-6275 is affecting that plugin

On Mon 11 Sep 2017 at 01:00, Mark Derricutt  wrote:

> +0 non-commital -
>
> Tested on our tiles/osgi based projects and all seems to work, but for
> some reason - one project that uses the
> org.openqa.selenium.phantomjs.PhantomJSDriverService seems to blowing up
> when using 3.5.1 - need to do some more digging and see if I can spot whats
> going on.
>
> Will try and dig into this after work tonight.
>
> Mark
>
> On 11 Sep 2017, at 8:01, Arnaud Héritier wrote:
>
> Tested on several projects
>
> +1
>
> On Sun, Sep 10, 2017 at 5:39 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> Hi,
>
> We solved 25 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> version=12338964=Text=12316922
>
> There are 350 issues left in JIRA for Maven core:
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1364/
>
> The distributable binaries and sources can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/
>
> Specifically the zip, tarball and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
>
> Source release checksum(s):
> apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
> bd2059560d
> apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab69e698eb0e
>
> Git tag:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> 094e4e31a5af55bb17be87675da41d9aeca062f3
>
> Staging site:
> https://maven.apache.org/components/ref/3-LATEST/
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Thanks,
>
> Stephen.
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>
> --
>
> "The ease with which a change can be implemented has no relevance at all
> to whether it is the right change for the (Java) Platform for all time." —
> Mark Reinhold.
>
> Mark Derricutt
> http://www.theoryinpractice.net
> http://www.chaliceofblood.net
> http://plus.google.com/+MarkDerricutt
> http://twitter.com/talios
> http://facebook.com/mderricutt
>
-- 
Sent from my phone

Re: [VOTE] Release Apache Maven 3.5.1

[Hervé BOUTEMY]

just tested "mvn verify" on Maven (did not build it previously, then no 3.5.2-
SNAPSHOT artifact in my local repo), and works like a charm (as expected since 
artifacts are resolved from reactor)

I can't reproduce the issue: does anybody else have same problems?

Regards,

Hervé

Le dimanche 10 septembre 2017, 14:50:09 CEST Dan Tran a écrit :
> Looks like 3.5.1 not able to resolve snapshot dependencies
> 
> i just clone out apache-maven and, change directory to apache-maven and
> build from there
> 
> here is error
> 
> [ERROR] Failed to execute goal on project apache-maven: Could not resolve
> dependencies for project org.apache.maven:apache-maven:pom:3.5.2-SNAPSHOT:
> The following artifacts could not be resolved:
> org.apache.maven:maven-embedder:jar:3.5.2-SNAPSHOT,
> org.apache.maven:maven-core:jar:3.5.2-SNAPSHOT,
> org.apache.maven:maven-compat:jar:3.5.2-SNAPSHOT,
> org.apache.maven:maven-slf4j-provider:jar:3.5.2-SNAPSHOT: Could not find
> artifact org.apache.maven:maven-embedder:jar:3.5.2-SNAPSHOT -> [Help 1]
> 
> my build is behind artifactory
> 
> Same issue also found at my  internal project
> 
> 
> -Dan
> 
> On Sun, Sep 10, 2017 at 1:01 PM, Arnaud Héritier 
> 
> wrote:
> > Tested on several projects
> > 
> > +1
> > 
> > On Sun, Sep 10, 2017 at 5:39 PM, Stephen Connolly <
> > 
> > stephen.alan.conno...@gmail.com> wrote:
> > > Hi,
> > > 
> > > We solved 25 issues:
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > version=12338964=Text=12316922
> > > 
> > > There are 350 issues left in JIRA for Maven core:
> > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > > 
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-1364/
> > > 
> > > The distributable binaries and sources can be found here:
> > > https://repository.apache.org/content/repositories/maven-> > > 
> > > 1364/org/apache/maven/apache-maven/3.5.1/
> > > 
> > > Specifically the zip, tarball and source archives can be found here:
> > > https://repository.apache.org/content/repositories/maven-> > > 
> > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
> > > https://repository.apache.org/content/repositories/maven-> > > 
> > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
> > > https://repository.apache.org/content/repositories/maven-> > > 
> > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
> > > https://repository.apache.org/content/repositories/maven-> > > 
> > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
> > > 
> > > Source release checksum(s):
> > > apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
> > > bd2059560d
> > > apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab
> > 
> > 69e698eb0e
> > 
> > > Git tag:
> > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> > > 094e4e31a5af55bb17be87675da41d9aeca062f3
> > > 
> > > Staging site:
> > > https://maven.apache.org/components/ref/3-LATEST/
> > > 
> > > Vote open for 72 hours.
> > > 
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > > 
> > > Thanks,
> > > 
> > > Stephen.
> > 
> > --
> > -
> > Arnaud Héritier
> > http://aheritier.net
> > Mail/GTalk: aheritier AT gmail DOT com
> > Twitter/Skype : aheritier



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

Re: [VOTE] Release Apache Maven 3.5.1

[Mark Derricutt]

+0 non-commital -

Tested on our tiles/osgi based projects and all seems to work, but for some 
reason - one project that uses the 
org.openqa.selenium.phantomjs.PhantomJSDriverService seems to blowing up when 
using 3.5.1 - need to do some more digging and see if I can spot whats going on.

Will try and dig into this after work tonight.

Mark


On 11 Sep 2017, at 8:01, Arnaud Héritier wrote:

> Tested on several projects
>
> +1
>
> On Sun, Sep 10, 2017 at 5:39 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> Hi,
>>
>> We solved 25 issues:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> version=12338964=Text=12316922
>>
>> There are 350 issues left in JIRA for Maven core:
>> https://issues.apache.org/jira/issues/?jql=project%20%
>> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
>> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1364/
>>
>> The distributable binaries and sources can be found here:
>> https://repository.apache.org/content/repositories/maven-
>> 1364/org/apache/maven/apache-maven/3.5.1/
>>
>> Specifically the zip, tarball and source archives can be found here:
>> https://repository.apache.org/content/repositories/maven-
>> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
>> https://repository.apache.org/content/repositories/maven-
>> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
>> https://repository.apache.org/content/repositories/maven-
>> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
>> https://repository.apache.org/content/repositories/maven-
>> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
>>
>> Source release checksum(s):
>> apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
>> bd2059560d
>> apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab69e698eb0e
>>
>> Git tag:
>> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
>> 094e4e31a5af55bb17be87675da41d9aeca062f3
>>
>> Staging site:
>> https://maven.apache.org/components/ref/3-LATEST/
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> Thanks,
>>
>> Stephen.
>>
>
>
>
> -- 
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven 3.5.1

[Dan Tran]

Looks like 3.5.1 not able to resolve snapshot dependencies

i just clone out apache-maven and, change directory to apache-maven and
build from there

here is error

[ERROR] Failed to execute goal on project apache-maven: Could not resolve
dependencies for project org.apache.maven:apache-maven:pom:3.5.2-SNAPSHOT:
The following artifacts could not be resolved:
org.apache.maven:maven-embedder:jar:3.5.2-SNAPSHOT,
org.apache.maven:maven-core:jar:3.5.2-SNAPSHOT,
org.apache.maven:maven-compat:jar:3.5.2-SNAPSHOT,
org.apache.maven:maven-slf4j-provider:jar:3.5.2-SNAPSHOT: Could not find
artifact org.apache.maven:maven-embedder:jar:3.5.2-SNAPSHOT -> [Help 1]

my build is behind artifactory

Same issue also found at my  internal project


-Dan

On Sun, Sep 10, 2017 at 1:01 PM, Arnaud Héritier 
wrote:

> Tested on several projects
>
> +1
>
> On Sun, Sep 10, 2017 at 5:39 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Hi,
> >
> > We solved 25 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > version=12338964=Text=12316922
> >
> > There are 350 issues left in JIRA for Maven core:
> > https://issues.apache.org/jira/issues/?jql=project%20%
> > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1364/
> >
> > The distributable binaries and sources can be found here:
> > https://repository.apache.org/content/repositories/maven-
> > 1364/org/apache/maven/apache-maven/3.5.1/
> >
> > Specifically the zip, tarball and source archives can be found here:
> > https://repository.apache.org/content/repositories/maven-
> > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
> > https://repository.apache.org/content/repositories/maven-
> > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
> > https://repository.apache.org/content/repositories/maven-
> > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
> > https://repository.apache.org/content/repositories/maven-
> > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
> >
> > Source release checksum(s):
> > apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
> > bd2059560d
> > apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab
> 69e698eb0e
> >
> > Git tag:
> > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> > 094e4e31a5af55bb17be87675da41d9aeca062f3
> >
> > Staging site:
> > https://maven.apache.org/components/ref/3-LATEST/
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > Thanks,
> >
> > Stephen.
> >
>
>
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>

Re: [VOTE] Release Apache Maven 3.5.1

[Arnaud Héritier]

Tested on several projects

+1

On Sun, Sep 10, 2017 at 5:39 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Hi,
>
> We solved 25 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> version=12338964=Text=12316922
>
> There are 350 issues left in JIRA for Maven core:
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1364/
>
> The distributable binaries and sources can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/
>
> Specifically the zip, tarball and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
>
> Source release checksum(s):
> apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
> bd2059560d
> apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab69e698eb0e
>
> Git tag:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> 094e4e31a5af55bb17be87675da41d9aeca062f3
>
> Staging site:
> https://maven.apache.org/components/ref/3-LATEST/
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Thanks,
>
> Stephen.
>



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

Re: [VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

Analyzer...

stagingUrl: https://repository.apache.org/content/repositories/maven-1364
groupId: org.apache.maven
artifactId: apache-maven
version: 3.5.1

Source ZIP url exists.
https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip

Source ZIP SHA1 url exists.
https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip.sha1

Binary ZIP url exists.
https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip

Binary ZIP SHA1 url exists.
https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip.sha1

Calculated SHA1 of source ZIP matches published SHA1 of source ZIP.
121d54b045380a8a4895eb137970ab69e698eb0e

Calculated SHA1 of binary ZIP matches published SHA1 of binary ZIP.
8a3d7ec315e0759eb1d1c6f9286b243a006bf91e

Git revision of release as determined from
maven-core-3.5.1.jar:org/apache/maven/messages/build.properties(buildNumber):
094e4e31a5af55bb17be87675da41d9aeca062f3

Files that are present in the source distribution but not in the source
revision:
DEPENDENCIES


On 10 September 2017 at 16:39, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Hi,
>
> We solved 25 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> version=12338964=Text=12316922
>
> There are 350 issues left in JIRA for Maven core:
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1364/
>
> The distributable binaries and sources can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/
>
> Specifically the zip, tarball and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
> https://repository.apache.org/content/repositories/maven-
> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
>
> Source release checksum(s):
> apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
> bd2059560d
> apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab69e698eb0e
>
> Git tag:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> 094e4e31a5af55bb17be87675da41d9aeca062f3
>
> Staging site:
> https://maven.apache.org/components/ref/3-LATEST/
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Thanks,
>
> Stephen.
>

[VOTE] Release Apache Maven 3.5.1

[Stephen Connolly]

Hi,

We solved 25 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12338964=Text=12316922

There are 350 issues left in JIRA for Maven core:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

Staging repo:
https://repository.apache.org/content/repositories/maven-1364/

The distributable binaries and sources can be found here:
https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/

Specifically the zip, tarball and source archives can be found here:
https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
https://repository.apache.org/content/repositories/maven-1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz

Source release checksum(s):
apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7bd2059560d
apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab69e698eb0e

Git tag:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=094e4e31a5af55bb17be87675da41d9aeca062f3

Staging site:
https://maven.apache.org/components/ref/3-LATEST/

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

Thanks,

Stephen.