Re: ATTN: Maven core build is broken

[Tibor Digana]

Class-Path is used in Manifest unless you configure the plugin to use env
variable CLASSPATH.

On Thu, Aug 31, 2017 at 12:24 AM, Igor Fedorenko 
wrote:

> How does surefire setup jvm classpath when it runs plugin unit and
> integration tests?
>
> --
> Regards,
> Igor
>
> On Wed, Aug 30, 2017, at 05:22 PM, Stephen Connolly wrote:
> > Unit test is still present in my branch, so should be a yes (if your unit
> > test works)
> >
> > On Wed 30 Aug 2017 at 21:50, Robert Scholte 
> wrote:
> >
> > > But can you access classes via the ServiceLoader?
> > >
> > > On Wed, 30 Aug 2017 22:48:40 +0200, Stephen Connolly
> > >  wrote:
> > >
> > > > Oh wow!
> > > >
> > > https://builds.apache.org/blue/organizations/jenkins/
> maven-3.x-jenkinsfile/detail/mng-6275/3/pipeline
> > > >
> > > > Can we get Stuart and Igor to review:
> > > > https://github.com/apache/maven/compare/mng-6275
> > > >
> > > > Seems almost too easy!
> > > >
> > > >
> > > >
> > > > On 30 August 2017 at 17:02, Robert Scholte 
> wrote:
> > > >
> > > >> I agree
> > > >>
> > > >>
> > > >> On Wed, 30 Aug 2017 18:01:12 +0200, Stephen Connolly <
> > > >> stephen.alan.conno...@gmail.com> wrote:
> > > >>
> > > >> I think we'll de-scope 6275 for 3.5.1
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Wed 30 Aug 2017 at 16:04, Stephen Connolly <
> > > >>> stephen.alan.conno...@gmail.com> wrote:
> > > >>>
> > > >>> Hmmm... looking like we may have to descope MNG-6275... I'll do
> some
> > > >>> more
> > >  digging first though
> > > 
> > > 
> > >  On 30 August 2017 at 04:34, Stephen Connolly <
> > >  stephen.alan.conno...@gmail.com> wrote:
> > > 
> > >  fef668789f6abe79f603b96a8ee6f13ea52de4df should verify if that
> fixes
> > > > things
> > > >
> > > > On 30 August 2017 at 04:13, Stuart McCulloch 
> > > > wrote:
> > > >
> > > > On Wednesday, 30 August 2017 at 10:26, Stephen Connolly wrote:
> > > >> >
> > > >> https://github.com/apache/maven/commit/39004f6aee634a0ac6daa
> > > >> 1f99add299ff439f5ec
> > > >> > should fix
> > > >> >
> > > >> >
> > > >>
> > > >> Is it worth storing the chosen context/system loader in a member
> > > >> variable, or maybe even statically like PARENT_CLASSLOADER,
> rather
> > > >> than
> > > >> checking each time?
> > > >>
> > > >> This would also avoid the off-chance that something changes the
> > > >> thread’s
> > > >> context loader during the build which could then influence
> > > >> subsequent
> > > >> calls
> > > >> to “newRealm”.
> > > >>
> > > >> (IIUC when embedding we’d expect the context loader to be set
> > > >> correctly
> > > >> during construction of the realm manager, and that same loader
> > > >> should
> > > >> then
> > > >> be used for all realms)
> > > >> > On 30 August 2017 at 02:09, Robert Scholte <
> rfscho...@apache.org
> > > >> (mailto:rfscho...@apache.org)> wrote:
> > > >> >
> > > >> > > Now that the ITs are all in place again it is good to see
> that
> > > >> these
> > > >> > > failures reflect the concerns of Igor.
> > > >> > > Originally this issue said it was Java 9 related, but this
> is a
> > > >> Java
> > > >> 8
> > > >> > > issue as well, so there's no real need to include it for
> 3.5.1
> > > >> > > I'll revert this commit and reopen the issue.
> > > >> > > Future analysis must answer the question where and how the
> > > >> classloading
> > > >> > > must be improved.
> > > >> > >
> > > >> > > Robert
> > > >> > >
> > > >> > >
> > > >> > > On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
> > > >> > > stephen.alan.conno...@gmail.com (mailto:
> > > >> stephen.alan.conno...@gmail.com)> wrote:
> > > >> > >
> > > >> > > Ok, looking a the results of the bisect-0 through bisect-3
> > > >> builds,
> > > >> 0
> > > >> and 1
> > > >> > > > both fail just for the MNG-6127 integration tests,
> bisect-2
> > > >> adds
> > > >> the fix
> > > >> > > > for MNG-6127, so the build passes... bisect-3 also
> passes, so
> > > >> the
> > > >> smoking
> > > >> > > > gun is...
> > > >> > > >
> > > >> > > > https://github.com/apache/maven/commit/
> f047ea143766fd22ae420
> > > >> > > > 40e6805bef287f3cc3e
> > > >> > > >
> > > >> > > > On 29 August 2017 at 22:17, Stephen Connolly <
> > > >> > > > stephen.alan.conno...@gmail.com (mailto:
> > > >> stephen.alan.conno...@gmail.com)> wrote:
> > > >> > > >
> > > >> > > > bisect-0 is the last known good commit with the
> Jenkinsfile
> > > >> fix
> > > >> to
> > > >> confirm
> > > >> > > > > that the failures are not another infra related change
> > > >> > > > >
> > > >> > > > > On 29 August 2017 at 22:13, Stephen Connolly
> > > 

Re: ATTN: Maven core build is broken

[Igor Fedorenko]

How does surefire setup jvm classpath when it runs plugin unit and
integration tests?

-- 
Regards,
Igor

On Wed, Aug 30, 2017, at 05:22 PM, Stephen Connolly wrote:
> Unit test is still present in my branch, so should be a yes (if your unit
> test works)
> 
> On Wed 30 Aug 2017 at 21:50, Robert Scholte  wrote:
> 
> > But can you access classes via the ServiceLoader?
> >
> > On Wed, 30 Aug 2017 22:48:40 +0200, Stephen Connolly
> >  wrote:
> >
> > > Oh wow!
> > >
> > https://builds.apache.org/blue/organizations/jenkins/maven-3.x-jenkinsfile/detail/mng-6275/3/pipeline
> > >
> > > Can we get Stuart and Igor to review:
> > > https://github.com/apache/maven/compare/mng-6275
> > >
> > > Seems almost too easy!
> > >
> > >
> > >
> > > On 30 August 2017 at 17:02, Robert Scholte  wrote:
> > >
> > >> I agree
> > >>
> > >>
> > >> On Wed, 30 Aug 2017 18:01:12 +0200, Stephen Connolly <
> > >> stephen.alan.conno...@gmail.com> wrote:
> > >>
> > >> I think we'll de-scope 6275 for 3.5.1
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Wed 30 Aug 2017 at 16:04, Stephen Connolly <
> > >>> stephen.alan.conno...@gmail.com> wrote:
> > >>>
> > >>> Hmmm... looking like we may have to descope MNG-6275... I'll do some
> > >>> more
> >  digging first though
> > 
> > 
> >  On 30 August 2017 at 04:34, Stephen Connolly <
> >  stephen.alan.conno...@gmail.com> wrote:
> > 
> >  fef668789f6abe79f603b96a8ee6f13ea52de4df should verify if that fixes
> > > things
> > >
> > > On 30 August 2017 at 04:13, Stuart McCulloch 
> > > wrote:
> > >
> > > On Wednesday, 30 August 2017 at 10:26, Stephen Connolly wrote:
> > >> >
> > >> https://github.com/apache/maven/commit/39004f6aee634a0ac6daa
> > >> 1f99add299ff439f5ec
> > >> > should fix
> > >> >
> > >> >
> > >>
> > >> Is it worth storing the chosen context/system loader in a member
> > >> variable, or maybe even statically like PARENT_CLASSLOADER, rather
> > >> than
> > >> checking each time?
> > >>
> > >> This would also avoid the off-chance that something changes the
> > >> thread’s
> > >> context loader during the build which could then influence
> > >> subsequent
> > >> calls
> > >> to “newRealm”.
> > >>
> > >> (IIUC when embedding we’d expect the context loader to be set
> > >> correctly
> > >> during construction of the realm manager, and that same loader
> > >> should
> > >> then
> > >> be used for all realms)
> > >> > On 30 August 2017 at 02:09, Robert Scholte  > >> (mailto:rfscho...@apache.org)> wrote:
> > >> >
> > >> > > Now that the ITs are all in place again it is good to see that
> > >> these
> > >> > > failures reflect the concerns of Igor.
> > >> > > Originally this issue said it was Java 9 related, but this is a
> > >> Java
> > >> 8
> > >> > > issue as well, so there's no real need to include it for 3.5.1
> > >> > > I'll revert this commit and reopen the issue.
> > >> > > Future analysis must answer the question where and how the
> > >> classloading
> > >> > > must be improved.
> > >> > >
> > >> > > Robert
> > >> > >
> > >> > >
> > >> > > On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
> > >> > > stephen.alan.conno...@gmail.com (mailto:
> > >> stephen.alan.conno...@gmail.com)> wrote:
> > >> > >
> > >> > > Ok, looking a the results of the bisect-0 through bisect-3
> > >> builds,
> > >> 0
> > >> and 1
> > >> > > > both fail just for the MNG-6127 integration tests, bisect-2
> > >> adds
> > >> the fix
> > >> > > > for MNG-6127, so the build passes... bisect-3 also passes, so
> > >> the
> > >> smoking
> > >> > > > gun is...
> > >> > > >
> > >> > > > https://github.com/apache/maven/commit/f047ea143766fd22ae420
> > >> > > > 40e6805bef287f3cc3e
> > >> > > >
> > >> > > > On 29 August 2017 at 22:17, Stephen Connolly <
> > >> > > > stephen.alan.conno...@gmail.com (mailto:
> > >> stephen.alan.conno...@gmail.com)> wrote:
> > >> > > >
> > >> > > > bisect-0 is the last known good commit with the Jenkinsfile
> > >> fix
> > >> to
> > >> confirm
> > >> > > > > that the failures are not another infra related change
> > >> > > > >
> > >> > > > > On 29 August 2017 at 22:13, Stephen Connolly
> > >> > > > >  > >> > > > > com> wrote:
> > >> > > > >
> > >> > > > > I have pushed bisect-1, bisect-2 and bisect-3 to see if we
> > >> can
> > >> identify
> > >> > > > > > the problematic commit since the last known good build of
> > >> master (#123
> > >> > > > > > for
> > >> > > > > > commit 4f2a2dba89251d9045fe9944783509a397491da3)
> > >> > > > > >
> > >> > > > > > On 29 August 2017 

Re: ATTN: Maven core build is broken

[Stephen Connolly]

Unit test is still present in my branch, so should be a yes (if your unit
test works)

On Wed 30 Aug 2017 at 21:50, Robert Scholte  wrote:

