Re: Improving Jenkins

[Hervé BOUTEMY]

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 

Re: Improving Jenkins

[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)?

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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



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

Re: Improving Jenkins

[Christian Schulte]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Improving Jenkins

[Christian Schulte]

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.

> "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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Christian Schulte]

Am 12/20/16 um 01:58 schrieb Christian Schulte:
> 2. Collect dependency
> -
> CollectRequest.setRoot(Dependency):
> The dependency passed to this method is some *direct* dependency you got
> from somewhere. Management is considered to already be applied. This
> will become the root node of the result tree.
> 
> CollectRequest.addDependency(Dependency):
> The dependencies passed to this method are considered to be *transitive*
> dependencies of the root dependency. The resolver will apply management
> to them. See above. That is different. Here they are transitive, whereas
> above they are direct. This is what was not handled consistently accross
> the various selectors.

The Javadoc clearly states the 'addDependency' method to take direct
dependencies. It may well be that I took the incorrect selector and made
the others behave the same although I should have fixed that one
selector to match the others. That's the minefield. Will take a look
again. The result is the same. So whatever that leads to will not change
the behaviour you are now seeing on master.


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

Re: Improving Jenkins

[Christian Schulte]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Christian Schulte]

Am 12/19/16 um 18:26 schrieb Stephen Connolly:
> We need to clarify.
> 
> There is stuff that is "wrong" but has become expected behaviour because we
> never "fixed" it => we cannot "fix" now because it will break too many users
> 
> There is stuff that is "wrong" because we broke it, some users have
> legitimate bugs and other users have hacks around the "wrong" => we will
> break something no matter what we do, so maybe we can "fix"
> 
> There is stuff that is "wrong" because it was never specified and we'd now
> like it to work one way because that way feels "right"
> 
> Etc
> 
> What class of problem is this?
> 
> To my mind, depMgmt should never alter the scope of a dependency... if you
> specify a scope you are saying apply the rest when it is added with this
> scope.
> 
> But that is my "how I would like it to work"...
> 
> Christian, you need to identify which kind of "wrong" behaviour is going on
> here... then we can reframe the debate and find a path forward

That's by far not easy. I maybe should explain where most of this comes
from. Working on an issue, I read a lot from the
'DefaultDependencyCollector' and involved classes from the resolver.
That's like walking in a minefield. Also for the original author. During
reading, I found some inconsistencies between various
'DependencySelector' implementations which happened to be the cause for
the issue I was working on. I took the one implementation I understood
was working as intendend and made two others match that logic (decide if
a depencency is transitive or direct). Then wrote test cases for all of
this to test they all behave the same. What influences the transitive
vs. direct logic is how the 'CollectRequest' has been populated. For
project resolution, the 'setRootArtifact(POM)' method should be used,
for dependency resolution the 'setRoot(Dependency)' method should be used.



This has a direct impact on the way the following methods need to decide
transitive vs. direct.

'deriveChildSelector' here:



'deriveChildManager' here:



'deriveChildTraverser' here:



'deriveChildFilter' here:



Implementations in use are here:


Sometime back in time, this difference between POM resolution and
dependency resolution must have been introduced without all those
'deriveXyz' implementations having been updated to reflect that
difference. That's what I did. They now all behave the same and
correctly decide transitive vs. direct based on what the
'CollectRequest' has been setup to. The core use-cases are the following:

1. Collect project
--
CollectRequest.setRootArtifact(Artifact):
The artifact passed to this method is a project. This will become the
root node of the result tree.

CollectRequest.addDependency(Dependency):
The dependencies passed to this method are the *direct* dependencies of
that POM the way the core model builder has build/managed them.

CollectRequest.addManagedDependency(Dependency):
The management from the POM to be applied to *transitive* dependencies.
The direct dependencies already have been managed by the core model
builder. Whereas the model builder only manages elements not declared
directly, the resolver overrides all elements (it cannot know if a
mandatory element has been declared directly or has been managed by the
core model builder because the elements are just there.)

2. Collect dependency
-
CollectRequest.setRoot(Dependency):
The dependency passed to this method is some *direct* dependency you got
from somewhere. Management is considered to already be applied. This
will become the root node of the result tree.

CollectRequest.addDependency(Dependency):
The dependencies passed to this method are considered to be *transitive*
dependencies of the root dependency. The resolver 

Re: Scope promotion of managed dependencies in current Maven master

[Christian Schulte]

Am 12/19/16 um 15:56 schrieb Michael Osipov:
> [DEBUG]net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile
> [DEBUG]   org.slf4j:slf4j-simple:jar:1.7.21:runtime (scope managed from 
> test by com.company.project:project-parent:0.11-SNAPSHOT)



That's what the resolver does. It uses the management as a global
override for transitive dependencies. It's correct this will get managed
to 'runtime'. That's what you have in your management.

> My questions are:
> 1. Is this another fix in master where I relied on an erratic behavior in 
> core previously?
> 2. Should depMgmthave influence on transitive deps or direct only?

Direct dependencies (those being declared in the POM) are handled by the
core (model builder), transitive dependencies are handled by the
resolver. It has always been that way. This is what has changed:





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

Re: Improving Jenkins

