On Sun 29 Jul 2018 at 18:31, Robert Scholte wrote:
> jenkinsEnv.groovy contains
> def nodeSelection(String osLabel)
>
> this section can be used to temporary disable certain nodes for all our
> jobs.
And it is for this *exact* purpose that the env is separate from the rest
of the pipeline s
jenkinsEnv.groovy contains
def nodeSelection(String osLabel)
this section can be used to temporary disable certain nodes for all our
jobs.
Robert
On Sun, 29 Jul 2018 14:40:45 +0200, Karl Heinz Marbaise
wrote:
Hi,
unfortunately our current master fails constantly with an issue on
Hi,
unfortunately our current master fails constantly with an issue on
Windows JDK 7 which is related to a particular node (Windows-2016-1)
for this I have opened an issue at infra[1]..
Kind regards
Karl Heinz Marbaise
[1]: https://issues.apache.org/jira/browse/INFRA-16836
-
Because the plan is to bump min jdk with the version bump to 4.0.0
We have a checklist of things to get out of the way first, from memory:
- [ ] Release resolver
- [ ] Release 3.5.3
- [ ] Get something that can verify api binary compatibility evolution and
integrate into build
- [ ] Bump core to
Hi Sylwester,
On 18/02/18 16:45, Sylwester Lachiewicz wrote:
I would also ask, why Core is still build with old maven versions ? :)
What do you mean? Currently Maven is build with Maven 3.5.2 / 3.5.0 (On
Windows nodes)...I don't see the problem ?
imho it would be nice from dev perspective
I would also ask, why Core is still build with old maven versions ? :)
imho it would be nice from dev perspective to require Java 8 to build maven
core (keep jdk level for source/target at 7 and still enforce this with
maven-enforcer) and Maven 3.5.2. From Ops perspective, there will be less
build
Hi,
On 18/02/18 15:13, Karl Heinz Marbaise wrote:
Hi,
I've stumbled over a thing ..
why is Maven Core not build with JDK 9 as well as JDK 7, 8 ?
I have taken a look into Jenkinsfile and there is not implementation for
that...
I would suggest that it should be added ...(I can do ..)
So tr
Hi,
I've stumbled over a thing ..
why is Maven Core not build with JDK 9 as well as JDK 7, 8 ?
I have taken a look into Jenkinsfile and there is not implementation for
that...
I would suggest that it should be added ...(I can do ..)
cause our plugins etc. are tested with the build against J
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 superclass
2) the ‘p
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]
https://github.com/takari/takar
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 background first -
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
N
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
no
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
g
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 via the ServiceLoader?
On Wed, 30 Aug 2017 22:48:40 +0200
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
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 Sch
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.apach
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/
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
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 t
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.c
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, St
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
>
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 v
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
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 t
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
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-
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 b
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/interpola
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-tes
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
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
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
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
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, bise
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/f047ea143766fd22ae42040e680
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 <
stephen.a
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 i
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
i
42 matches
Mail list logo