> But can you access classes via the ServiceLoader?
>
> On Wed, 30 Aug 2017 22:48:40 +0200, Stephen Connolly
>  wrote:
>
> > Oh wow!
> >
> https://builds.apache.org/blue/organizations/jenkins/maven-3.x-jenkinsfile/detail/mng-6275/3/pipeline
> >
> > Can we get Stuart and Igor to review:
> > https://github.com/apache/maven/compare/mng-6275
> >
> > Seems almost too easy!
> >
> >
> >
> > On 30 August 2017 at 17:02, Robert Scholte  wrote:
> >
> >> I agree
> >>
> >>
> >> On Wed, 30 Aug 2017 18:01:12 +0200, Stephen Connolly <
> >> stephen.alan.conno...@gmail.com> wrote:
> >>
> >> I think we'll de-scope 6275 for 3.5.1
> >>>
> >>>
> >>>
> >>>
> >>> On Wed 30 Aug 2017 at 16:04, Stephen Connolly <
> >>> stephen.alan.conno...@gmail.com> wrote:
> >>>
> >>> Hmmm... looking like we may have to descope MNG-6275... I'll do some
> >>> more
>  digging first though
> 
> 
>  On 30 August 2017 at 04:34, Stephen Connolly <
>  stephen.alan.conno...@gmail.com> wrote:
> 
>  fef668789f6abe79f603b96a8ee6f13ea52de4df should verify if that fixes
> > things
> >
> > On 30 August 2017 at 04:13, Stuart McCulloch 
> > wrote:
> >
> > On Wednesday, 30 August 2017 at 10:26, Stephen Connolly wrote:
> >> >
> >> https://github.com/apache/maven/commit/39004f6aee634a0ac6daa
> >> 1f99add299ff439f5ec
> >> > should fix
> >> >
> >> >
> >>
> >> Is it worth storing the chosen context/system loader in a member
> >> variable, or maybe even statically like PARENT_CLASSLOADER, rather
> >> than
> >> checking each time?
> >>
> >> This would also avoid the off-chance that something changes the
> >> thread’s
> >> context loader during the build which could then influence
> >> subsequent
> >> calls
> >> to “newRealm”.
> >>
> >> (IIUC when embedding we’d expect the context loader to be set
> >> correctly
> >> during construction of the realm manager, and that same loader
> >> should
> >> then
> >> be used for all realms)
> >> > On 30 August 2017 at 02:09, Robert Scholte  >> (mailto:rfscho...@apache.org)> wrote:
> >> >
> >> > > Now that the ITs are all in place again it is good to see that
> >> these
> >> > > failures reflect the concerns of Igor.
> >> > > Originally this issue said it was Java 9 related, but this is a
> >> Java
> >> 8
> >> > > issue as well, so there's no real need to include it for 3.5.1
> >> > > I'll revert this commit and reopen the issue.
> >> > > Future analysis must answer the question where and how the
> >> classloading
> >> > > must be improved.
> >> > >
> >> > > Robert
> >> > >
> >> > >
> >> > > On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
> >> > > stephen.alan.conno...@gmail.com (mailto:
> >> stephen.alan.conno...@gmail.com)> wrote:
> >> > >
> >> > > Ok, looking a the results of the bisect-0 through bisect-3
> >> builds,
> >> 0
> >> and 1
> >> > > > both fail just for the MNG-6127 integration tests, bisect-2
> >> adds
> >> the fix
> >> > > > for MNG-6127, so the build passes... bisect-3 also passes, so
> >> the
> >> smoking
> >> > > > gun is...
> >> > > >
> >> > > > https://github.com/apache/maven/commit/f047ea143766fd22ae420
> >> > > > 40e6805bef287f3cc3e
> >> > > >
> >> > > > On 29 August 2017 at 22:17, Stephen Connolly <
> >> > > > stephen.alan.conno...@gmail.com (mailto:
> >> stephen.alan.conno...@gmail.com)> wrote:
> >> > > >
> >> > > > bisect-0 is the last known good commit with the Jenkinsfile
> >> fix
> >> to
> >> confirm
> >> > > > > that the failures are not another infra related change
> >> > > > >
> >> > > > > On 29 August 2017 at 22:13, Stephen Connolly
> >> > > > >  >> > > > > com> wrote:
> >> > > > >
> >> > > > > I have pushed bisect-1, bisect-2 and bisect-3 to see if we
> >> can
> >> identify
> >> > > > > > the problematic commit since the last known good build of
> >> master (#123
> >> > > > > > for
> >> > > > > > commit 4f2a2dba89251d9045fe9944783509a397491da3)
> >> > > > > >
> >> > > > > > On 29 August 2017 at 22:09, Stephen Connolly <
> >> > > > > > stephen.alan.conno...@gmail.com (mailto:
> >> stephen.alan.conno...@gmail.com)> wrote:
> >> > > > > >
> >> > > > > > Failure is in testBootstrap, probably something obvious,
> >> here's the
> >> > > > > > > problematic build log... you can inspect for yourself at
> >> > > > > > >
> >> https://builds.apache.org/blue/organizations/jenkins/mave
> >> > > > > > > 

Re: ATTN: Maven core build is broken

[Robert Scholte]

But can you access classes via the ServiceLoader?

On Wed, 30 Aug 2017 22:48:40 +0200, Stephen Connolly  
 wrote:



Oh wow!
https://builds.apache.org/blue/organizations/jenkins/maven-3.x-jenkinsfile/detail/mng-6275/3/pipeline

Can we get Stuart and Igor to review:
https://github.com/apache/maven/compare/mng-6275

Seems almost too easy!



On 30 August 2017 at 17:02, Robert Scholte  wrote:


I agree


On Wed, 30 Aug 2017 18:01:12 +0200, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

I think we'll de-scope 6275 for 3.5.1





On Wed 30 Aug 2017 at 16:04, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

Hmmm... looking like we may have to descope MNG-6275... I'll do some  
more

digging first though


On 30 August 2017 at 04:34, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

fef668789f6abe79f603b96a8ee6f13ea52de4df should verify if that fixes

things

On 30 August 2017 at 04:13, Stuart McCulloch   
wrote:


On Wednesday, 30 August 2017 at 10:26, Stephen Connolly wrote:

>
https://github.com/apache/maven/commit/39004f6aee634a0ac6daa
1f99add299ff439f5ec
> should fix
>
>

Is it worth storing the chosen context/system loader in a member
variable, or maybe even statically like PARENT_CLASSLOADER, rather  
than

checking each time?

This would also avoid the off-chance that something changes the
thread’s
context loader during the build which could then influence  
subsequent

calls
to “newRealm”.

(IIUC when embedding we’d expect the context loader to be set  
correctly
during construction of the realm manager, and that same loader  
should

then
be used for all realms)
> On 30 August 2017 at 02:09, Robert Scholte  wrote:
>
> > Now that the ITs are all in place again it is good to see that
these
> > failures reflect the concerns of Igor.
> > Originally this issue said it was Java 9 related, but this is a
Java
8
> > issue as well, so there's no real need to include it for 3.5.1
> > I'll revert this commit and reopen the issue.
> > Future analysis must answer the question where and how the
classloading
> > must be improved.
> >
> > Robert
> >
> >
> > On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
> > stephen.alan.conno...@gmail.com (mailto:
stephen.alan.conno...@gmail.com)> wrote:
> >
> > Ok, looking a the results of the bisect-0 through bisect-3  
builds,

0
and 1
> > > both fail just for the MNG-6127 integration tests, bisect-2  
adds

the fix
> > > for MNG-6127, so the build passes... bisect-3 also passes, so  
the

smoking
> > > gun is...
> > >
> > > https://github.com/apache/maven/commit/f047ea143766fd22ae420
> > > 40e6805bef287f3cc3e
> > >
> > > On 29 August 2017 at 22:17, Stephen Connolly <
> > > stephen.alan.conno...@gmail.com (mailto:
stephen.alan.conno...@gmail.com)> wrote:
> > >
> > > bisect-0 is the last known good commit with the Jenkinsfile  
fix

to
confirm
> > > > that the failures are not another infra related change
> > > >
> > > > On 29 August 2017 at 22:13, Stephen Connolly
> > > >  > > > com> wrote:
> > > >
> > > > I have pushed bisect-1, bisect-2 and bisect-3 to see if we  
can

identify
> > > > > the problematic commit since the last known good build of
master (#123
> > > > > for
> > > > > commit 4f2a2dba89251d9045fe9944783509a397491da3)
> > > > >
> > > > > On 29 August 2017 at 22:09, Stephen Connolly <
> > > > > stephen.alan.conno...@gmail.com (mailto:
stephen.alan.conno...@gmail.com)> wrote:
> > > > >
> > > > > Failure is in testBootstrap, probably something obvious,
here's the
> > > > > > problematic build log... you can inspect for yourself at
> > > > > >  
https://builds.apache.org/blue/organizations/jenkins/mave
> > > > > > n-3.x-jenkinsfile/detail/master/128/tests but there is  
no

point in
> > > > > > looking at any tests other than testBootstrap as if that
fails
> > > > > > everything
> > > > > > else will fail too
> > > > > >
> > > > > > [WARNING] Error injecting:  
org.apache.maven.plugins.depen

> > > > > > dency.resolvers.ResolvePluginsMojo
> > > > > > com.google.inject.ProvisionException: Unable to  
provision,

see the
> > > > > > following errors:
> > > > > > 1) No implementation for org.apache.maven.artifact.hand
> > > > > > ler.manager.ArtifactHandlerManager was bound.
> > > > > > while locating org.apache.maven.plugins.depen
> > > > > > dency.resolvers.ResolvePluginsMojo
> > > > > > 1 error
> > > > > > at
com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.j
> > > > > > ava:1025)
> > > > > > at
com.google.inject.internal.InjectorImpl.getInstance(Injector
> > > > > > Impl.java:1051)
> > > > > > at
org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDef
> > > > > > erredClass.java:48)
> > > > > > at com.google.inject.internal.Pro
viderInternalFactory.provision
> > > > > > (ProviderInternalFactory.java:81)
> > > > > > at com.google.inject.internal.Int

Re: ATTN: Maven core build is broken

[Stephen Connolly]

Oh wow!
https://builds.apache.org/blue/organizations/jenkins/maven-3.x-jenkinsfile/detail/mng-6275/3/pipeline

Can we get Stuart and Igor to review:
https://github.com/apache/maven/compare/mng-6275

Seems almost too easy!



On 30 August 2017 at 17:02, Robert Scholte  wrote:

> I agree
>
>
> On Wed, 30 Aug 2017 18:01:12 +0200, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> I think we'll de-scope 6275 for 3.5.1
>>
>>
>>
>>
>> On Wed 30 Aug 2017 at 16:04, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>> Hmmm... looking like we may have to descope MNG-6275... I'll do some more
>>> digging first though
>>>
>>>
>>> On 30 August 2017 at 04:34, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
>>> fef668789f6abe79f603b96a8ee6f13ea52de4df should verify if that fixes
 things

 On 30 August 2017 at 04:13, Stuart McCulloch  wrote:

 On Wednesday, 30 August 2017 at 10:26, Stephen Connolly wrote:
> >
> https://github.com/apache/maven/commit/39004f6aee634a0ac6daa
> 1f99add299ff439f5ec
> > should fix
> >
> >
>
> Is it worth storing the chosen context/system loader in a member
> variable, or maybe even statically like PARENT_CLASSLOADER, rather than
> checking each time?
>
> This would also avoid the off-chance that something changes the
> thread’s
> context loader during the build which could then influence subsequent
> calls
> to “newRealm”.
>
> (IIUC when embedding we’d expect the context loader to be set correctly
> during construction of the realm manager, and that same loader should
> then
> be used for all realms)
> > On 30 August 2017 at 02:09, Robert Scholte  (mailto:rfscho...@apache.org)> wrote:
> >
> > > Now that the ITs are all in place again it is good to see that
> these
> > > failures reflect the concerns of Igor.
> > > Originally this issue said it was Java 9 related, but this is a
> Java
> 8
> > > issue as well, so there's no real need to include it for 3.5.1
> > > I'll revert this commit and reopen the issue.
> > > Future analysis must answer the question where and how the
> classloading
> > > must be improved.
> > >
> > > Robert
> > >
> > >
> > > On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
> > > stephen.alan.conno...@gmail.com (mailto:
> stephen.alan.conno...@gmail.com)> wrote:
> > >
> > > Ok, looking a the results of the bisect-0 through bisect-3 builds,
> 0
> and 1
> > > > both fail just for the MNG-6127 integration tests, bisect-2 adds
> the fix
> > > > for MNG-6127, so the build passes... bisect-3 also passes, so the
> smoking
> > > > gun is...
> > > >
> > > > https://github.com/apache/maven/commit/f047ea143766fd22ae420
> > > > 40e6805bef287f3cc3e
> > > >
> > > > On 29 August 2017 at 22:17, Stephen Connolly <
> > > > stephen.alan.conno...@gmail.com (mailto:
> stephen.alan.conno...@gmail.com)> wrote:
> > > >
> > > > bisect-0 is the last known good commit with the Jenkinsfile fix
> to
> confirm
> > > > > that the failures are not another infra related change
> > > > >
> > > > > On 29 August 2017 at 22:13, Stephen Connolly
> > > > >  > > > > com> wrote:
> > > > >
> > > > > I have pushed bisect-1, bisect-2 and bisect-3 to see if we can
> identify
> > > > > > the problematic commit since the last known good build of
> master (#123
> > > > > > for
> > > > > > commit 4f2a2dba89251d9045fe9944783509a397491da3)
> > > > > >
> > > > > > On 29 August 2017 at 22:09, Stephen Connolly <
> > > > > > stephen.alan.conno...@gmail.com (mailto:
> stephen.alan.conno...@gmail.com)> wrote:
> > > > > >
> > > > > > Failure is in testBootstrap, probably something obvious,
> here's the
> > > > > > > problematic build log... you can inspect for yourself at
> > > > > > > https://builds.apache.org/blue/organizations/jenkins/mave
> > > > > > > n-3.x-jenkinsfile/detail/master/128/tests but there is no
> point in
> > > > > > > looking at any tests other than testBootstrap as if that
> fails
> > > > > > > everything
> > > > > > > else will fail too
> > > > > > >
> > > > > > > [WARNING] Error injecting: org.apache.maven.plugins.depen
> > > > > > > dency.resolvers.ResolvePluginsMojo
> > > > > > > com.google.inject.ProvisionException: Unable to provision,
> see the
> > > > > > > following errors:
> > > > > > > 1) No implementation for org.apache.maven.artifact.hand
> > > > > > > ler.manager.ArtifactHandlerManager was bound.
> > > > > > > while locating org.apache.maven.plugins.depen
> > > > > > > dency.resolvers.ResolvePluginsMojo
> > > > > > > 1 error
> > > > > > 

