Re: [VOTE] Release Apache Maven JXR Plugin version 3.1.1

[Olivier Lamy]

+1

On Mon, 19 Apr 2021 at 05:12, Robert Scholte  wrote:

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


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: [VOTE] Release Apache Maven JXR Plugin version 3.1.1

[Robert Scholte]

+1
On 18-4-2021 21:12:47, Robert Scholte  wrote:
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

Re: [VOTE] Release Apache Maven JXR Plugin version 3.1.1

[Tibor Digana]

+1

On Sun, Apr 18, 2021 at 9:12 PM Robert Scholte  wrote:

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

Re: [VOTE] Release Apache Maven JXR Plugin version 3.1.1

[Robert Scholte]

Hi Andreas,

thanks for testing, I really appreciate it!


Regarding the voting, every vote counts, maybe especially from users.
Depending on the release manager, their negative votes might result in the 
cancelling of the release.
A few years ago we decided to drop the word "binding" during the vote, because 
it doesn't motivate non-committers to verify a release.
Instead we mention if there are enough PMC votes (for legal reasons).

With that in mind, can I turn your message into a +1?

thanks,
Robert

On 19-4-2021 14:39:42, Andreas Sewe  wrote:
Hi,


> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.

just a user of the maven-jxr-plugin and not a committer, but I wanted to
let you know anyway that version 3.1.1 works fine for me, even if I
cannot participate in the voting proper. So thanks for doing a release!

Hope this helps.

Andreas

Re: Security/Versioning policy proposal

[Romain Manni-Bucau]

Le lun. 19 avr. 2021 à 17:20, Benjamin Marwell  a
écrit :

> >  Do we write 3.6 and 4 are active and maintained branches currently or
> do we
> > drop 3.x with first 4.x release?
>
> Dropping 3.x with the first 4.x release would not make sense from the
> point you presented earlier.
> I'd drop 3.x as soon as we reach 4.1.0.
>

