Re: Releasing Wagon

so much stuff for a release, but we will help users > on GitHub Actions (and many Apache projects that are migrating to GH > Actions) > > I can make the release, but before starting the process I would like to see > the opinion for the community ? > > It would be great to have a

Releasing Wagon

starting the process I would like to see the opinion for the community ? It would be great to have a Maven Core release as well after releasing Wagon (otherwise upgrading Wagon will be nasty), but this out of the scope of this thread Shall I proceed with the release ? Enrico

Re: [VOTE] Releasing Wagon 2.11 - Cancel

net> wrote: If so, I would drop 2.11 altogether and go with 2.12. Gesendet: Mittwoch, 04. Januar 2017 um 08:47 Uhr Von: "Hervé BOUTEMY" An: "Maven Developers List" Betreff: Re: [VOTE] Releasing Wagon 2.11 - Cancel on git, AFAIK, going to 2.11.1 seems the best practice (rem

Re: Re: [VOTE] Releasing Wagon 2.11 - Cancel

Y" > > An: "Maven Developers List" > > Betreff: Re: [VOTE] Releasing Wagon 2.11 - Cancel > > > > on git, AFAIK, going to 2.11.1 seems the best practice (removing tag in > origin > > repo is not reliable given people who have copied it won't have

Re: Re: [VOTE] Releasing Wagon 2.11 - Cancel

If so, I would drop 2.11 altogether and go with 2.12. > Gesendet: Mittwoch, 04. Januar 2017 um 08:47 Uhr > Von: "Hervé BOUTEMY" > An: "Maven Developers List" > Betreff: Re: [VOTE] Releasing Wagon 2.11 - Cancel > > on git, AFAIK, going to 2.11.1 seems the be

Re: [VOTE] Releasing Wagon 2.11 - Cancel

on git, AFAIK, going to 2.11.1 seems the best practice (removing tag in origin repo is not reliable given people who have copied it won't have it removed automatically) Regards, Hervé Le mardi 3 janvier 2017, 18:59:15 CET Dan Tran a écrit : > I reverted the poms back to 2.11-SNAPSHOT not keep

Re: [VOTE] Releasing Wagon 2.11 - Cancel

Am 2017-01-04 um 03:59 schrieb Dan Tran: I reverted the poms back to 2.11-SNAPSHOT not keep the tag for now since some ppl may object removing remote history. so we can keep the tag and move to 2.11.1-SNAPSHOT or remove wagon-2.11 tag and move on I'd drop 2.11 altogether and re-run 2.11. I hav

Re: [VOTE] Releasing Wagon 2.11 - Cancel

I reverted the poms back to 2.11-SNAPSHOT not keep the tag for now since some ppl may object removing remote history. so we can keep the tag and move to 2.11.1-SNAPSHOT or remove wagon-2.11 tag and move on -Dan On Tue, Jan 3, 2017 at 6:08 PM, Dan Tran wrote: > yes I can. so it is ok to remove

Re: [VOTE] Releasing Wagon 2.11 - Cancel

yes I can. so it is ok to remove the tag? -D On Tue, Jan 3, 2017 at 2:01 PM, Michael Osipov wrote: > Am 2016-12-28 um 19:46 schrieb Dan Tran: > >> Hi >> >> I am going to cancel this vote due to inconsistent test failure at >> wagon-http provider on huge download test. >> > > Can you please rol

Re: [VOTE] Releasing Wagon 2.11 - Cancel

Am 2016-12-28 um 19:46 schrieb Dan Tran: Hi I am going to cancel this vote due to inconsistent test failure at wagon-http provider on huge download test. Can you please rollback release commits in the repo? Michael On Wed, Dec 28, 2016 at 7:08 AM, Michael Osipov wrote: Am 2016-12-28 um 0

Re: [VOTE] Releasing Wagon 2.11

I have made some concluding tests on my machine at work because my home machine is so fast that you don't see a difference if you change something. My tests are two-fold: improve HugeFileDownloadTest and manually reconstruct with pure Jetty and HttpClient (same versions). First of all sparse fi

Re: [VOTE] Releasing Wagon 2.11

Thanks for the analysis! Agree with dropping fsutil then; I committed the addition of the logs with it just so that we can have concrete numbers for comparison (the last build indicates there was no permission issues in using it, otherwise it wouldn't have timed out but just failed to find the

Re: [VOTE] Releasing Wagon 2.11

Am 2016-12-31 um 12:13 schrieb Guillaume Boué: Do you think I can add a dummy log before the creation of the test file (and add the timestamps to the logs of wagon-http), to see how much time it takes on the Windows Server 2012? I'd like to see the breakdown of what takes time on the Jenkins mach

Re: [VOTE] Releasing Wagon 2.11

Do you think I can add a dummy log before the creation of the test file (and add the timestamps to the logs of wagon-http), to see how much time it takes on the Windows Server 2012? I'd like to see the breakdown of what takes time on the Jenkins machine, perhaps there is nothing we can do bette

Re: [VOTE] Releasing Wagon 2.11

I just pushed another commit to the branch with your changes. The job does not really work on Windows [1], it simply takes too long to complete on the Windows Server 2012. [1] https://builds.apache.org/job/maven-wagon-jetty8-windows/2/org.apache.maven.wagon$wagon-http/console Am 2016-12-29 u

Re: [VOTE] Releasing Wagon 2.11

I have tested that code and read a bit about sparse files. Tests first: I had on average 65 s on Windows 10, it is down now to 50 to 55 seconds. The huge problem is that we cannot use @BeforeClass to create the file once because JUnit pre-annotations does not support hat. To the sparse stuff: a

Re: [VOTE] Releasing Wagon 2.11

Am 12/28/16 um 22:50 schrieb Robert Scholte: > "That's always been that way." > Well, apparently not. Maybe it was documented that way, but I expect that > users did their dependency management which felt natural and which worked. I created an issue in JIRA to track this:

Re: [VOTE] Releasing Wagon 2.11

I have a Toshiba SSHD (MQ02ABD100H). I think the issue is that the Java code should create a sparse file to have things faster. Using setLength on a random access file probably does it depending on the OS and type of drive, but it isn't creating one in my situation. When run on Ubuntu, creatin

Re: [VOTE] Releasing Wagon 2.11

Am 2016-12-29 um 12:24 schrieb Guillaume Boué: I ran them at least 10 times, and there was the timeout issue each time. Yes, the timeout is Surefire waiting for the forked VM. I applied the patch (I had done similar tries also) but I still have the issue on Windows 10. You'll find the logs attac

Re: [VOTE] Releasing Wagon 2.11

I ran them at least 10 times, and there was the timeout issue each time. Yes, the timeout is Surefire waiting for the forked VM. I applied the patch (I had done similar tries also) but I still have the issue on Windows 10. You'll find the logs attached. It seems that the download is really ad

Re: [VOTE] Releasing Wagon 2.11

>> Right now I see Wagon as a reference project for Maven 3.4.0: I disagree. It relies on overriding management althought that correctly is not supported when consumed. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

Re: [VOTE] Releasing Wagon 2.11

Am 12/29/16 um 03:19 schrieb Christian Schulte: > Am 12/29/16 um 02:41 schrieb Christian Schulte: >> Am 12/29/16 um 02:36 schrieb Christian Schulte: >>> Am 12/29/16 um 00:41 schrieb Michael Osipov: If this is how it should (I am neither pro nor cons) work, we should deprecate this elemen

Re: [VOTE] Releasing Wagon 2.11

Am 12/29/16 um 02:41 schrieb Christian Schulte: > Am 12/29/16 um 02:36 schrieb Christian Schulte: >> Am 12/29/16 um 00:41 schrieb Michael Osipov: >>> If this is how it should (I am neither pro nor cons) work, we should >>> deprecate this element or at least put a big WARNING on it. >> >> We should

Re: [VOTE] Releasing Wagon 2.11

Am 12/29/16 um 02:36 schrieb Christian Schulte: > Am 12/29/16 um 00:41 schrieb Michael Osipov: >> If this is how it should (I am neither pro nor cons) work, we should >> deprecate this element or at least put a big WARNING on it. > > We should spit out a big fat warning whenever someone overrides

Re: [VOTE] Releasing Wagon 2.11

Am 12/29/16 um 00:41 schrieb Michael Osipov: > If this is how it should (I am neither pro nor cons) work, we should > deprecate this element or at least put a big WARNING on it. We should spit out a big fat warning whenever someone overrides hers/his own management. It shouldn't even be possible

Re: [VOTE] Releasing Wagon 2.11

Am 12/29/16 um 02:12 schrieb Christian Schulte: > Am 12/29/16 um 00:41 schrieb Michael Osipov: >> Am 2016-12-28 um 22:51 schrieb Christian Schulte: >>> I just pushed a fix for this. I could also have made that transitive >>> dependency a direct one, where it is used, and could have left the scope >

Re: [VOTE] Releasing Wagon 2.11

Am 12/29/16 um 00:41 schrieb Michael Osipov: > Am 2016-12-28 um 22:51 schrieb Christian Schulte: >> I just pushed a fix for this. I could also have made that transitive >> dependency a direct one, where it is used, and could have left the scope >> management in. >> >> "Dependency management overrid

Re: [VOTE] Releasing Wagon 2.11

Am 2016-12-28 um 21:34 schrieb Guillaume Boué: I have the same results as Hervé, both on Windows and Ubuntu. This is what I have with Maven 3.3.9: - Windows 10 64bit, OpenJDK 1.8.0_102, Test failure: Timeout in HugeFileDownloadTest (perhaps the timeout should be increased?) How often did you r

Re: [VOTE] Releasing Wagon 2.11

Am 2016-12-28 um 22:51 schrieb Christian Schulte: I just pushed a fix for this. I could also have made that transitive dependency a direct one, where it is used, and could have left the scope management in. "Dependency management overrides are not transitive." Just checked this commit. It ulti

Re: [VOTE] Releasing Wagon 2.11

Am 2016-12-28 um 22:50 schrieb Robert Scholte: Which makes me wonder if this really is a fix. Wagon can be built with a wide range of Maven version covering a lot of years AND the maven-dependency-plugin shows what you would expect: junit is available with test-scope. "That's always been that wa

Re: [VOTE] Releasing Wagon 2.11

Am 12/28/16 um 22:21 schrieb Guillaume Boué: > > How come the tests compile fine with Maven 2.2.1, 3.0.5 and 3.3.9 then? > I'd say this is the root cause of nearly all issues we are having a hard time fixing and shipping. It does not make sense to compare some recent behaviour to some former beh

Re: [VOTE] Releasing Wagon 2.11

Am 12/28/16 um 22:21 schrieb Guillaume Boué: > This is the tree with Maven 3.3.9: > > [DEBUG] org.apache.maven.wagon:wagon-file:jar:2.12-SNAPSHOT > [DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.24:compile > [DEBUG]org.slf4j:slf4j-simple:jar:1.7.19:test > [DEBUG] org.slf4j:slf4j-api

Re: [VOTE] Releasing Wagon 2.11

To be even more clear: It's bullshit you can override the management in the POM when those overrides disappear transitively. Do not override management and be done with it. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.o

Re: [VOTE] Releasing Wagon 2.11

Am 12/28/16 um 22:50 schrieb Robert Scholte: > Which makes me wonder if this really is a fix. Wagon can be built with a > wide range of Maven version covering a lot of years AND the > maven-dependency-plugin shows what you would expect: junit is available > with test-scope. > > "That's alway

Re: [VOTE] Releasing Wagon 2.11

Le mercredi 28 décembre 2016, 22:50:52 CET Robert Scholte a écrit : > Which makes me wonder if this really is a fix. Wagon can be built with a > wide range of Maven version covering a lot of years AND the > maven-dependency-plugin shows what you would expect: junit is available > with test-scope. >

Re: [VOTE] Releasing Wagon 2.11

I just pushed a fix for this. I could also have made that transitive dependency a direct one, where it is used, and could have left the scope management in. "Dependency management overrides are not transitive." - To unsubscribe,

Re: [VOTE] Releasing Wagon 2.11

Which makes me wonder if this really is a fix. Wagon can be built with a wide range of Maven version covering a lot of years AND the maven-dependency-plugin shows what you would expect: junit is available with test-scope. "That's always been that way." Well, apparently not. Maybe it was doc

Re: [VOTE] Releasing Wagon 2.11

Am 12/28/16 um 22:21 schrieb Guillaume Boué: > > How come the tests compile fine with Maven 2.2.1, 3.0.5 and 3.3.9 then? Because it does not come with MRESOLVER-9 fixed. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.or

Re: [VOTE] Releasing Wagon 2.11

Le 28/12/2016 à 21:49, Christian Schulte a écrit : Am 12/28/16 um 21:34 schrieb Guillaume Boué: I have the same results as Hervé, both on Windows and Ubuntu. This is what I have with Maven 3.3.9: - Windows 10 64bit, OpenJDK 1.8.0_102, Test failure: Timeout in HugeFileDownloadTest (perhaps the

Re: [VOTE] Releasing Wagon 2.11

Am 12/28/16 um 21:34 schrieb Guillaume Boué: > I have the same results as Hervé, both on Windows and Ubuntu. This is > what I have with Maven 3.3.9: > > - Windows 10 64bit, OpenJDK 1.8.0_102, Test failure: Timeout in > HugeFileDownloadTest (perhaps the timeout should be increased?) > - Ubuntu 16

Re: [VOTE] Releasing Wagon 2.11

I have the same results as Hervé, both on Windows and Ubuntu. This is what I have with Maven 3.3.9: - Windows 10 64bit, OpenJDK 1.8.0_102, Test failure: Timeout in HugeFileDownloadTest (perhaps the timeout should be increased?) - Ubuntu 16.04 32bit, OpenJDK 1.8.0_111, Maven 3.3.9: All OK - Ubu

Re: [VOTE] Releasing Wagon 2.11 - Cancel

Hi I am going to cancel this vote due to inconsistent test failure at wagon-http provider on huge download test. Thanks -Dan On Wed, Dec 28, 2016 at 7:08 AM, Michael Osipov wrote: > Am 2016-12-28 um 06:05 schrieb Dan Tran: > >> i still see the same timeout error on the jetty8 branch. No issue

Re: [VOTE] Releasing Wagon 2.11

Am 2016-12-28 um 06:05 schrieb Dan Tran: i still see the same timeout error on the jetty8 branch. No issue at master [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on project wagon-http: There was a timeout or other error in the fork -> [

Re: [VOTE] Releasing Wagon 2.11

the branch runs without issue on my machine now: mvn: 3.3.9, jdk: Oracle 1.7.0_71, OS: Linux the proposed release was consistently failing on HugeFileDownloadTest Notice that with Maven 3.4.0-SNAPSHOT, there is a compilation failure: testCompile (default-testCompile) on project wagon-file Using

Re: [VOTE] Releasing Wagon 2.11

Am 2016-12-28 um 06:05 schrieb Dan Tran: i still see the same timeout error on the jetty8 branch. No issue at master [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on project wagon-http: There was a timeout or other error in the fork -> [

Re: [VOTE] Releasing Wagon 2.11

i still see the same timeout error on the jetty8 branch. No issue at master [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on project wagon-http: There was a timeout or other error in the fork -> [Help 1]org.apache.maven.lifecycle.Lifecycle

Re: [VOTE] Releasing Wagon 2.11

Hi Dan, Am 2016-12-25 um 19:51 schrieb Dan Tran: Just want to confirm, your FreeBSD and build.apache.org's ubuntu see the same test failure?? Do you think we should cancel the vote and wait for your fix? I was finally able to complete my coding and testings. After several hours of testing a

Re: [VOTE] Releasing Wagon 2.11

Am 2016-12-25 um 19:51 schrieb Dan Tran: Just want to confirm, your FreeBSD and build.apache.org's ubuntu see the same test failure?? As you have already noticed, the branch is up. It is preliminary work, but should be quite complete. The runTestSecuredGet() and friends failures might be du

Re: [VOTE] Releasing Wagon 2.11

Am 2016-12-25 um 19:51 schrieb Dan Tran: Just want to confirm, your FreeBSD and build.apache.org's ubuntu see the same test failure?? Yes, I had always the same two build failures as the Ubuntu box in contrast to Windows. I am currently testing the same code on different JDKs also to see wet

Re: [VOTE] Releasing Wagon 2.11

Just want to confirm, your FreeBSD and build.apache.org's ubuntu see the same test failure?? Do you think we should cancel the vote and wait for your fix? Thanks -Dan On Sun, Dec 25, 2016 at 10:34 AM, Michael Osipov wrote: > Am 2016-12-25 um 18:45 schrieb Dan Tran: > >> Thank Michael >> >>

Re: [VOTE] Releasing Wagon 2.11

Am 2016-12-25 um 18:45 schrieb Dan Tran: Thank Michael * Test failures at windows are intermittent. It is a known issue since the last few versions * No issue at my local redhat 7/java7 build * I am seeing test failures at https://builds.apache.org/view/All/job/maven-wagon/1323/starti

Re: [VOTE] Releasing Wagon 2.11

Thank Michael * Test failures at windows are intermittent. It is a known issue since the last few versions * No issue at my local redhat 7/java7 build * I am seeing test failures at https://builds.apache.org/view/All/job/maven-wagon/1323/starting with your change for WAGON-472. Dont thi

Re: [VOTE] Releasing Wagon 2.11

Am 2016-12-24 um 04:07 schrieb Dan Tran: Hi, We have fixed 18 issues: *https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122&version=1296 * There are still issues left in JIRA: *h

[VOTE] Releasing Wagon 2.11

Hi, We have fixed 18 issues: *https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122&version=1296 * There are still issues left in JIRA: *https://issues.apache.org/jira/issues/?jql=p

Releasing Wagon 2.9

If no one has any objections I'm going to release Wagon 2.9 which fixes a couple issues with Maven itself for the 3.3.3 release. I'll roll the release in the morning if no one speaks up. Thanks, Jason -- Jason van Zyl Founder, Takari and

Re: Releasing Wagon 2.3 for Maven 3.1.0

Cool, I'll spin up a release. On Nov 19, 2012, at 4:09 PM, Dennis Lundberg wrote: > This is fixed now. > > On 2012-11-19 20:57, Dennis Lundberg wrote: >> Hi >> >> I'd like to get a fix for https://jira.codehaus.org/browse/WAGON-370 >> into that release. I'm just not sure which version of slf4j

Re: Releasing Wagon 2.3 for Maven 3.1.0

This is fixed now. On 2012-11-19 20:57, Dennis Lundberg wrote: > Hi > > I'd like to get a fix for https://jira.codehaus.org/browse/WAGON-370 > into that release. I'm just not sure which version of slf4j to use, > given that Maven core uses it now. Could you have a look? It's a matter > of adding

Re: Releasing Wagon 2.3 for Maven 3.1.0

I updated SLF4J to 1.7.2 to match the core. If you want to try it out now I can help you if anything is wrong. I'd like to try and cut the release tonight/early tomorrow. On Nov 19, 2012, at 2:57 PM, Dennis Lundberg wrote: > Hi > > I'd like to get a fix for https://jira.codehaus.org/browse/WA

Re: Releasing Wagon 2.3 for Maven 3.1.0

Hi I'd like to get a fix for https://jira.codehaus.org/browse/WAGON-370 into that release. I'm just not sure which version of slf4j to use, given that Maven core uses it now. Could you have a look? It's a matter of adding back a dependency to wagon-webdav-jackrabbit that got lost, see comments on

Re: Releasing Wagon 2.3 for Maven 3.1.0

If nothing pops up tonight, I'll cut the release tonight. Hopefully it will be ready for integration on Friday. On Nov 19, 2012, at 7:35 AM, Jason van Zyl wrote: > I'd like to release Wagon 2.3 in preparation for Maven 3.1.0. I'd like to > start the vote tomorrow at the latest so that the rel

Releasing Wagon 2.3 for Maven 3.1.0

I'd like to release Wagon 2.3 in preparation for Maven 3.1.0. I'd like to start the vote tomorrow at the latest so that the release can be completed (if there are no problems) by Friday so that I can integrate it into the release. I took the remaining open issues and pushed them into the backlog

Re: Releasing Wagon?

You should be right to fix just that issue (or any others you feel you want to) and ship a release. It's a fairly standard release, and if it passes the built in tests it should be fine. If you want to do additional testing, I usually upgraded Maven to use the new version and ran the core integ

Releasing Wagon?

Hi WAGON-60 is currently blocking people from using Maven Site Plugin 2.1+ in combination with webdav. I'd like to get that fix released, but have never released Wagon before. There are currently 3 unresolved issues scheduled for 1.0-beta-7: http://jira.codehaus.org/secure/IssueNavigator.jspa?r