Re: ATTN: Maven core build is broken

[Robert Scholte]

I agree

On Wed, 30 Aug 2017 18:01:12 +0200, Stephen Connolly  
 wrote:



I think we'll de-scope 6275 for 3.5.1




On Wed 30 Aug 2017 at 16:04, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

Hmmm... looking like we may have to descope MNG-6275... I'll do some  
more

digging first though


On 30 August 2017 at 04:34, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:


fef668789f6abe79f603b96a8ee6f13ea52de4df should verify if that fixes
things

On 30 August 2017 at 04:13, Stuart McCulloch  wrote:


On Wednesday, 30 August 2017 at 10:26, Stephen Connolly wrote:
>
https://github.com/apache/maven/commit/39004f6aee634a0ac6daa1f99add299ff439f5ec
> should fix
>
>

Is it worth storing the chosen context/system loader in a member
variable, or maybe even statically like PARENT_CLASSLOADER, rather  
than

checking each time?

This would also avoid the off-chance that something changes the  
thread’s
context loader during the build which could then influence subsequent  
calls

to “newRealm”.

(IIUC when embedding we’d expect the context loader to be set  
correctly
during construction of the realm manager, and that same loader should  
then

be used for all realms)
> On 30 August 2017 at 02:09, Robert Scholte  wrote:
>
> > Now that the ITs are all in place again it is good to see that  
these

> > failures reflect the concerns of Igor.
> > Originally this issue said it was Java 9 related, but this is a  
Java

8
> > issue as well, so there's no real need to include it for 3.5.1
> > I'll revert this commit and reopen the issue.
> > Future analysis must answer the question where and how the
classloading
> > must be improved.
> >
> > Robert
> >
> >
> > On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
> > stephen.alan.conno...@gmail.com (mailto:
stephen.alan.conno...@gmail.com)> wrote:
> >
> > Ok, looking a the results of the bisect-0 through bisect-3  
builds, 0

and 1
> > > both fail just for the MNG-6127 integration tests, bisect-2 adds
the fix
> > > for MNG-6127, so the build passes... bisect-3 also passes, so  
the

smoking
> > > gun is...
> > >
> > > https://github.com/apache/maven/commit/f047ea143766fd22ae420
> > > 40e6805bef287f3cc3e
> > >
> > > On 29 August 2017 at 22:17, Stephen Connolly <
> > > stephen.alan.conno...@gmail.com (mailto:
stephen.alan.conno...@gmail.com)> wrote:
> > >
> > > bisect-0 is the last known good commit with the Jenkinsfile fix  
to

confirm
> > > > that the failures are not another infra related change
> > > >
> > > > On 29 August 2017 at 22:13, Stephen Connolly
> > > >  > > > com> wrote:
> > > >
> > > > I have pushed bisect-1, bisect-2 and bisect-3 to see if we can
identify
> > > > > the problematic commit since the last known good build of
master (#123
> > > > > for
> > > > > commit 4f2a2dba89251d9045fe9944783509a397491da3)
> > > > >
> > > > > On 29 August 2017 at 22:09, Stephen Connolly <
> > > > > stephen.alan.conno...@gmail.com (mailto:
stephen.alan.conno...@gmail.com)> wrote:
> > > > >
> > > > > Failure is in testBootstrap, probably something obvious,
here's the
> > > > > > problematic build log... you can inspect for yourself at
> > > > > > https://builds.apache.org/blue/organizations/jenkins/mave
> > > > > > n-3.x-jenkinsfile/detail/master/128/tests but there is no
point in
> > > > > > looking at any tests other than testBootstrap as if that
fails
> > > > > > everything
> > > > > > else will fail too
> > > > > >
> > > > > > [WARNING] Error injecting: org.apache.maven.plugins.depen
> > > > > > dency.resolvers.ResolvePluginsMojo
> > > > > > com.google.inject.ProvisionException: Unable to provision,
see the
> > > > > > following errors:
> > > > > > 1) No implementation for org.apache.maven.artifact.hand
> > > > > > ler.manager.ArtifactHandlerManager was bound.
> > > > > > while locating org.apache.maven.plugins.depen
> > > > > > dency.resolvers.ResolvePluginsMojo
> > > > > > 1 error
> > > > > > at
com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.j
> > > > > > ava:1025)
> > > > > > at
com.google.inject.internal.InjectorImpl.getInstance(Injector
> > > > > > Impl.java:1051)
> > > > > > at
org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDef
> > > > > > erredClass.java:48)
> > > > > > at com.google.inject.internal.Pro
viderInternalFactory.provision
> > > > > > (ProviderInternalFactory.java:81)
> > > > > > at com.google.inject.internal.Int
ernalFactoryToInitializableAda
> > > > > >  
pter.provision(InternalFactoryToInitializableAdapter.java:53)

> > > > > > at com.google.inject.internal.Pro
viderInternalFactory$1.call(Pr
> > > > > > oviderInternalFactory.java:65)
> > > > > > at com.google.inject.internal.Pro
visionListenerStackCallback$Pr
> > > > > > ovision.provision(ProvisionListenerStackCallback.java:115)
> > > > > > at com.google.inject.internal.Pro
visionListenerStackCallback$Pr
> > > > > > 

Re: ATTN: Maven core build is broken

[Stephen Connolly]

I think we'll de-scope 6275 for 3.5.1




On Wed 30 Aug 2017 at 16:04, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Hmmm... looking like we may have to descope MNG-6275... I'll do some more
> digging first though
>
>
> On 30 August 2017 at 04:34, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> fef668789f6abe79f603b96a8ee6f13ea52de4df should verify if that fixes
>> things
>>
>> On 30 August 2017 at 04:13, Stuart McCulloch  wrote:
>>
>>> On Wednesday, 30 August 2017 at 10:26, Stephen Connolly wrote:
>>> >
>>> https://github.com/apache/maven/commit/39004f6aee634a0ac6daa1f99add299ff439f5ec
>>> > should fix
>>> >
>>> >
>>>
>>> Is it worth storing the chosen context/system loader in a member
>>> variable, or maybe even statically like PARENT_CLASSLOADER, rather than
>>> checking each time?
>>>
>>> This would also avoid the off-chance that something changes the thread’s
>>> context loader during the build which could then influence subsequent calls
>>> to “newRealm”.
>>>
>>> (IIUC when embedding we’d expect the context loader to be set correctly
>>> during construction of the realm manager, and that same loader should then
>>> be used for all realms)
>>> > On 30 August 2017 at 02:09, Robert Scholte >> (mailto:rfscho...@apache.org)> wrote:
>>> >
>>> > > Now that the ITs are all in place again it is good to see that these
>>> > > failures reflect the concerns of Igor.
>>> > > Originally this issue said it was Java 9 related, but this is a Java
>>> 8
>>> > > issue as well, so there's no real need to include it for 3.5.1
>>> > > I'll revert this commit and reopen the issue.
>>> > > Future analysis must answer the question where and how the
>>> classloading
>>> > > must be improved.
>>> > >
>>> > > Robert
>>> > >
>>> > >
>>> > > On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
>>> > > stephen.alan.conno...@gmail.com (mailto:
>>> stephen.alan.conno...@gmail.com)> wrote:
>>> > >
>>> > > Ok, looking a the results of the bisect-0 through bisect-3 builds, 0
>>> and 1
>>> > > > both fail just for the MNG-6127 integration tests, bisect-2 adds
>>> the fix
>>> > > > for MNG-6127, so the build passes... bisect-3 also passes, so the
>>> smoking
>>> > > > gun is...
>>> > > >
>>> > > > https://github.com/apache/maven/commit/f047ea143766fd22ae420
>>> > > > 40e6805bef287f3cc3e
>>> > > >
>>> > > > On 29 August 2017 at 22:17, Stephen Connolly <
>>> > > > stephen.alan.conno...@gmail.com (mailto:
>>> stephen.alan.conno...@gmail.com)> wrote:
>>> > > >
>>> > > > bisect-0 is the last known good commit with the Jenkinsfile fix to
>>> confirm
>>> > > > > that the failures are not another infra related change
>>> > > > >
>>> > > > > On 29 August 2017 at 22:13, Stephen Connolly
>>> > > > > >> > > > > com> wrote:
>>> > > > >
>>> > > > > I have pushed bisect-1, bisect-2 and bisect-3 to see if we can
>>> identify
>>> > > > > > the problematic commit since the last known good build of
>>> master (#123
>>> > > > > > for
>>> > > > > > commit 4f2a2dba89251d9045fe9944783509a397491da3)
>>> > > > > >
>>> > > > > > On 29 August 2017 at 22:09, Stephen Connolly <
>>> > > > > > stephen.alan.conno...@gmail.com (mailto:
>>> stephen.alan.conno...@gmail.com)> wrote:
>>> > > > > >
>>> > > > > > Failure is in testBootstrap, probably something obvious,
>>> here's the
>>> > > > > > > problematic build log... you can inspect for yourself at
>>> > > > > > > https://builds.apache.org/blue/organizations/jenkins/mave
>>> > > > > > > n-3.x-jenkinsfile/detail/master/128/tests but there is no
>>> point in
>>> > > > > > > looking at any tests other than testBootstrap as if that
>>> fails
>>> > > > > > > everything
>>> > > > > > > else will fail too
>>> > > > > > >
>>> > > > > > > [WARNING] Error injecting: org.apache.maven.plugins.depen
>>> > > > > > > dency.resolvers.ResolvePluginsMojo
>>> > > > > > > com.google.inject.ProvisionException: Unable to provision,
>>> see the
>>> > > > > > > following errors:
>>> > > > > > > 1) No implementation for org.apache.maven.artifact.hand
>>> > > > > > > ler.manager.ArtifactHandlerManager was bound.
>>> > > > > > > while locating org.apache.maven.plugins.depen
>>> > > > > > > dency.resolvers.ResolvePluginsMojo
>>> > > > > > > 1 error
>>> > > > > > > at
>>> com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.j
>>> > > > > > > ava:1025)
>>> > > > > > > at
>>> com.google.inject.internal.InjectorImpl.getInstance(Injector
>>> > > > > > > Impl.java:1051)
>>> > > > > > > at
>>> org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDef
>>> > > > > > > erredClass.java:48)
>>> > > > > > > at com.google.inject.internal.Pro
>>> viderInternalFactory.provision
>>> > > > > > > (ProviderInternalFactory.java:81)
>>> > > > > > > at com.google.inject.internal.Int
>>> ernalFactoryToInitializableAda
>>> > > > > > > pter.provision(InternalFactoryToInitializableAdapter.java:53)
>>> > > > > > > at com.google.inject.internal.Pro
>>> 

Re: ATTN: Maven core build is broken

[Stephen Connolly]

Hmmm... looking like we may have to descope MNG-6275... I'll do some more
digging first though