I can agree but it also means we define what is 4.1.0 and since we "jump"
versions it will require us to better respect what we plan (I think it is
very good, don't take it wrong).


>
> > maintenance branches on demands
> My vote would be to cherry pick security fixes for the previous minor
> version.
> E.g. if we release 4.0.1, also release a 3.8.2 (assuming the current
> latest versions are 4.0.0. and 3.8.1).
>
> I mean, we can try this for a single release and see if we like it.
> If not, we can still drop this again and revert back to "on demand"
> maintenance branches.
>
> Backporting features does not make sense (imo) how maven treats releases.
>

I think it is the whole point: what when we fix a security issue by a new
feature -> "does not make sense" (quoting your words but that's what was
the outcome for 3.8.1) and it is exactly the issue I face and I want we
fix: no predictability on stable maven versions with a minimal maintenance
"guaranteed" (no security issue opened in CVE databases).
So I think we either write we backport the security fixes in last 2
maintained branches with some duration (we can align on java LTS duration
for example which should be close to our major breaking changes) or we
write we don't care and only maintain the last release branch and it is the
only one guaranteed to get fixes (which kind of means there will be no
anticipation of version but it is known upfront).
Indeed I'm not a fan of such "you will see" policies but it clarifies the
point which is my main blocker at the moment at least we can justify our
last behavior.
This is really the answer I'm after: explicit what we do and continue or
make us more rigorous in the future.

That said I note the "we can still revert back" point which is surely a
very good one so idea can be to write "we will do " and add a banner on
top saying "experimental policy until " (for example for a year) and we
can change the policy (and update the deadline) within this duration if it
does not fit. This would enable us to test and validate the policy with an
error right and let the user know it upfront.

So proposal can be:

[Experimental policy until June 2022]
1. We maintain two major releases, ie 3.x and 4.x as of today (no minor in
particular, just the highest one)
2. We maintain versions and notify the EOL 3 years before it is reached (so
if we want to EOL v3 in 2025 we will notify users in 2022)
3. We backport and release security fixes (new feature or not) in all
maintained branches

Wdyt?


>
> Am So., 18. Apr. 2021 um 22:45 Uhr schrieb Romain Manni-Bucau
> :
> >
> > 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 maint

Re: maven-site-plugin and sisu-inject-plexus

[Stuart McCulloch]

On Sat, 17 Apr 2021 at 13:47, Elliotte Rusty Harold 
wrote:

> I'd certainly prefer to use a fully supported, maintained, and
> documented framework instead of Plexus. So about Sisu:
>

Sisu is basically a few modules installed on top of Guice to make it more
dynamic, plus a thin compatibility layer that provides the Plexus API

Maven has used Sisu (and Guice) since version 3 - the general idea was to
allow plugins to use standard annotations (like JSR330 @Inject) while still
supporting legacy plugins.


> Where is it documented?
>

The main project site is https://www.eclipse.org/sisu/

The doc most useful for Maven developers is
http://wiki.eclipse.org/Sisu/PlexusMigration

There's more detail in the javadoc:
https://www.eclipse.org/sisu/docs/api/org.eclipse.sisu.inject/reference/packages.html
https://www.eclipse.org/sisu/docs/api/org.eclipse.sisu.plexus/reference/packages.html


> Is it under active development?
>

Yes - contributions are also welcome.


> When will 1.0 be released?
>

This year, if everything goes to plan.


> Which projects besides Maven use it?
>

Various Sonatype projects, including Nexus.


> On Sat, Apr 17, 2021 at 12:29 PM Tamás Cservenák 
> wrote:
> >
> > To be clear, am talking about this artifact (sisu plexus shim):
> >
> https://repo1.maven.org/maven2/org/eclipse/sisu/org.eclipse.sisu.plexus/0.3.4/
> >
> > Whenever you see plexus-container-default, you SHOULD replace it with
> this
> > above (or better yet, convert to plain sisu).
> >
> > T
> >
> > On Sat, Apr 17, 2021, 14:25 Tamás Cservenák  wrote:
> >
> > > Plexus-container-default is NOT (and SHOULD NOT) be used anywhere, but
> the
> > > drop in sisu-plexus drop replacement should be used instead.
> > >
> > > If we use p-c-d anywhere (even in UTs), that's bad, as maven uses s-p
> > > instead.
> > >
> > > p-c-d is not used in maven for sure.
> > >
> > > T
> > >
> > > On Sat, Apr 17, 2021, 14:02 Elliotte Rusty Harold 
> > > wrote:
> > >
> > >> plexus-container-default is used by Maven shared utils and thus by
> > >> almost everything in Maven. Not that this is a good thing, but c'est
> > >> la vie.
> > >>
> > >> There's a lot of over-engineered, unnecessary code splitting between
> > >> Maven, Aether, Plexus, and Modello. Maven's a pretty classic example
> > >> of why developers should resist the urge to build yet another
> > >> framework. Code maintenance and development would be far simpler and
> > >> less expensive today if 20 years ago the Maven developers had simply
> > >> written a build tool without trying to extend it to a general purpose
> > >> framework. YAGNI.
> > >>
> > >> On Tue, Feb 9, 2021 at 4:39 PM Tamás Cservenák 
> > >> wrote:
> > >> >
> > >> > Howdy,
> > >> >
> > >> > my 5 cents:
> > >> >
> > >> > Something is stale, very stale in there, as
> plexus-container-default was
> > >> > abandoned about 10 (maybe 12?) years ago, and sisu "shim"
> > >> > (sisu-inject-plexus) was created as the direct replacement (as
> > >> functional
> > >> > and as API).
> > >> >
> > >> > If your project has Plexus "the old container"
> > >> (plexus-container-default)
> > >> > pulled in, it means something on project or it's transitive
> dependency
> > >> hull
> > >> > lags for about 10+ years if not more :)
> > >> >
> > >> > Given Plexus is "maven only" (mostly), it is most probably that some
> > >> > dependency (governed by us, chance is 90%+) pulls it in, that has
> not
> > >> been
> > >> > touched for quite a long time.
> > >> >
> > >> > Plexus et al is one of the reasons why "maven pulls down the
> internet",
> > >> > especially as we resolve/download it only to toss it away (drop it).
> > >> >
> > >> > HTH
> > >> > T
> > >> >
> > >> > On Tue, Feb 9, 2021 at 5:13 PM Slawomir Jaranowski <
> > >> s.jaranow...@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Project used class like org.codehaus.plexus.PlexusContainer
> > >> > >
> > >> > > We can remove direct dependency because we have transitive
> dependency
> > >> > > from other artifacts - of course we needn't remove it.
> > >> > >
> > >> > > [INFO] --- maven-dependency-plugin:2.10:tree (default-cli) @
> > >> > > maven-site-plugin ---
> > >> > > [WARNING] Using Maven 2 dependency tree to get verbose output,
> which
> > >> may be
> > >> > > inconsistent with actual Maven 3 resolution
> > >> > > [INFO]
> > >> > >
> > >>
> org.apache.maven.plugins:maven-site-plugin:maven-plugin:3.10.0-SNAPSHOT
> > >> > > [INFO] +- org.apache.maven:maven-compat:jar:3.0.5:provided
> > >> > > [INFO] |  \-
> (org.sonatype.sisu:sisu-inject-plexus:jar:2.3.0:compile -
> > >> > > scope updated from provided; omitted for duplicate)
> > >> > > [INFO] +- org.apache.maven:maven-core:jar:3.0.5:compile
> > >> > > [INFO] |  \-
> (org.sonatype.sisu:sisu-inject-plexus:jar:2.3.0:compile -
> > >> > > omitted for conflict with 1.4.2)
> > >> > > [INFO] +- org.apache.maven:maven-plugin-api:jar:3.0.5:compile
> > >> > > [INFO] |  \-
> (org.sonatype.sisu:sisu-inject-plexus:jar:2.3.0:compile -
> > >> > > omitted for dupli

Re: Security/Versioning policy proposal

[Benjamin Marwell]

>  Do we write 3.6 and 4 are active and maintained branches currently or do we
> drop 3.x with first 4.x release?

Dropping 3.x with the first 4.x release would not make sense from the
point you presented earlier.
I'd drop 3.x as soon as we reach 4.1.0.

> maintenance branches on demands
My vote would be to cherry pick security fixes for the previous minor version.
E.g. if we release 4.0.1, also release a 3.8.2 (assuming the current
latest versions are 4.0.0. and 3.8.1).

I mean, we can try this for a single release and see if we like it.
If not, we can still drop this again and revert back to "on demand"
maintenance branches.

Backporting features does not make sense (imo) how maven treats releases.

Am So., 18. Apr. 2021 um 22:45 Uhr schrieb Romain Manni-Bucau
:
>
> 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 

[GitHub] [maven-doxia] asfgit closed pull request #60: Bump ant-apache-regexp from 1.10.9 to 1.10.10

[GitBox]

asfgit closed pull request #60:
URL: https://github.com/apache/maven-doxia/pull/60


   


-- 
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: [VOTE] Release Apache Maven JXR Plugin version 3.1.1

[Arnaud Héritier]

+1

Le dim. 18 avr. 2021 à 21:12, Robert Scholte  a
écrit :

> 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
>
-- 
Arnaud Héritier
Twitter/Skype : aheritier

Re: [VOTE] Release Apache Maven JXR Plugin version 3.1.1

[Andreas Sewe]

Hi,


> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.

just a user of the maven-jxr-plugin and not a committer, but I wanted to
let you know anyway that version 3.1.1 works fine for me, even if I
cannot participate in the voting proper. So thanks for doing a release!

Hope this helps.

Andreas



signature.asc
Description: OpenPGP digital signature

[GitHub] [maven-site] asfgit closed pull request #234: Bump ant from 1.10.9 to 1.10.10

[GitBox]

asfgit closed pull request #234:
URL: https://github.com/apache/maven-site/pull/234


   


-- 
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] dependabot[bot] commented on pull request #234: Bump ant from 1.10.9 to 1.10.10