[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:
>  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
>  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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



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

Re: Maven 3.4.0 Release

[Hervé BOUTEMY]

+1 also

Regards,

Hervé

Le lundi 19 décembre 2016, 20:36:48 CET Robert Scholte a écrit :
> +100
> 
> On Mon, 19 Dec 2016 20:12:33 +0100, Stephen Connolly
> 
>  wrote:
> > We need to get the project back in the habit of releasing.
> > 
> > My vote is the we rebuild master with a clean history. keep current
> > master
> > as a reference branch, and cherry-pick as we go.
> > 
> > The aim should be kept tight in scope and focus on the aether replacement
> > only. Minimum change for aether replacement.
> > 
> > Then we can start bringing in bug fixes.
> > 
> > If we need to break things, we can go 3.6.x or 4.x.y I only request that
> > 5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
> > (which is what my proposals are aiming to help us flesh out... though my
> > proposals may not be selected by committers in the end, hopefully they
> > will
> > allow us to have a reasoned debate)
> > 
> > Wdyt?
> > 
> > On Mon 19 Dec 2016 at 17:41, Robert Scholte  wrote:
> >> We're already trying to push a new release for quite some time. And it
> >> 
> >> seems the discussion is not over yet.
> >> 
> >> There are a lot of improvements which deserve a release, so personally
> >> I'd
> >> 
> >> like to push the discussion to 3.5.0
> >> 
> >> 
> >> 
> >> Robert
> >> 
> >> 
> >> 
> >> On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
> >> 
> >>  wrote:
> >> > Isn't that postponing the discussion we're having here on those
> >> > 
> >> > controversial changes? I'd rather give it an extra effort rather than
> >> > 
> >> > pushing it back and loosing all the context once we have to tackle
> >> 
> >> 3.5.
> >> 
> >> > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
> >> > 
> >> > stephen.alan.conno...@gmail.com> wrote:
> >> >> I like that plan, but let's call that 3.4.0 and let these other
> >> 
> >> changes
> >> 
> >> >> go
> >> >> 
> >> >> for either 3.5.0
> >> >> 
> >> >> 
> >> >> 
> >> >> Does someone want to take a stab at forking master from an earlier
> >> 
> >> point
> >> 
> >> >> (perhaps get infra to let us rewrite master back to the fork point
> >> 
> >> and
> >> 
> >> >> push
> >> >> 
> >> >> the current state to a branch?)
> >> >> 
> >> >> 
> >> >> 
> >> >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko 
> >> 
> >> wrote:
> >> >> > No, I meant just eclipse->apache move, not all changes that went
> >> 
> >> into
> >> 
> >> >> > maven-resolver. The idea is to have a release branch we can
> >> 
> >> maintain
> >> 
> >> >> > while things stabilize in master.
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > --
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > Regards,
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > Igor
> >> >> > 
> >> >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
> >> >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
> >> >> > > > I wonder if it makes sense to release 3.3.10 with just the new
> >> >> 
> >> >> aether
> >> >> 
> >> >> > > > and give 3.4 more time to bake on master.
> >> >> > > 
> >> >> > > Changing a dependency with so many changes recently in a fix
> >> >> 
> >> >> version?
> >> >> 
> >> >> > > Doesn't sound right to me.
> >> >> > > 
> >> >> > > 
> >> >> > > 
> >> >> > > 
> >> >> > > 
> >> >> > > 
> >> >> > > 
> >> >> > > M
> >> >> 
> >> >> -
> >> >> 
> >> >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> >> > > 
> >> >> > > 
> >> >> > > 
> >> >> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >> 
> >> -
> >> 
> >> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > For additional commands, e-mail: dev-h...@maven.apache.org
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > --
> >> >> 
> >> >> Sent from my phone
> >> 
> >> -
> >> 
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> 
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >> 
> >> 
> >> 
> >> --
> > 
> > Sent from my phone
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



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

Developing fix that spans across several Apache projects

[Plamen Totev]

Hi,

There is an issue in the Maven Assembly Plugin cause by a bug in the 
Plexus Archiver - 
https://github.com/codehaus-plexus/plexus-archiver/issues/53. To fix the 
issue I've created a patch for Apache Common Compress - 
https://issues.apache.org/jira/browse/COMPRESS-375


My understanding is that in order to fix the issue three releases are 
required. First the Apache Common Compress should be released, then 
Plexus Archiver and finally the Maven Assembly plugin. I'm new to 
contributing to open source project in general so I'll be very grateful 
if somebody could tell me more about the procedure in such cases and how 
should I handle them. Excuse me if this question was asked already, but 
I didn't manage to find any information.


And maybe a bit off-topic. My proposed fix introduces a backward 
incompatible change in Plexus Archiver. You could take a look at the 
proposed changes here - 
https://github.com/plamentotev/plexus-archiver/commit/c493756f86acbe5d64084a875045f00e905c8136. 
What do you think? Tt needs a polish such as better javadocs for the 
ConcurrentJarCreator constructor and more test cases, but you could get 
an idea about the patch. Does this change require major version change 
in Plexus Archiver? Not quite sure if ConcurrentJarCreator is part of 
the public interface of the library.


Thanks,
Plamen Totev



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

Re: Maven 3.4.0 Release

[Manfred Moser]

Sure... but as close to be ready to release as possible. At a minimum passing 
ITs... 

Gary Gregory wrote on 2016-12-19 11:39:

> On Mon, Dec 19, 2016 at 11:24 AM, Manfred Moser 
> wrote:
> 
>> Totally agree. Master should be ready to release all the time imho.
>> Nothing that isnt tested well and proven to at least pass all IT's should
>> be merged into master. Experimentation should happen in feature branches..
>>
> 
> I think it's OK to have a master branch that is not ready to release at a
> moment's notice but it MUST be the case that all tests pass all the time.
> 
> Gary
> 
> 
>>
>> Just my 2c.
>>
>> Manfred
>>
>> Stephen Connolly wrote on 2016-12-19 11:12:
>>
>> > We need to get the project back in the habit of releasing.
>> >
>> > My vote is the we rebuild master with a clean history. keep current
>> master
>> > as a reference branch, and cherry-pick as we go.
>> >
>> > The aim should be kept tight in scope and focus on the aether replacement
>> > only. Minimum change for aether replacement.
>> >
>> > Then we can start bringing in bug fixes.
>> >
>> > If we need to break things, we can go 3.6.x or 4.x.y I only request that
>> > 5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
>> > (which is what my proposals are aiming to help us flesh out... though my
>> > proposals may not be selected by committers in the end, hopefully they
>> will
>> > allow us to have a reasoned debate)
>> >
>> > Wdyt?
>> >
>> > On Mon 19 Dec 2016 at 17:41, Robert Scholte 
>> wrote:
>> >
>> >> We're already trying to push a new release for quite some time. And it
>> >>
>> >> seems the discussion is not over yet.
>> >>
>> >> There are a lot of improvements which deserve a release, so personally
>> I'd
>> >>
>> >> like to push the discussion to 3.5.0
>> >>
>> >>
>> >>
>> >> Robert
>> >>
>> >>
>> >>
>> >> On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
>> >>
>> >>  wrote:
>> >>
>> >>
>> >>
>> >> > Isn't that postponing the discussion we're having here on those
>> >>
>> >> > controversial changes? I'd rather give it an extra effort rather than
>> >>
>> >> > pushing it back and loosing all the context once we have to tackle
>> 3.5.
>> >>
>> >> >
>> >>
>> >> > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
>> >>
>> >> > stephen.alan.conno...@gmail.com> wrote:
>> >>
>> >> >
>> >>
>> >> >> I like that plan, but let's call that 3.4.0 and let these other
>> changes
>> >>
>> >> >> go
>> >>
>> >> >> for either 3.5.0
>> >>
>> >> >>
>> >>
>> >> >> Does someone want to take a stab at forking master from an earlier
>> point
>> >>
>> >> >> (perhaps get infra to let us rewrite master back to the fork point
>> and
>> >>
>> >> >> push
>> >>
>> >> >> the current state to a branch?)
>> >>
>> >> >>
>> >>
>> >> >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko 
>> >> wrote:
>> >>
>> >> >>
>> >>
>> >> >> > No, I meant just eclipse->apache move, not all changes that went
>> into
>> >>
>> >> >> >
>> >>
>> >> >> > maven-resolver. The idea is to have a release branch we can
>> maintain
>> >>
>> >> >> >
>> >>
>> >> >> > while things stabilize in master.
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> > --
>> >>
>> >> >> >
>> >>
>> >> >> > Regards,
>> >>
>> >> >> >
>> >>
>> >> >> > Igor
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
>> >>
>> >> >> >
>> >>
>> >> >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
>> >>
>> >> >> >
>> >>
>> >> >> > > > I wonder if it makes sense to release 3.3.10 with just the new
>> >>
>> >> >> aether
>> >>
>> >> >> >
>> >>
>> >> >> > > > and give 3.4 more time to bake on master.
>> >>
>> >> >> >
>> >>
>> >> >> > >
>> >>
>> >> >> >
>> >>
>> >> >> > > Changing a dependency with so many changes recently in a fix
>> >>
>> >> >> version?
>> >>
>> >> >> >
>> >>
>> >> >> > > Doesn't sound right to me.
>> >>
>> >> >> >
>> >>
>> >> >> > >
>> >>
>> >> >> >
>> >>
>> >> >> > > M
>> >>
>> >> >> >
>> >>
>> >> >> > >
>> >>
>> >> >> >
>> >>
>> >> >> > >
>> >>
>> >> >> >
>> >>
>> >> >> > >
>> >>
>> >> >> 
>> -
>> >>
>> >> >> >
>> >>
>> >> >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> >>
>> >> >> >
>> >>
>> >> >> > > For additional commands, e-mail: dev-h...@maven.apache.org
>> >>
>> >> >> >
>> >>
>> >> >> > >
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> > 
>> -
>> >>
>> >> >> >
>> >>
>> >> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> >>
>> >> >> >
>> >>
>> >> >> > For additional commands, e-mail: dev-h...@maven.apache.org
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> >
>> >>
>> >> >> > --
>> >>
>> >> >> Sent from my phone
>> >>
>> >>
>> >>
>> >> -
>> >>
>> 

Re: Maven 3.4.0 Release

[Gary Gregory]

On Mon, Dec 19, 2016 at 11:24 AM, Manfred Moser 
wrote:

> Totally agree. Master should be ready to release all the time imho.
> Nothing that isnt tested well and proven to at least pass all IT's should
> be merged into master. Experimentation should happen in feature branches..
>

I think it's OK to have a master branch that is not ready to release at a
moment's notice but it MUST be the case that all tests pass all the time.

Gary


>
> Just my 2c.
>
> Manfred
>
> Stephen Connolly wrote on 2016-12-19 11:12:
>
> > We need to get the project back in the habit of releasing.
> >
> > My vote is the we rebuild master with a clean history. keep current
> master
> > as a reference branch, and cherry-pick as we go.
> >
> > The aim should be kept tight in scope and focus on the aether replacement
> > only. Minimum change for aether replacement.
> >
> > Then we can start bringing in bug fixes.
> >
> > If we need to break things, we can go 3.6.x or 4.x.y I only request that
> > 5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
> > (which is what my proposals are aiming to help us flesh out... though my
> > proposals may not be selected by committers in the end, hopefully they
> will
> > allow us to have a reasoned debate)
> >
> > Wdyt?
> >
> > On Mon 19 Dec 2016 at 17:41, Robert Scholte 
> wrote:
> >
> >> We're already trying to push a new release for quite some time. And it
> >>
> >> seems the discussion is not over yet.
> >>
> >> There are a lot of improvements which deserve a release, so personally
> I'd
> >>
> >> like to push the discussion to 3.5.0
> >>
> >>
> >>
> >> Robert
> >>
> >>
> >>
> >> On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
> >>
> >>  wrote:
> >>
> >>
> >>
> >> > Isn't that postponing the discussion we're having here on those
> >>
> >> > controversial changes? I'd rather give it an extra effort rather than
> >>
> >> > pushing it back and loosing all the context once we have to tackle
> 3.5.
> >>
> >> >
> >>
> >> > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
> >>
> >> > stephen.alan.conno...@gmail.com> wrote:
> >>
> >> >
> >>
> >> >> I like that plan, but let's call that 3.4.0 and let these other
> changes
> >>
> >> >> go
> >>
> >> >> for either 3.5.0
> >>
> >> >>
> >>
> >> >> Does someone want to take a stab at forking master from an earlier
> point
> >>
> >> >> (perhaps get infra to let us rewrite master back to the fork point
> and
> >>
> >> >> push
> >>
> >> >> the current state to a branch?)
> >>
> >> >>
> >>
> >> >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko 
> >> wrote:
> >>
> >> >>
> >>
> >> >> > No, I meant just eclipse->apache move, not all changes that went
> into
> >>
> >> >> >
> >>
> >> >> > maven-resolver. The idea is to have a release branch we can
> maintain
> >>
> >> >> >
> >>
> >> >> > while things stabilize in master.
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> > --
> >>
> >> >> >
> >>
> >> >> > Regards,
> >>
> >> >> >
> >>
> >> >> > Igor
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
> >>
> >> >> >
> >>
> >> >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
> >>
> >> >> >
> >>
> >> >> > > > I wonder if it makes sense to release 3.3.10 with just the new
> >>
> >> >> aether
> >>
> >> >> >
> >>
> >> >> > > > and give 3.4 more time to bake on master.
> >>
> >> >> >
> >>
> >> >> > >
> >>
> >> >> >
> >>
> >> >> > > Changing a dependency with so many changes recently in a fix
> >>
> >> >> version?
> >>
> >> >> >
> >>
> >> >> > > Doesn't sound right to me.
> >>
> >> >> >
> >>
> >> >> > >
> >>
> >> >> >
> >>
> >> >> > > M
> >>
> >> >> >
> >>
> >> >> > >
> >>
> >> >> >
> >>
> >> >> > >
> >>
> >> >> >
> >>
> >> >> > >
> >>
> >> >> 
> -
> >>
> >> >> >
> >>
> >> >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>
> >> >> >
> >>
> >> >> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >> >> >
> >>
> >> >> > >
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> > 
> -
> >>
> >> >> >
> >>
> >> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>
> >> >> >
> >>
> >> >> > For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> >
> >>
> >> >> > --
> >>
> >> >> Sent from my phone
> >>
> >>
> >>
> >> -
> >>
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
> >>
> >> --
> > Sent from my phone
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

Re: Maven 3.4.0 Release

[Robert Scholte]

+100

On Mon, 19 Dec 2016 20:12:33 +0100, Stephen Connolly  
 wrote:



We need to get the project back in the habit of releasing.

My vote is the we rebuild master with a clean history. keep current  
master

as a reference branch, and cherry-pick as we go.

The aim should be kept tight in scope and focus on the aether replacement
only. Minimum change for aether replacement.

Then we can start bringing in bug fixes.

If we need to break things, we can go 3.6.x or 4.x.y I only request that
5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
(which is what my proposals are aiming to help us flesh out... though my
proposals may not be selected by committers in the end, hopefully they  
will

allow us to have a reasoned debate)

Wdyt?

On Mon 19 Dec 2016 at 17:41, Robert Scholte  wrote:


We're already trying to push a new release for quite some time. And it

seems the discussion is not over yet.

There are a lot of improvements which deserve a release, so personally  
I'd


like to push the discussion to 3.5.0



Robert



On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll

 wrote:



> Isn't that postponing the discussion we're having here on those

> controversial changes? I'd rather give it an extra effort rather than

> pushing it back and loosing all the context once we have to tackle  
3.5.


>

> On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <

> stephen.alan.conno...@gmail.com> wrote:

>

>> I like that plan, but let's call that 3.4.0 and let these other  
changes


>> go

>> for either 3.5.0

>>

>> Does someone want to take a stab at forking master from an earlier  
point


>> (perhaps get infra to let us rewrite master back to the fork point  
and


>> push

>> the current state to a branch?)

>>

>> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko 
wrote:

>>

>> > No, I meant just eclipse->apache move, not all changes that went  
into


>> >

>> > maven-resolver. The idea is to have a release branch we can  
maintain


>> >

>> > while things stabilize in master.

>> >

>> >

>> >

>> > --

>> >

>> > Regards,

>> >

>> > Igor

>> >

>> >

>> >

>> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:

>> >

>> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:

>> >

>> > > > I wonder if it makes sense to release 3.3.10 with just the new

>> aether

>> >

>> > > > and give 3.4 more time to bake on master.

>> >

>> > >

>> >

>> > > Changing a dependency with so many changes recently in a fix

>> version?

>> >

>> > > Doesn't sound right to me.

>> >

>> > >

>> >

>> > > M

>> >

>> > >

>> >

>> > >

>> >

>> > >

>> -

>> >

>> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

>> >

>> > > For additional commands, e-mail: dev-h...@maven.apache.org

>> >

>> > >

>> >

>> >

>> >

>> >  
-


>> >

>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

>> >

>> > For additional commands, e-mail: dev-h...@maven.apache.org

>> >

>> >

>> >

>> > --

>> Sent from my phone



-

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

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



--

Sent from my phone


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

Re: Scope promotion of managed dependencies in current Maven master

[Guillaume Boué]

Hi Michael,

I can reproduce that behaviour as well. In the current 3.4.0, a 
dependency management that declares a dependency with scope runtime will 
manage a transitive dependency of scope test. A reproducer is


  

  
org.slf4j
slf4j-simple
1.7.21
runtime
  

  
  

  test
  test
  1.0-SNAPSHOT

  

And having in the POM of test:

  

  org.slf4j
  slf4j-simple
  1.7.21
  test

  

This doesn't feel right to me: dependencies of scope test are not 
transitive, so the test scoped slf4j-simple shouldn't be considered 
during dependency resolution. I wouldn't also expect the 
dependencyManagement to change the scope of the inherited slf4j-simple 
(if it were to be inherited), since there are definite rules about which 
scope a transitive dependency should have depending on the scope of the 
declared dependency (summarized in the table here 
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope).


Guillaume

Le 19/12/2016 à 15:56, Michael Osipov a écrit :

Hi folks,

I just tried a fresh Maven master (7d1d8ac0c14bdea6c92356436bfc6f8548cbae8b; 
2016-12-19T15:22:22+01:00)
on an in-house project.

My project's parent POM states in depMgmt:


   org.slf4j
   slf4j-api
   ${slf4j.version}


   org.slf4j
   jcl-over-slf4j
   ${slf4j.version}
   runtime


   org.slf4j
   slf4j-simple
   ${slf4j.version}
   runtime


nothing special so far, a WAR module dependends on 
net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile
which has slf4j-simple in *test* scope. mvn dependency:tree with 3.3.9 properly 
gives me:

[DEBUG]net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile

Doing this with master gives me:

[DEBUG]net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile
[DEBUG]   org.slf4j:slf4j-simple:jar:1.7.21:runtime (scope managed from 
test by com.company.project:project-parent:0.11-SNAPSHOT)

My questions are:
1. Is this another fix in master where I relied on an erratic behavior in core 
previously?
2. Should depMgmthave influence on transitive deps or direct only?

I cannot really say what's right or wrong but now I have two SLF4J bindings on 
my WAR classpath:
SLF4J Simple and Logback, now that is obviously wrong!

Any thoughts?

Michael

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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: Maven 3.4.0 Release

[Manfred Moser]

Totally agree. Master should be ready to release all the time imho. Nothing 
that isnt tested well and proven to at least pass all IT's should be merged 
into master. Experimentation should happen in feature branches.. 

Just my 2c. 

Manfred

Stephen Connolly wrote on 2016-12-19 11:12:

> We need to get the project back in the habit of releasing.
> 
> My vote is the we rebuild master with a clean history. keep current master
> as a reference branch, and cherry-pick as we go.
> 
> The aim should be kept tight in scope and focus on the aether replacement
> only. Minimum change for aether replacement.
> 
> Then we can start bringing in bug fixes.
> 
> If we need to break things, we can go 3.6.x or 4.x.y I only request that
> 5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
> (which is what my proposals are aiming to help us flesh out... though my
> proposals may not be selected by committers in the end, hopefully they will
> allow us to have a reasoned debate)
> 
> Wdyt?
> 
> On Mon 19 Dec 2016 at 17:41, Robert Scholte  wrote:
> 
>> We're already trying to push a new release for quite some time. And it
>>
>> seems the discussion is not over yet.
>>
>> There are a lot of improvements which deserve a release, so personally I'd
>>
>> like to push the discussion to 3.5.0
>>
>>
>>
>> Robert
>>
>>
>>
>> On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
>>
>>  wrote:
>>
>>
>>
>> > Isn't that postponing the discussion we're having here on those
>>
>> > controversial changes? I'd rather give it an extra effort rather than
>>
>> > pushing it back and loosing all the context once we have to tackle 3.5.
>>
>> >
>>
>> > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
>>
>> > stephen.alan.conno...@gmail.com> wrote:
>>
>> >
>>
>> >> I like that plan, but let's call that 3.4.0 and let these other changes
>>
>> >> go
>>
>> >> for either 3.5.0
>>
>> >>
>>
>> >> Does someone want to take a stab at forking master from an earlier point
>>
>> >> (perhaps get infra to let us rewrite master back to the fork point and
>>
>> >> push
>>
>> >> the current state to a branch?)
>>
>> >>
>>
>> >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko 
>> wrote:
>>
>> >>
>>
>> >> > No, I meant just eclipse->apache move, not all changes that went into
>>
>> >> >
>>
>> >> > maven-resolver. The idea is to have a release branch we can maintain
>>
>> >> >
>>
>> >> > while things stabilize in master.
>>
>> >> >
>>
>> >> >
>>
>> >> >
>>
>> >> > --
>>
>> >> >
>>
>> >> > Regards,
>>
>> >> >
>>
>> >> > Igor
>>
>> >> >
>>
>> >> >
>>
>> >> >
>>
>> >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
>>
>> >> >
>>
>> >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
>>
>> >> >
>>
>> >> > > > I wonder if it makes sense to release 3.3.10 with just the new
>>
>> >> aether
>>
>> >> >
>>
>> >> > > > and give 3.4 more time to bake on master.
>>
>> >> >
>>
>> >> > >
>>
>> >> >
>>
>> >> > > Changing a dependency with so many changes recently in a fix
>>
>> >> version?
>>
>> >> >
>>
>> >> > > Doesn't sound right to me.
>>
>> >> >
>>
>> >> > >
>>
>> >> >
>>
>> >> > > M
>>
>> >> >
>>
>> >> > >
>>
>> >> >
>>
>> >> > >
>>
>> >> >
>>
>> >> > >
>>
>> >> -
>>
>> >> >
>>
>> >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>
>> >> >
>>
>> >> > > For additional commands, e-mail: dev-h...@maven.apache.org
>>
>> >> >
>>
>> >> > >
>>
>> >> >
>>
>> >> >
>>
>> >> >
>>
>> >> > -
>>
>> >> >
>>
>> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>
>> >> >
>>
>> >> > For additional commands, e-mail: dev-h...@maven.apache.org
>>
>> >> >
>>
>> >> >
>>
>> >> >
>>
>> >> > --
>>
>> >> Sent from my phone
>>
>>
>>
>> -
>>
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>>
>> --
> Sent from my phone
> 


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

Re: Maven 3.4.0 Release

[Gary Gregory]

On Mon, Dec 19, 2016 at 11:12 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> We need to get the project back in the habit of releasing.
>

+1!

Gary


>
> My vote is the we rebuild master with a clean history. keep current master
> as a reference branch, and cherry-pick as we go.
>
> The aim should be kept tight in scope and focus on the aether replacement
> only. Minimum change for aether replacement.
>
> Then we can start bringing in bug fixes.
>
> If we need to break things, we can go 3.6.x or 4.x.y I only request that
> 5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
> (which is what my proposals are aiming to help us flesh out... though my
> proposals may not be selected by committers in the end, hopefully they will
> allow us to have a reasoned debate)
>
> Wdyt?
>
> On Mon 19 Dec 2016 at 17:41, Robert Scholte  wrote:
>
> > We're already trying to push a new release for quite some time. And it
> >
> > seems the discussion is not over yet.
> >
> > There are a lot of improvements which deserve a release, so personally
> I'd
> >
> > like to push the discussion to 3.5.0
> >
> >
> >
> > Robert
> >
> >
> >
> > On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
> >
> >  wrote:
> >
> >
> >
> > > Isn't that postponing the discussion we're having here on those
> >
> > > controversial changes? I'd rather give it an extra effort rather than
> >
> > > pushing it back and loosing all the context once we have to tackle 3.5.
> >
> > >
> >
> > > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
> >
> > > stephen.alan.conno...@gmail.com> wrote:
> >
> > >
> >
> > >> I like that plan, but let's call that 3.4.0 and let these other
> changes
> >
> > >> go
> >
> > >> for either 3.5.0
> >
> > >>
> >
> > >> Does someone want to take a stab at forking master from an earlier
> point
> >
> > >> (perhaps get infra to let us rewrite master back to the fork point and
> >
> > >> push
> >
> > >> the current state to a branch?)
> >
> > >>
> >
> > >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko 
> > wrote:
> >
> > >>
> >
> > >> > No, I meant just eclipse->apache move, not all changes that went
> into
> >
> > >> >
> >
> > >> > maven-resolver. The idea is to have a release branch we can maintain
> >
> > >> >
> >
> > >> > while things stabilize in master.
> >
> > >> >
> >
> > >> >
> >
> > >> >
> >
> > >> > --
> >
> > >> >
> >
> > >> > Regards,
> >
> > >> >
> >
> > >> > Igor
> >
> > >> >
> >
> > >> >
> >
> > >> >
> >
> > >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
> >
> > >> >
> >
> > >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
> >
> > >> >
> >
> > >> > > > I wonder if it makes sense to release 3.3.10 with just the new
> >
> > >> aether
> >
> > >> >
> >
> > >> > > > and give 3.4 more time to bake on master.
> >
> > >> >
> >
> > >> > >
> >
> > >> >
> >
> > >> > > Changing a dependency with so many changes recently in a fix
> >
> > >> version?
> >
> > >> >
> >
> > >> > > Doesn't sound right to me.
> >
> > >> >
> >
> > >> > >
> >
> > >> >
> >
> > >> > > M
> >
> > >> >
> >
> > >> > >
> >
> > >> >
> >
> > >> > >
> >
> > >> >
> >
> > >> > >
> >
> > >> -
> >
> > >> >
> >
> > >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >
> > >> >
> >
> > >> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > >> >
> >
> > >> > >
> >
> > >> >
> >
> > >> >
> >
> > >> >
> >
> > >> > 
> -
> >
> > >> >
> >
> > >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >
> > >> >
> >
> > >> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > >> >
> >
> > >> >
> >
> > >> >
> >
> > >> > --
> >
> > >> Sent from my phone
> >
> >
> >
> > -
> >
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> >
> > --
> Sent from my phone
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: 

Re: Maven 3.4.0 Release

[Stephen Connolly]

We need to get the project back in the habit of releasing.

My vote is the we rebuild master with a clean history. keep current master
as a reference branch, and cherry-pick as we go.

The aim should be kept tight in scope and focus on the aether replacement
only. Minimum change for aether replacement.

Then we can start bringing in bug fixes.

If we need to break things, we can go 3.6.x or 4.x.y I only request that
5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom
(which is what my proposals are aiming to help us flesh out... though my
proposals may not be selected by committers in the end, hopefully they will
allow us to have a reasoned debate)

Wdyt?

On Mon 19 Dec 2016 at 17:41, Robert Scholte  wrote:

> We're already trying to push a new release for quite some time. And it
>
> seems the discussion is not over yet.
>
> There are a lot of improvements which deserve a release, so personally I'd
>
> like to push the discussion to 3.5.0
>
>
>
> Robert
>
>
>
> On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll
>
>  wrote:
>
>
>
> > Isn't that postponing the discussion we're having here on those
>
> > controversial changes? I'd rather give it an extra effort rather than
>
> > pushing it back and loosing all the context once we have to tackle 3.5.
>
> >
>
> > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
>
> > stephen.alan.conno...@gmail.com> wrote:
>
> >
>
> >> I like that plan, but let's call that 3.4.0 and let these other changes
>
> >> go
>
> >> for either 3.5.0
>
> >>
>
> >> Does someone want to take a stab at forking master from an earlier point
>
> >> (perhaps get infra to let us rewrite master back to the fork point and
>
> >> push
>
> >> the current state to a branch?)
>
> >>
>
> >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko 
> wrote:
>
> >>
>
> >> > No, I meant just eclipse->apache move, not all changes that went into
>
> >> >
>
> >> > maven-resolver. The idea is to have a release branch we can maintain
>
> >> >
>
> >> > while things stabilize in master.
>
> >> >
>
> >> >
>
> >> >
>
> >> > --
>
> >> >
>
> >> > Regards,
>
> >> >
>
> >> > Igor
>
> >> >
>
> >> >
>
> >> >
>
> >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
>
> >> >
>
> >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
>
> >> >
>
> >> > > > I wonder if it makes sense to release 3.3.10 with just the new
>
> >> aether
>
> >> >
>
> >> > > > and give 3.4 more time to bake on master.
>
> >> >
>
> >> > >
>
> >> >
>
> >> > > Changing a dependency with so many changes recently in a fix
>
> >> version?
>
> >> >
>
> >> > > Doesn't sound right to me.
>
> >> >
>
> >> > >
>
> >> >
>
> >> > > M
>
> >> >
>
> >> > >
>
> >> >
>
> >> > >
>
> >> >
>
> >> > >
>
> >> -
>
> >> >
>
> >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> >> >
>
> >> > > For additional commands, e-mail: dev-h...@maven.apache.org
>
> >> >
>
> >> > >
>
> >> >
>
> >> >
>
> >> >
>
> >> > -
>
> >> >
>
> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> >> >
>
> >> > For additional commands, e-mail: dev-h...@maven.apache.org
>
> >> >
>
> >> >
>
> >> >
>
> >> > --
>
> >> Sent from my phone
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

Re: Maven 3.4.0 Release

[Robert Scholte]

We're already trying to push a new release for quite some time. And it  
seems the discussion is not over yet.
There are a lot of improvements which deserve a release, so personally I'd  
like to push the discussion to 3.5.0


Robert

On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll  
 wrote:



Isn't that postponing the discussion we're having here on those
controversial changes? I'd rather give it an extra effort rather than
pushing it back and loosing all the context once we have to tackle 3.5.

On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

I like that plan, but let's call that 3.4.0 and let these other changes  
go

for either 3.5.0

Does someone want to take a stab at forking master from an earlier point
(perhaps get infra to let us rewrite master back to the fork point and  
push

the current state to a branch?)

On Sun 18 Dec 2016 at 19:45, Igor Fedorenko  wrote:

> No, I meant just eclipse->apache move, not all changes that went into
>
> maven-resolver. The idea is to have a release branch we can maintain
>
> while things stabilize in master.
>
>
>
> --
>
> Regards,
>
> Igor
>
>
>
> On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
>
> > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
>
> > > I wonder if it makes sense to release 3.3.10 with just the new  
aether

>
> > > and give 3.4 more time to bake on master.
>
> >
>
> > Changing a dependency with so many changes recently in a fix  
version?

>
> > Doesn't sound right to me.
>
> >
>
> > M
>
> >
>
> >
>
> >  
-

>
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
> >
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone


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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Stephen Connolly]