On 30 August 2017 at 04:34, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> fef668789f6abe79f603b96a8ee6f13ea52de4df should verify if that fixes
> things
>
> On 30 August 2017 at 04:13, Stuart McCulloch  wrote:
>
>> On Wednesday, 30 August 2017 at 10:26, Stephen Connolly wrote:
>> > https://github.com/apache/maven/commit/39004f6aee634a0ac6daa
>> 1f99add299ff439f5ec
>> > should fix
>> >
>> >
>>
>> Is it worth storing the chosen context/system loader in a member
>> variable, or maybe even statically like PARENT_CLASSLOADER, rather than
>> checking each time?
>>
>> This would also avoid the off-chance that something changes the thread’s
>> context loader during the build which could then influence subsequent calls
>> to “newRealm”.
>>
>> (IIUC when embedding we’d expect the context loader to be set correctly
>> during construction of the realm manager, and that same loader should then
>> be used for all realms)
>> > On 30 August 2017 at 02:09, Robert Scholte > (mailto:rfscho...@apache.org)> wrote:
>> >
>> > > Now that the ITs are all in place again it is good to see that these
>> > > failures reflect the concerns of Igor.
>> > > Originally this issue said it was Java 9 related, but this is a Java 8
>> > > issue as well, so there's no real need to include it for 3.5.1
>> > > I'll revert this commit and reopen the issue.
>> > > Future analysis must answer the question where and how the
>> classloading
>> > > must be improved.
>> > >
>> > > Robert
>> > >
>> > >
>> > > On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
>> > > stephen.alan.conno...@gmail.com (mailto:stephen.alan.connolly@
>> gmail.com)> wrote:
>> > >
>> > > Ok, looking a the results of the bisect-0 through bisect-3 builds, 0
>> and 1
>> > > > both fail just for the MNG-6127 integration tests, bisect-2 adds
>> the fix
>> > > > for MNG-6127, so the build passes... bisect-3 also passes, so the
>> smoking
>> > > > gun is...
>> > > >
>> > > > https://github.com/apache/maven/commit/f047ea143766fd22ae420
>> > > > 40e6805bef287f3cc3e
>> > > >
>> > > > On 29 August 2017 at 22:17, Stephen Connolly <
>> > > > stephen.alan.conno...@gmail.com (mailto:stephen.alan.connolly@
>> gmail.com)> wrote:
>> > > >
>> > > > bisect-0 is the last known good commit with the Jenkinsfile fix to
>> confirm
>> > > > > that the failures are not another infra related change
>> > > > >
>> > > > > On 29 August 2017 at 22:13, Stephen Connolly
>> > > > > > > > > > com> wrote:
>> > > > >
>> > > > > I have pushed bisect-1, bisect-2 and bisect-3 to see if we can
>> identify
>> > > > > > the problematic commit since the last known good build of
>> master (#123
>> > > > > > for
>> > > > > > commit 4f2a2dba89251d9045fe9944783509a397491da3)
>> > > > > >
>> > > > > > On 29 August 2017 at 22:09, Stephen Connolly <
>> > > > > > stephen.alan.conno...@gmail.com (mailto:stephen.alan.connolly@
>> gmail.com)> wrote:
>> > > > > >
>> > > > > > Failure is in testBootstrap, probably something obvious, here's
>> the
>> > > > > > > problematic build log... you can inspect for yourself at
>> > > > > > > https://builds.apache.org/blue/organizations/jenkins/mave
>> > > > > > > n-3.x-jenkinsfile/detail/master/128/tests but there is no
>> point in
>> > > > > > > looking at any tests other than testBootstrap as if that fails
>> > > > > > > everything
>> > > > > > > else will fail too
>> > > > > > >
>> > > > > > > [WARNING] Error injecting: org.apache.maven.plugins.depen
>> > > > > > > dency.resolvers.ResolvePluginsMojo
>> > > > > > > com.google.inject.ProvisionException: Unable to provision,
>> see the
>> > > > > > > following errors:
>> > > > > > > 1) No implementation for org.apache.maven.artifact.hand
>> > > > > > > ler.manager.ArtifactHandlerManager was bound.
>> > > > > > > while locating org.apache.maven.plugins.depen
>> > > > > > > dency.resolvers.ResolvePluginsMojo
>> > > > > > > 1 error
>> > > > > > > at com.google.inject.internal.Inj
>> ectorImpl$2.get(InjectorImpl.j
>> > > > > > > ava:1025)
>> > > > > > > at com.google.inject.internal.Inj
>> ectorImpl.getInstance(Injector
>> > > > > > > Impl.java:1051)
>> > > > > > > at org.eclipse.sisu.space.Abstrac
>> tDeferredClass.get(AbstractDef
>> > > > > > > erredClass.java:48)
>> > > > > > > at com.google.inject.internal.Pro
>> viderInternalFactory.provision
>> > > > > > > (ProviderInternalFactory.java:81)
>> > > > > > > at com.google.inject.internal.Int
>> ernalFactoryToInitializableAda
>> > > > > > > pter.provision(InternalFactoryToInitializableAdapter.java:53)
>> > > > > > > at com.google.inject.internal.Pro
>> viderInternalFactory$1.call(Pr
>> > > > > > > oviderInternalFactory.java:65)
>> > > > > > > at com.google.inject.internal.Pro
>> visionListenerStackCallback$Pr
>> > > > > > > ovision.provision(ProvisionListenerStackCallback.java:115)
>> > > > > > > at 

[GitHub] maven-surefire issue #157: SUREFIRE-1383 dependenciesToScan Does Not Leverag...

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/157
  
@owenfarrell 
I will try by myself. I will let you know with new branch and we can 
discuss it.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: ATTN: Maven core build is broken

[Stephen Connolly]

fef668789f6abe79f603b96a8ee6f13ea52de4df should verify if that fixes things

On 30 August 2017 at 04:13, Stuart McCulloch  wrote:

> On Wednesday, 30 August 2017 at 10:26, Stephen Connolly wrote:
> > https://github.com/apache/maven/commit/39004f6aee634a0ac6daa1f99add29
> 9ff439f5ec
> > should fix
> >
> >
>
> Is it worth storing the chosen context/system loader in a member variable,
> or maybe even statically like PARENT_CLASSLOADER, rather than checking each
> time?
>
> This would also avoid the off-chance that something changes the thread’s
> context loader during the build which could then influence subsequent calls
> to “newRealm”.
>
> (IIUC when embedding we’d expect the context loader to be set correctly
> during construction of the realm manager, and that same loader should then
> be used for all realms)
> > On 30 August 2017 at 02:09, Robert Scholte  (mailto:rfscho...@apache.org)> wrote:
> >
> > > Now that the ITs are all in place again it is good to see that these
> > > failures reflect the concerns of Igor.
> > > Originally this issue said it was Java 9 related, but this is a Java 8
> > > issue as well, so there's no real need to include it for 3.5.1
> > > I'll revert this commit and reopen the issue.
> > > Future analysis must answer the question where and how the classloading
> > > must be improved.
> > >
> > > Robert
> > >
> > >
> > > On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
> > > stephen.alan.conno...@gmail.com (mailto:stephen.alan.connolly@
> gmail.com)> wrote:
> > >
> > > Ok, looking a the results of the bisect-0 through bisect-3 builds, 0
> and 1
> > > > both fail just for the MNG-6127 integration tests, bisect-2 adds the
> fix
> > > > for MNG-6127, so the build passes... bisect-3 also passes, so the
> smoking
> > > > gun is...
> > > >
> > > > https://github.com/apache/maven/commit/f047ea143766fd22ae420
> > > > 40e6805bef287f3cc3e
> > > >
> > > > On 29 August 2017 at 22:17, Stephen Connolly <
> > > > stephen.alan.conno...@gmail.com (mailto:stephen.alan.connolly@
> gmail.com)> wrote:
> > > >
> > > > bisect-0 is the last known good commit with the Jenkinsfile fix to
> confirm
> > > > > that the failures are not another infra related change
> > > > >
> > > > > On 29 August 2017 at 22:13, Stephen Connolly
> > > > >  > > > > com> wrote:
> > > > >
> > > > > I have pushed bisect-1, bisect-2 and bisect-3 to see if we can
> identify
> > > > > > the problematic commit since the last known good build of master
> (#123
> > > > > > for
> > > > > > commit 4f2a2dba89251d9045fe9944783509a397491da3)
> > > > > >
> > > > > > On 29 August 2017 at 22:09, Stephen Connolly <
> > > > > > stephen.alan.conno...@gmail.com (mailto:stephen.alan.connolly@
> gmail.com)> wrote:
> > > > > >
> > > > > > Failure is in testBootstrap, probably something obvious, here's
> the
> > > > > > > problematic build log... you can inspect for yourself at
> > > > > > > https://builds.apache.org/blue/organizations/jenkins/mave
> > > > > > > n-3.x-jenkinsfile/detail/master/128/tests but there is no
> point in
> > > > > > > looking at any tests other than testBootstrap as if that fails
> > > > > > > everything
> > > > > > > else will fail too
> > > > > > >
> > > > > > > [WARNING] Error injecting: org.apache.maven.plugins.depen
> > > > > > > dency.resolvers.ResolvePluginsMojo
> > > > > > > com.google.inject.ProvisionException: Unable to provision,
> see the
> > > > > > > following errors:
> > > > > > > 1) No implementation for org.apache.maven.artifact.hand
> > > > > > > ler.manager.ArtifactHandlerManager was bound.
> > > > > > > while locating org.apache.maven.plugins.depen
> > > > > > > dency.resolvers.ResolvePluginsMojo
> > > > > > > 1 error
> > > > > > > at com.google.inject.internal.InjectorImpl$2.get(
> InjectorImpl.j
> > > > > > > ava:1025)
> > > > > > > at com.google.inject.internal.InjectorImpl.getInstance(
> Injector
> > > > > > > Impl.java:1051)
> > > > > > > at org.eclipse.sisu.space.AbstractDeferredClass.get(
> AbstractDef
> > > > > > > erredClass.java:48)
> > > > > > > at com.google.inject.internal.ProviderInternalFactory.
> provision
> > > > > > > (ProviderInternalFactory.java:81)
> > > > > > > at com.google.inject.internal.InternalFactoryToInitializable
> Ada
> > > > > > > pter.provision(InternalFactoryToInitializableAdapter.java:53)
> > > > > > > at com.google.inject.internal.ProviderInternalFactory$1.
> call(Pr
> > > > > > > oviderInternalFactory.java:65)
> > > > > > > at com.google.inject.internal.ProvisionListenerStackCallback
> $Pr
> > > > > > > ovision.provision(ProvisionListenerStackCallback.java:115)
> > > > > > > at com.google.inject.internal.ProvisionListenerStackCallback
> $Pr
> > > > > > > ovision.provision(ProvisionListenerStackCallback.java:133)
> > > > > > > at com.google.inject.internal.ProvisionListenerStackCallback
> .pr
> > > > > > > ovision(ProvisionListenerStackCallback.java:68)
> > > > > > > at 

Re: ATTN: Maven core build is broken

[Stephen Connolly]

On 30 August 2017 at 04:13, Stuart McCulloch  wrote:

> On Wednesday, 30 August 2017 at 10:26, Stephen Connolly wrote:
> > https://github.com/apache/maven/commit/39004f6aee634a0ac6daa1f99add29
> 9ff439f5ec
> > should fix
> >
> >
>
> Is it worth storing the chosen context/system loader in a member variable,
> or maybe even statically like PARENT_CLASSLOADER, rather than checking each
> time?
>

Statically would not be compatible with usage from embedder... need to
figure out where to hold it


>
> This would also avoid the off-chance that something changes the thread’s
> context loader during the build which could then influence subsequent calls
> to “newRealm”.
>
> (IIUC when embedding we’d expect the context loader to be set correctly
> during construction of the realm manager, and that same loader should then
> be used for all realms)
> > On 30 August 2017 at 02:09, Robert Scholte  (mailto:rfscho...@apache.org)> wrote:
> >
> > > Now that the ITs are all in place again it is good to see that these
> > > failures reflect the concerns of Igor.
> > > Originally this issue said it was Java 9 related, but this is a Java 8
> > > issue as well, so there's no real need to include it for 3.5.1
> > > I'll revert this commit and reopen the issue.
> > > Future analysis must answer the question where and how the classloading
> > > must be improved.
> > >
> > > Robert
> > >
> > >
> > > On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
> > > stephen.alan.conno...@gmail.com (mailto:stephen.alan.connolly@
> gmail.com)> wrote:
> > >
> > > Ok, looking a the results of the bisect-0 through bisect-3 builds, 0
> and 1
> > > > both fail just for the MNG-6127 integration tests, bisect-2 adds the
> fix
> > > > for MNG-6127, so the build passes... bisect-3 also passes, so the
> smoking
> > > > gun is...
> > > >
> > > > https://github.com/apache/maven/commit/f047ea143766fd22ae420
> > > > 40e6805bef287f3cc3e
> > > >
> > > > On 29 August 2017 at 22:17, Stephen Connolly <
> > > > stephen.alan.conno...@gmail.com (mailto:stephen.alan.connolly@
> gmail.com)> wrote:
> > > >
> > > > bisect-0 is the last known good commit with the Jenkinsfile fix to
> confirm
> > > > > that the failures are not another infra related change
> > > > >
> > > > > On 29 August 2017 at 22:13, Stephen Connolly
> > > > >  > > > > com> wrote:
> > > > >
> > > > > I have pushed bisect-1, bisect-2 and bisect-3 to see if we can
> identify
> > > > > > the problematic commit since the last known good build of master
> (#123
> > > > > > for
> > > > > > commit 4f2a2dba89251d9045fe9944783509a397491da3)
> > > > > >
> > > > > > On 29 August 2017 at 22:09, Stephen Connolly <
> > > > > > stephen.alan.conno...@gmail.com (mailto:stephen.alan.connolly@
> gmail.com)> wrote:
> > > > > >
> > > > > > Failure is in testBootstrap, probably something obvious, here's
> the
> > > > > > > problematic build log... you can inspect for yourself at
> > > > > > > https://builds.apache.org/blue/organizations/jenkins/mave
> > > > > > > n-3.x-jenkinsfile/detail/master/128/tests but there is no
> point in
> > > > > > > looking at any tests other than testBootstrap as if that fails
> > > > > > > everything
> > > > > > > else will fail too
> > > > > > >
> > > > > > > [WARNING] Error injecting: org.apache.maven.plugins.depen
> > > > > > > dency.resolvers.ResolvePluginsMojo
> > > > > > > com.google.inject.ProvisionException: Unable to provision,
> see the
> > > > > > > following errors:
> > > > > > > 1) No implementation for org.apache.maven.artifact.hand
> > > > > > > ler.manager.ArtifactHandlerManager was bound.
> > > > > > > while locating org.apache.maven.plugins.depen
> > > > > > > dency.resolvers.ResolvePluginsMojo
> > > > > > > 1 error
> > > > > > > at com.google.inject.internal.InjectorImpl$2.get(
> InjectorImpl.j
> > > > > > > ava:1025)
> > > > > > > at com.google.inject.internal.InjectorImpl.getInstance(
> Injector
> > > > > > > Impl.java:1051)
> > > > > > > at org.eclipse.sisu.space.AbstractDeferredClass.get(
> AbstractDef
> > > > > > > erredClass.java:48)
> > > > > > > at com.google.inject.internal.ProviderInternalFactory.
> provision
> > > > > > > (ProviderInternalFactory.java:81)
> > > > > > > at com.google.inject.internal.InternalFactoryToInitializable
> Ada
> > > > > > > pter.provision(InternalFactoryToInitializableAdapter.java:53)
> > > > > > > at com.google.inject.internal.ProviderInternalFactory$1.
> call(Pr
> > > > > > > oviderInternalFactory.java:65)
> > > > > > > at com.google.inject.internal.ProvisionListenerStackCallback
> $Pr
> > > > > > > ovision.provision(ProvisionListenerStackCallback.java:115)
> > > > > > > at com.google.inject.internal.ProvisionListenerStackCallback
> $Pr
> > > > > > > ovision.provision(ProvisionListenerStackCallback.java:133)
> > > > > > > at com.google.inject.internal.ProvisionListenerStackCallback
> .pr
> > > > > > > ovision(ProvisionListenerStackCallback.java:68)
> > > > > > > 