[GitBox]

dependabot[bot] commented on pull request #234:
URL: https://github.com/apache/maven-site/pull/234#issuecomment-822408264


   OK, I won't notify you again about this release, but will get in touch when 
a new version is available.
   
   If you change your mind, just re-open this PR and I'll resolve any conflicts 
on it.


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

[Olivier Lamy]

yup definitely use loopback address (hostnames are not very reliable on
such ephemeral nodes environments)

On Mon, 19 Apr 2021 at 18:15, Tibor Digana  wrote:

> I had this problem with GH CI:
>
> java.net.BindException: Cannot assign requested address
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:461)
> at sun.nio.ch.Net.bind(Net.java:453)
> at
> sun.nio.ch
> .AsynchronousServerSocketChannelImpl.bind(AsynchronousServerSocketChannelImpl.java:163)
>
> and solved it see
>
> https://github.com/apache/maven-surefire/commit/a1d3866eb0dd81e8ea62f740f93fde93#diff-24d3dc1df1df617f7318394dde0b087beef68c26909828ccca72bf2af78ed9bfR84
> and now the CI is green.
> I guess we have the same problem in our ITs.
>
> T
>
>
>
>
>
>
> On Mon, Apr 19, 2021 at 10:09 AM Tibor Digana 
> wrote:
>
> > Port 0 does not exist, only in your code.
> > 0 means that a new unused local port is allocated.
> > Again you have to use local loopback 127.0.0.1 as me. I had the same
> > problem and I solved it.
> > T
> >
> > On Mon, Apr 19, 2021 at 8:41 AM Maarten Mulders 
> > wrote:
> >
> >> 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 <
> >> mthmuld...@apache.org>
> >> >>> 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
> >>
> >>
>


