On Thu, 31 Aug 2017 15:00:36 +0200, Stuart McCulloch
wrote:
Hi,
A bit of background first - ClassRealm has two different different
concepts of class loading hierarchy:
1) the base class loader passed into the constructor, which is passed
onto the URLClassLoader
Checking my notes [1], maven-dependency-tree seems to be an interesting
case. It calls (or at least used to call) ClassLoader#loadClass to guess
which version of aether to use and its tests may misbehave if there is
"another" set of aether in system classloader.
[1]
Do we have a list of integrator contacts we can send an FYI to?
By the sounds of it, we should be OK for merging this fix - at least for
3.5.1-rc-1 and revert if integrators find significantly problematic
On 31 August 2017 at 06:00, Stuart McCulloch wrote:
> Hi,
>
> A bit of
Hi,
A bit of background first - ClassRealm has two different different concepts of
class loading hierarchy:
1) the base class loader passed into the constructor, which is passed onto the
URLClassLoader superclass
2) the ‘parent’ class loader set via setParentClassLoader / setParentRealm
I don't have strong opinion about this change, but here are couple of
observations
Manifest Class-Path is used to populate system classloader, iirc. Plugin
integration testing is likely to be affected by this change. This change
will give the plugin access to maven core and its dependencies not
I have rebased and squashed the commit: https://github.com/
apache/maven/compare/mng-6275
The tests should still pass: https://builds.apache.org/
blue/organizations/jenkins/maven-3.x-jenkinsfile/detail/mng-6275/4/pipeline
So just need the code review from Stuart and Igor and then I think we are
Cool
On Wed, 30 Aug 2017 23:22:14 +0200, 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
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
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
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
>
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
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
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 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 <
>
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,
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
>
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
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,
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
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,
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
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
Hmmm so my fix has 24 failing tests... most of which seem to be failing due
to:
Caused by: java.lang.NoSuchMethodError:
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
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
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://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
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.
I'll delete branches bisect-0 through bisect-3 once Robert ACKs my analysis
On 29 August 2017 at 16:57, 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,
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...
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 <
stephen.alan.conno...@gmail.com> wrote:
> I have pushed bisect-1, bisect-2 and bisect-3 to see if we can identify
> the
Another build based on master is well failing on all four exec environments:
https://builds.apache.org/job/maven-3.x-jenkinsfile/job/MNG-6216/4/testReport/junit/org.apache.maven.it/MavenITBootstrapTest/
So clearly the build failure is real
On 29 August 2017 at 22:13, Stephen Connolly <
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
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/maven-3.x-jenkinsfile/detail/master/128/tests
but there is no point in looking at any tests other than testBootstrap as
34 matches
Mail list logo