Re: ATTN: Maven core build is broken

[Stuart McCulloch]

On Wednesday, 30 August 2017 at 10:26, Stephen Connolly wrote:
> https://github.com/apache/maven/commit/39004f6aee634a0ac6daa1f99add299ff439f5ec
> should fix
>  
>  

Is it worth storing the chosen context/system loader in a member variable, or 
maybe even statically like PARENT_CLASSLOADER, rather than checking each time?

This would also avoid the off-chance that something changes the thread’s 
context loader during the build which could then influence subsequent calls to 
“newRealm”.

(IIUC when embedding we’d expect the context loader to be set correctly during 
construction of the realm manager, and that same loader should then be used for 
all realms)
> On 30 August 2017 at 02:09, Robert Scholte  (mailto:rfscho...@apache.org)> wrote:
>  
> > Now that the ITs are all in place again it is good to see that these
> > failures reflect the concerns of Igor.
> > Originally this issue said it was Java 9 related, but this is a Java 8
> > issue as well, so there's no real need to include it for 3.5.1
> > I'll revert this commit and reopen the issue.
> > Future analysis must answer the question where and how the classloading
> > must be improved.
> >  
> > Robert
> >  
> >  
> > On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
> > stephen.alan.conno...@gmail.com (mailto:stephen.alan.conno...@gmail.com)> 
> > wrote:
> >  
> > Ok, looking a the results of the bisect-0 through bisect-3 builds, 0 and 1
> > > both fail just for the MNG-6127 integration tests, bisect-2 adds the fix
> > > for MNG-6127, so the build passes... bisect-3 also passes, so the smoking
> > > gun is...
> > >  
> > > https://github.com/apache/maven/commit/f047ea143766fd22ae420
> > > 40e6805bef287f3cc3e
> > >  
> > > On 29 August 2017 at 22:17, Stephen Connolly <
> > > stephen.alan.conno...@gmail.com (mailto:stephen.alan.conno...@gmail.com)> 
> > > wrote:
> > >  
> > > bisect-0 is the last known good commit with the Jenkinsfile fix to confirm
> > > > that the failures are not another infra related change
> > > >  
> > > > On 29 August 2017 at 22:13, Stephen Connolly
> > > >  > > > com> wrote:
> > > >  
> > > > I have pushed bisect-1, bisect-2 and bisect-3 to see if we can identify
> > > > > the problematic commit since the last known good build of master (#123
> > > > > for
> > > > > commit 4f2a2dba89251d9045fe9944783509a397491da3)
> > > > >  
> > > > > On 29 August 2017 at 22:09, Stephen Connolly <
> > > > > stephen.alan.conno...@gmail.com 
> > > > > (mailto:stephen.alan.conno...@gmail.com)> wrote:
> > > > >  
> > > > > Failure is in testBootstrap, probably something obvious, here's the
> > > > > > problematic build log... you can inspect for yourself at
> > > > > > https://builds.apache.org/blue/organizations/jenkins/mave
> > > > > > n-3.x-jenkinsfile/detail/master/128/tests but there is no point in
> > > > > > looking at any tests other than testBootstrap as if that fails
> > > > > > everything
> > > > > > else will fail too
> > > > > >  
> > > > > > [WARNING] Error injecting: org.apache.maven.plugins.depen
> > > > > > dency.resolvers.ResolvePluginsMojo
> > > > > > com.google.inject.ProvisionException: Unable to provision, see the
> > > > > > following errors:
> > > > > > 1) No implementation for org.apache.maven.artifact.hand
> > > > > > ler.manager.ArtifactHandlerManager was bound.
> > > > > > while locating org.apache.maven.plugins.depen
> > > > > > dency.resolvers.ResolvePluginsMojo
> > > > > > 1 error
> > > > > > at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.j
> > > > > > ava:1025)
> > > > > > at com.google.inject.internal.InjectorImpl.getInstance(Injector
> > > > > > Impl.java:1051)
> > > > > > at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDef
> > > > > > erredClass.java:48)
> > > > > > at com.google.inject.internal.ProviderInternalFactory.provision
> > > > > > (ProviderInternalFactory.java:81)
> > > > > > at com.google.inject.internal.InternalFactoryToInitializableAda
> > > > > > pter.provision(InternalFactoryToInitializableAdapter.java:53)
> > > > > > at com.google.inject.internal.ProviderInternalFactory$1.call(Pr
> > > > > > oviderInternalFactory.java:65)
> > > > > > at com.google.inject.internal.ProvisionListenerStackCallback$Pr
> > > > > > ovision.provision(ProvisionListenerStackCallback.java:115)
> > > > > > at com.google.inject.internal.ProvisionListenerStackCallback$Pr
> > > > > > ovision.provision(ProvisionListenerStackCallback.java:133)
> > > > > > at com.google.inject.internal.ProvisionListenerStackCallback.pr
> > > > > > ovision(ProvisionListenerStackCallback.java:68)
> > > > > > at com.google.inject.internal.ProviderInternalFactory.circularG
> > > > > > et(ProviderInternalFactory.java:63)
> > > > > > at com.google.inject.internal.InternalFactoryToInitializableAda
> > > > > > pter.get(InternalFactoryToInitializableAdapter.java:45)
> > > > > > at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImp
> > > > > > l.java:1016)
> > 

Re: ATTN: Maven core build is broken

[Robert Scholte]

https://builds.apache.org/job/maven-3.x-jenkinsfile/job/mng-6275/1/testReport/junit/org.apache.maven.it/MavenITmng4273RestrictedCoreRealmAccessForPluginTest/testit/

This one now fails as well, suggesting that suddenly classes solely for  
core became available for the plugin.


Would mean to me that the fix is incomplete.


On Wed, 30 Aug 2017 13:05:20 +0200, Stephen Connolly  
 wrote:



The question is this:

Is plexus-interpolator part of the classes contracted to be exposed from
core or is it one of the classes that plugin-first classloading should
apply.

If the first then we have exposed a bug... if the latter then the fix is
incomplete

On 30 August 2017 at 04:02, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:


https://github.com/codehaus-plexus/plexus-interpolation/commit/
0714af6ce3b4371a8a914496f3632c405b2e3e0c#diff-
95342973516cd90dd54ef6a15afa1961 should have *added* the methods taking
BasicInterpolator rather than replace the methods taking Interpolator

Then https://github.com/codehaus-plexus/plexus-interpolation/commit/
0714af6ce3b4371a8a914496f3632c405b2e3e0c#diff-
787778a91b4ed9d89b7a12e55be5d31aL138 should have had

@Deprecated
public void interpolate( Object target, Interpolator interpolator,
RecursionInterceptor recursionInterceptor ) {
  interpolate( target, (BasicInterpolator) interpolator,
recursionInterceptor );
}

style chaining

Unclear at this point if the change for MNG-6275 is exposing this  
breaking

change

On 30 August 2017 at 03:56, Stephen Connolly  
 wrote:


Kristian, FYI

https://github.com/codehaus-plexus/plexus-interpolation/comm
it/0714af6ce3b4371a8a914496f3632c405b2e3e0c broke binary compatibility

On 30 August 2017 at 03:54, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

Hmmm so my fix has 24 failing tests... most of which seem to be  
failing

due to:

Caused by: java.lang.NoSuchMethodError: org.codehaus.plexus.interpolat
ion.object.FieldBasedObjectInterpolator.interpolate(Ljava/la
ng/Object;Lorg/codehaus/plexus/interpolation/Interpolator;
Lorg/codehaus/plexus/interpolation/RecursionInterceptor;)V
at org.apache.maven.plugin.assembly.interpolation.AssemblyInter
polator.interpolate(AssemblyInterpolator.java:114)
at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.re
adAssembly(DefaultAssemblyReader.java:377)
at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.ad
dAssemblyFromDescriptor(DefaultAssemblyReader.java:324)
at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.re
adAssemblies(DefaultAssemblyReader.java:117)
at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.
execute(AbstractAssemblyMojo.java:434)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMoj
o(DefaultBuildPluginManager.java:137)
... 44 more

I wonder if my fix is actually exposing a bug in the integration test
harness because the test harness may be picking up an older version of
plexus-interpolation than used by maven and the new version breaks
backwards binary compatibility


On 30 August 2017 at 02:38, Robert Scholte   
wrote:


I agree, it would be nice if this one was shipped with one of the  
next

releases, as long as it's stable.
I was kind of surprised that the contextloader could be null, but  
after

reading the docs this change makes sense.
I was too fast with the revert, meaning you could reintroduce the
unit-test, which was the original symptom.

Robert


On Wed, 30 Aug 2017 11:31:30 +0200, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-

jenkinsfile/job/mng-6275/
will report the status... I am more in favour of including MNG-6275
rather
than reverting, but let's get Igor's opinion after we (hopefully)  
get a

clean test run.

Absence a clean test run on
https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-
jenkinsfile/job/mng-6275/
then I say revert and descope for 3.5.1 as it is no worse than  
before

on
Java 8 and I'm happy to take time and roll a 3.5.2 for this rather  
than

hold up a release train for something that is not a regression from
3.5.0

On 30 August 2017 at 02:26, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

https://github.com/apache/maven/commit/39004f6aee634a0ac6daa1f99add29

9ff439f5ec should fix

On 30 August 2017 at 02:09, Robert Scholte 
wrote:

Now that the ITs are all in place again it is good to see that  
these

failures reflect the concerns of Igor.
Originally this issue said it was Java 9 related, but this is a  
Java

8
issue as well, so there's no real need to include it for 3.5.1
I'll revert this commit and reopen the issue.
Future analysis must answer the question where and how the
classloading
must be improved.

Robert


On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

Ok, looking a the results of the bisect-0 through 

Re: ATTN: Maven core build is broken

[Stephen Connolly]

The question is this:

Is plexus-interpolator part of the classes contracted to be exposed from
core or is it one of the classes that plugin-first classloading should
apply.

If the first then we have exposed a bug... if the latter then the fix is
incomplete