-- 
Olivier Lamy
http://twitter.com/

Re: Failing IT's on Linux in GitHub Actions

[Tibor Digana]

I had this problem with GH CI:

java.net.BindException: Cannot assign requested address
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:461)
at sun.nio.ch.Net.bind(Net.java:453)
at
sun.nio.ch.AsynchronousServerSocketChannelImpl.bind(AsynchronousServerSocketChannelImpl.java:163)

and solved it see
https://github.com/apache/maven-surefire/commit/a1d3866eb0dd81e8ea62f740f93fde93#diff-24d3dc1df1df617f7318394dde0b087beef68c26909828ccca72bf2af78ed9bfR84
and now the CI is green.
I guess we have the same problem in our ITs.

T






On Mon, Apr 19, 2021 at 10:09 AM Tibor Digana 
wrote:

> Port 0 does not exist, only in your code.
> 0 means that a new unused local port is allocated.
> Again you have to use local loopback 127.0.0.1 as me. I had the same
> problem and I solved it.
> T
>
> On Mon, Apr 19, 2021 at 8:41 AM Maarten Mulders 
> wrote:
>
>> 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 <
>> mthmuld...@apache.org>
>> >>> 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
>>
>>

Re: Failing IT's on Linux in GitHub Actions

[Tibor Digana]

Port 0 does not exist, only in your code.
0 means that a new unused local port is allocated.
Again you have to use local loopback 127.0.0.1 as me. I had the same
problem and I solved it.
T

On Mon, Apr 19, 2021 at 8:41 AM Maarten Mulders 
wrote:

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

Re: Failing IT's on Linux in GitHub Actions

[Romain Manni-Bucau]

Hi

Should we set java.net.preferIPv4Stack=true?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 19 avr. 2021 à 08:41, Maarten Mulders  a
écrit :

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