You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Christian Schulte <cs...@schulte.it> on 2016/12/17 03:17:42 UTC
Improving Jenkins
Hi,
I renamed the 'maven-aether-provider' module to
'maven-resolver-provider'. What happens on Jenkins is this: The
'maven-aether-provider' folder will not get deleted correctly when
Jenkins performs the SCM update/checkout. This may be due to the
existence of the 'maven-aether-provider/target' folder. We cannot run a
post-build 'clean' execution. This would throw away the build result
after a successfull build so that no-one could download anything of that
build result. Does someone know how to make Jenkins correctly handle
module renames? Issue is the old module folder is lying around on every
build node and the workspace needs to be deleted manually on every build
node. That's one of the reasons Jenkins is sending out failure notices
for the 'maven-3.x' and related build jobs since a few days. Can we do
something about it? If not, just delete the workspace whenever such a
build failure gets reported until all build nodes caught up.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Hervé BOUTEMY <he...@free.fr>.
Le mardi 20 décembre 2016, 03:45:47 CET Christian Schulte a écrit :
> Am 12/19/16 um 08:32 schrieb Hervé BOUTEMY:
> > Le lundi 19 décembre 2016, 00:44:48 CET Christian Schulte a écrit :
> >> Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY:
> >> Thats what the resolver does when requested to collect dependencies for
> >> a POM or for a dependency. I just made two selector implementations
> >> behave the same.
> >
> > that's the risky job: changing key Maven core feature => require a lot of
> > explanation for everybody before changing it on master
> > And a choice on when to include such breaking change
>
> I consider master "bleeding edge". This is where everyone is working on
> and what is used by the developers themselves. Main point of
> collaboration. Not questioning your points. We are talking about those
> things solely because I pushed them to master. That's the intention and
> that has lead to a state I would not mind to release. That's a different
> story, I know.
we are in a stabilization phase, to make a long awaited release which has
already numerous questions attached for end users migration: that's not the
time to add more breaking changes
>
> > "I'm not the author": wrong conclusion
> > right conclusion is: "change with extreme care, because even if your
> > intentions are the best, such change will bite a lot of users"
>
> I try to be that careful. The resolver codebase is quite special. What
> appears to be common sense patterns applied turns out to be tweaked like
> mad under the hood applying some custom only the original author knows
> what's going on patterns everywhere sometimes in conflict with what is
> common sense. I may be totally wrong with this. That's my impression
> having read large parts of that codebase. Continously re-reading may
> yield different results.
yes: that's why working on changing it requires unusual strategies
>
> >> What is broken?
> >
> > remember we have thousands or millions of users: the change will make a
> > lot of builds fail
>
> All ITs are passing. I really do not expect that much of breakage.
All ITs are passing: that's a first minimal step = "it can fly"
the next step is to estimate how much efforts it will require for users to
upgrade (for which benefit): do you have a list of plugins versions that are
failing with the new plugins resolution algorithm? Putting it on a Wiki page
would be useful for change management.
and there is even eventually another step: can a pom be configured to work both
with the old algorithm and the new one?
>
> > As a conclusion: you're working on changing dependencies and plugin
> > management, which is the most difficult and risky part of Maven changes,
> > that has a lot of impact on every user (Maven developers being only the
> > first level of users)
> > Then this require extreme caution that you missed at the moment
>
> All ITs are passing. It took a weekend of work to reach that. Ok. In
> between master was in an unusable state from time to time but never for
> more than 2 hours. It maybe is a matter of workflow. I fetch only before
> I want to push something but I am pushing often. So this may not work
> when not fetching for weeks.
one week on a feature branch is the way to go for such key changes.
This is true in general, and even more when we're trying to do a release
>
> > I want to be supportive of such changes, but that will require other
> > working methods for the whole Maven team to be able to explain to ouor
> > end users why *we* changed something that breaks existing builds
>
> It is not breaking existing builds. Really. I haven't changed things
> that dramatically. Hopefully.
still has to be proven and documented: I want to help on the wiki page, please
give some initial list and I'll work with you on it
> It may break broken builds working before. Different story.
that one is what makes me mad: you're playing like a purist kid, against
normal users
If it was working, it was not broken: it may have worked by "chance", yes, and
we must work on removing this risky "chance" part. But you can't start by
telling users their build was broken: no, it worked
>
> > On the short term, I think that everything can't go into Maven 3.4.0 but
> > will have to be explained,documented and included in a future version:
> > perhaps Robert's idea on rewinding to a past state to rework what goes
> > into Maven 3.4.0 and what will go in a future version will be the best
> > solution to help us work back on a shared vision and clean codebase
>
> Maybe create a 3.4.0 branch forking from somewhere you feel comfortable
> with. The same for the resolver. Time for release branches then.
time for exceptional release branch, because this is exceptional change
> Means
> instead of everyone creating theire own branches, let everyone
> collaborate on master and have a release branch kept in a state one can
> cut a release from whenever needed/wanted. Maybe some release manager
> decides what is merged from master and what not. It's possible to cut
> releases in between whenever needed/wanted/requested/required that way.
> Collaboration is important. It has helped a lot getting those changes
> sorted out. In fact, we are still sorting things out now. That's
> something very positive.
yes, collaboration is positive: but you're still avoiding the fact that you
just postponed the 3.4.0 release for I don't know how much time. It seems
you're missing empathy for the rest of the team and for users: that one is a
lot less positive :(
I hope this is the last time you're working on master for such risky key
changes: please confirm
Regards,
Hervé
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/20/16 um 03:45 schrieb Christian Schulte:
> Collaboration is important. It has helped a lot getting those changes
> sorted out. In fact, we are still sorting things out now. That's
> something very positive.
I do use the 3.4.0-SNAPSHOT locally for everything. Whenever I build a
new snapshot (locally or download from Jenkins) I do want the changes
others have made to be part of it. If these changes are on some private
branch, I would never have a chance to test them out.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/19/16 um 08:32 schrieb Herv BOUTEMY:
> Le lundi 19 dcembre 2016, 00:44:48 CET Christian Schulte a crit :
>> Am 12/18/16 um 10:19 schrieb Herv BOUTEMY:
>> Thats what the resolver does when requested to collect dependencies for
>> a POM or for a dependency. I just made two selector implementations
>> behave the same.
> that's the risky job: changing key Maven core feature => require a lot of
> explanation for everybody before changing it on master
> And a choice on when to include such breaking change
I consider master "bleeding edge". This is where everyone is working on
and what is used by the developers themselves. Main point of
collaboration. Not questioning your points. We are talking about those
things solely because I pushed them to master. That's the intention and
that has lead to a state I would not mind to release. That's a different
story, I know.
> "I'm not the author": wrong conclusion
> right conclusion is: "change with extreme care, because even if your
> intentions are the best, such change will bite a lot of users"
I try to be that careful. The resolver codebase is quite special. What
appears to be common sense patterns applied turns out to be tweaked like
mad under the hood applying some custom only the original author knows
what's going on patterns everywhere sometimes in conflict with what is
common sense. I may be totally wrong with this. That's my impression
having read large parts of that codebase. Continously re-reading may
yield different results.
>> What is broken?
> remember we have thousands or millions of users: the change will make a lot of
> builds fail
All ITs are passing. I really do not expect that much of breakage.
> As a conclusion: you're working on changing dependencies and plugin
> management, which is the most difficult and risky part of Maven changes, that
> has a lot of impact on every user (Maven developers being only the first level
> of users)
> Then this require extreme caution that you missed at the moment
All ITs are passing. It took a weekend of work to reach that. Ok. In
between master was in an unusable state from time to time but never for
more than 2 hours. It maybe is a matter of workflow. I fetch only before
I want to push something but I am pushing often. So this may not work
when not fetching for weeks.
> I want to be supportive of such changes, but that will require other working
> methods for the whole Maven team to be able to explain to ouor end users why
> *we* changed something that breaks existing builds
It is not breaking existing builds. Really. I haven't changed things
that dramatically. Hopefully. It may break broken builds working before.
Different story.
> On the short term, I think that everything can't go into Maven 3.4.0 but will
> have to be explained,documented and included in a future version: perhaps
> Robert's idea on rewinding to a past state to rework what goes into Maven
> 3.4.0 and what will go in a future version will be the best solution to help
> us work back on a shared vision and clean codebase
Maybe create a 3.4.0 branch forking from somewhere you feel comfortable
with. The same for the resolver. Time for release branches then. Means
instead of everyone creating theire own branches, let everyone
collaborate on master and have a release branch kept in a state one can
cut a release from whenever needed/wanted. Maybe some release manager
decides what is merged from master and what not. It's possible to cut
releases in between whenever needed/wanted/requested/required that way.
Collaboration is important. It has helped a lot getting those changes
sorted out. In fact, we are still sorting things out now. That's
something very positive.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Hervé BOUTEMY <he...@free.fr>.
Le lundi 19 décembre 2016, 00:44:48 CET Christian Schulte a écrit :
> Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY:
> > you are completely missing my point: simply put, when doing such risky
> > change (that require Review Then Commit), *please do it on a branch*, not
> > on master (that you'll later revert to postpone to a future Maven
> > version: tracking changes on master is a big giant mess lately, with
> > updates and reverts in every place!)
>
> Master is WIP. Working on a branch does not make Jenkins check anything.
you're just missing "by default": if you need a branch build job, we can add
it
and you can even be added as Jenkins admin to do it yourself
> I can continue to use my machine during Jenkins doing it's job.
you *must* do it, particularly if you're working on master
> Running
> the ITs locally means my machine is unuseable for nearly an hour.
yes, working on Maven core is hard
> If the
> ITs are running fine locally, it happened way to often that the ITs on
> Jenkins failed due to other reasons. I do run them locally whenever
> Jenkins sends out failure notices to reproduce things locally.
wrong process, particularly when you're working on core master and on changing
key features like dependency and plugins management
> I am no
> fan of developers working for weeks on theire own and then trying to
> integrate their weeks of work all in one go no-one has ever had a chance
> to follow and comment.
the requirements you describe are requirements for a branch
>
> > and on "As far as I understand it we want the plugins and core
> >
> > extensions to use the same classpath when executed and when build"
> >
> > You know what? We want also that libraries classpath are consistent when
> > built and when used as dependencies: nothing specific to plugins and core
> > extensions.
> I am not the author who made that a difference but there is a
> difference. There is a reason some logic is in place deciding to select
> a transitive dependency or to ignore it. That's just the way Maven is
> designed.
>
> POM
> - depdency (always selected, no matter what)
> - transitive dependency (selected only if not non-transitive)
>
> Dependency
> - transitive dependency (selected if not non-transitive)
ok, we're starting to have an explanation the initial facts: thank you
>
> Thats what the resolver does when requested to collect dependencies for
> a POM or for a dependency. I just made two selector implementations
> behave the same.
that's the risky job: changing key Maven core feature => require a lot of
explanation for everybody before changing it on master
And a choice on when to include such breaking change
> Some were updated to reflect this difference. Some were
> not. They are now all behaving the same. Plugins and core extensions
> were resolved as dependencies. This started to work consistently. That
> led to MNG-6135. That should be implemented now. I had to update an IT
> when plugin resolution (as dependency) started to work. I could revert
> that update since they are now resolved as projects.
>
> > Everything is built some time then used.
> > If there are some unexpected discrepencies, we have an issue.
>
> See above. This is how things have been implemented for years. I am not
> the author.
"I'm not the author": wrong conclusion
right conclusion is: "change with extreme care, because even if your
intentions are the best, such change will bite a lot of users"
>
> > And updating plugins for Maven own builds to work now won't help Maven
> > users to update their builds
> > Notice I use the word "update", not "fix": I don't care if you think that
> > the required update is a positive fix because everything was buggy for 10
> > years and you're the guy who is saving us from the bugs we lived with:
> > for normal users, it worked and you're once again breaking Maven
>
> What is broken?
remember we have thousands or millions of users: the change will make a lot of
builds fail
> The number of failing ITs is down to one already. How
> many commits did it take to get the ANSI colors going?
adding a new feature that don't change existing builds is far easier beast:
and even then, notice I did branches when some changes could cause issues.
Sometimes, even if we can continue CTR on master, doing RTC through a branch
is the way to go: it takes more time but improves team decision process
>
> mng5771CoreExtensions(CoreExtensionRetrievedFromAMirrorWithBasicAuthenticati
> on) FAILURE (3.5 s)
>
> I am looking into this one right now.
>
> Regards,
As a conclusion: you're working on changing dependencies and plugin
management, which is the most difficult and risky part of Maven changes, that
has a lot of impact on every user (Maven developers being only the first level
of users)
Then this require extreme caution that you missed at the moment
I want to be supportive of such changes, but that will require other working
methods for the whole Maven team to be able to explain to ouor end users why
*we* changed something that breaks existing builds
On the short term, I think that everything can't go into Maven 3.4.0 but will
have to be explained,documented and included in a future version: perhaps
Robert's idea on rewinding to a past state to rework what goes into Maven
3.4.0 and what will go in a future version will be the best solution to help
us work back on a shared vision and clean codebase
Don't hesitate to come on IRC also to discuss and interact in additional ways
to sourcecontrol or email after having changed hard things
Regards,
Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/21/16 um 08:04 schrieb Herv BOUTEMY:
> And remember we'll require to prepare a list of known plugins
Older findbugs plugin versions are not working with 3.4.
The maven-plugin-plugin 3.4 is not working with 3.4. You can downgrade
to 3.3 or upgrade to 3.5. That's the plugins I know of.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Christian Schulte <cs...@schulte.it>.
Boils down to:
Decide the list of issues part of the next release. Update JIRA to
reflect that. Provide the release nodes and what else needs to be
documented. Personally, cut a resolver release 1.2.0 from current
resolver master and throw out tons of RCs of current core master using
either 3.4.0 or 4.0.0 as the version. It's important this gets used by a
large group of people. For this, documentation needs to be ready and
published so that you do not need to answer the same questions over and
over again. A link to the documentation needs to be the answer. I am
still not keen on writing documentation I can throw out of the window
right after committing.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Hervé BOUTEMY <he...@free.fr>.
Le samedi 24 décembre 2016, 18:33:06 CET Guillaume Boué a écrit :
> Yes, I agree with this. The plugin doesn't need to inspect its own
> annotations at runtime, so the dependency is "only needed at
> compile-time, unused at run-time". The provided scope may be a bit of an
> abuse for lack of a "compile-only" scope... but it works. The current
> documentation on how to create plugins is correct, clarifying that
> nothing is providing the dependency in MPLUGIN-321 is great.
in general, provided dependencies are really provided by a runtime context
then I'm still confident we chose a good term: the annotations case is really
something that is uncommon (and even didn't exist at the time when provided
scope was defined)
Does not deserve to create a new term, that would de-facto be a synonym
thanks for the feedback
Regards,
Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Guillaume Boué <gb...@apache.org>.
Le 24/12/2016 17:11, Herv BOUTEMY a crit :
> Le vendredi 23 dcembre 2016, 09:32:50 CET Christian Schulte a crit :
>> Am 12/23/16 um 08:16 schrieb Herv BOUTEMY:
>>> Le vendredi 23 dcembre 2016, 03:59:17 CET Christian Schulte a crit :
>>>> Am 12/22/16 um 19:14 schrieb Robert Scholte:
>>>>> -0.9 for the commandline option, there should be only one truth.
>>>> +1
>>>>
>>>>> Dependency management is way too important, you should not have an
>>>>> option
>>>>> to choose. Better to agree that we are indeed fixing a bug or that we
>>>>> should maintain the current behavior. And that'll take time. I will have
>>>>> a
>>>>> look at all the related issues which could be controlled by this flag
>>>>> and
>>>>> find a way to get feedback from more people.
>>>> -1 for maintaining the current behavior. Issues will get reported over
>>>> and over again.
>>> you keep saying that but don't give any other example than MPLUGIN-296 = a
>>> failure caused by your purist fix in MRESOLVER-8
>>> and you talked about findbugs-maven-plugin, but did not give any pointer
>>>
>>> once again, can you give examples of something that MRESOLVER-8 fixes,
>>> apart from the logic of exact resolution?
>> Why are you questioning making plugin resolution work the same way
>> project resolution is performed? I don't get that.
> please look at "if it ain't broke, don't fix it" proverb, or "never change a
> running system"
>
> for example at https://en.wiktionary.org/wiki/if_it_ain't_broke,_don't_fix_it
>
>> The bugfix
>> immediately uncovered a mistake in a POM of a plugin everyone agrees to
>> be a real issue.
> no, I don't agree that it is a real issue
>
>> I just verified that selector had that bug right from
>> the intial resolver contribution outside Apache so has always been
>> there. Right now only the maven-plugin-plugin version 3.4 is affected.
>> Version 3.3 and 3.5 are not affected.
> I fear it's not only one plugin, but every plugin that applied the
> scope=provided recipe that Maven Plugin Tools Annotations promotes
>
>> The findbugs-maven-plugin issue
>> I've been talking about is unrelated to the resolver and is also fixed
>> in recent releases.
> ok, I don't know why you talked about it if it's not related
>
> [...]
>
>>> I respect logic, since I can imagine that in addition to the case that
>>> worked magically, there can be cases that fail magically = not something
>>> I want forever.
>>> You found a few cases working magically = in fact one recipe based on it,
>>> that is still in our documentation [1] as "<!-- annotations are needed
>>> only to build the plugin -->").
>>> If we didn't find cases failing magically, pressure to change is not the
>>> same.
>> Things working magically are a recipe for desaster.
> disaster didn't happen for years before your work on "fixing" something that
> didn't break: remember to read about "if it ain't broke, don't fix it" proverb,
> it has to be known and respected at least in some cases
>
>> It's just
>> unpredictable behaviour presented to be something done intentionally
>> although things are just a matter of luck or bad luck.
> that's why I try to know if you have reported cases (as you told) of something
> really broken (= something with bad luck)
> IIUC, you don't have any case of bad luck
>
>> Especially when a
>> lot of the POMs around are a result of trial and error. Maven should
>> have produced an error but did not "magically". Chances are great
>> someone starts applying his findings to each and every project without
>> ever noticing things really are not working as intended. We should be
>> super sure that this trial and error always leads to valid POMs.
>>
>>> And of course, this wrong explanation in our doc should be fixed and
>>> explained: I'll work on that (because, remember, I already told I'm
>>> supportive of improvements): I opened MPLUGIN-321 [2], please review and
>>> improve explanations if necessary = this is the start of something that
>>> will also appear in release notes for the version of Maven that will
>>> contaning the updated plugin resolution algorithm (we'll see later if
>>> it's Maven 3.4.0 or not)
>> There is nothing wrong about that documentation. It's a special case
>> with the maven-plugin-plugin. Only that plugin must not use "provided"
>> for the annotations because that plugin is what needs them at runtime.
>> It is the provider itself. Other plugins should in fact use "provided"
>> because the annotations are provided by maven-plugin-plugin and not used
>> by anything else.
> ok, I start to understand: no, the plugin does not provide the annotations
> dependency (as I wrote in MPLUGIN-321, Maven core uses META-INF/maven/
> plugin.xml) but this is one of the rare case where a dependency is simply *not
> used* at runtime...
>
>
> Ok, I now understand the real impact on plugins: no impact in general, only
> maven-plugin-plugin is impacted because it uses annotations to extract
> information from bytecode to generate META-INF/maven/plugin.xml
>
> I'll improve MPLUGIN-296 description, which is currently at least not clear at
> all (which I knew but could not get any useful answer)
>
> But at least, now, I think I better imagine the impact of this bugfix of a bug
> that nobody noticed: it just breaks maven-plugin-plugin, which is an edge case
> of the bugfix edge case.
> I feel more confident now on this one
>
> let's move on evaluating other changes currently in 3.4.0-SNAPSHOT
Yes, I agree with this. The plugin doesn't need to inspect its own
annotations at runtime, so the dependency is "only needed at
compile-time, unused at run-time". The provided scope may be a bit of an
abuse for lack of a "compile-only" scope... but it works. The current
documentation on how to create plugins is correct, clarifying that
nothing is providing the dependency in MPLUGIN-321 is great.
>
> Regards,
>
> Herv
>
>>
>> Regards,
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
L'absence de virus dans ce courrier lectronique a t vrifie par le logiciel antivirus Avast.
https://www.avast.com/antivirus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Hervé BOUTEMY <he...@free.fr>.
Le vendredi 23 décembre 2016, 09:32:50 CET Christian Schulte a écrit :
> Am 12/23/16 um 08:16 schrieb Hervé BOUTEMY:
> > Le vendredi 23 décembre 2016, 03:59:17 CET Christian Schulte a écrit :
> >> Am 12/22/16 um 19:14 schrieb Robert Scholte:
> >>> -0.9 for the commandline option, there should be only one truth.
> >>
> >> +1
> >>
> >>> Dependency management is way too important, you should not have an
> >>> option
> >>> to choose. Better to agree that we are indeed fixing a bug or that we
> >>> should maintain the current behavior. And that'll take time. I will have
> >>> a
> >>> look at all the related issues which could be controlled by this flag
> >>> and
> >>> find a way to get feedback from more people.
> >>
> >> -1 for maintaining the current behavior. Issues will get reported over
> >> and over again.
> >
> > you keep saying that but don't give any other example than MPLUGIN-296 = a
> > failure caused by your purist fix in MRESOLVER-8
> > and you talked about findbugs-maven-plugin, but did not give any pointer
> >
> > once again, can you give examples of something that MRESOLVER-8 fixes,
> > apart from the logic of exact resolution?
>
> Why are you questioning making plugin resolution work the same way
> project resolution is performed? I don't get that.
please look at "if it ain't broke, don't fix it" proverb, or "never change a
running system"
for example at https://en.wiktionary.org/wiki/if_it_ain't_broke,_don't_fix_it
> The bugfix
> immediately uncovered a mistake in a POM of a plugin everyone agrees to
> be a real issue.
no, I don't agree that it is a real issue
> I just verified that selector had that bug right from
> the intial resolver contribution outside Apache so has always been
> there. Right now only the maven-plugin-plugin version 3.4 is affected.
> Version 3.3 and 3.5 are not affected.
I fear it's not only one plugin, but every plugin that applied the
scope=provided recipe that Maven Plugin Tools Annotations promotes
> The findbugs-maven-plugin issue
> I've been talking about is unrelated to the resolver and is also fixed
> in recent releases.
ok, I don't know why you talked about it if it's not related
[...]
> > I respect logic, since I can imagine that in addition to the case that
> > worked magically, there can be cases that fail magically = not something
> > I want forever.
> > You found a few cases working magically = in fact one recipe based on it,
> > that is still in our documentation [1] as "<!-- annotations are needed
> > only to build the plugin -->").
> > If we didn't find cases failing magically, pressure to change is not the
> > same.
> Things working magically are a recipe for desaster.
disaster didn't happen for years before your work on "fixing" something that
didn't break: remember to read about "if it ain't broke, don't fix it" proverb,
it has to be known and respected at least in some cases
> It's just
> unpredictable behaviour presented to be something done intentionally
> although things are just a matter of luck or bad luck.
that's why I try to know if you have reported cases (as you told) of something
really broken (= something with bad luck)
IIUC, you don't have any case of bad luck
> Especially when a
> lot of the POMs around are a result of trial and error. Maven should
> have produced an error but did not "magically". Chances are great
> someone starts applying his findings to each and every project without
> ever noticing things really are not working as intended. We should be
> super sure that this trial and error always leads to valid POMs.
>
> > And of course, this wrong explanation in our doc should be fixed and
> > explained: I'll work on that (because, remember, I already told I'm
> > supportive of improvements): I opened MPLUGIN-321 [2], please review and
> > improve explanations if necessary = this is the start of something that
> > will also appear in release notes for the version of Maven that will
> > contaning the updated plugin resolution algorithm (we'll see later if
> > it's Maven 3.4.0 or not)
>
> There is nothing wrong about that documentation. It's a special case
> with the maven-plugin-plugin. Only that plugin must not use "provided"
> for the annotations because that plugin is what needs them at runtime.
> It is the provider itself. Other plugins should in fact use "provided"
> because the annotations are provided by maven-plugin-plugin and not used
> by anything else.
ok, I start to understand: no, the plugin does not provide the annotations
dependency (as I wrote in MPLUGIN-321, Maven core uses META-INF/maven/
plugin.xml) but this is one of the rare case where a dependency is simply *not
used* at runtime...
Ok, I now understand the real impact on plugins: no impact in general, only
maven-plugin-plugin is impacted because it uses annotations to extract
information from bytecode to generate META-INF/maven/plugin.xml
I'll improve MPLUGIN-296 description, which is currently at least not clear at
all (which I knew but could not get any useful answer)
But at least, now, I think I better imagine the impact of this bugfix of a bug
that nobody noticed: it just breaks maven-plugin-plugin, which is an edge case
of the bugfix edge case.
I feel more confident now on this one
let's move on evaluating other changes currently in 3.4.0-SNAPSHOT
Regards,
Hervé
>
>
> Regards,
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Hervé BOUTEMY <he...@free.fr>.
seriously, you should make an effort to improve description of the failures
caused by the MRESOLVER-8 bugfix (which AFAIK only causes breaks: not so many,
but only breaks currently, so it's hard to call MRESOLVER-8 a real fix...)
Regards,
Hervé
Le samedi 24 décembre 2016, 15:58:20 CET Christian Schulte a écrit :
> maven-pmd-plugin >= 3.4 is affected.
>
> <https://issues.apache.org/jira/browse/MPMD-230>
> <http://pastebin.com/GiJ39AYk>
> <http://pastebin.com/CsyHJAnX>
> <http://pastebin.com/tk6YHzVs>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Christian Schulte <cs...@schulte.it>.
I setup a Jenkins job today running weekly testing that a release build
can be performed successfully with the current Maven master and that
core and plugin ITs do pass with the result of that build. It will send
mails to dev@ with a subject starting with [NOTIFICATION].
<https://builds.apache.org/view/Maven/job/maven-master-release-status>
Obviously it's not enough to just run the core ITs with such a build. At
least the plugin ITs need to be run as well. There may even be other
things we need to test as well. Still tweaking those jobs to run as
intended. It may send meaningless emails today until things are setup
correctly.
Am 12/23/16 um 08:16 schrieb Herv BOUTEMY:
> Le vendredi 23 dcembre 2016, 03:59:17 CET Christian Schulte a crit :
>> Am 12/22/16 um 19:14 schrieb Robert Scholte:
>>> -0.9 for the commandline option, there should be only one truth.
>>
>> +1
>>
>>> Dependency management is way too important, you should not have an option
>>> to choose. Better to agree that we are indeed fixing a bug or that we
>>> should maintain the current behavior. And that'll take time. I will have a
>>> look at all the related issues which could be controlled by this flag and
>>> find a way to get feedback from more people.
>>
>> -1 for maintaining the current behavior. Issues will get reported over
>> and over again.
> you keep saying that but don't give any other example than MPLUGIN-296 = a
> failure caused by your purist fix in MRESOLVER-8
> and you talked about findbugs-maven-plugin, but did not give any pointer
>
> once again, can you give examples of something that MRESOLVER-8 fixes, apart
> from the logic of exact resolution?
>
> I respect logic, since I can imagine that in addition to the case that worked
> magically, there can be cases that fail magically = not something I want
> forever.
> You found a few cases working magically = in fact one recipe based on it, that
> is still in our documentation [1] as "<!-- annotations are needed only to
> build the plugin -->").
> If we didn't find cases failing magically, pressure to change is not the same.
>
> And of course, this wrong explanation in our doc should be fixed and explained:
> I'll work on that (because, remember, I already told I'm supportive of
> improvements): I opened MPLUGIN-321 [2], please review and improve
> explanations if necessary = this is the start of something that will also
> appear in release notes for the version of Maven that will contaning the
> updated plugin resolution algorithm (we'll see later if it's Maven 3.4.0 or
> not)
>
> Regards,
>
> Herv
>
> [1] https://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html#POM_configuration
>
> [2] https://issues.apache.org/jira/browse/MPLUGIN-321
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Christian Schulte <cs...@schulte.it>.
maven-resources-plugin < 3.0.2 also is affected.
<http://pastebin.com/JqsBSBd9>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Christian Schulte <cs...@schulte.it>.
maven-pmd-plugin >= 3.4 is affected.
<https://issues.apache.org/jira/browse/MPMD-230>
<http://pastebin.com/GiJ39AYk>
<http://pastebin.com/CsyHJAnX>
<http://pastebin.com/tk6YHzVs>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Stephen Connolly <st...@gmail.com>.
No that is not quite what I am saying...
I'll respond in detail later
On Thu 12 Jan 2017 at 20:32, Christian Schulte <cs...@schulte.it> wrote:
> Am 12.01.2017 um 12:09 schrieb Robert Scholte:
>
> > On Thu, 12 Jan 2017 09:00:16 +0100, Hervé BOUTEMY <herve.boutemy@free.fr
> >
>
> > wrote:
>
> >
>
> >> Do we agree on the initial explanation about the plugin runtime
>
> >> resolution hack?
>
> >
>
> > The first thing Maven does is create a BuildPlan. This means that the
>
> > plugins being part of this run are initiated. This is also the reason why
>
> > a maven-plugin cannot be used within the same multimodule project.
>
> > Regarding the prerequisite value, it means that the code has been
> compiled
>
> > and unit tested with these dependencies(!) and should work with at least
>
> > this version. This is also the reason why we should be very,very careful
>
> > with removing methods or changing signatures!
>
> > The fact that a plugin requires 3.0.5 to be built doesn't mean it's
>
> > prerequisite is also 3.0.5. It should be part of the vote to run plugins
>
> > against the prerequisite version, i.e run as
>
> > "/path/to/apache-maven-3.3.9/bin/mvn clean verify -Prun-its
>
> > -Dinvoker.mavenHome=/path/to/apache-maven-3.0"
>
> >
>
> >> Do we agree on how to fix the hack?
>
> > I would like to avoid the word "hack", because in the end the current
>
> > behavior is the intended behavior (ensuring all runtime required
>
> > dependencies are there no matter what).
>
> > If I'm correct the idea is to try to make the plugin dependency
> resolution
>
> > work the same way as project dependency resolution (and I'm not going to
>
> > say which parts are wrong or right, that's another discussion)
>
> > MNG-5739 is a requirement to be able to make the resolutions equal.
>
> >
>
>
>
> I think Stephen's point was something different. The artifacts exported
>
> to plugins differ between various Maven versions. Stephen is suggesting
>
> to use the prerequisites to make Maven allways provide the same set of
>
> artifacts. So for a plugin with prerequisite 2.2.1 Maven should always
>
> export the same set of artifacts Maven 2.2.1 would have done, and for a
>
> plugin with prerequisite 3.0.0 Maven should always export the same set
>
> of artifacts Maven 3.0.0 would have done, and so on. IF the
>
> prerequisites are honoured by Maven core that way, different resolution
>
> strategies COULD be provided as well.
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
Sent from my phone
Re: Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Christian Schulte <cs...@schulte.it>.
Am 12.01.2017 um 12:09 schrieb Robert Scholte:
> On Thu, 12 Jan 2017 09:00:16 +0100, Herv BOUTEMY <he...@free.fr>
> wrote:
>
>> Do we agree on the initial explanation about the plugin runtime
>> resolution hack?
>
> The first thing Maven does is create a BuildPlan. This means that the
> plugins being part of this run are initiated. This is also the reason why
> a maven-plugin cannot be used within the same multimodule project.
> Regarding the prerequisite value, it means that the code has been compiled
> and unit tested with these dependencies(!) and should work with at least
> this version. This is also the reason why we should be very,very careful
> with removing methods or changing signatures!
> The fact that a plugin requires 3.0.5 to be built doesn't mean it's
> prerequisite is also 3.0.5. It should be part of the vote to run plugins
> against the prerequisite version, i.e run as
> "/path/to/apache-maven-3.3.9/bin/mvn clean verify -Prun-its
> -Dinvoker.mavenHome=/path/to/apache-maven-3.0"
>
>> Do we agree on how to fix the hack?
> I would like to avoid the word "hack", because in the end the current
> behavior is the intended behavior (ensuring all runtime required
> dependencies are there no matter what).
> If I'm correct the idea is to try to make the plugin dependency resolution
> work the same way as project dependency resolution (and I'm not going to
> say which parts are wrong or right, that's another discussion)
> MNG-5739 is a requirement to be able to make the resolutions equal.
>
I think Stephen's point was something different. The artifacts exported
to plugins differ between various Maven versions. Stephen is suggesting
to use the prerequisites to make Maven allways provide the same set of
artifacts. So for a plugin with prerequisite 2.2.1 Maven should always
export the same set of artifacts Maven 2.2.1 would have done, and for a
plugin with prerequisite 3.0.0 Maven should always export the same set
of artifacts Maven 3.0.0 would have done, and so on. IF the
prerequisites are honoured by Maven core that way, different resolution
strategies COULD be provided as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Robert Scholte <rf...@apache.org>.
On Thu, 12 Jan 2017 09:00:16 +0100, Hervé BOUTEMY <he...@free.fr>
wrote:
> Do we agree on the initial explanation about the plugin runtime
> resolution hack?
The first thing Maven does is create a BuildPlan. This means that the
plugins being part of this run are initiated. This is also the reason why
a maven-plugin cannot be used within the same multimodule project.
Regarding the prerequisite value, it means that the code has been compiled
and unit tested with these dependencies(!) and should work with at least
this version. This is also the reason why we should be very,very careful
with removing methods or changing signatures!
The fact that a plugin requires 3.0.5 to be built doesn't mean it's
prerequisite is also 3.0.5. It should be part of the vote to run plugins
against the prerequisite version, i.e run as
"/path/to/apache-maven-3.3.9/bin/mvn clean verify -Prun-its
-Dinvoker.mavenHome=/path/to/apache-maven-3.0"
> Do we agree on how to fix the hack?
I would like to avoid the word "hack", because in the end the current
behavior is the intended behavior (ensuring all runtime required
dependencies are there no matter what).
If I'm correct the idea is to try to make the plugin dependency resolution
work the same way as project dependency resolution (and I'm not going to
say which parts are wrong or right, that's another discussion)
MNG-5739 is a requirement to be able to make the resolutions equal.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Hervé BOUTEMY <he...@free.fr>.
I'm not ok with the "maven baseline" approach: IMHO, there is no such thing
during plugin dependencies resolution.
AFAIK, plugin dependencies resolution happens "normally" (or more precisely
with the current hack for test or provided scoped dependencies), then when
plugin "classpath" creation happens (more precisely ClassWorlds classloader
instanciation), there is:
1. some filtering
2. some inheritence from parent classloader
Then whatever you put in your plugin pom, exact classes available at runtime
are not what was requested by dependency resolution.
For more details on code, see exportedPackages and exportedArtifacts of core
extensions [1] and classloader hierarchy explanations and code pointers [2]
Notice that having at runtime a different version from what you defined in your
pom for build is quite classical: it happens constantly when dependency
conflicts are resolved, then plugins are like anything else.
Then the explanations about prerequisite "feeling wrong" are IMHO wrong :)
Like anything else, you ask for one version when compiling, and when running
in an integrated system, where full system resolution has been done and
conflicts have been resolved at integrated system level, one component doesn't
get the version it requested: as usual and full normal.
That's why compatibility over time matters...
Now there is currently a hack for plugins dependencies resolution that ignores
test and provided scoped direct dependencies, because in such case, our
current conflict resolution algorithm keeps test scope even if a transitive
dependency requires the artifact at runtime: ok, this hack permitted plugins
to work when normal libraries could not benefit of same feature.
Then the fix is not to blindly remove the hack but improve the initial issue:
test scoped dependencies should not override runtime scope transitive ones.
There is MNG-5739 JIRA issue about that [3].
And waiting for MNG-5739 implementation, I'm fine with the hack that worked so
well for 10 years. And nobody yet showed me a case where the hack caused an
issue: remocing the hack is pure logic, that I fully understand and respect,
but I prefer keeping this hack to adding a hack to a lot of plugins that
consists in changing test scoped dependency to compile scope just to work
around transitive dependency resolution issue.
Do we agree on the initial explanation about the plugin runtime resolution
hack?
Do we agree on how to fix the hack?
Regards,
Hervé
[1] http://maven.apache.org/ref/3-LATEST/maven-core/core-extensions.html
[2] http://maven.apache.org/ref/3-LATEST/maven-core/
[3] https://issues.apache.org/jira/browse/MNG-5739
Le vendredi 23 décembre 2016, 09:33:50 CET Stephen Connolly a écrit :
> Ok, so I think we need to change how we describe things a bit.
>
> Project resolution starts from a clean baseline. If you have a project with
> zero dependencies (other than those implicit in being a java project say...
> which means the JRE classpath is an implicit dependency) then you just have
> the implicit dependencies present.
>
> Plugin resolution starts from a maven baseline. There are some dependencies
> which are forced on you by the nature of the maven version you are running.
>
> If we are dealing with a dependency that is not in the maven baseline, say
> com.example.foo:bar then project resolution and plugin resolution should
> behave exactly the same way for a plugin as for a project.
>
> If we are dealing with a dependency that is part of Maven core *but* not
> exposed to plugins, this could be org.slf4j:slf4j-api (but I would need to
> check the plugin classloader setup rules... in any case there are some
> dependencies in Maven that we do not expose to plugins) then project and
> plugin resolution should behave exactly the same way for a plugin as for a
> project.
>
> If we are dealing with a dependency that is exported by Maven core to
> plugins: plugin-api, plexus-utils, etc... now we are in a different
> situation. The plugin is no longer free to get the version it requested.
> The plugin *will* be getting the version exported by Maven Core
> irrespective of what it requested. This is what the
> xpath:/project/prerequisites/maven is for (though we probably have not been
> good at expressing its utility.
>
> So
> https://svn.apache.org/viewvc/maven/plugin-tools/trunk/maven-plugin-plugin/p
> om.xml?view=markup#l41 being 2.2.1 is probably "wrong" _if_ there is a
> conflict between the exported dependencies by Maven core and the
> dependencies in the plugin pom.
>
> The reason I say "wrong" is that logically it may not be *wrong* only feel
> wrong.
>
> What we should be doing is maintaining the Maven a list of _previous_
> versions and the rules to apply to those... so for example,
>
> * when a plugin says xpath:/project/prerequisites/maven=2.2.1 then we know
> that it is expecting the 2.2.1 APIs on the classpath, we can then remove
> the corresponding implicits from the tree for that plugin despite the fact
> that some of the dependencies have been relocated / restructured.
>
> * when a plugin says xpath:/project/prerequisites/maven=3.3.9 then we know
> that it is expecting the APIs for 3.3.9 on the classpath and we can now
> assume that, for example, some of the 2.x Maven APIs that were removed with
> 3.0 are no longer implicit on that plugins classpath... except that we
> cannot do that right now as that would be a breaking change because we were
> not purists in enforcing this...
>
> So let's say we do the purist clean-up of dependencies... that would mean
> that going forward we declare that any plugin with
> xpath:/project/prerequisites/maven>=3.4.0 would need to have the correct
> dependencies of maven core for a "modern" style... those dependencies will
> be overridden by Maven core and you will get what Maven core says you will
> get.
>
> HTH
>
> On 23 December 2016 at 08:32, Christian Schulte <cs...@schulte.it> wrote:
> > Am 12/23/16 um 08:16 schrieb Hervé BOUTEMY:
> > > Le vendredi 23 décembre 2016, 03:59:17 CET Christian Schulte a écrit :
> > >> Am 12/22/16 um 19:14 schrieb Robert Scholte:
> > >>> -0.9 for the commandline option, there should be only one truth.
> > >>
> > >> +1
> > >>
> > >>> Dependency management is way too important, you should not have an
> >
> > option
> >
> > >>> to choose. Better to agree that we are indeed fixing a bug or that we
> > >>> should maintain the current behavior. And that'll take time. I will
> >
> > have a
> >
> > >>> look at all the related issues which could be controlled by this flag
> >
> > and
> >
> > >>> find a way to get feedback from more people.
> > >>
> > >> -1 for maintaining the current behavior. Issues will get reported over
> > >> and over again.
> > >
> > > you keep saying that but don't give any other example than MPLUGIN-296 =
> >
> > a
> >
> > > failure caused by your purist fix in MRESOLVER-8
> > > and you talked about findbugs-maven-plugin, but did not give any pointer
> > >
> > > once again, can you give examples of something that MRESOLVER-8 fixes,
> >
> > apart
> >
> > > from the logic of exact resolution?
> >
> > Why are you questioning making plugin resolution work the same way
> > project resolution is performed? I don't get that. The bugfix
> > immediately uncovered a mistake in a POM of a plugin everyone agrees to
> > be a real issue. I just verified that selector had that bug right from
> > the intial resolver contribution outside Apache so has always been
> > there. Right now only the maven-plugin-plugin version 3.4 is affected.
> > Version 3.3 and 3.5 are not affected. The findbugs-maven-plugin issue
> > I've been talking about is unrelated to the resolver and is also fixed
> > in recent releases.
> >
> > <https://github.com/gleclaire/findbugs-maven-plugin/commit/
> > 7954b94eff5c6b0524e7fe26d8f114b3c5450b86>
> >
> > This is nothing different to the resolver bugfix. The changes in core
> > were made to make collections returned by getters in maven core
> > consistently immutable. A lot of
> >
> > return this.collection == null
> >
> > ? Collections.emptyList()
> >
> > : this.collection;
> >
> > were updated to look like
> >
> > return this.collection == null
> >
> > ? Collections.emptyList()
> >
> > : Collections.unmodifiableList(this.collection);
> >
> > The emptyList is immutable and will lead to runtime exceptions when
> > modified so the collection returned always needs to be immutable and not
> > only when null just to prevent someone from beeing able to modify a
> > non-empty list returned and then run into runtime exceptions when that
> > list "magically" is null.
> >
> > > I respect logic, since I can imagine that in addition to the case that
> >
> > worked
> >
> > > magically, there can be cases that fail magically = not something I want
> > > forever.
> > > You found a few cases working magically = in fact one recipe based on
> >
> > it, that
> >
> > > is still in our documentation [1] as "<!-- annotations are needed only
> > > to
> > > build the plugin -->").
> > > If we didn't find cases failing magically, pressure to change is not the
> >
> > same.
> >
> > Things working magically are a recipe for desaster. It's just
> > unpredictable behaviour presented to be something done intentionally
> > although things are just a matter of luck or bad luck. Especially when a
> > lot of the POMs around are a result of trial and error. Maven should
> > have produced an error but did not "magically". Chances are great
> > someone starts applying his findings to each and every project without
> > ever noticing things really are not working as intended. We should be
> > super sure that this trial and error always leads to valid POMs.
> >
> > > And of course, this wrong explanation in our doc should be fixed and
> >
> > explained:
> > > I'll work on that (because, remember, I already told I'm supportive of
> > > improvements): I opened MPLUGIN-321 [2], please review and improve
> > > explanations if necessary = this is the start of something that will
> > > also
> > > appear in release notes for the version of Maven that will contaning the
> > > updated plugin resolution algorithm (we'll see later if it's Maven 3.4.0
> >
> > or
> >
> > > not)
> >
> > There is nothing wrong about that documentation. It's a special case
> > with the maven-plugin-plugin. Only that plugin must not use "provided"
> > for the annotations because that plugin is what needs them at runtime.
> > It is the provider itself. Other plugins should in fact use "provided"
> > because the annotations are provided by maven-plugin-plugin and not used
> > by anything else.
> >
> >
> > Regards,
> > --
> > Christian
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/23/16 um 10:33 schrieb Stephen Connolly:
> Ok, so I think we need to change how we describe things a bit.
>
> Project resolution starts from a clean baseline. If you have a project with
> zero dependencies (other than those implicit in being a java project say...
> which means the JRE classpath is an implicit dependency) then you just have
> the implicit dependencies present.
>
> Plugin resolution starts from a maven baseline. There are some dependencies
> which are forced on you by the nature of the maven version you are running.
>
> If we are dealing with a dependency that is not in the maven baseline, say
> com.example.foo:bar then project resolution and plugin resolution should
> behave exactly the same way for a plugin as for a project.
>
> If we are dealing with a dependency that is part of Maven core *but* not
> exposed to plugins, this could be org.slf4j:slf4j-api (but I would need to
> check the plugin classloader setup rules... in any case there are some
> dependencies in Maven that we do not expose to plugins) then project and
> plugin resolution should behave exactly the same way for a plugin as for a
> project.
>
> If we are dealing with a dependency that is exported by Maven core to
> plugins: plugin-api, plexus-utils, etc... now we are in a different
> situation. The plugin is no longer free to get the version it requested.
> The plugin *will* be getting the version exported by Maven Core
> irrespective of what it requested. This is what the
> xpath:/project/prerequisites/maven is for (though we probably have not been
> good at expressing its utility.
>
> So
> https://svn.apache.org/viewvc/maven/plugin-tools/trunk/maven-plugin-plugin/pom.xml?view=markup#l41
> being 2.2.1 is probably "wrong" _if_ there is a conflict between the
> exported dependencies by Maven core and the dependencies in the plugin pom.
>
> The reason I say "wrong" is that logically it may not be *wrong* only feel
> wrong.
>
> What we should be doing is maintaining the Maven a list of _previous_
> versions and the rules to apply to those... so for example,
>
> * when a plugin says xpath:/project/prerequisites/maven=2.2.1 then we know
> that it is expecting the 2.2.1 APIs on the classpath, we can then remove
> the corresponding implicits from the tree for that plugin despite the fact
> that some of the dependencies have been relocated / restructured.
>
> * when a plugin says xpath:/project/prerequisites/maven=3.3.9 then we know
> that it is expecting the APIs for 3.3.9 on the classpath and we can now
> assume that, for example, some of the 2.x Maven APIs that were removed with
> 3.0 are no longer implicit on that plugins classpath... except that we
> cannot do that right now as that would be a breaking change because we were
> not purists in enforcing this...
>
> So let's say we do the purist clean-up of dependencies... that would mean
> that going forward we declare that any plugin with
> xpath:/project/prerequisites/maven>=3.4.0 would need to have the correct
> dependencies of maven core for a "modern" style... those dependencies will
> be overridden by Maven core and you will get what Maven core says you will
> get.
>
> HTH
Still catching up with unread emails.
+1 to all of that.
As far as I can tell, we ourselves only use three different values for
the prerequisites. 2.0 (implicitly because default), 2.2.1 and 3.0.0.
Not much to research. I'll take a look at 2.0.11, 2.2.1 and 3.0.5.
Depends on what the next prerequisite we are going to use. As it seems,
that would be 3.6.0.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Stephen Connolly <st...@gmail.com>.
Ok, so I think we need to change how we describe things a bit.
Project resolution starts from a clean baseline. If you have a project with
zero dependencies (other than those implicit in being a java project say...
which means the JRE classpath is an implicit dependency) then you just have
the implicit dependencies present.
Plugin resolution starts from a maven baseline. There are some dependencies
which are forced on you by the nature of the maven version you are running.
If we are dealing with a dependency that is not in the maven baseline, say
com.example.foo:bar then project resolution and plugin resolution should
behave exactly the same way for a plugin as for a project.
If we are dealing with a dependency that is part of Maven core *but* not
exposed to plugins, this could be org.slf4j:slf4j-api (but I would need to
check the plugin classloader setup rules... in any case there are some
dependencies in Maven that we do not expose to plugins) then project and
plugin resolution should behave exactly the same way for a plugin as for a
project.
If we are dealing with a dependency that is exported by Maven core to
plugins: plugin-api, plexus-utils, etc... now we are in a different
situation. The plugin is no longer free to get the version it requested.
The plugin *will* be getting the version exported by Maven Core
irrespective of what it requested. This is what the
xpath:/project/prerequisites/maven is for (though we probably have not been
good at expressing its utility.
So
https://svn.apache.org/viewvc/maven/plugin-tools/trunk/maven-plugin-plugin/pom.xml?view=markup#l41
being 2.2.1 is probably "wrong" _if_ there is a conflict between the
exported dependencies by Maven core and the dependencies in the plugin pom.
The reason I say "wrong" is that logically it may not be *wrong* only feel
wrong.
What we should be doing is maintaining the Maven a list of _previous_
versions and the rules to apply to those... so for example,
* when a plugin says xpath:/project/prerequisites/maven=2.2.1 then we know
that it is expecting the 2.2.1 APIs on the classpath, we can then remove
the corresponding implicits from the tree for that plugin despite the fact
that some of the dependencies have been relocated / restructured.
* when a plugin says xpath:/project/prerequisites/maven=3.3.9 then we know
that it is expecting the APIs for 3.3.9 on the classpath and we can now
assume that, for example, some of the 2.x Maven APIs that were removed with
3.0 are no longer implicit on that plugins classpath... except that we
cannot do that right now as that would be a breaking change because we were
not purists in enforcing this...
So let's say we do the purist clean-up of dependencies... that would mean
that going forward we declare that any plugin with
xpath:/project/prerequisites/maven>=3.4.0 would need to have the correct
dependencies of maven core for a "modern" style... those dependencies will
be overridden by Maven core and you will get what Maven core says you will
get.
HTH
On 23 December 2016 at 08:32, Christian Schulte <cs...@schulte.it> wrote:
> Am 12/23/16 um 08:16 schrieb Hervé BOUTEMY:
> > Le vendredi 23 décembre 2016, 03:59:17 CET Christian Schulte a écrit :
> >> Am 12/22/16 um 19:14 schrieb Robert Scholte:
> >>> -0.9 for the commandline option, there should be only one truth.
> >>
> >> +1
> >>
> >>> Dependency management is way too important, you should not have an
> option
> >>> to choose. Better to agree that we are indeed fixing a bug or that we
> >>> should maintain the current behavior. And that'll take time. I will
> have a
> >>> look at all the related issues which could be controlled by this flag
> and
> >>> find a way to get feedback from more people.
> >>
> >> -1 for maintaining the current behavior. Issues will get reported over
> >> and over again.
> > you keep saying that but don't give any other example than MPLUGIN-296 =
> a
> > failure caused by your purist fix in MRESOLVER-8
> > and you talked about findbugs-maven-plugin, but did not give any pointer
> >
> > once again, can you give examples of something that MRESOLVER-8 fixes,
> apart
> > from the logic of exact resolution?
>
> Why are you questioning making plugin resolution work the same way
> project resolution is performed? I don't get that. The bugfix
> immediately uncovered a mistake in a POM of a plugin everyone agrees to
> be a real issue. I just verified that selector had that bug right from
> the intial resolver contribution outside Apache so has always been
> there. Right now only the maven-plugin-plugin version 3.4 is affected.
> Version 3.3 and 3.5 are not affected. The findbugs-maven-plugin issue
> I've been talking about is unrelated to the resolver and is also fixed
> in recent releases.
>
> <https://github.com/gleclaire/findbugs-maven-plugin/commit/
> 7954b94eff5c6b0524e7fe26d8f114b3c5450b86>
>
> This is nothing different to the resolver bugfix. The changes in core
> were made to make collections returned by getters in maven core
> consistently immutable. A lot of
>
> return this.collection == null
> ? Collections.emptyList()
> : this.collection;
>
> were updated to look like
>
> return this.collection == null
> ? Collections.emptyList()
> : Collections.unmodifiableList(this.collection);
>
> The emptyList is immutable and will lead to runtime exceptions when
> modified so the collection returned always needs to be immutable and not
> only when null just to prevent someone from beeing able to modify a
> non-empty list returned and then run into runtime exceptions when that
> list "magically" is null.
>
> >
> > I respect logic, since I can imagine that in addition to the case that
> worked
> > magically, there can be cases that fail magically = not something I want
> > forever.
> > You found a few cases working magically = in fact one recipe based on
> it, that
> > is still in our documentation [1] as "<!-- annotations are needed only to
> > build the plugin -->").
> > If we didn't find cases failing magically, pressure to change is not the
> same.
>
> Things working magically are a recipe for desaster. It's just
> unpredictable behaviour presented to be something done intentionally
> although things are just a matter of luck or bad luck. Especially when a
> lot of the POMs around are a result of trial and error. Maven should
> have produced an error but did not "magically". Chances are great
> someone starts applying his findings to each and every project without
> ever noticing things really are not working as intended. We should be
> super sure that this trial and error always leads to valid POMs.
>
> >
> > And of course, this wrong explanation in our doc should be fixed and
> explained:
> > I'll work on that (because, remember, I already told I'm supportive of
> > improvements): I opened MPLUGIN-321 [2], please review and improve
> > explanations if necessary = this is the start of something that will also
> > appear in release notes for the version of Maven that will contaning the
> > updated plugin resolution algorithm (we'll see later if it's Maven 3.4.0
> or
> > not)
> >
>
> There is nothing wrong about that documentation. It's a special case
> with the maven-plugin-plugin. Only that plugin must not use "provided"
> for the annotations because that plugin is what needs them at runtime.
> It is the provider itself. Other plugins should in fact use "provided"
> because the annotations are provided by maven-plugin-plugin and not used
> by anything else.
>
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/23/16 um 08:16 schrieb Herv BOUTEMY:
> Le vendredi 23 dcembre 2016, 03:59:17 CET Christian Schulte a crit :
>> Am 12/22/16 um 19:14 schrieb Robert Scholte:
>>> -0.9 for the commandline option, there should be only one truth.
>>
>> +1
>>
>>> Dependency management is way too important, you should not have an option
>>> to choose. Better to agree that we are indeed fixing a bug or that we
>>> should maintain the current behavior. And that'll take time. I will have a
>>> look at all the related issues which could be controlled by this flag and
>>> find a way to get feedback from more people.
>>
>> -1 for maintaining the current behavior. Issues will get reported over
>> and over again.
> you keep saying that but don't give any other example than MPLUGIN-296 = a
> failure caused by your purist fix in MRESOLVER-8
> and you talked about findbugs-maven-plugin, but did not give any pointer
>
> once again, can you give examples of something that MRESOLVER-8 fixes, apart
> from the logic of exact resolution?
Why are you questioning making plugin resolution work the same way
project resolution is performed? I don't get that. The bugfix
immediately uncovered a mistake in a POM of a plugin everyone agrees to
be a real issue. I just verified that selector had that bug right from
the intial resolver contribution outside Apache so has always been
there. Right now only the maven-plugin-plugin version 3.4 is affected.
Version 3.3 and 3.5 are not affected. The findbugs-maven-plugin issue
I've been talking about is unrelated to the resolver and is also fixed
in recent releases.
<https://github.com/gleclaire/findbugs-maven-plugin/commit/7954b94eff5c6b0524e7fe26d8f114b3c5450b86>
This is nothing different to the resolver bugfix. The changes in core
were made to make collections returned by getters in maven core
consistently immutable. A lot of
return this.collection == null
? Collections.emptyList()
: this.collection;
were updated to look like
return this.collection == null
? Collections.emptyList()
: Collections.unmodifiableList(this.collection);
The emptyList is immutable and will lead to runtime exceptions when
modified so the collection returned always needs to be immutable and not
only when null just to prevent someone from beeing able to modify a
non-empty list returned and then run into runtime exceptions when that
list "magically" is null.
>
> I respect logic, since I can imagine that in addition to the case that worked
> magically, there can be cases that fail magically = not something I want
> forever.
> You found a few cases working magically = in fact one recipe based on it, that
> is still in our documentation [1] as "<!-- annotations are needed only to
> build the plugin -->").
> If we didn't find cases failing magically, pressure to change is not the same.
Things working magically are a recipe for desaster. It's just
unpredictable behaviour presented to be something done intentionally
although things are just a matter of luck or bad luck. Especially when a
lot of the POMs around are a result of trial and error. Maven should
have produced an error but did not "magically". Chances are great
someone starts applying his findings to each and every project without
ever noticing things really are not working as intended. We should be
super sure that this trial and error always leads to valid POMs.
>
> And of course, this wrong explanation in our doc should be fixed and explained:
> I'll work on that (because, remember, I already told I'm supportive of
> improvements): I opened MPLUGIN-321 [2], please review and improve
> explanations if necessary = this is the start of something that will also
> appear in release notes for the version of Maven that will contaning the
> updated plugin resolution algorithm (we'll see later if it's Maven 3.4.0 or
> not)
>
There is nothing wrong about that documentation. It's a special case
with the maven-plugin-plugin. Only that plugin must not use "provided"
for the annotations because that plugin is what needs them at runtime.
It is the provider itself. Other plugins should in fact use "provided"
because the annotations are provided by maven-plugin-plugin and not used
by anything else.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Hervé BOUTEMY <he...@free.fr>.
Le vendredi 23 décembre 2016, 03:59:17 CET Christian Schulte a écrit :
> Am 12/22/16 um 19:14 schrieb Robert Scholte:
> > -0.9 for the commandline option, there should be only one truth.
>
> +1
>
> > Dependency management is way too important, you should not have an option
> > to choose. Better to agree that we are indeed fixing a bug or that we
> > should maintain the current behavior. And that'll take time. I will have a
> > look at all the related issues which could be controlled by this flag and
> > find a way to get feedback from more people.
>
> -1 for maintaining the current behavior. Issues will get reported over
> and over again.
you keep saying that but don't give any other example than MPLUGIN-296 = a
failure caused by your purist fix in MRESOLVER-8
and you talked about findbugs-maven-plugin, but did not give any pointer
once again, can you give examples of something that MRESOLVER-8 fixes, apart
from the logic of exact resolution?
I respect logic, since I can imagine that in addition to the case that worked
magically, there can be cases that fail magically = not something I want
forever.
You found a few cases working magically = in fact one recipe based on it, that
is still in our documentation [1] as "<!-- annotations are needed only to
build the plugin -->").
If we didn't find cases failing magically, pressure to change is not the same.
And of course, this wrong explanation in our doc should be fixed and explained:
I'll work on that (because, remember, I already told I'm supportive of
improvements): I opened MPLUGIN-321 [2], please review and improve
explanations if necessary = this is the start of something that will also
appear in release notes for the version of Maven that will contaning the
updated plugin resolution algorithm (we'll see later if it's Maven 3.4.0 or
not)
Regards,
Hervé
[1] https://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html#POM_configuration
[2] https://issues.apache.org/jira/browse/MPLUGIN-321
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/22/16 um 19:14 schrieb Robert Scholte:
> -0.9 for the commandline option, there should be only one truth.
+1
> Dependency management is way too important, you should not have an option
> to choose. Better to agree that we are indeed fixing a bug or that we
> should maintain the current behavior. And that'll take time. I will have a
> look at all the related issues which could be controlled by this flag and
> find a way to get feedback from more people.
-1 for maintaining the current behavior. Issues will get reported over
and over again. It's just not correct. Updating the documentation would
mean we would add phrases like "this is how things should behave but
they don't due to bugs we cannot fix". Personally, something like this
would make me look for alternatives immediately.
>
> I have a different proposal: suppose we could "autocorrect" the pom.xml
> during distribution. I'm especially looking into MNG-5971. What happens if
> the include-scope is used, but is being replaced with all the actual
> included dependencies? Most important: do we get the expected behavior.
> The advantage of this is that you can use a new scope in your pom.xml, but
> in the repositories you will only see well-known scopes.
> We should also have a look at the flatten-maven-plugin. Some parts are
> quite interesting
Would not work when ranges are used in the dependency management. This
is <https://issues.apache.org/jira/browse/MNG-4463>. That has been fixed
for 3.4. There currently is no Maven release supporting that. The
imported dependencies still could use ranges. Simply provide that
include scope. The import scope got introduced in a patch release 2.0.6.
Adding that include scope in a feature release should be fine. Older
Maven versions will just handle that like runtime scope and will just
"ignore" those dependencies that way due to the POM type.
> This would be the first time where the projects pom wouldn't have to be
> the same as the installed or deployed pom. I would like to work on that,
> but for 3.5.x
There are some issues in JIRA containing patches for Maven 2.0.x where
something like this has been tested. There were multiple issues with
this like how to do interpolation. Not that easy. If I remember
correctly, there were issues making this impossible back then.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Robert Scholte <rf...@apache.org>.
-0.9 for the commandline option, there should be only one truth.
Dependency management is way too important, you should not have an option
to choose. Better to agree that we are indeed fixing a bug or that we
should maintain the current behavior. And that'll take time. I will have a
look at all the related issues which could be controlled by this flag and
find a way to get feedback from more people.
I have a different proposal: suppose we could "autocorrect" the pom.xml
during distribution. I'm especially looking into MNG-5971. What happens if
the include-scope is used, but is being replaced with all the actual
included dependencies? Most important: do we get the expected behavior.
The advantage of this is that you can use a new scope in your pom.xml, but
in the repositories you will only see well-known scopes.
We should also have a look at the flatten-maven-plugin. Some parts are
quite interesting
This would be the first time where the projects pom wouldn't have to be
the same as the installed or deployed pom. I would like to work on that,
but for 3.5.x
Robert
On Wed, 21 Dec 2016 17:53:04 +0100, Christian Schulte <cs...@schulte.it>
wrote:
> Am 12/21/16 um 13:46 schrieb Christian Schulte:
>> ago. The next commits from me would be for the Maven site and for the
>> release notes. Except that command line option. Ok. It really depends on
>
> That command line option got added with this commit:
> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=7e70c59e43f112c12282de49d937e870c9545fc9>
>
> It is lacking ITs to test the command line option really makes
> everything behave as before. Will add some in the next days.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/21/16 um 13:46 schrieb Christian Schulte:
> ago. The next commits from me would be for the Maven site and for the
> release notes. Except that command line option. Ok. It really depends on
That command line option got added with this commit:
<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=7e70c59e43f112c12282de49d937e870c9545fc9>
It is lacking ITs to test the command line option really makes
everything behave as before. Will add some in the next days.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Roadmap to the next Maven release (Re: Improving Jenkins)
Posted by Christian Schulte <cs...@schulte.it>.
Am 21.12.2016 um 08:04 schrieb Herv BOUTEMY:
> remember: we'll have to explain users why we did a breaking change
> I don't think such an explanation will be possible for users: for long-dev
> like me, it's hardly a valid explanation
>
> Can you explain in plain english some cases, please?
>
> And remember we'll require to prepare a list of known plugins
>
> When fixing the code means breaking user builds at large scale (which I fear is
> the case here), there is change management to prepare: the team can help, but
> you need to help the team first
It's mainly a matter of updating the documentation and providing
meaningful examples in the release notes and so on. For this we first
need to decide some kind of roadmap to what will be the next Maven
release. It has been requested to add some kind of command line option
to be able to opt-out of the dependency management fixes
(legacy-dependency-management, for example). That would be something I
would still need to do. It mainly depends on what is decided to be
released. There are no issues I am working on at the moment. Everything
I started to work an last year in december is finished as of a few hours
ago. The next commits from me would be for the Maven site and for the
release notes. Except that command line option. Ok. It really depends on
what will pass the next release vote. Personally, the current resolver
master could be released as 1.2.0 together with the current Maven master
as 3.4.0. There are these two bugfixes (MRESOLVER-8 -> fixes plugin
resolution, MRESOLVER-9 -> fixes dependency management) in the resolver
having that noticable impact on the resolution. That's a all-or-nothing
decision. If current resolver master is release as 1.2.0 and the next
Maven release will use that resolver version, all of current Maven
master should go into the next Maven release as well. If the next
resolver release does not contain those bugfixes, all of those
resolution and dependency management impacting changes in Maven should
not be released with that unfixed resolver. Do it all in one release or
don't do it. Just needs to be decided. That's not my decision. Cherry
picking my changes would be easy for me to do. The first line of the
commit message is what makes this easy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Hervé BOUTEMY <he...@free.fr>.
remember: we'll have to explain users why we did a breaking change
I don't think such an explanation will be possible for users: for long-dev
like me, it's hardly a valid explanation
Can you explain in plain english some cases, please?
And remember we'll require to prepare a list of known plugins
When fixing the code means breaking user builds at large scale (which I fear is
the case here), there is change management to prepare: the team can help, but
you need to help the team first
Regards,
Hervé
Le mercredi 21 décembre 2016, 02:45:05 CET Christian Schulte a écrit :
> Am 12/20/16 um 08:06 schrieb Hervé BOUTEMY:
> > I must confess I never investigated why this "provided" recipe worked: it
> > just looked nice :)
> >
> > but you didn't answer the important part of the question:
> > From a purist point of view, I understand
> > From a user point of view, do you have any case where the new behaviour
> > fixes a non-working configuration (instead of breaking a build that was
> > working previously)?
>
> The issues in JIRA currently fixed on master do have example projects
> attached. Those are what started this. Some of them became ITs.
>
> ~/Sources/apache.org/maven-integration-testing/core-it-suite
> $ grep -ri "\[3\.4" *
> src/test/java/org/apache/maven/it/MavenITmng1701DuplicatePlugin34Test.java:
> super( "[3.4,)" );
> src/test/java/org/apache/maven/it/MavenITmng3843PomInheritanceTest.java:
> if ( matchesVersionRange( "[3.4,)" ) )
> src/test/java/org/apache/maven/it/MavenITmng5889CoreExtensionsTest.java:
> super( "[3.4.0,)" );
> src/test/java/org/apache/maven/it/MavenITmng3719PomExecutionOrdering34Test.j
> ava: super( "[3.4,)" );
> src/test/java/org/apache/maven/it/MavenITmng4005UniqueDependencyKey34Test.ja
> va: super( "[3.4,)" );
> src/test/java/org/apache/maven/it/MavenITmng4463DependencyManagementImportVe
> rsionRanges.java: super( "[3.4,)" );
> src/test/java/org/apache/maven/it/MavenITmng5227DependencyOptionalFlagManage
> mentTest.java: super( "[3.4,)" );
> src/test/java/org/apache/maven/it/MavenITmng5359CleanPluginExecutionDeclarat
> ionInPluginMgmtTest.java: super( "[2.0.11,3.0-alpha-1),[3.4,)" );
> src/test/java/org/apache/maven/it/MavenITmng5527DependencyManagementImportRe
> locationsTest.java: super( "[3.4,)" );
> src/test/java/org/apache/maven/it/MavenITmng5600DependencyManagementImportEx
> clusionsTest.java: super( "[3.4,)" );
> src/test/java/org/apache/maven/it/MavenITmng5971HierarchicalImportScopeTest.
> java: super( "[3.4,)" );
> src/test/java/org/apache/maven/it/MavenITmng6084Jsr250PluginTest.java:
> super( "[3.4.0-SNAPSHOT,)" );
> src/test/java/org/apache/maven/it/MavenITmng6127PluginExecutionConfiguration
> InterferenceTest.java: super( "[3.4.0,)" );
> src/test/java/org/apache/maven/it/MavenITmng4720DependencyManagementExclusio
> nMerge34Test.java: super( "[3.4,)" );
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/20/16 um 08:06 schrieb Herv BOUTEMY:
> I must confess I never investigated why this "provided" recipe worked: it just
> looked nice :)
>
> but you didn't answer the important part of the question:
> From a purist point of view, I understand
> From a user point of view, do you have any case where the new behaviour fixes a
> non-working configuration (instead of breaking a build that was working
> previously)?
The issues in JIRA currently fixed on master do have example projects
attached. Those are what started this. Some of them became ITs.
~/Sources/apache.org/maven-integration-testing/core-it-suite
$ grep -ri "\[3\.4" *
src/test/java/org/apache/maven/it/MavenITmng1701DuplicatePlugin34Test.java:
super( "[3.4,)" );
src/test/java/org/apache/maven/it/MavenITmng3843PomInheritanceTest.java:
if ( matchesVersionRange( "[3.4,)" ) )
src/test/java/org/apache/maven/it/MavenITmng5889CoreExtensionsTest.java:
super( "[3.4.0,)" );
src/test/java/org/apache/maven/it/MavenITmng3719PomExecutionOrdering34Test.java:
super( "[3.4,)" );
src/test/java/org/apache/maven/it/MavenITmng4005UniqueDependencyKey34Test.java:
super( "[3.4,)" );
src/test/java/org/apache/maven/it/MavenITmng4463DependencyManagementImportVersionRanges.java:
super( "[3.4,)" );
src/test/java/org/apache/maven/it/MavenITmng5227DependencyOptionalFlagManagementTest.java:
super( "[3.4,)" );
src/test/java/org/apache/maven/it/MavenITmng5359CleanPluginExecutionDeclarationInPluginMgmtTest.java:
super( "[2.0.11,3.0-alpha-1),[3.4,)" );
src/test/java/org/apache/maven/it/MavenITmng5527DependencyManagementImportRelocationsTest.java:
super( "[3.4,)" );
src/test/java/org/apache/maven/it/MavenITmng5600DependencyManagementImportExclusionsTest.java:
super( "[3.4,)" );
src/test/java/org/apache/maven/it/MavenITmng5971HierarchicalImportScopeTest.java:
super( "[3.4,)" );
src/test/java/org/apache/maven/it/MavenITmng6084Jsr250PluginTest.java:
super( "[3.4.0-SNAPSHOT,)" );
src/test/java/org/apache/maven/it/MavenITmng6127PluginExecutionConfigurationInterferenceTest.java:
super( "[3.4.0,)" );
src/test/java/org/apache/maven/it/MavenITmng4720DependencyManagementExclusionMerge34Test.java:
super( "[3.4,)" );
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Hervé BOUTEMY <he...@free.fr>.
I must confess I never investigated why this "provided" recipe worked: it just
looked nice :)
but you didn't answer the important part of the question:
From a purist point of view, I understand
From a user point of view, do you have any case where the new behaviour fixes a
non-working configuration (instead of breaking a build that was working
previously)?
Regards,
Hervé
Le mardi 20 décembre 2016, 02:28:37 CET Christian Schulte a écrit :
> Am 12/19/16 um 23:22 schrieb Hervé BOUTEMY:
> > Le lundi 19 décembre 2016, 03:39:15 CET Christian Schulte a écrit :
> >> Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY:
> > different: IIUC, if the resolution was not different, the failure would
> > have happened at build time, isn't it?
>
> From what I can tell, most ITs just would have failed. Nothing is
> providing the annotations at runtime. They are available at build time
> but not at runtime. That's provided.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/19/16 um 23:22 schrieb Herv BOUTEMY:
> Le lundi 19 dcembre 2016, 03:39:15 CET Christian Schulte a crit :
>> Am 12/18/16 um 10:19 schrieb Herv BOUTEMY:
> different: IIUC, if the resolution was not different, the failure would have
> happened at build time, isn't it?
From what I can tell, most ITs just would have failed. Nothing is
providing the annotations at runtime. They are available at build time
but not at runtime. That's provided.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Hervé BOUTEMY <he...@free.fr>.
Le lundi 19 décembre 2016, 03:39:15 CET Christian Schulte a écrit :
> Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY:
> You know what? We want also that libraries classpath are consistent
> when built
>
> > and when used as dependencies: nothing specific to plugins and core
> > extensions. Everything is built some time then used.
> > If there are some unexpected discrepencies, we have an issue.
>
> That may well be! You can take
> <https://issues.apache.org/jira/browse/MPLUGIN-296> as an example
> demonstrating the difference. You just need a maven-plugin project to
> build using the maven-plugin-plugin-3.4. Build that with Maven < 3.4 and
> Maven >= 3.4 and compare the different plugin classpaths (-X). You'll
> notice that in Maven 3.4 a provided direct dependency of the plugin is
> collected and used to do conflict resolution and everything else and
> then filtered out during resolving the artifacts. In Maven < 3.4 that
> provided direct dependency is not collected and so another node (same
> dependency but transitive) is used to do conflict resolution and
> everything else which is then not filtered out during resolving the
> artifacts. Maven 3.4 gets that right.
from a purist point of view, I understand: from a user point of view, do you
have any case where the new behaviour fixes a non-working configuration (instead
of breaking a build that was working previously)?
> Maybe that's also the way
> dependencies should be resolved as well.
I must confess that what is the most suprising is that the resolution is
different: IIUC, if the resolution was not different, the failure would have
happened at build time, isn't it?
Regards,
Hervé
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Stephen Connolly <st...@gmail.com>.
No. my son is only in school during the AM, so you might have a chance to
try some iterations to get it working sooner... we are only prodding the
dark! (And I'm validating my complaints about how literate is better than
jenkinsfile... but I lost that popularity contest)
Or anyone else can too (just remember until infra upgrades you need to
trigger a manual indexing to pick up new branches/commits faster than once
per hour)
On Mon 19 Dec 2016 at 14:20, Arnaud Héritier <ah...@gmail.com> wrote:
> For windows? Am I punished ?
>
>
>
> Bouhhh
>
>
>
> Le lun. 19 déc. 2016 à 15:17, Stephen Connolly <
>
> stephen.alan.connolly@gmail.com> a écrit :
>
>
>
> > https://builds.apache.org/view/M-R/view/Maven/job/maven-jenkinsfile
>
> >
>
> >
>
> >
>
> > Working on a Jenkinsfile... should work for linux on Java 7 & 8...
> getting
>
> >
>
> > the Windows builds working will be "fun"... perhaps Arnaud can assist!
>
> >
>
> >
>
> >
>
> > On 19 December 2016 at 09:41, Stephen Connolly <
>
> >
>
> > stephen.alan.connolly@gmail.com> wrote:
>
> >
>
> >
>
> >
>
> > > We should probably look at switching to multi-branch / org folders...
>
> >
>
> > >
>
> >
>
> > > I released a set of -beta-1 releases on Friday (due to some
> scaredy-cats
>
> >
>
> > > not being comfortable with pushing full releases to the update centre
> on
>
> > a
>
> >
>
> > > Friday afternoon before I start a 2 week break! Chickens!)
>
> >
>
> > >
>
> >
>
> > > These releases significantly reduce the impact of org-folders on API
>
> >
>
> > > limits... we should check with infra and see if that will make it into
>
> > the
>
> >
>
> > > "usable" zone (otherwise we'll need to wait for my 2nd gen
>
> > improvements...)
>
> >
>
> > >
>
> >
>
> > > Other than that, in the interim we can set up jobs for a "DEV" branch
> if
>
> >
>
> > > that helps... we need to be keeping master releasable... the current
>
> > state
>
> >
>
> > > of master does not seem to match that expectation
>
> >
>
> > >
>
> >
>
> > > On Sun 18 Dec 2016 at 23:45, Christian Schulte <cs...@schulte.it> wrote:
>
> >
>
> > >
>
> >
>
> > >> Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY:
>
> >
>
> > >>
>
> >
>
> > >> > you are completely missing my point: simply put, when doing such
> risky
>
> >
>
> > >> change
>
> >
>
> > >>
>
> >
>
> > >> > (that require Review Then Commit), *please do it on a branch*, not
> on
>
> >
>
> > >> master
>
> >
>
> > >>
>
> >
>
> > >> > (that you'll later revert to postpone to a future Maven version:
>
> >
>
> > >> tracking
>
> >
>
> > >>
>
> >
>
> > >> > changes on master is a big giant mess lately, with updates and
> reverts
>
> >
>
> > >> in
>
> >
>
> > >>
>
> >
>
> > >> > every place!)
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >> Master is WIP. Working on a branch does not make Jenkins check
> anything.
>
> >
>
> > >>
>
> >
>
> > >> I can continue to use my machine during Jenkins doing it's job.
> Running
>
> >
>
> > >>
>
> >
>
> > >> the ITs locally means my machine is unuseable for nearly an hour. If
> the
>
> >
>
> > >>
>
> >
>
> > >> ITs are running fine locally, it happened way to often that the ITs on
>
> >
>
> > >>
>
> >
>
> > >> Jenkins failed due to other reasons. I do run them locally whenever
>
> >
>
> > >>
>
> >
>
> > >> Jenkins sends out failure notices to reproduce things locally. I am no
>
> >
>
> > >>
>
> >
>
> > >> fan of developers working for weeks on theire own and then trying to
>
> >
>
> > >>
>
> >
>
> > >> integrate their weeks of work all in one go no-one has ever had a
> chance
>
> >
>
> > >>
>
> >
>
> > >> to follow and comment.
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >> > and on "As far as I understand it we want the plugins and core
>
> >
>
> > >>
>
> >
>
> > >> > extensions to use the same classpath when executed and when build"
>
> >
>
> > >>
>
> >
>
> > >> > You know what? We want also that libraries classpath are consistent
>
> >
>
> > >> when built
>
> >
>
> > >>
>
> >
>
> > >> > and when used as dependencies: nothing specific to plugins and core
>
> >
>
> > >> extensions.
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >> I am not the author who made that a difference but there is a
>
> >
>
> > >>
>
> >
>
> > >> difference. There is a reason some logic is in place deciding to
> select
>
> >
>
> > >>
>
> >
>
> > >> a transitive dependency or to ignore it. That's just the way Maven is
>
> >
>
> > >>
>
> >
>
> > >> designed.
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >> POM
>
> >
>
> > >>
>
> >
>
> > >> - depdency (always selected, no matter what)
>
> >
>
> > >>
>
> >
>
> > >> - transitive dependency (selected only if not non-transitive)
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >> Dependency
>
> >
>
> > >>
>
> >
>
> > >> - transitive dependency (selected if not non-transitive)
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >> Thats what the resolver does when requested to collect dependencies
> for
>
> >
>
> > >>
>
> >
>
> > >> a POM or for a dependency. I just made two selector implementations
>
> >
>
> > >>
>
> >
>
> > >> behave the same. Some were updated to reflect this difference. Some
> were
>
> >
>
> > >>
>
> >
>
> > >> not. They are now all behaving the same. Plugins and core extensions
>
> >
>
> > >>
>
> >
>
> > >> were resolved as dependencies. This started to work consistently. That
>
> >
>
> > >>
>
> >
>
> > >> led to MNG-6135. That should be implemented now. I had to update an IT
>
> >
>
> > >>
>
> >
>
> > >> when plugin resolution (as dependency) started to work. I could revert
>
> >
>
> > >>
>
> >
>
> > >> that update since they are now resolved as projects.
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >> > Everything is built some time then used.
>
> >
>
> > >>
>
> >
>
> > >> > If there are some unexpected discrepencies, we have an issue.
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >> See above. This is how things have been implemented for years. I am
> not
>
> >
>
> > >>
>
> >
>
> > >> the author.
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >> > And updating plugins for Maven own builds to work now won't help
> Maven
>
> >
>
> > >> users
>
> >
>
> > >>
>
> >
>
> > >> > to update their builds
>
> >
>
> > >>
>
> >
>
> > >> > Notice I use the word "update", not "fix": I don't care if you think
>
> >
>
> > >> that the
>
> >
>
> > >>
>
> >
>
> > >> > required update is a positive fix because everything was buggy for
> 10
>
> >
>
> > >> years and
>
> >
>
> > >>
>
> >
>
> > >> > you're the guy who is saving us from the bugs we lived with: for
>
> > normal
>
> >
>
> > >> users,
>
> >
>
> > >>
>
> >
>
> > >> > it worked and you're once again breaking Maven
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >> What is broken? The number of failing ITs is down to one already. How
>
> >
>
> > >>
>
> >
>
> > >> many commits did it take to get the ANSI colors going?
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >> mng5771CoreExtensions(CoreExtensionRetrievedFromAMir
>
> >
>
> > >> rorWithBasicAuthentication)
>
> >
>
> > >>
>
> >
>
> > >> FAILURE (3.5 s)
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >> I am looking into this one right now.
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >> Regards,
>
> >
>
> > >>
>
> >
>
> > >> --
>
> >
>
> > >>
>
> >
>
> > >> Christian
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >> ---------------------------------------------------------------------
>
> >
>
> > >>
>
> >
>
> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> >
>
> > >>
>
> >
>
> > >> For additional commands, e-mail: dev-help@maven.apache.org
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >>
>
> >
>
> > >> --
>
> >
>
> > > Sent from my phone
>
> >
>
> > >
>
> >
>
> >
>
> --
Sent from my phone
Re: Improving Jenkins
Posted by Arnaud Héritier <ah...@gmail.com>.
For windows? Am I punished ?
Bouhhh
Le lun. 19 déc. 2016 à 15:17, Stephen Connolly <
stephen.alan.connolly@gmail.com> a écrit :
> https://builds.apache.org/view/M-R/view/Maven/job/maven-jenkinsfile
>
>
>
> Working on a Jenkinsfile... should work for linux on Java 7 & 8... getting
>
> the Windows builds working will be "fun"... perhaps Arnaud can assist!
>
>
>
> On 19 December 2016 at 09:41, Stephen Connolly <
>
> stephen.alan.connolly@gmail.com> wrote:
>
>
>
> > We should probably look at switching to multi-branch / org folders...
>
> >
>
> > I released a set of -beta-1 releases on Friday (due to some scaredy-cats
>
> > not being comfortable with pushing full releases to the update centre on
> a
>
> > Friday afternoon before I start a 2 week break! Chickens!)
>
> >
>
> > These releases significantly reduce the impact of org-folders on API
>
> > limits... we should check with infra and see if that will make it into
> the
>
> > "usable" zone (otherwise we'll need to wait for my 2nd gen
> improvements...)
>
> >
>
> > Other than that, in the interim we can set up jobs for a "DEV" branch if
>
> > that helps... we need to be keeping master releasable... the current
> state
>
> > of master does not seem to match that expectation
>
> >
>
> > On Sun 18 Dec 2016 at 23:45, Christian Schulte <cs...@schulte.it> wrote:
>
> >
>
> >> Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY:
>
> >>
>
> >> > you are completely missing my point: simply put, when doing such risky
>
> >> change
>
> >>
>
> >> > (that require Review Then Commit), *please do it on a branch*, not on
>
> >> master
>
> >>
>
> >> > (that you'll later revert to postpone to a future Maven version:
>
> >> tracking
>
> >>
>
> >> > changes on master is a big giant mess lately, with updates and reverts
>
> >> in
>
> >>
>
> >> > every place!)
>
> >>
>
> >>
>
> >>
>
> >> Master is WIP. Working on a branch does not make Jenkins check anything.
>
> >>
>
> >> I can continue to use my machine during Jenkins doing it's job. Running
>
> >>
>
> >> the ITs locally means my machine is unuseable for nearly an hour. If the
>
> >>
>
> >> ITs are running fine locally, it happened way to often that the ITs on
>
> >>
>
> >> Jenkins failed due to other reasons. I do run them locally whenever
>
> >>
>
> >> Jenkins sends out failure notices to reproduce things locally. I am no
>
> >>
>
> >> fan of developers working for weeks on theire own and then trying to
>
> >>
>
> >> integrate their weeks of work all in one go no-one has ever had a chance
>
> >>
>
> >> to follow and comment.
>
> >>
>
> >>
>
> >>
>
> >> > and on "As far as I understand it we want the plugins and core
>
> >>
>
> >> > extensions to use the same classpath when executed and when build"
>
> >>
>
> >> > You know what? We want also that libraries classpath are consistent
>
> >> when built
>
> >>
>
> >> > and when used as dependencies: nothing specific to plugins and core
>
> >> extensions.
>
> >>
>
> >>
>
> >>
>
> >> I am not the author who made that a difference but there is a
>
> >>
>
> >> difference. There is a reason some logic is in place deciding to select
>
> >>
>
> >> a transitive dependency or to ignore it. That's just the way Maven is
>
> >>
>
> >> designed.
>
> >>
>
> >>
>
> >>
>
> >> POM
>
> >>
>
> >> - depdency (always selected, no matter what)
>
> >>
>
> >> - transitive dependency (selected only if not non-transitive)
>
> >>
>
> >>
>
> >>
>
> >> Dependency
>
> >>
>
> >> - transitive dependency (selected if not non-transitive)
>
> >>
>
> >>
>
> >>
>
> >> Thats what the resolver does when requested to collect dependencies for
>
> >>
>
> >> a POM or for a dependency. I just made two selector implementations
>
> >>
>
> >> behave the same. Some were updated to reflect this difference. Some were
>
> >>
>
> >> not. They are now all behaving the same. Plugins and core extensions
>
> >>
>
> >> were resolved as dependencies. This started to work consistently. That
>
> >>
>
> >> led to MNG-6135. That should be implemented now. I had to update an IT
>
> >>
>
> >> when plugin resolution (as dependency) started to work. I could revert
>
> >>
>
> >> that update since they are now resolved as projects.
>
> >>
>
> >>
>
> >>
>
> >> > Everything is built some time then used.
>
> >>
>
> >> > If there are some unexpected discrepencies, we have an issue.
>
> >>
>
> >>
>
> >>
>
> >> See above. This is how things have been implemented for years. I am not
>
> >>
>
> >> the author.
>
> >>
>
> >>
>
> >>
>
> >> > And updating plugins for Maven own builds to work now won't help Maven
>
> >> users
>
> >>
>
> >> > to update their builds
>
> >>
>
> >> > Notice I use the word "update", not "fix": I don't care if you think
>
> >> that the
>
> >>
>
> >> > required update is a positive fix because everything was buggy for 10
>
> >> years and
>
> >>
>
> >> > you're the guy who is saving us from the bugs we lived with: for
> normal
>
> >> users,
>
> >>
>
> >> > it worked and you're once again breaking Maven
>
> >>
>
> >>
>
> >>
>
> >> What is broken? The number of failing ITs is down to one already. How
>
> >>
>
> >> many commits did it take to get the ANSI colors going?
>
> >>
>
> >>
>
> >>
>
> >> mng5771CoreExtensions(CoreExtensionRetrievedFromAMir
>
> >> rorWithBasicAuthentication)
>
> >>
>
> >> FAILURE (3.5 s)
>
> >>
>
> >>
>
> >>
>
> >> I am looking into this one right now.
>
> >>
>
> >>
>
> >>
>
> >> Regards,
>
> >>
>
> >> --
>
> >>
>
> >> Christian
>
> >>
>
> >>
>
> >>
>
> >>
>
> >>
>
> >> ---------------------------------------------------------------------
>
> >>
>
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> >>
>
> >> For additional commands, e-mail: dev-help@maven.apache.org
>
> >>
>
> >>
>
> >>
>
> >> --
>
> > Sent from my phone
>
> >
>
>
Re: Improving Jenkins
Posted by Stephen Connolly <st...@gmail.com>.
https://builds.apache.org/view/M-R/view/Maven/job/maven-jenkinsfile
Working on a Jenkinsfile... should work for linux on Java 7 & 8... getting
the Windows builds working will be "fun"... perhaps Arnaud can assist!
On 19 December 2016 at 09:41, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> We should probably look at switching to multi-branch / org folders...
>
> I released a set of -beta-1 releases on Friday (due to some scaredy-cats
> not being comfortable with pushing full releases to the update centre on a
> Friday afternoon before I start a 2 week break! Chickens!)
>
> These releases significantly reduce the impact of org-folders on API
> limits... we should check with infra and see if that will make it into the
> "usable" zone (otherwise we'll need to wait for my 2nd gen improvements...)
>
> Other than that, in the interim we can set up jobs for a "DEV" branch if
> that helps... we need to be keeping master releasable... the current state
> of master does not seem to match that expectation
>
> On Sun 18 Dec 2016 at 23:45, Christian Schulte <cs...@schulte.it> wrote:
>
>> Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY:
>>
>> > you are completely missing my point: simply put, when doing such risky
>> change
>>
>> > (that require Review Then Commit), *please do it on a branch*, not on
>> master
>>
>> > (that you'll later revert to postpone to a future Maven version:
>> tracking
>>
>> > changes on master is a big giant mess lately, with updates and reverts
>> in
>>
>> > every place!)
>>
>>
>>
>> Master is WIP. Working on a branch does not make Jenkins check anything.
>>
>> I can continue to use my machine during Jenkins doing it's job. Running
>>
>> the ITs locally means my machine is unuseable for nearly an hour. If the
>>
>> ITs are running fine locally, it happened way to often that the ITs on
>>
>> Jenkins failed due to other reasons. I do run them locally whenever
>>
>> Jenkins sends out failure notices to reproduce things locally. I am no
>>
>> fan of developers working for weeks on theire own and then trying to
>>
>> integrate their weeks of work all in one go no-one has ever had a chance
>>
>> to follow and comment.
>>
>>
>>
>> > and on "As far as I understand it we want the plugins and core
>>
>> > extensions to use the same classpath when executed and when build"
>>
>> > You know what? We want also that libraries classpath are consistent
>> when built
>>
>> > and when used as dependencies: nothing specific to plugins and core
>> extensions.
>>
>>
>>
>> I am not the author who made that a difference but there is a
>>
>> difference. There is a reason some logic is in place deciding to select
>>
>> a transitive dependency or to ignore it. That's just the way Maven is
>>
>> designed.
>>
>>
>>
>> POM
>>
>> - depdency (always selected, no matter what)
>>
>> - transitive dependency (selected only if not non-transitive)
>>
>>
>>
>> Dependency
>>
>> - transitive dependency (selected if not non-transitive)
>>
>>
>>
>> Thats what the resolver does when requested to collect dependencies for
>>
>> a POM or for a dependency. I just made two selector implementations
>>
>> behave the same. Some were updated to reflect this difference. Some were
>>
>> not. They are now all behaving the same. Plugins and core extensions
>>
>> were resolved as dependencies. This started to work consistently. That
>>
>> led to MNG-6135. That should be implemented now. I had to update an IT
>>
>> when plugin resolution (as dependency) started to work. I could revert
>>
>> that update since they are now resolved as projects.
>>
>>
>>
>> > Everything is built some time then used.
>>
>> > If there are some unexpected discrepencies, we have an issue.
>>
>>
>>
>> See above. This is how things have been implemented for years. I am not
>>
>> the author.
>>
>>
>>
>> > And updating plugins for Maven own builds to work now won't help Maven
>> users
>>
>> > to update their builds
>>
>> > Notice I use the word "update", not "fix": I don't care if you think
>> that the
>>
>> > required update is a positive fix because everything was buggy for 10
>> years and
>>
>> > you're the guy who is saving us from the bugs we lived with: for normal
>> users,
>>
>> > it worked and you're once again breaking Maven
>>
>>
>>
>> What is broken? The number of failing ITs is down to one already. How
>>
>> many commits did it take to get the ANSI colors going?
>>
>>
>>
>> mng5771CoreExtensions(CoreExtensionRetrievedFromAMir
>> rorWithBasicAuthentication)
>>
>> FAILURE (3.5 s)
>>
>>
>>
>> I am looking into this one right now.
>>
>>
>>
>> Regards,
>>
>> --
>>
>> Christian
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>> --
> Sent from my phone
>
Re: Improving Jenkins
Posted by Stephen Connolly <st...@gmail.com>.
We should probably look at switching to multi-branch / org folders...
I released a set of -beta-1 releases on Friday (due to some scaredy-cats
not being comfortable with pushing full releases to the update centre on a
Friday afternoon before I start a 2 week break! Chickens!)
These releases significantly reduce the impact of org-folders on API
limits... we should check with infra and see if that will make it into the
"usable" zone (otherwise we'll need to wait for my 2nd gen improvements...)
Other than that, in the interim we can set up jobs for a "DEV" branch if
that helps... we need to be keeping master releasable... the current state
of master does not seem to match that expectation
On Sun 18 Dec 2016 at 23:45, Christian Schulte <cs...@schulte.it> wrote:
> Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY:
>
> > you are completely missing my point: simply put, when doing such risky
> change
>
> > (that require Review Then Commit), *please do it on a branch*, not on
> master
>
> > (that you'll later revert to postpone to a future Maven version: tracking
>
> > changes on master is a big giant mess lately, with updates and reverts in
>
> > every place!)
>
>
>
> Master is WIP. Working on a branch does not make Jenkins check anything.
>
> I can continue to use my machine during Jenkins doing it's job. Running
>
> the ITs locally means my machine is unuseable for nearly an hour. If the
>
> ITs are running fine locally, it happened way to often that the ITs on
>
> Jenkins failed due to other reasons. I do run them locally whenever
>
> Jenkins sends out failure notices to reproduce things locally. I am no
>
> fan of developers working for weeks on theire own and then trying to
>
> integrate their weeks of work all in one go no-one has ever had a chance
>
> to follow and comment.
>
>
>
> > and on "As far as I understand it we want the plugins and core
>
> > extensions to use the same classpath when executed and when build"
>
> > You know what? We want also that libraries classpath are consistent when
> built
>
> > and when used as dependencies: nothing specific to plugins and core
> extensions.
>
>
>
> I am not the author who made that a difference but there is a
>
> difference. There is a reason some logic is in place deciding to select
>
> a transitive dependency or to ignore it. That's just the way Maven is
>
> designed.
>
>
>
> POM
>
> - depdency (always selected, no matter what)
>
> - transitive dependency (selected only if not non-transitive)
>
>
>
> Dependency
>
> - transitive dependency (selected if not non-transitive)
>
>
>
> Thats what the resolver does when requested to collect dependencies for
>
> a POM or for a dependency. I just made two selector implementations
>
> behave the same. Some were updated to reflect this difference. Some were
>
> not. They are now all behaving the same. Plugins and core extensions
>
> were resolved as dependencies. This started to work consistently. That
>
> led to MNG-6135. That should be implemented now. I had to update an IT
>
> when plugin resolution (as dependency) started to work. I could revert
>
> that update since they are now resolved as projects.
>
>
>
> > Everything is built some time then used.
>
> > If there are some unexpected discrepencies, we have an issue.
>
>
>
> See above. This is how things have been implemented for years. I am not
>
> the author.
>
>
>
> > And updating plugins for Maven own builds to work now won't help Maven
> users
>
> > to update their builds
>
> > Notice I use the word "update", not "fix": I don't care if you think
> that the
>
> > required update is a positive fix because everything was buggy for 10
> years and
>
> > you're the guy who is saving us from the bugs we lived with: for normal
> users,
>
> > it worked and you're once again breaking Maven
>
>
>
> What is broken? The number of failing ITs is down to one already. How
>
> many commits did it take to get the ANSI colors going?
>
>
>
>
> mng5771CoreExtensions(CoreExtensionRetrievedFromAMirrorWithBasicAuthentication)
>
> FAILURE (3.5 s)
>
>
>
> I am looking into this one right now.
>
>
>
> Regards,
>
> --
>
> Christian
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
Sent from my phone
Re: Re: Improving Jenkins
Posted by Michael Osipov <19...@gmx.net>.
> > And updating plugins for Maven own builds to work now won't help Maven users
> > to update their builds
> > Notice I use the word "update", not "fix": I don't care if you think that the
> > required update is a positive fix because everything was buggy for 10 years and
> > you're the guy who is saving us from the bugs we lived with: for normal users,
> > it worked and you're once again breaking Maven
>
> What is broken? The number of failing ITs is down to one already. How
> many commits did it take to get the ANSI colors going?
>
> mng5771CoreExtensions(CoreExtensionRetrievedFromAMirrorWithBasicAuthentication)
> FAILURE (3.5 s)
I can confirm that, tried Wagon 2.11-SNAPSHOT in Maven master and is is the only
IT failing on my FreeBSD 10.3-RELEASE test machine.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/19/16 um 00:44 schrieb Christian Schulte:
> Master is WIP. Working on a branch does not make Jenkins check anything.
> I can continue to use my machine during Jenkins doing it's job. Running
> the ITs locally means my machine is unuseable for nearly an hour.
Ok. It's not nearly an hour but it feels like infinity:
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 19:42 min
[INFO] Finished at: 2016-12-19T05:05:13+01:00
[INFO] Final Memory: 46M/154M
[INFO]
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/18/16 um 10:19 schrieb Herv BOUTEMY:
> you are completely missing my point: simply put, when doing such risky change
> (that require Review Then Commit), *please do it on a branch*, not on master
> (that you'll later revert to postpone to a future Maven version: tracking
> changes on master is a big giant mess lately, with updates and reverts in
> every place!)
Master is WIP. Working on a branch does not make Jenkins check anything.
I can continue to use my machine during Jenkins doing it's job. Running
the ITs locally means my machine is unuseable for nearly an hour. If the
ITs are running fine locally, it happened way to often that the ITs on
Jenkins failed due to other reasons. I do run them locally whenever
Jenkins sends out failure notices to reproduce things locally. I am no
fan of developers working for weeks on theire own and then trying to
integrate their weeks of work all in one go no-one has ever had a chance
to follow and comment.
> and on "As far as I understand it we want the plugins and core
> extensions to use the same classpath when executed and when build"
> You know what? We want also that libraries classpath are consistent when built
> and when used as dependencies: nothing specific to plugins and core extensions.
I am not the author who made that a difference but there is a
difference. There is a reason some logic is in place deciding to select
a transitive dependency or to ignore it. That's just the way Maven is
designed.
POM
- depdency (always selected, no matter what)
- transitive dependency (selected only if not non-transitive)
Dependency
- transitive dependency (selected if not non-transitive)
Thats what the resolver does when requested to collect dependencies for
a POM or for a dependency. I just made two selector implementations
behave the same. Some were updated to reflect this difference. Some were
not. They are now all behaving the same. Plugins and core extensions
were resolved as dependencies. This started to work consistently. That
led to MNG-6135. That should be implemented now. I had to update an IT
when plugin resolution (as dependency) started to work. I could revert
that update since they are now resolved as projects.
> Everything is built some time then used.
> If there are some unexpected discrepencies, we have an issue.
See above. This is how things have been implemented for years. I am not
the author.
> And updating plugins for Maven own builds to work now won't help Maven users
> to update their builds
> Notice I use the word "update", not "fix": I don't care if you think that the
> required update is a positive fix because everything was buggy for 10 years and
> you're the guy who is saving us from the bugs we lived with: for normal users,
> it worked and you're once again breaking Maven
What is broken? The number of failing ITs is down to one already. How
many commits did it take to get the ANSI colors going?
mng5771CoreExtensions(CoreExtensionRetrievedFromAMirrorWithBasicAuthentication)
FAILURE (3.5 s)
I am looking into this one right now.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Hervé BOUTEMY <he...@free.fr>.
thank you for these explanations: I'll have a deep look tonight
Regards,
Hervé
Le lundi 19 décembre 2016, 04:12:01 CET Christian Schulte a écrit :
> Am 12/19/16 um 03:39 schrieb Christian Schulte:
> > Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY:
> > You know what? We want also that libraries classpath are consistent
> >
> > when built
> >
> >> and when used as dependencies: nothing specific to plugins and core
> >> extensions. Everything is built some time then used.
> >> If there are some unexpected discrepencies, we have an issue.
> >
> > That may well be! You can take
> > <https://issues.apache.org/jira/browse/MPLUGIN-296> as an example
> > demonstrating the difference. You just need a maven-plugin project to
> > build using the maven-plugin-plugin-3.4. Build that with Maven < 3.4 and
> > Maven >= 3.4 and compare the different plugin classpaths (-X). You'll
> > notice that in Maven 3.4 a provided direct dependency of the plugin is
> > collected and used to do conflict resolution and everything else and
> > then filtered out during resolving the artifacts. In Maven < 3.4 that
> > provided direct dependency is not collected and so another node (same
> > dependency but transitive) is used to do conflict resolution and
> > everything else which is then not filtered out during resolving the
> > artifacts. Maven 3.4 gets that right. Maybe that's also the way
> > dependencies should be resolved as well.
>
> Maven 3.4 (project): <http://pastebin.com/tuc1TncQ>
> Maven 3.0.5 (dependency): <http://pastebin.com/W4fJd93B>
>
> Note that 3.4 collects direct 'test', 'provided' and 'optional'
> dependencies whereas 3.0.5 does not. In 3.4 the conflict resolver selects
>
> [DEBUG]
> org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.4:provided
>
> (nearest) whereas in 3.0.5 the conflict resolver selects
>
> [DEBUG]
> org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.4:runtime
>
> because the nearer provided dependency has not been selected during
> collecting dependencies. This result is passed to the resolver to
> download the corresponding artifacts (jars). That resolver is setup to
> filter out anything non-transitive ever since but it never saw anything
> non-transitive due to the collector not collecting the nodes.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/19/16 um 03:39 schrieb Christian Schulte:
> Am 12/18/16 um 10:19 schrieb Herv BOUTEMY:
> You know what? We want also that libraries classpath are consistent
> when built
>> and when used as dependencies: nothing specific to plugins and core extensions.
>> Everything is built some time then used.
>> If there are some unexpected discrepencies, we have an issue.
>
> That may well be! You can take
> <https://issues.apache.org/jira/browse/MPLUGIN-296> as an example
> demonstrating the difference. You just need a maven-plugin project to
> build using the maven-plugin-plugin-3.4. Build that with Maven < 3.4 and
> Maven >= 3.4 and compare the different plugin classpaths (-X). You'll
> notice that in Maven 3.4 a provided direct dependency of the plugin is
> collected and used to do conflict resolution and everything else and
> then filtered out during resolving the artifacts. In Maven < 3.4 that
> provided direct dependency is not collected and so another node (same
> dependency but transitive) is used to do conflict resolution and
> everything else which is then not filtered out during resolving the
> artifacts. Maven 3.4 gets that right. Maybe that's also the way
> dependencies should be resolved as well.
Maven 3.4 (project): <http://pastebin.com/tuc1TncQ>
Maven 3.0.5 (dependency): <http://pastebin.com/W4fJd93B>
Note that 3.4 collects direct 'test', 'provided' and 'optional'
dependencies whereas 3.0.5 does not. In 3.4 the conflict resolver selects
[DEBUG]
org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.4:provided
(nearest) whereas in 3.0.5 the conflict resolver selects
[DEBUG]
org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.4:runtime
because the nearer provided dependency has not been selected during
collecting dependencies. This result is passed to the resolver to
download the corresponding artifacts (jars). That resolver is setup to
filter out anything non-transitive ever since but it never saw anything
non-transitive due to the collector not collecting the nodes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/18/16 um 10:19 schrieb Herv BOUTEMY:
You know what? We want also that libraries classpath are consistent
when built
> and when used as dependencies: nothing specific to plugins and core extensions.
> Everything is built some time then used.
> If there are some unexpected discrepencies, we have an issue.
That may well be! You can take
<https://issues.apache.org/jira/browse/MPLUGIN-296> as an example
demonstrating the difference. You just need a maven-plugin project to
build using the maven-plugin-plugin-3.4. Build that with Maven < 3.4 and
Maven >= 3.4 and compare the different plugin classpaths (-X). You'll
notice that in Maven 3.4 a provided direct dependency of the plugin is
collected and used to do conflict resolution and everything else and
then filtered out during resolving the artifacts. In Maven < 3.4 that
provided direct dependency is not collected and so another node (same
dependency but transitive) is used to do conflict resolution and
everything else which is then not filtered out during resolving the
artifacts. Maven 3.4 gets that right. Maybe that's also the way
dependencies should be resolved as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-12-18 um 10:19 schrieb Hervé BOUTEMY:
> you are completely missing my point: simply put, when doing such risky change
> (that require Review Then Commit), *please do it on a branch*, not on master
> (that you'll later revert to postpone to a future Maven version: tracking
> changes on master is a big giant mess lately, with updates and reverts in
> every place!)
I must agree here, I cannot not read the Git log anymore. It is terribly
poluted.
> And updating plugins for Maven own builds to work now won't help Maven users
> to update their builds
> Notice I use the word "update", not "fix": I don't care if you think that the
> required update is a positive fix because everything was buggy for 10 years and
> you're the guy who is saving us from the bugs we lived with: for normal users,
> it worked and you're once again breaking Maven
Fixing long-standing issues people lived with is hard, I do agree, but
this does not mean we shouldn't do it. Rather this has to be a new major
version.
> Le samedi 17 décembre 2016, 21:34:54 CET Christian Schulte a écrit :
>> Am 12/17/16 um 11:52 schrieb Hervé BOUTEMY:
>>> looks like MNG-6135 causes a lot of issues
>>>
>>> "Maven plugins and core extensions are not dependencies, they should be
>>> resolved the same way as projects."
>>> "Maven plugins and core extensions are not dependencies": why not
>>> "they should be resolved the same way as projects": why? what does that
>>> mean? they are not really currently built project either
>>>
>>> I'm not yet asking to revert, but seriously, such changes done now without
>>> explanations, tests (and after having maven-resolver-provider that caused
>>> false positives on ASF Jenkins => we're in the blue), I really dislike it
>>>
>>> I'm starting to be really tired of constant heavy changes like that :(
>>
>> I am still looking into it. I'll provide some examples later we can talk
>> about. Currently I agree with Igor that the resolution should be done
>> that way. As far as I understand it we want the plugins and core
>> extensions to use the same classpath when executed and when build.
>> Currently this is not the case.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/18/16 um 10:19 schrieb Herv BOUTEMY:
> Notice I use the word "update", not "fix": I don't care if you think that the
> required update is a positive fix because everything was buggy for 10 years and
> you're the guy who is saving us from the bugs we lived with: for normal users,
> it worked and you're once again breaking Maven
There is some very important part I'd like to say once again. I have
worked on issues reported by exactly those normal users. I am not the
reporter of any of those issues. I created MNG-6135 in JIRA due to
Igor's comments on my update to an IT. All other issues were not
reported by me but by those normal users. What is breaking Maven, IMHO,
is refusing to fix those issues what appears to those users as getting
ignored. Maven is a build tool. Chances are great those normal users
happen to be developers themselves. So what needs to be said is this:
Thank you all for taking the time and for reporting your findings to us
so that we can fix things we have not noticed ourselves.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Hervé BOUTEMY <he...@free.fr>.
you are completely missing my point: simply put, when doing such risky change
(that require Review Then Commit), *please do it on a branch*, not on master
(that you'll later revert to postpone to a future Maven version: tracking
changes on master is a big giant mess lately, with updates and reverts in
every place!)
and on "As far as I understand it we want the plugins and core
extensions to use the same classpath when executed and when build"
You know what? We want also that libraries classpath are consistent when built
and when used as dependencies: nothing specific to plugins and core extensions.
Everything is built some time then used.
If there are some unexpected discrepencies, we have an issue.
And updating plugins for Maven own builds to work now won't help Maven users
to update their builds
Notice I use the word "update", not "fix": I don't care if you think that the
required update is a positive fix because everything was buggy for 10 years and
you're the guy who is saving us from the bugs we lived with: for normal users,
it worked and you're once again breaking Maven
Regards,
Hervé
Le samedi 17 décembre 2016, 21:34:54 CET Christian Schulte a écrit :
> Am 12/17/16 um 11:52 schrieb Hervé BOUTEMY:
> > looks like MNG-6135 causes a lot of issues
> >
> > "Maven plugins and core extensions are not dependencies, they should be
> > resolved the same way as projects."
> > "Maven plugins and core extensions are not dependencies": why not
> > "they should be resolved the same way as projects": why? what does that
> > mean? they are not really currently built project either
> >
> > I'm not yet asking to revert, but seriously, such changes done now without
> > explanations, tests (and after having maven-resolver-provider that caused
> > false positives on ASF Jenkins => we're in the blue), I really dislike it
> >
> > I'm starting to be really tired of constant heavy changes like that :(
>
> I am still looking into it. I'll provide some examples later we can talk
> about. Currently I agree with Igor that the resolution should be done
> that way. As far as I understand it we want the plugins and core
> extensions to use the same classpath when executed and when build.
> Currently this is not the case.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/17/16 um 11:52 schrieb Herv BOUTEMY:
> looks like MNG-6135 causes a lot of issues
>
> "Maven plugins and core extensions are not dependencies, they should be
> resolved the same way as projects."
> "Maven plugins and core extensions are not dependencies": why not
> "they should be resolved the same way as projects": why? what does that mean?
> they are not really currently built project either
>
> I'm not yet asking to revert, but seriously, such changes done now without
> explanations, tests (and after having maven-resolver-provider that caused
> false positives on ASF Jenkins => we're in the blue), I really dislike it
>
> I'm starting to be really tired of constant heavy changes like that :(
I am still looking into it. I'll provide some examples later we can talk
about. Currently I agree with Igor that the resolution should be done
that way. As far as I understand it we want the plugins and core
extensions to use the same classpath when executed and when build.
Currently this is not the case.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Hervé BOUTEMY <he...@free.fr>.
looks like MNG-6135 causes a lot of issues
"Maven plugins and core extensions are not dependencies, they should be
resolved the same way as projects."
"Maven plugins and core extensions are not dependencies": why not
"they should be resolved the same way as projects": why? what does that mean?
they are not really currently built project either
I'm not yet asking to revert, but seriously, such changes done now without
explanations, tests (and after having maven-resolver-provider that caused
false positives on ASF Jenkins => we're in the blue), I really dislike it
I'm starting to be really tired of constant heavy changes like that :(
Regards,
Hervé
Le samedi 17 décembre 2016, 09:27:01 CET Hervé BOUTEMY a écrit :
> I fixed core-integration-testing-maven-3-embedded job
> (since wiping out the workspace was not sufficient because this target was
> re- appearing and rat complained, I just ran a build with -Drat.skip)
>
> Other Maven 3 jobs are failing for other cause [1], I did not investigate
>
> Regards,
>
> Hervé
>
> [1]
> https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-> maven-3-jdk-1.7/1926/console
> Le samedi 17 décembre 2016, 04:17:42 CET Christian Schulte a écrit :
> > Hi,
> >
> > I renamed the 'maven-aether-provider' module to
> > 'maven-resolver-provider'. What happens on Jenkins is this: The
> > 'maven-aether-provider' folder will not get deleted correctly when
> > Jenkins performs the SCM update/checkout. This may be due to the
> > existence of the 'maven-aether-provider/target' folder. We cannot run a
> > post-build 'clean' execution. This would throw away the build result
> > after a successfull build so that no-one could download anything of that
> > build result. Does someone know how to make Jenkins correctly handle
> > module renames? Issue is the old module folder is lying around on every
> > build node and the workspace needs to be deleted manually on every build
> > node. That's one of the reasons Jenkins is sending out failure notices
> > for the 'maven-3.x' and related build jobs since a few days. Can we do
> > something about it? If not, just delete the workspace whenever such a
> > build failure gets reported until all build nodes caught up.
> >
> > Regards,
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Improving Jenkins
Posted by Hervé BOUTEMY <he...@free.fr>.
I fixed core-integration-testing-maven-3-embedded job
(since wiping out the workspace was not sufficient because this target was re-
appearing and rat complained, I just ran a build with -Drat.skip)
Other Maven 3 jobs are failing for other cause [1], I did not investigate
Regards,
Hervé
[1] https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.7/1926/console
Le samedi 17 décembre 2016, 04:17:42 CET Christian Schulte a écrit :
> Hi,
>
> I renamed the 'maven-aether-provider' module to
> 'maven-resolver-provider'. What happens on Jenkins is this: The
> 'maven-aether-provider' folder will not get deleted correctly when
> Jenkins performs the SCM update/checkout. This may be due to the
> existence of the 'maven-aether-provider/target' folder. We cannot run a
> post-build 'clean' execution. This would throw away the build result
> after a successfull build so that no-one could download anything of that
> build result. Does someone know how to make Jenkins correctly handle
> module renames? Issue is the old module folder is lying around on every
> build node and the workspace needs to be deleted manually on every build
> node. That's one of the reasons Jenkins is sending out failure notices
> for the 'maven-3.x' and related build jobs since a few days. Can we do
> something about it? If not, just delete the workspace whenever such a
> build failure gets reported until all build nodes caught up.
>
> Regards,
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org