On 30 August 2017 at 04:02, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> https://github.com/codehaus-plexus/plexus-interpolation/commit/
> 0714af6ce3b4371a8a914496f3632c405b2e3e0c#diff-
> 95342973516cd90dd54ef6a15afa1961 should have *added* the methods taking
> BasicInterpolator rather than replace the methods taking Interpolator
>
> Then https://github.com/codehaus-plexus/plexus-interpolation/commit/
> 0714af6ce3b4371a8a914496f3632c405b2e3e0c#diff-
> 787778a91b4ed9d89b7a12e55be5d31aL138 should have had
>
> @Deprecated
> public void interpolate( Object target, Interpolator interpolator,
> RecursionInterceptor recursionInterceptor ) {
>   interpolate( target, (BasicInterpolator) interpolator,
> recursionInterceptor );
> }
>
> style chaining
>
> Unclear at this point if the change for MNG-6275 is exposing this breaking
> change
>
> On 30 August 2017 at 03:56, Stephen Connolly  com> wrote:
>
>> Kristian, FYI
>>
>> https://github.com/codehaus-plexus/plexus-interpolation/comm
>> it/0714af6ce3b4371a8a914496f3632c405b2e3e0c broke binary compatibility
>>
>> On 30 August 2017 at 03:54, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>>> Hmmm so my fix has 24 failing tests... most of which seem to be failing
>>> due to:
>>>
>>> Caused by: java.lang.NoSuchMethodError: org.codehaus.plexus.interpolat
>>> ion.object.FieldBasedObjectInterpolator.interpolate(Ljava/la
>>> ng/Object;Lorg/codehaus/plexus/interpolation/Interpolator;
>>> Lorg/codehaus/plexus/interpolation/RecursionInterceptor;)V
>>> at org.apache.maven.plugin.assembly.interpolation.AssemblyInter
>>> polator.interpolate(AssemblyInterpolator.java:114)
>>> at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.re
>>> adAssembly(DefaultAssemblyReader.java:377)
>>> at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.ad
>>> dAssemblyFromDescriptor(DefaultAssemblyReader.java:324)
>>> at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.re
>>> adAssemblies(DefaultAssemblyReader.java:117)
>>> at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.
>>> execute(AbstractAssemblyMojo.java:434)
>>> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMoj
>>> o(DefaultBuildPluginManager.java:137)
>>> ... 44 more
>>>
>>> I wonder if my fix is actually exposing a bug in the integration test
>>> harness because the test harness may be picking up an older version of
>>> plexus-interpolation than used by maven and the new version breaks
>>> backwards binary compatibility
>>>
>>>
>>> On 30 August 2017 at 02:38, Robert Scholte  wrote:
>>>
 I agree, it would be nice if this one was shipped with one of the next
 releases, as long as it's stable.
 I was kind of surprised that the contextloader could be null, but after
 reading the docs this change makes sense.
 I was too fast with the revert, meaning you could reintroduce the
 unit-test, which was the original symptom.

 Robert


 On Wed, 30 Aug 2017 11:31:30 +0200, Stephen Connolly <
 stephen.alan.conno...@gmail.com> wrote:

 https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-
> jenkinsfile/job/mng-6275/
> will report the status... I am more in favour of including MNG-6275
> rather
> than reverting, but let's get Igor's opinion after we (hopefully) get a
> clean test run.
>
> Absence a clean test run on
> https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-
> jenkinsfile/job/mng-6275/
> then I say revert and descope for 3.5.1 as it is no worse than before
> on
> Java 8 and I'm happy to take time and roll a 3.5.2 for this rather than
> hold up a release train for something that is not a regression from
> 3.5.0
>
> On 30 August 2017 at 02:26, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> https://github.com/apache/maven/commit/39004f6aee634a0ac6daa1f99add29
>> 9ff439f5ec should fix
>>
>> On 30 August 2017 at 02:09, Robert Scholte 
>> wrote:
>>
>> Now that the ITs are all in place again it is good to see that these
>>> failures reflect the concerns of Igor.
>>> Originally this issue said it was Java 9 related, but this is a Java
>>> 8
>>> issue as well, so there's no real need to include it for 3.5.1
>>> I'll revert this commit and reopen the issue.
>>> Future analysis must answer the question where and how the
>>> classloading
>>> must be improved.
>>>
>>> Robert
>>>
>>>
>>> On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
>>> 

Re: ATTN: Maven core build is broken

[Stephen Connolly]

https://github.com/codehaus-plexus/plexus-interpolation/commit/0714af6ce3b4371a8a914496f3632c405b2e3e0c#diff-95342973516cd90dd54ef6a15afa1961
should have *added* the methods taking BasicInterpolator rather than
replace the methods taking Interpolator

Then
https://github.com/codehaus-plexus/plexus-interpolation/commit/0714af6ce3b4371a8a914496f3632c405b2e3e0c#diff-787778a91b4ed9d89b7a12e55be5d31aL138
should have had

@Deprecated
public void interpolate( Object target, Interpolator interpolator,
RecursionInterceptor recursionInterceptor ) {
  interpolate( target, (BasicInterpolator) interpolator,
recursionInterceptor );
}

style chaining

Unclear at this point if the change for MNG-6275 is exposing this breaking
change

On 30 August 2017 at 03:56, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Kristian, FYI
>
> https://github.com/codehaus-plexus/plexus-interpolation/commit/
> 0714af6ce3b4371a8a914496f3632c405b2e3e0c broke binary compatibility
>
> On 30 August 2017 at 03:54, Stephen Connolly  com> wrote:
>
>> Hmmm so my fix has 24 failing tests... most of which seem to be failing
>> due to:
>>
>> Caused by: java.lang.NoSuchMethodError: org.codehaus.plexus.interpolat
>> ion.object.FieldBasedObjectInterpolator.interpolate(Ljava/
>> lang/Object;Lorg/codehaus/plexus/interpolation/
>> Interpolator;Lorg/codehaus/plexus/interpolation/RecursionInterceptor;)V
>> at org.apache.maven.plugin.assembly.interpolation.AssemblyInter
>> polator.interpolate(AssemblyInterpolator.java:114)
>> at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.re
>> adAssembly(DefaultAssemblyReader.java:377)
>> at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.ad
>> dAssemblyFromDescriptor(DefaultAssemblyReader.java:324)
>> at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.re
>> adAssemblies(DefaultAssemblyReader.java:117)
>> at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.
>> execute(AbstractAssemblyMojo.java:434)
>> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMoj
>> o(DefaultBuildPluginManager.java:137)
>> ... 44 more
>>
>> I wonder if my fix is actually exposing a bug in the integration test
>> harness because the test harness may be picking up an older version of
>> plexus-interpolation than used by maven and the new version breaks
>> backwards binary compatibility
>>
>>
>> On 30 August 2017 at 02:38, Robert Scholte  wrote:
>>
>>> I agree, it would be nice if this one was shipped with one of the next
>>> releases, as long as it's stable.
>>> I was kind of surprised that the contextloader could be null, but after
>>> reading the docs this change makes sense.
>>> I was too fast with the revert, meaning you could reintroduce the
>>> unit-test, which was the original symptom.
>>>
>>> Robert
>>>
>>>
>>> On Wed, 30 Aug 2017 11:31:30 +0200, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-
 jenkinsfile/job/mng-6275/
 will report the status... I am more in favour of including MNG-6275
 rather
 than reverting, but let's get Igor's opinion after we (hopefully) get a
 clean test run.

 Absence a clean test run on
 https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-
 jenkinsfile/job/mng-6275/
 then I say revert and descope for 3.5.1 as it is no worse than before on
 Java 8 and I'm happy to take time and roll a 3.5.2 for this rather than
 hold up a release train for something that is not a regression from
 3.5.0

 On 30 August 2017 at 02:26, Stephen Connolly <
 stephen.alan.conno...@gmail.com> wrote:

 https://github.com/apache/maven/commit/39004f6aee634a0ac6daa1f99add29
> 9ff439f5ec should fix
>
> On 30 August 2017 at 02:09, Robert Scholte 
> wrote:
>
> Now that the ITs are all in place again it is good to see that these
>> failures reflect the concerns of Igor.
>> Originally this issue said it was Java 9 related, but this is a Java 8
>> issue as well, so there's no real need to include it for 3.5.1
>> I'll revert this commit and reopen the issue.
>> Future analysis must answer the question where and how the
>> classloading
>> must be improved.
>>
>> Robert
>>
>>
>> On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>> Ok, looking a the results of the bisect-0 through bisect-3 builds, 0
>> and 1
>>
>>> both fail just for the MNG-6127 integration tests, bisect-2 adds the
>>> fix
>>> for MNG-6127, so the build passes... bisect-3 also passes, so the
>>> smoking
>>> gun is...
>>>
>>> https://github.com/apache/maven/commit/f047ea143766fd22ae420
>>> 40e6805bef287f3cc3e
>>>
>>> On 29 August 2017 at 22:17, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:

Re: ATTN: Maven core build is broken

[Stephen Connolly]

Kristian, FYI

https://github.com/codehaus-plexus/plexus-interpolation/commit/0714af6ce3b4371a8a914496f3632c405b2e3e0c
broke binary compatibility

On 30 August 2017 at 03:54, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Hmmm so my fix has 24 failing tests... most of which seem to be failing
> due to:
>
> Caused by: java.lang.NoSuchMethodError: org.codehaus.plexus.
> interpolation.object.FieldBasedObjectInterpolator.
> interpolate(Ljava/lang/Object;Lorg/codehaus/plexus/
> interpolation/Interpolator;Lorg/codehaus/plexus/interpolation/
> RecursionInterceptor;)V
> at org.apache.maven.plugin.assembly.interpolation.AssemblyInterpolator.
> interpolate(AssemblyInterpolator.java:114)
> at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssembly(
> DefaultAssemblyReader.java:377)
> at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.
> addAssemblyFromDescriptor(DefaultAssemblyReader.java:324)
> at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.
> readAssemblies(DefaultAssemblyReader.java:117)
> at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(
> AbstractAssemblyMojo.java:434)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(
> DefaultBuildPluginManager.java:137)
> ... 44 more
>
> I wonder if my fix is actually exposing a bug in the integration test
> harness because the test harness may be picking up an older version of
> plexus-interpolation than used by maven and the new version breaks
> backwards binary compatibility
>
>
> On 30 August 2017 at 02:38, Robert Scholte  wrote:
>
>> I agree, it would be nice if this one was shipped with one of the next
>> releases, as long as it's stable.
>> I was kind of surprised that the contextloader could be null, but after
>> reading the docs this change makes sense.
>> I was too fast with the revert, meaning you could reintroduce the
>> unit-test, which was the original symptom.
>>
>> Robert
>>
>>
>> On Wed, 30 Aug 2017 11:31:30 +0200, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>> https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-
>>> jenkinsfile/job/mng-6275/
>>> will report the status... I am more in favour of including MNG-6275
>>> rather
>>> than reverting, but let's get Igor's opinion after we (hopefully) get a
>>> clean test run.
>>>
>>> Absence a clean test run on
>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-
>>> jenkinsfile/job/mng-6275/
>>> then I say revert and descope for 3.5.1 as it is no worse than before on
>>> Java 8 and I'm happy to take time and roll a 3.5.2 for this rather than
>>> hold up a release train for something that is not a regression from 3.5.0
>>>
>>> On 30 August 2017 at 02:26, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
>>> https://github.com/apache/maven/commit/39004f6aee634a0ac6daa1f99add29
 9ff439f5ec should fix

 On 30 August 2017 at 02:09, Robert Scholte 
 wrote:

 Now that the ITs are all in place again it is good to see that these
> failures reflect the concerns of Igor.
> Originally this issue said it was Java 9 related, but this is a Java 8
> issue as well, so there's no real need to include it for 3.5.1
> I'll revert this commit and reopen the issue.
> Future analysis must answer the question where and how the classloading
> must be improved.
>
> Robert
>
>
> On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> Ok, looking a the results of the bisect-0 through bisect-3 builds, 0
> and 1
>
>> both fail just for the MNG-6127 integration tests, bisect-2 adds the
>> fix
>> for MNG-6127, so the build passes... bisect-3 also passes, so the
>> smoking
>> gun is...
>>
>> https://github.com/apache/maven/commit/f047ea143766fd22ae420
>> 40e6805bef287f3cc3e
>>
>> On 29 August 2017 at 22:17, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>> bisect-0 is the last known good commit with the Jenkinsfile fix to
>>
>>> confirm
>>> that the failures are not another infra related change
>>>
>>> On 29 August 2017 at 22:13, Stephen Connolly
>>> >> com> wrote:
>>>
>>> I have pushed bisect-1, bisect-2 and bisect-3 to see if we can
>>> identify
>>>
 the problematic commit since the last known good build of master
 (#123
 for
 commit 4f2a2dba89251d9045fe9944783509a397491da3)

 On 29 August 2017 at 22:09, Stephen Connolly <
 stephen.alan.conno...@gmail.com> wrote:

 Failure is in testBootstrap, probably something obvious, here's the

> problematic build log... you can inspect for yourself at
> https://builds.apache.org/blue/organizations/jenkins/mave
> 

Re: ATTN: Maven core build is broken

[Stephen Connolly]

Hmmm so my fix has 24 failing tests... most of which seem to be failing due
to:

Caused by: java.lang.NoSuchMethodError:
org.codehaus.plexus.interpolation.object.FieldBasedObjectInterpolator.interpolate(Ljava/lang/Object;Lorg/codehaus/plexus/interpolation/Interpolator;Lorg/codehaus/plexus/interpolation/RecursionInterceptor;)V
at
org.apache.maven.plugin.assembly.interpolation.AssemblyInterpolator.interpolate(AssemblyInterpolator.java:114)
at
org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssembly(DefaultAssemblyReader.java:377)
at
org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.addAssemblyFromDescriptor(DefaultAssemblyReader.java:324)
at
org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssemblies(DefaultAssemblyReader.java:117)
at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:434)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
... 44 more

I wonder if my fix is actually exposing a bug in the integration test
harness because the test harness may be picking up an older version of
plexus-interpolation than used by maven and the new version breaks
backwards binary compatibility


On 30 August 2017 at 02:38, Robert Scholte  wrote:

