[VOTE] Releasing Wagon 2.11

[Dan Tran]

Hi,

We have fixed 18 issues:
*https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122=1296
*

There are still issues left in JIRA:
*https://issues.apache.org/jira/issues/?jql=project%20%3D%20WAGON%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20DESC%2C%20priority%20DESC
*

Staging repository:
https://repository.apache.org/content/repositories/maven-1313
https://repository.apache.org/content/repositories/maven-
1313/org/apache/maven/wagon/wagon/2.11/wagon-2.11-source-release.zip

Source release checksum(s):
wagon-2.11-source-release.zip sha1: 98bc0b031880b175e144c55447a62000c58abfa5

Staging site:
*http://maven.apache.org/components/wagon-archives/wagon-LATEST/
*

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72H + 48H to accomodate for holidays

[+1]
[0]
[-1]

Thanks,

The Maven Team

[GitHub] maven-wagon issue #27: Support external downloader for downloading files

[soiff]

Github user soiff commented on the issue:

https://github.com/apache/maven-wagon/pull/27
  
Actually, `axel` is based on `c` programing language and do really failfast 
I think. Of course this is not a problem that always happen, which means it 
would be narrowly needed. After all, improving the default provider should be 
the more acceptible way. So I'm going to close this comment and post any 
sugestion if I encountered such problems again. Thanks for your attention!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] maven-wagon pull request #27: Support external downloader for downloading fi...

[soiff]

Github user soiff closed the pull request at:

https://github.com/apache/maven-wagon/pull/27


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] maven-surefire pull request #137: Fix SUREFIRE-1239

[jsdima]

GitHub user jsdima opened a pull request:

https://github.com/apache/maven-surefire/pull/137

Fix SUREFIRE-1239

Project to reproduce - https://github.com/jsdima/SUREFIRE-1239-reproduce

More info:
Problem appears when there are a lot of console output after last 
test(which leads to save this output to file) in TestSet, and in the next 
TestSet some test fails. It happens because stream 
(`Utf8RecodingDeferredFileOutputStream testStdOut`)  which collects data after 
test execution but before TestSet finished  then also used in next TestSet.

Sometimes it leads to 
```
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on 
project SUREFIRE-1239-reproduce: Execution default-test of goal 
org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: 
java.lang.RuntimeException: org.apache.maven.surefire.report.ReporterException: 
When writing xml report stdout/stderr: /tmp/stdout8948920314382993444deferred 
(No such file or directory) -> [Help 1]
```

sometimes build just hangs

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jsdima/maven-surefire master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-surefire/pull/137.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #137


commit 768bd3c1bc0894269b6f6819eb643ea328d08c42
Author: dg 
Date:   2016-12-23T11:14:17Z

Fix SUREFIRE-1239




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] maven-wagon issue #27: Support external downloader for downloading files

[michael-o]

Github user michael-o commented on the issue:

https://github.com/apache/maven-wagon/pull/27
  
I do agree, but still think that we can tweak Wagon HTTP to fail faster if 
such a case happens. Your proxy is likely to use Apache HttpClient, just like 
Wagon does. You could still suffer from the same problems. I really would like 
to see this flexibility in a well-established provider which is the default, 
rather than people having to declare and configure a new one.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [HEADS UP] Releasing maven-wagon-2.11

[Michael Osipov]

Am 2016-12-23 um 07:26 schrieb Dan Tran:

I am seeing this at my local build

testConnectNullRepository(org.apache.maven.wagon.AbstractWagonTest)
Time elapsed: 0.017 sec  <<< ERROR!
java.lang.NullPointerException: repository cannot be null
at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:181)
at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:134)
at 
org.apache.maven.wagon.AbstractWagonTest.testConnectNullRepository(AbstractWagonTest.java:514)



must have something to do with

   1. [WAGON-473] Don't abuse IllegalArgumentException to intercept null
   input — michaelo  / detail
   



Issue is fixed. Seems like that was on oversight, I haven't noticed the 
Jenkins failures for some reasons.


Michael



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

Re: [HEADS UP] Releasing maven-wagon-2.11

[Michael Osipov]

Am 2016-12-23 um 07:26 schrieb Dan Tran:

I am seeing this at my local build

testConnectNullRepository(org.apache.maven.wagon.AbstractWagonTest)
Time elapsed: 0.017 sec  <<< ERROR!
java.lang.NullPointerException: repository cannot be null
at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:181)
at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:134)
at 
org.apache.maven.wagon.AbstractWagonTest.testConnectNullRepository(AbstractWagonTest.java:514)



must have something to do with

   1. [WAGON-473] Don't abuse IllegalArgumentException to intercept null
   input — michaelo  / detail
   



I will have a look. Really weird, I ran all ITs several times. Thanks 
for testing!


Michael



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

Re: Roadmap to the next Maven release (Re: Improving Jenkins)

[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

On 23 December 2016 at 08:32, Christian Schulte  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.
>
>  7954b94eff5c6b0524e7fe26d8f114b3c5450b86>
>
> This is nothing different to the resolver bugfix. The changes in core
> were made to make collections returned by getters in maven 

Re: Roadmap to the next Maven release (Re: Improving Jenkins)

[Christian Schulte]

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].



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 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 "").
> 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-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: Roadmap to the next Maven release (Re: Improving Jenkins)

[Christian Schulte]

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.



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