We need to clarify.

There is stuff that is "wrong" but has become expected behaviour because we
never "fixed" it => we cannot "fix" now because it will break too many users

There is stuff that is "wrong" because we broke it, some users have
legitimate bugs and other users have hacks around the "wrong" => we will
break something no matter what we do, so maybe we can "fix"

There is stuff that is "wrong" because it was never specified and we'd now
like it to work one way because that way feels "right"

Etc

What class of problem is this?

To my mind, depMgmt should never alter the scope of a dependency... if you
specify a scope you are saying apply the rest when it is added with this
scope.

But that is my "how I would like it to work"...

Christian, you need to identify which kind of "wrong" behaviour is going on
here... then we can reframe the debate and find a path forward

- Stephen

On Sun 18 Dec 2016 at 23:52, Christian Schulte  wrote:

> Am 12/18/16 um 13:36 schrieb Robert Scholte:
>
> > On Fri, 16 Dec 2016 21:23:14 +0100, Christian Schulte 
>
> > wrote:
>
> >
>
> >> Am 12/16/16 um 20:30 schrieb Robert Scholte:
>
> >>> On Fri, 16 Dec 2016 17:25:16 +0100, Christian Schulte 
>
> >>> wrote:
>
> >>>
>
>  Am 12/16/16 um 15:21 schrieb Robert Scholte:
>
> >
>
> > but this cover the issue we are talking about, because IIUC you are
>
> > saying
>
> > that IF both junit and hamcrest get the test-scope AND hamcrest would
>
> > have
>
> > a dependency THEN that dependency is not added to the classpath. That
>
> > is
>
> > still unexpected behavior.
>
> 
>
>  Just add 'test' scope to the hamcrest dependency in that pom. It will
>
>  disappear from the classpath. I would expect that to happen. Why
> should
>
>  it manage the version but not the scope?
>
> 
>
> >>>
>
> >>> Because Junit refers to hamcrest classes, so they are required to be
>
> >>> able
>
> >>> to compile.
>
> >>> There is an issue about this, that Maven should never reduce the scope.
>
> >>
>
> >> It's not Maven reducing any scope, it's the user telling Maven to do
>
> >> that. The user is the dependency manager, not Maven.
>
> >>
>
> >
>
> > No, no, no. Dependency management may never make dependencies disappear,
>
> > no matter the scope specified. If a user doesn't want a dependency, it
>
> > must use dependency.excludes.
>
>
>
> Managing the scope of a dependency to 'test' Maven must behave the same
>
> way as if the dependency had been declared 'test' directly in the POM.
>
> That's the point. That's what dependency management is used for. Manage
>
> dependencies not in your control (global override to what is in the POM
>
> during resolution).
>
>
>
>
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