> I agree, it would be nice if this one was shipped with one of the next
> releases, as long as it's stable.
> I was kind of surprised that the contextloader could be null, but after
> reading the docs this change makes sense.
> I was too fast with the revert, meaning you could reintroduce the
> unit-test, which was the original symptom.
>
> Robert
>
>
> On Wed, 30 Aug 2017 11:31:30 +0200, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-
>> jenkinsfile/job/mng-6275/
>> will report the status... I am more in favour of including MNG-6275 rather
>> than reverting, but let's get Igor's opinion after we (hopefully) get a
>> clean test run.
>>
>> Absence a clean test run on
>> https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-
>> jenkinsfile/job/mng-6275/
>> then I say revert and descope for 3.5.1 as it is no worse than before on
>> Java 8 and I'm happy to take time and roll a 3.5.2 for this rather than
>> hold up a release train for something that is not a regression from 3.5.0
>>
>> On 30 August 2017 at 02:26, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>> https://github.com/apache/maven/commit/39004f6aee634a0ac6daa1f99add29
>>> 9ff439f5ec should fix
>>>
>>> On 30 August 2017 at 02:09, Robert Scholte  wrote:
>>>
>>> Now that the ITs are all in place again it is good to see that these
 failures reflect the concerns of Igor.
 Originally this issue said it was Java 9 related, but this is a Java 8
 issue as well, so there's no real need to include it for 3.5.1
 I'll revert this commit and reopen the issue.
 Future analysis must answer the question where and how the classloading
 must be improved.

 Robert


 On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
 stephen.alan.conno...@gmail.com> wrote:

 Ok, looking a the results of the bisect-0 through bisect-3 builds, 0
 and 1

> both fail just for the MNG-6127 integration tests, bisect-2 adds the
> fix
> for MNG-6127, so the build passes... bisect-3 also passes, so the
> smoking
> gun is...
>
> https://github.com/apache/maven/commit/f047ea143766fd22ae420
> 40e6805bef287f3cc3e
>
> On 29 August 2017 at 22:17, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> bisect-0 is the last known good commit with the Jenkinsfile fix to
>
>> confirm
>> that the failures are not another infra related change
>>
>> On 29 August 2017 at 22:13, Stephen Connolly
>> > com> wrote:
>>
>> I have pushed bisect-1, bisect-2 and bisect-3 to see if we can
>> identify
>>
>>> the problematic commit since the last known good build of master
>>> (#123
>>> for
>>> commit 4f2a2dba89251d9045fe9944783509a397491da3)
>>>
>>> On 29 August 2017 at 22:09, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
>>> Failure is in testBootstrap, probably something obvious, here's the
>>>
 problematic build log... you can inspect for yourself at
 https://builds.apache.org/blue/organizations/jenkins/mave
 n-3.x-jenkinsfile/detail/master/128/tests but there is no point in
 looking at any tests other than testBootstrap as if that fails
 everything
 else will fail too

 [WARNING] Error injecting: org.apache.maven.plugins.depen
 dency.resolvers.ResolvePluginsMojo
 com.google.inject.ProvisionException: Unable to provision, see the
 following errors:
 1) No 

[VOTE] Release Apache Maven JDeps Plugin version 3.1.0

[Robert Scholte]

Hi,

We solved 4 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319223=12341415=Text

There is still one issue left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012319223%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1358/
https://repository.apache.org/service/local/repositories/maven-1358/content/org/apache/maven/plugins/maven-jdeps-plugin/3.1.0/maven-jdeps-plugin-3.1.0-source-release.zip

Source release checksum(s):
maven-jdeps-plugin-3.1.0-source-release.zip sha1:  
25a568612b63d25a76e554e622624bffc1f2eece


Staging site:
https://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

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

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

Re: ATTN: Maven core build is broken

[Robert Scholte]

I agree, it would be nice if this one was shipped with one of the next  
releases, as long as it's stable.
I was kind of surprised that the contextloader could be null, but after  
reading the docs this change makes sense.
I was too fast with the revert, meaning you could reintroduce the  
unit-test, which was the original symptom.


Robert

On Wed, 30 Aug 2017 11:31:30 +0200, Stephen Connolly  
 wrote:



https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-jenkinsfile/job/mng-6275/
will report the status... I am more in favour of including MNG-6275  
rather

than reverting, but let's get Igor's opinion after we (hopefully) get a
clean test run.

Absence a clean test run on
https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-jenkinsfile/job/mng-6275/
then I say revert and descope for 3.5.1 as it is no worse than before on
Java 8 and I'm happy to take time and roll a 3.5.2 for this rather than
hold up a release train for something that is not a regression from 3.5.0

On 30 August 2017 at 02:26, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:


https://github.com/apache/maven/commit/39004f6aee634a0ac6daa1f99add29
9ff439f5ec should fix

On 30 August 2017 at 02:09, Robert Scholte  wrote:


Now that the ITs are all in place again it is good to see that these
failures reflect the concerns of Igor.
Originally this issue said it was Java 9 related, but this is a Java 8
issue as well, so there's no real need to include it for 3.5.1
I'll revert this commit and reopen the issue.
Future analysis must answer the question where and how the classloading
must be improved.

Robert


On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

Ok, looking a the results of the bisect-0 through bisect-3 builds, 0  
and 1
both fail just for the MNG-6127 integration tests, bisect-2 adds the  
fix
for MNG-6127, so the build passes... bisect-3 also passes, so the  
smoking

gun is...

https://github.com/apache/maven/commit/f047ea143766fd22ae420
40e6805bef287f3cc3e

On 29 August 2017 at 22:17, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

bisect-0 is the last known good commit with the Jenkinsfile fix to

confirm
that the failures are not another infra related change

On 29 August 2017 at 22:13, Stephen Connolly
 wrote:

I have pushed bisect-1, bisect-2 and bisect-3 to see if we can  
identify
the problematic commit since the last known good build of master  
(#123

for
commit 4f2a2dba89251d9045fe9944783509a397491da3)

On 29 August 2017 at 22:09, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

Failure is in testBootstrap, probably something obvious, here's the

problematic build log... you can inspect for yourself at
https://builds.apache.org/blue/organizations/jenkins/mave
n-3.x-jenkinsfile/detail/master/128/tests but there is no point in
looking at any tests other than testBootstrap as if that fails
everything
else will fail too

[WARNING] Error injecting: org.apache.maven.plugins.depen
dency.resolvers.ResolvePluginsMojo
com.google.inject.ProvisionException: Unable to provision, see the
following errors:
1) No implementation for org.apache.maven.artifact.hand
ler.manager.ArtifactHandlerManager was bound.
  while locating org.apache.maven.plugins.depen
dency.resolvers.ResolvePluginsMojo
1 error
 at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.j
ava:1025)
 at com.google.inject.internal.InjectorImpl.getInstance(Injector
Impl.java:1051)
 at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDef
erredClass.java:48)
 at com.google.inject.internal.ProviderInternalFactory.provision
(ProviderInternalFactory.java:81)
 at com.google.inject.internal.InternalFactoryToInitializableAda
pter.provision(InternalFactoryToInitializableAdapter.java:53)
 at com.google.inject.internal.ProviderInternalFactory$1.call(Pr
oviderInternalFactory.java:65)
 at com.google.inject.internal.ProvisionListenerStackCallback$Pr
ovision.provision(ProvisionListenerStackCallback.java:115)
 at com.google.inject.internal.ProvisionListenerStackCallback$Pr
ovision.provision(ProvisionListenerStackCallback.java:133)
 at com.google.inject.internal.ProvisionListenerStackCallback.pr
ovision(ProvisionListenerStackCallback.java:68)
 at com.google.inject.internal.ProviderInternalFactory.circularG
et(ProviderInternalFactory.java:63)
 at com.google.inject.internal.InternalFactoryToInitializableAda
pter.get(InternalFactoryToInitializableAdapter.java:45)
 at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImp
l.java:1016)
 at com.google.inject.internal.InjectorImpl.callInContext(Inject
orImpl.java:1092)
 at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.j
ava:1012)
 at org.eclipse.sisu.inject.Guice4$1.get(Guice4.java:162)
 at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry
.java:81)
 at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBe
an.java:51)

Re: ATTN: Maven core build is broken

[Stephen Connolly]

I have deleted bisect-0 through -3 as they have served their purpose

On Wed 30 Aug 2017 at 10:31, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

>
> https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-jenkinsfile/job/mng-6275/
> will report the status... I am more in favour of including MNG-6275 rather
> than reverting, but let's get Igor's opinion after we (hopefully) get a
> clean test run.
>
> Absence a clean test run on
> https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-jenkinsfile/job/mng-6275/
> then I say revert and descope for 3.5.1 as it is no worse than before on
> Java 8 and I'm happy to take time and roll a 3.5.2 for this rather than
> hold up a release train for something that is not a regression from 3.5.0
>
> On 30 August 2017 at 02:26, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>>
>> https://github.com/apache/maven/commit/39004f6aee634a0ac6daa1f99add299ff439f5ec
>> should fix
>>
>> On 30 August 2017 at 02:09, Robert Scholte  wrote:
>>
>>> Now that the ITs are all in place again it is good to see that these
>>> failures reflect the concerns of Igor.
>>> Originally this issue said it was Java 9 related, but this is a Java 8
>>> issue as well, so there's no real need to include it for 3.5.1
>>> I'll revert this commit and reopen the issue.
>>> Future analysis must answer the question where and how the classloading
>>> must be improved.
>>>
>>> Robert
>>>
>>>
>>> On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
>>> Ok, looking a the results of the bisect-0 through bisect-3 builds, 0 and
 1
 both fail just for the MNG-6127 integration tests, bisect-2 adds the fix
 for MNG-6127, so the build passes... bisect-3 also passes, so the
 smoking
 gun is...


 https://github.com/apache/maven/commit/f047ea143766fd22ae42040e6805bef287f3cc3e

 On 29 August 2017 at 22:17, Stephen Connolly <
 stephen.alan.conno...@gmail.com> wrote:

 bisect-0 is the last known good commit with the Jenkinsfile fix to
