[GitHub] [maven-site] dependabot[bot] opened a new pull request #234: Bump ant from 1.10.9 to 1.10.10
dependabot[bot] opened a new pull request #234: URL: https://github.com/apache/maven-site/pull/234 Bumps ant from 1.10.9 to 1.10.10. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Failing IT's on Linux in GitHub Actions
All of those tests seem to follow the process of starting a server at port 0 indeed. Some tests even start two servers in one test: MavenITmng4991NonProxyHostsTest and MavenITmng2387InactiveProxyTest. And in all three scenarios they use `InetAddress.getLocalHost().getCanonicalHostName()` to lookup their hostname. I'm not sure if that's the best way to do it? Interestingly, I now see that those tests do not *always* fail on Linux. During the last GitHub Action run (640, [1]), two out of four Linux jobs actually succeeded. The failing ones logged stuff like this: Connect to fv-az154-166.internal.cloudapp.net:34307 [fv-az154-166.internal.cloudapp.net/10.1.0.103] failed: Connection timed out (Connection timed out) Connect to fv-az292-806.internal.cloudapp.net:33785 [fv-az292-806.internal.cloudapp.net/10.1.0.129] failed: Connection timed out (Connection timed out) Interestingly, they seem to not be able to connect, but the name lookup doesn't seem the issue, right? Thanks, Maarten [1] https://github.com/apache/maven/actions/runs/761300517 On 19/04/2021 00:31, Tibor Digaňa wrote: yes, there was one more issue with host. I also had to turn "localhost" to 127.0.0.1 in the socket. T On Sun, Apr 18, 2021 at 11:48 PM Olivier Lamy wrote: Hi, Do not change ports or use hard coded ports. The current ITs are using port 0 which means Jetty will allocate a random available port. There must be some problems with host lookup. In some environments (such as kubernetes) using localhost or 127.0.0.1 can be problematic. What is the error? What is the status of using java8 for IT tests? (current ITs are using a very very old version of Jetty 9.0.4...) On Mon, 19 Apr 2021 at 06:56, Tibor Digana wrote: I had exactly the same problem and I added one more step to the CI which checked all open ports. For instance they changed something in Github and 8081 or 8082 was allocated. There was a conflict with the ports and I had to shift mine, that;s it. T On Sun, Apr 18, 2021 at 8:17 PM Maarten Mulders wrote: Hi all, It seems the following IT's predictably fail on Linux (not on Windows or MacOS) in GitHub Actions, but not at all in Jenkins: * MavenIT0146InstallerSnapshotNaming * MavenITmng2387InactiveProxyTest * MavenITmng4991NonProxyHostsTest This is also the case in master, by the way. What they have in common is that they all spin up an HTTP server during the test, but apparently that server cannot be reached under all circumstances. Does anyone have an idea what might be causing this and how we could address this? Thanks, Maarten - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-doxia] dependabot[bot] opened a new pull request #60: Bump ant-apache-regexp from 1.10.9 to 1.10.10
dependabot[bot] opened a new pull request #60: URL: https://github.com/apache/maven-doxia/pull/60 Bumps ant-apache-regexp from 1.10.9 to 1.10.10. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-doxia-site] dependabot[bot] opened a new pull request #11: Bump ant from 1.10.9 to 1.10.10
dependabot[bot] opened a new pull request #11: URL: https://github.com/apache/maven-doxia-site/pull/11 Bumps ant from 1.10.9 to 1.10.10. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-site-plugin] dependabot[bot] opened a new pull request #47: Bump plexus-archiver from 4.2.4 to 4.2.5
dependabot[bot] opened a new pull request #47: URL: https://github.com/apache/maven-site-plugin/pull/47 Bumps [plexus-archiver](https://github.com/codehaus-plexus/plexus-archiver) from 4.2.4 to 4.2.5. Release notes Sourced from https://github.com/codehaus-plexus/plexus-archiver/releases";>plexus-archiver's releases. Plexus Archiver 4.2.5 🚀 New features and improvements Speed improvements (https://github-redirect.dependabot.com/codehaus-plexus/plexus-archiver/issues/157";>#157) https://github.com/gnodet";>@gnodet 🐛 Bug Fixes Fix use of a mismatching Unicode path extra field in zip unarchiving (https://github-redirect.dependabot.com/codehaus-plexus/plexus-archiver/issues/167";>#167) https://github.com/cwalther";>@cwalther In some cases zip archiver may update the file path but not the Unicode path extra field. This would result in Plexus Archiver extracting the file using wrong (obsolete) path. Now Plexus Archiver follows the specification and in this case will ignore the extra filed and extract the file in the correct location. 📦 Dependency updates Bump plexus from 6.5 to 7 (https://github-redirect.dependabot.com/codehaus-plexus/plexus-archiver/issues/158";>#158) https://github.com/dependabot";>@dependabot Bump xz from 1.8 to 1.9 (https://github-redirect.dependabot.com/codehaus-plexus/plexus-archiver/issues/165";>#165) https://github.com/dependabot";>@dependabot Commits https://github.com/codehaus-plexus/plexus-archiver/commit/3c3109ca0cc0c17b0806aab54c182dfb5cdd5caf";>3c3109c [maven-release-plugin] prepare release plexus-archiver-4.2.5 https://github.com/codehaus-plexus/plexus-archiver/commit/e6b0d937da09c435746657ed61c44c7d7659799a";>e6b0d93 [maven-release-plugin] rollback the release of plexus-archiver-4.2.5 https://github.com/codehaus-plexus/plexus-archiver/commit/82c3830971ecf7b40cb87f484ecc5f9388ce86b0";>82c3830 [maven-release-plugin] prepare for next development iteration https://github.com/codehaus-plexus/plexus-archiver/commit/e2df60536052300247b7a86e7f737904c2833064";>e2df605 [maven-release-plugin] prepare release plexus-archiver-4.2.5 https://github.com/codehaus-plexus/plexus-archiver/commit/1094bda6a485f737e1e12196f89ae32b3b241311";>1094bda Merge pull request https://github-redirect.dependabot.com/codehaus-plexus/plexus-archiver/issues/169";>#169 from codehaus-plexus/dependabot/github_actions/action... https://github.com/codehaus-plexus/plexus-archiver/commit/2c31a4de8e7e5a15abd556acb3f3baec12fea880";>2c31a4d Create codeql-analysis.yml https://github.com/codehaus-plexus/plexus-archiver/commit/dce7a9d539a41d587d439917c617432efaa7b77a";>dce7a9d Bump actions/cache from v2.1.4 to v2.1.5 https://github.com/codehaus-plexus/plexus-archiver/commit/b074384a3ff07ad5518ae9b3374524601940ca0f";>b074384 Fix use of a mismatching unicode path extra field in zip unarchiving https://github.com/codehaus-plexus/plexus-archiver/commit/e3a2cb63e2c2f94697880bd74212e457ce48d0f6";>e3a2cb6 Update javadoc according to the code https://github.com/codehaus-plexus/plexus-archiver/commit/8a085746885c4e0e3600edac80cd5a33162424dc";>8a08574 Use non synchronized collections Additional commits viewable in https://github.com/codehaus-plexus/plexus-archiver/compare/plexus-archiver-4.2.4...plexus-archiver-4.2.5";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact In
Re: Failing IT's on Linux in GitHub Actions
yes, there was one more issue with host. I also had to turn "localhost" to 127.0.0.1 in the socket. T On Sun, Apr 18, 2021 at 11:48 PM Olivier Lamy wrote: > Hi, > Do not change ports or use hard coded ports. > The current ITs are using port 0 which means Jetty will allocate a > random available port. > There must be some problems with host lookup. In some environments (such as > kubernetes) using localhost or 127.0.0.1 can be problematic. > What is the error? > > What is the status of using java8 for IT tests? (current ITs are using a > very very old version of Jetty 9.0.4...) > > > On Mon, 19 Apr 2021 at 06:56, Tibor Digana wrote: > > > I had exactly the same problem and I added one more step to the CI which > > checked all open ports. > > For instance they changed something in Github and 8081 or 8082 was > > allocated. > > There was a conflict with the ports and I had to shift mine, that;s it. > > > > T > > > > On Sun, Apr 18, 2021 at 8:17 PM Maarten Mulders > > wrote: > > > > > Hi all, > > > > > > It seems the following IT's predictably fail on Linux (not on Windows > or > > > MacOS) in GitHub Actions, but not at all in Jenkins: > > > > > > * MavenIT0146InstallerSnapshotNaming > > > * MavenITmng2387InactiveProxyTest > > > * MavenITmng4991NonProxyHostsTest > > > > > > This is also the case in master, by the way. What they have in common > is > > > that they all spin up an HTTP server during the test, but apparently > > > that server cannot be reached under all circumstances. > > > > > > Does anyone have an idea what might be causing this and how we could > > > address this? > > > > > > Thanks, > > > > > > Maarten > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > -- > Olivier Lamy > http://twitter.com/olamy | http://linkedin.com/in/olamy > -- Cheers Tibor
Re: Failing IT's on Linux in GitHub Actions
Hi, Do not change ports or use hard coded ports. The current ITs are using port 0 which means Jetty will allocate a random available port. There must be some problems with host lookup. In some environments (such as kubernetes) using localhost or 127.0.0.1 can be problematic. What is the error? What is the status of using java8 for IT tests? (current ITs are using a very very old version of Jetty 9.0.4...) On Mon, 19 Apr 2021 at 06:56, Tibor Digana wrote: > I had exactly the same problem and I added one more step to the CI which > checked all open ports. > For instance they changed something in Github and 8081 or 8082 was > allocated. > There was a conflict with the ports and I had to shift mine, that;s it. > > T > > On Sun, Apr 18, 2021 at 8:17 PM Maarten Mulders > wrote: > > > Hi all, > > > > It seems the following IT's predictably fail on Linux (not on Windows or > > MacOS) in GitHub Actions, but not at all in Jenkins: > > > > * MavenIT0146InstallerSnapshotNaming > > * MavenITmng2387InactiveProxyTest > > * MavenITmng4991NonProxyHostsTest > > > > This is also the case in master, by the way. What they have in common is > > that they all spin up an HTTP server during the test, but apparently > > that server cannot be reached under all circumstances. > > > > Does anyone have an idea what might be causing this and how we could > > address this? > > > > Thanks, > > > > Maarten > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Failing IT's on Linux in GitHub Actions
I had exactly the same problem and I added one more step to the CI which checked all open ports. For instance they changed something in Github and 8081 or 8082 was allocated. There was a conflict with the ports and I had to shift mine, that;s it. T On Sun, Apr 18, 2021 at 8:17 PM Maarten Mulders wrote: > Hi all, > > It seems the following IT's predictably fail on Linux (not on Windows or > MacOS) in GitHub Actions, but not at all in Jenkins: > > * MavenIT0146InstallerSnapshotNaming > * MavenITmng2387InactiveProxyTest > * MavenITmng4991NonProxyHostsTest > > This is also the case in master, by the way. What they have in common is > that they all spin up an HTTP server during the test, but apparently > that server cannot be reached under all circumstances. > > Does anyone have an idea what might be causing this and how we could > address this? > > Thanks, > > Maarten > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Security/Versioning policy proposal
Hi all, Back on this topic - which prepares v4 releases too btw. What do we finally write? That maven will always fix the latest (stable) version and can release maintenance branches on demands (lazily)? Do we write 3.6 and 4 are active and maintained branches currently or do we drop 3.x with first 4.x release? Indeed I'd like the 2 branches option but I am fine with whatever policy while written and clear for end users upfront. I'd love we solve that before next release if possible cause it always create pointless work due to the blurry exchanges on this topic over our website and the net/mail archives. Le lun. 5 avr. 2021 à 19:51, Romain Manni-Bucau a écrit : > > > > Le lun. 5 avr. 2021 à 17:42, Ralph Goers a > écrit : > >> I don’t understand the point. The very next version of Maven did get the >> security fix. Just because the release manager decided to follow a peculiar >> version numbering practice unique to Maven doesn’t mean there is a problem. >> > > This had been an issue only because the versioning policy of maven is > undefined. > If defined it is perfectly fine for me. > > >> >> I don’t know what you mean by random, nor do I know what you mean by a >> stability statement. AFAIK Maven has been very stable from the 2.x versions >> through the 3.x versions. In some ways too stable, which is why introducing >> new concepts that have been wanted for years is so hard. >> > > Last statements tend to mean that once 4.x will be there, 3.x will be > forgotten and no more maintained. > Since it is a breaking change and if you picked 3.x today it is a big deal > since you have no guarantee you can upgrade without a lot of investment and > get security fixes when needed by just upgrading (and potentially tuning a > bit the conf but not by rewriting the poms for ex). > > For 2.x -> 3.x time, the 2.x was maintained some years. > This is very close to the LTS concept, and this is mainly this kind of > statement I'm trying to get to let projects plan properly and not have > maven on their road too easily. > If properly defined it will not impact much maven dev but can save a lot > of time for enterprises and enable them to properly setup their projects in > time. > > So overall the definition points are still the same: > > 1. which versions are maintained (ie can get security fixes - new features > are not required to be in the box here) > 2. for how long > 3. what does mean version (major.minor.*, major.* for ex) in 1. > > "3.x will be supported for 3 more years when 4.x is out and maintained > major versions are guaranteed to get security fixes" is a kind of statement > which solves that - we can also use N=current and N+1 in the statement to > not stick it to 3 and 4. > "4.x is the current released branch, other branch will never be released > anymore" does not work for me for example IMHO (but we can put it on vote > if that's the community desire). > > >> >> FWIW, my employer’s repository manager still uses http since it is behind >> a VPN. After trying 3.8.1 I found I had to specify mirrors for all the >> repos even though they are not defined in pom’s. Apparently the fix also >> affects repositories defined in settings.xml. >> > > Yes because it is a mirror and wildcard one. > Using a custom global settings - to override default one - is a solution > if you know all http repositories you want to force to be blocked (can be > hard since you never know all of them by definition and mirroring does not > support custom patterns but can be a quick workaround to upgrade without > blocking builds). > > >> >> Ralph >> >> > On Apr 5, 2021, at 12:28 AM, Romain Manni-Bucau >> wrote: >> > >> > Hmm, general/common asf way of doing is to move forward until users ask >> > (and if so any branch is patched while a pr is done). >> > If maven does not follow that practise it cant say "last version will >> get >> > the security fix" too because it means "we dont care of users, to get >> the >> > cve fix you will have to rewrite your build". >> > So at least a major stability statement is required IMO with some lts >> > statement and eol on majors. >> > Without that using maven sounds random for projects, no? >> > >> > Le dim. 4 avr. 2021 à 22:13, Bernd Eckenfels a >> > écrit : >> > >> >> I agree, maven does not need to concern itself with branches as long >> as it >> >> stays fairly forward drop-in compatible. >> >> >> >> Having said that, things like changing the policy for handling http >> might >> >> not be that drop-in, but on the other hand it’s just a config option >> and >> >> does not require complicated (plugin) dependency updates. >> >> >> >> I do wonder if the version number should better reflect such >> incompatible >> >> requirement changes. (And if somebody really wants to provide security >> >> fixes for those incompatible older branches why not, but I don’t think >> you >> >> can require them from a project which does not offer them by themself). >> >> >> >> >> >> -- >> >> http://bernd.eckenfels
[VOTE] Release Apache Maven JXR Plugin version 3.1.1
Hi, We solved 12 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317527&version=12344185&styleName=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317527%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1640/ https://repository.apache.org/content/repositories/maven-1640/org/apache/maven/jxr/jxr/3.1.1/jxr-3.1.1-source-release.zip Source release checksum(s): jxr-3.1.1-source-release.zip sha512: d7bdbedc72568192a9b63132a91852379ad542c606d222a87cf316e1cef8e60434c4b573b55d7e39c1159cb17728eb5ae5c1cb0922337bb5c06885805a36d76c Staging site: https://maven.apache.org/jxr-archives/jxr-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for at least 72 hours. [ ] +1 [ ] +0 [ ] -1
Failing IT's on Linux in GitHub Actions
Hi all, It seems the following IT's predictably fail on Linux (not on Windows or MacOS) in GitHub Actions, but not at all in Jenkins: * MavenIT0146InstallerSnapshotNaming * MavenITmng2387InactiveProxyTest * MavenITmng4991NonProxyHostsTest This is also the case in master, by the way. What they have in common is that they all spin up an HTTP server during the test, but apparently that server cannot be reached under all circumstances. Does anyone have an idea what might be causing this and how we could address this? Thanks, Maarten - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