Can I get some other measures of the ITs?

[Stephen Connolly]

https://builds.apache.org/view/M-R/view/Maven/job/maven-jenkinsfile/job/master/26/testReport/
Is currently the best I have... and with 1084 failing tests it is *not*
good... anyone else have a measure?

Package

Duration

Fail

(diff)

Skip

(diff)

Pass

(diff)

Total

(diff)

org.apache.maven.it

1
hr 5 min 1084 0 516 1600
org.apache.maven.its.mng5640

8
ms 2 0 0 2
org.apache.maven.plugin.coreit

69
ms 0 0 22 22

Scope promotion of managed dependencies in current Maven master

[Michael Osipov]

Hi folks,

I just tried a fresh Maven master (7d1d8ac0c14bdea6c92356436bfc6f8548cbae8b; 
2016-12-19T15:22:22+01:00)
on an in-house project.

My project's parent POM states in depMgmt:


  org.slf4j
  slf4j-api
  ${slf4j.version}


  org.slf4j
  jcl-over-slf4j
  ${slf4j.version}
  runtime


  org.slf4j
  slf4j-simple
  ${slf4j.version}
  runtime


nothing special so far, a WAR module dependends on 
net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile
which has slf4j-simple in *test* scope. mvn dependency:tree with 3.3.9 properly 
gives me:

[DEBUG]net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile

Doing this with master gives me:

[DEBUG]net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile
[DEBUG]   org.slf4j:slf4j-simple:jar:1.7.21:runtime (scope managed from 
test by com.company.project:project-parent:0.11-SNAPSHOT)

My questions are:
1. Is this another fix in master where I relied on an erratic behavior in core 
previously?
2. Should depMgmthave influence on transitive deps or direct only?

I cannot really say what's right or wrong but now I have two SLF4J bindings on 
my WAR classpath:
SLF4J Simple and Logback, now that is obviously wrong!

Any thoughts?

Michael

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

Re: Improving Jenkins

[Stephen Connolly]

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  wrote:

> For windows? Am I punished ?
>
>
>
> Bouhhh
>
>
>
> Le lun. 19 déc. 2016 à 15:17, Stephen Connolly <
>
> stephen.alan.conno...@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.conno...@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  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 

Re: Improving Jenkins

[Arnaud Héritier]

For windows? Am I punished ?

Bouhhh

Le lun. 19 déc. 2016 à 15:17, Stephen Connolly <
stephen.alan.conno...@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.conno...@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  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 

Re: Improving Jenkins

[Stephen Connolly]

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.conno...@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  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-unsubscr...@maven.apache.org
>>
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>>
>> --
> Sent from my phone
>