> confirm
> that the failures are not another infra related change
>
> On 29 August 2017 at 22:13, Stephen Connolly
>  com> wrote:
>
> I have pushed bisect-1, bisect-2 and bisect-3 to see if we can identify
>> the problematic commit since the last known good build of master
>> (#123 for
>> commit 4f2a2dba89251d9045fe9944783509a397491da3)
>>
>> On 29 August 2017 at 22:09, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>> Failure is in testBootstrap, probably something obvious, here's the
>>> problematic build log... you can inspect for yourself at
>>> https://builds.apache.org/blue/organizations/jenkins/mave
>>> n-3.x-jenkinsfile/detail/master/128/tests but there is no point in
>>> looking at any tests other than testBootstrap as if that fails
>>> everything
>>> else will fail too
>>>
>>> [WARNING] Error injecting: org.apache.maven.plugins.depen
>>> dency.resolvers.ResolvePluginsMojo
>>> com.google.inject.ProvisionException: Unable to provision, see the
>>> following errors:
>>> 1) No implementation for org.apache.maven.artifact.hand
>>> ler.manager.ArtifactHandlerManager was bound.
>>>   while locating org.apache.maven.plugins.depen
>>> dency.resolvers.ResolvePluginsMojo
>>> 1 error
>>>  at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.j
>>> ava:1025)
>>>  at com.google.inject.internal.InjectorImpl.getInstance(Injector
>>> Impl.java:1051)
>>>  at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDef
>>> erredClass.java:48)
>>>  at com.google.inject.internal.ProviderInternalFactory.provision
>>> (ProviderInternalFactory.java:81)
>>>  at com.google.inject.internal.InternalFactoryToInitializableAda
>>> pter.provision(InternalFactoryToInitializableAdapter.java:53)
>>>  at com.google.inject.internal.ProviderInternalFactory$1.call(Pr
>>> oviderInternalFactory.java:65)
>>>  at com.google.inject.internal.ProvisionListenerStackCallback$Pr
>>> ovision.provision(ProvisionListenerStackCallback.java:115)
>>>  at com.google.inject.internal.ProvisionListenerStackCallback$Pr
>>> ovision.provision(ProvisionListenerStackCallback.java:133)
>>>  at com.google.inject.internal.ProvisionListenerStackCallback.pr
>>> ovision(ProvisionListenerStackCallback.java:68)
>>>  at com.google.inject.internal.ProviderInternalFactory.circularG
>>> et(ProviderInternalFactory.java:63)
>>>  at com.google.inject.internal.InternalFactoryToInitializableAda
>>> pter.get(InternalFactoryToInitializableAdapter.java:45)
>>>  at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImp
>>> l.java:1016)
>>>  at com.google.inject.internal.InjectorImpl.callInContext(Inject
>>> 

Re: ATTN: Maven core build is broken

[Stephen Connolly]

https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-jenkinsfile/job/mng-6275/
will report the status... I am more in favour of including MNG-6275 rather
than reverting, but let's get Igor's opinion after we (hopefully) get a
clean test run.

Absence a clean test run on
https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-jenkinsfile/job/mng-6275/
then I say revert and descope for 3.5.1 as it is no worse than before on
Java 8 and I'm happy to take time and roll a 3.5.2 for this rather than
hold up a release train for something that is not a regression from 3.5.0

On 30 August 2017 at 02:26, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> https://github.com/apache/maven/commit/39004f6aee634a0ac6daa1f99add29
> 9ff439f5ec should fix
>
> On 30 August 2017 at 02:09, Robert Scholte  wrote:
>
>> Now that the ITs are all in place again it is good to see that these
>> failures reflect the concerns of Igor.
>> Originally this issue said it was Java 9 related, but this is a Java 8
>> issue as well, so there's no real need to include it for 3.5.1
>> I'll revert this commit and reopen the issue.
>> Future analysis must answer the question where and how the classloading
>> must be improved.
>>
>> Robert
>>
>>
>> On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>> Ok, looking a the results of the bisect-0 through bisect-3 builds, 0 and 1
>>> both fail just for the MNG-6127 integration tests, bisect-2 adds the fix
>>> for MNG-6127, so the build passes... bisect-3 also passes, so the smoking
>>> gun is...
>>>
>>> https://github.com/apache/maven/commit/f047ea143766fd22ae420
>>> 40e6805bef287f3cc3e
>>>
>>> On 29 August 2017 at 22:17, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
>>> bisect-0 is the last known good commit with the Jenkinsfile fix to
 confirm
 that the failures are not another infra related change

 On 29 August 2017 at 22:13, Stephen Connolly
  wrote:

 I have pushed bisect-1, bisect-2 and bisect-3 to see if we can identify
> the problematic commit since the last known good build of master (#123
> for
> commit 4f2a2dba89251d9045fe9944783509a397491da3)
>
> On 29 August 2017 at 22:09, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> Failure is in testBootstrap, probably something obvious, here's the
>> problematic build log... you can inspect for yourself at
>> https://builds.apache.org/blue/organizations/jenkins/mave
>> n-3.x-jenkinsfile/detail/master/128/tests but there is no point in
>> looking at any tests other than testBootstrap as if that fails
>> everything
>> else will fail too
>>
>> [WARNING] Error injecting: org.apache.maven.plugins.depen
>> dency.resolvers.ResolvePluginsMojo
>> com.google.inject.ProvisionException: Unable to provision, see the
>> following errors:
>> 1) No implementation for org.apache.maven.artifact.hand
>> ler.manager.ArtifactHandlerManager was bound.
>>   while locating org.apache.maven.plugins.depen
>> dency.resolvers.ResolvePluginsMojo
>> 1 error
>>  at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.j
>> ava:1025)
>>  at com.google.inject.internal.InjectorImpl.getInstance(Injector
>> Impl.java:1051)
>>  at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDef
>> erredClass.java:48)
>>  at com.google.inject.internal.ProviderInternalFactory.provision
>> (ProviderInternalFactory.java:81)
>>  at com.google.inject.internal.InternalFactoryToInitializableAda
>> pter.provision(InternalFactoryToInitializableAdapter.java:53)
>>  at com.google.inject.internal.ProviderInternalFactory$1.call(Pr
>> oviderInternalFactory.java:65)
>>  at com.google.inject.internal.ProvisionListenerStackCallback$Pr
>> ovision.provision(ProvisionListenerStackCallback.java:115)
>>  at com.google.inject.internal.ProvisionListenerStackCallback$Pr
>> ovision.provision(ProvisionListenerStackCallback.java:133)
>>  at com.google.inject.internal.ProvisionListenerStackCallback.pr
>> ovision(ProvisionListenerStackCallback.java:68)
>>  at com.google.inject.internal.ProviderInternalFactory.circularG
>> et(ProviderInternalFactory.java:63)
>>  at com.google.inject.internal.InternalFactoryToInitializableAda
>> pter.get(InternalFactoryToInitializableAdapter.java:45)
>>  at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImp
>> l.java:1016)
>>  at com.google.inject.internal.InjectorImpl.callInContext(Inject
>> orImpl.java:1092)
>>  at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.j
>> ava:1012)
>>  at org.eclipse.sisu.inject.Guice4$1.get(Guice4.java:162)
>>  at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry
>> .java:81)
>>  at 

Re: ATTN: Maven core build is broken

[Stephen Connolly]

https://github.com/apache/maven/commit/39004f6aee634a0ac6daa1f99add299ff439f5ec
should fix

On 30 August 2017 at 02:09, Robert Scholte  wrote:

> Now that the ITs are all in place again it is good to see that these
> failures reflect the concerns of Igor.
> Originally this issue said it was Java 9 related, but this is a Java 8
> issue as well, so there's no real need to include it for 3.5.1
> I'll revert this commit and reopen the issue.
> Future analysis must answer the question where and how the classloading
> must be improved.
>
> Robert
>
>
> On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> Ok, looking a the results of the bisect-0 through bisect-3 builds, 0 and 1
>> both fail just for the MNG-6127 integration tests, bisect-2 adds the fix
>> for MNG-6127, so the build passes... bisect-3 also passes, so the smoking
>> gun is...
>>
>> https://github.com/apache/maven/commit/f047ea143766fd22ae420
>> 40e6805bef287f3cc3e
>>
>> On 29 August 2017 at 22:17, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>> bisect-0 is the last known good commit with the Jenkinsfile fix to confirm
>>> that the failures are not another infra related change
>>>
>>> On 29 August 2017 at 22:13, Stephen Connolly
>>> >> com> wrote:
>>>
>>> I have pushed bisect-1, bisect-2 and bisect-3 to see if we can identify
 the problematic commit since the last known good build of master (#123
 for
 commit 4f2a2dba89251d9045fe9944783509a397491da3)

 On 29 August 2017 at 22:09, Stephen Connolly <
 stephen.alan.conno...@gmail.com> wrote:

 Failure is in testBootstrap, probably something obvious, here's the
> problematic build log... you can inspect for yourself at
> https://builds.apache.org/blue/organizations/jenkins/mave
> n-3.x-jenkinsfile/detail/master/128/tests but there is no point in
> looking at any tests other than testBootstrap as if that fails
> everything
> else will fail too
>
> [WARNING] Error injecting: org.apache.maven.plugins.depen
> dency.resolvers.ResolvePluginsMojo
> com.google.inject.ProvisionException: Unable to provision, see the
> following errors:
> 1) No implementation for org.apache.maven.artifact.hand
> ler.manager.ArtifactHandlerManager was bound.
>   while locating org.apache.maven.plugins.depen
> dency.resolvers.ResolvePluginsMojo
> 1 error
>  at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.j
> ava:1025)
>  at com.google.inject.internal.InjectorImpl.getInstance(Injector
> Impl.java:1051)
>  at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDef
> erredClass.java:48)
>  at com.google.inject.internal.ProviderInternalFactory.provision
> (ProviderInternalFactory.java:81)
>  at com.google.inject.internal.InternalFactoryToInitializableAda
> pter.provision(InternalFactoryToInitializableAdapter.java:53)
>  at com.google.inject.internal.ProviderInternalFactory$1.call(Pr
> oviderInternalFactory.java:65)
>  at com.google.inject.internal.ProvisionListenerStackCallback$Pr
> ovision.provision(ProvisionListenerStackCallback.java:115)
>  at com.google.inject.internal.ProvisionListenerStackCallback$Pr
> ovision.provision(ProvisionListenerStackCallback.java:133)
>  at com.google.inject.internal.ProvisionListenerStackCallback.pr
> ovision(ProvisionListenerStackCallback.java:68)
>  at com.google.inject.internal.ProviderInternalFactory.circularG
> et(ProviderInternalFactory.java:63)
>  at com.google.inject.internal.InternalFactoryToInitializableAda
> pter.get(InternalFactoryToInitializableAdapter.java:45)
>  at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImp
> l.java:1016)
>  at com.google.inject.internal.InjectorImpl.callInContext(Inject
> orImpl.java:1092)
>  at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.j
> ava:1012)
>  at org.eclipse.sisu.inject.Guice4$1.get(Guice4.java:162)
>  at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry
> .java:81)
>  at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBe
> an.java:51)
>  at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPle
> xusContainer.java:263)
>  at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPle
> xusContainer.java:255)
>  at org.apache.maven.plugin.internal.DefaultMavenPluginManager.g
> etConfiguredMojo(DefaultMavenPluginManager.java:519)
>  at org.apache.maven.plugin.DefaultBuildPluginManager.executeMoj
> o(DefaultBuildPluginManager.java:124)
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj
> oExecutor.java:208)
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj
> oExecutor.java:154)
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj
> 

Re: ATTN: Maven core build is broken

[Robert Scholte]

Now that the ITs are all in place again it is good to see that these  
failures reflect the concerns of Igor.
Originally this issue said it was Java 9 related, but this is a Java 8  
issue as well, so there's no real need to include it for 3.5.1

I'll revert this commit and reopen the issue.
Future analysis must answer the question where and how the classloading  
must be improved.


Robert

On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly  
 wrote:


Ok, looking a the results of the bisect-0 through bisect-3 builds, 0 and  
1

both fail just for the MNG-6127 integration tests, bisect-2 adds the fix
for MNG-6127, so the build passes... bisect-3 also passes, so the smoking
gun is...

https://github.com/apache/maven/commit/f047ea143766fd22ae42040e6805bef287f3cc3e

On 29 August 2017 at 22:17, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

bisect-0 is the last known good commit with the Jenkinsfile fix to  
confirm

that the failures are not another infra related change

On 29 August 2017 at 22:13, Stephen Connolly  
 wrote:


I have pushed bisect-1, bisect-2 and bisect-3 to see if we can identify
the problematic commit since the last known good build of master (#123  
for

commit 4f2a2dba89251d9045fe9944783509a397491da3)

On 29 August 2017 at 22:09, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:


Failure is in testBootstrap, probably something obvious, here's the
problematic build log... you can inspect for yourself at
https://builds.apache.org/blue/organizations/jenkins/mave
n-3.x-jenkinsfile/detail/master/128/tests but there is no point in
looking at any tests other than testBootstrap as if that fails  
everything

else will fail too

[WARNING] Error injecting: org.apache.maven.plugins.depen
dency.resolvers.ResolvePluginsMojo
com.google.inject.ProvisionException: Unable to provision, see the
following errors:
1) No implementation for org.apache.maven.artifact.hand
ler.manager.ArtifactHandlerManager was bound.
  while locating org.apache.maven.plugins.depen
dency.resolvers.ResolvePluginsMojo
1 error
 at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.j
ava:1025)
 at com.google.inject.internal.InjectorImpl.getInstance(Injector
Impl.java:1051)
 at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDef
erredClass.java:48)
 at com.google.inject.internal.ProviderInternalFactory.provision
(ProviderInternalFactory.java:81)
 at com.google.inject.internal.InternalFactoryToInitializableAda
pter.provision(InternalFactoryToInitializableAdapter.java:53)
 at com.google.inject.internal.ProviderInternalFactory$1.call(Pr
oviderInternalFactory.java:65)
 at com.google.inject.internal.ProvisionListenerStackCallback$Pr
ovision.provision(ProvisionListenerStackCallback.java:115)
 at com.google.inject.internal.ProvisionListenerStackCallback$Pr
ovision.provision(ProvisionListenerStackCallback.java:133)
 at com.google.inject.internal.ProvisionListenerStackCallback.pr
ovision(ProvisionListenerStackCallback.java:68)
 at com.google.inject.internal.ProviderInternalFactory.circularG
et(ProviderInternalFactory.java:63)
 at com.google.inject.internal.InternalFactoryToInitializableAda
pter.get(InternalFactoryToInitializableAdapter.java:45)
 at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImp
l.java:1016)
 at com.google.inject.internal.InjectorImpl.callInContext(Inject
orImpl.java:1092)
 at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.j
ava:1012)
 at org.eclipse.sisu.inject.Guice4$1.get(Guice4.java:162)
 at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry
.java:81)
 at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBe
an.java:51)
 at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPle
xusContainer.java:263)
 at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPle
xusContainer.java:255)
 at org.apache.maven.plugin.internal.DefaultMavenPluginManager.g
etConfiguredMojo(DefaultMavenPluginManager.java:519)
 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMoj
o(DefaultBuildPluginManager.java:124)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj
oExecutor.java:208)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj
oExecutor.java:154)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj
oExecutor.java:146)
 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.b
uildProject(LifecycleModuleBuilder.java:117)
 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.b
uildProject(LifecycleModuleBuilder.java:81)
 at org.apache.maven.lifecycle.internal.builder.singlethreaded.S
ingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
 at