Re: [VOTE] Release Apache Maven JDeps Plugin version 3.1.0

+1 from me. Tested on JDK9 without any changes to dependencies - works a treat. Reverted back to 3.0.0 in test and observed the failing build. So bring on the new release! On 30 Aug 2017, at 22:51, Robert Scholte wrote: > Hi, > > We solved 4 issues: >

Re: ATTN: Maven core build is broken

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

Re: ATTN: Maven core build is broken

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

Re: ATTN: Maven core build is broken

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

Re: ATTN: Maven core build is broken

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

Re: ATTN: Maven core build is broken

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

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

Github user owenfarrell commented on the issue: https://github.com/apache/maven-surefire/pull/157 @Tibor17 I see what you're going for, that makes sense. I've update my PR to just include IT contents now, with an improved IT that emulates a scenario where working copy changes

Re: ATTN: Maven core build is broken

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]

Re: ATTN: Maven core build is broken

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

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

Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/157 @owenfarrell My tests passed on this code. I have to continue to develop and refactor more. List testDepends = project.getTestArtifacts();