Re: Maven 3.4.0 Release

[Stephane Nicoll]

Isn't that postponing the discussion we're having here on those
controversial changes? I'd rather give it an extra effort rather than
pushing it back and loosing all the context once we have to tackle 3.5.

On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I like that plan, but let's call that 3.4.0 and let these other changes go
> for either 3.5.0
>
> Does someone want to take a stab at forking master from an earlier point
> (perhaps get infra to let us rewrite master back to the fork point and push
> the current state to a branch?)
>
> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko  wrote:
>
> > No, I meant just eclipse->apache move, not all changes that went into
> >
> > maven-resolver. The idea is to have a release branch we can maintain
> >
> > while things stabilize in master.
> >
> >
> >
> > --
> >
> > Regards,
> >
> > Igor
> >
> >
> >
> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
> >
> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
> >
> > > > I wonder if it makes sense to release 3.3.10 with just the new aether
> >
> > > > and give 3.4 more time to bake on master.
> >
> > >
> >
> > > Changing a dependency with so many changes recently in a fix version?
> >
> > > Doesn't sound right to me.
> >
> > >
> >
> > > M
> >
> > >
> >
> > >
> >
> > > -
> >
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > >
> >
> >
> >
> > -
> >
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> >
> > --
> Sent from my phone
>

Re: IPv6

[Stian Soiland-Reyes]

I would hope that IPv6  records would be recognized from DNS.

Another question is using RFC2732 style host URLs like
http://[1080::8:800:200C:417A]/foo

https://www.ietf.org/rfc/rfc2732.txt


One tiny isuse for a pure IPv6 deployment is that Maven Central don't
seem to be available on IPv6. However IPv6 users will usually have
access to a IPv4 translating gateway.


On 18 December 2016 at 18:06, Michael Osipov  wrote:
> Am 2016-12-18 um 18:53 schrieb Robert Scholte:
>>
>> Hi,
>>
>> I got this question during Devoxx: is Maven IPv6 ready?
>> My guess is that this is something for Wagon to confirm.
>> How can we test it?
>
>
> Shall we really answer that question? For all transports, we are using
> third-party components and finally the IPv6 capablitiies of Java itself. We
> probably won't be able to answer this properly anyway.
> Additionally, we aren't jusing using Wagon with HttpClient but Java
> URLConnection at several spots.
>
> Michael
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: Improving Jenkins

[Stephen Connolly]

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  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-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

Re: Re: Improving Jenkins

[Michael Osipov]

> > 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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org