Re: ITs in maven-release
I've invested a lot of time when the TLSv1.2 became a requirement and this
is the best solution:
- pass https.protocols to plugin configuration when a new JVM is started
(if it is not set, it'll be ignored)
- this is based on the fact that if you have a clean repo you must pass
this value anyway.
- this property must be forward compatible: if TLS1.3 is the new default,
we should never reduce it to TLSv1.2
If the UK mirror still allows TLSv1.1, then *that* should be fixed, not
the current configuration of plugins.
thanks,
Robert
On Wed, 24 Jul 2019 23:37:31 +0200, Clemens Quoss wrote:
Hi Robert,
well it is already handled in the POM only for JDK 7:
...
jdk7
(,1.7]
org.apache.maven.plugins
maven-invoker-plugin
${https.protocols}
-Dhttps.protocols=${https.protocols}
...
Of course, this only takes care of when you release something with the
plugin using JDK 7. When building maven-release itself you will have to
provide the system property for JDK 7, but not when using UK mirror ;-)
Cheers, Clemens
Am 24.07.2019 um 23:20 schrieb Robert Scholte:
Hi Clemens,
We need to stay as close as possible to the real world.
With JDK8+ it should work without its being set, so the preferred way
it to execute it without the value being set.
And this way, once we must move TLS 1.3 we don't have to change all our
tests.
Here's how we do it with our Jenkins script[1], only activate it for
Java 7.
Robert
[1]
https://github.com/apache/maven-jenkins-lib/blob/master/vars/asfMavenTlpPlgnBuild.groovy#L128-L131
On Wed, 24 Jul 2019 23:03:22 +0200, Clemens Quoss
wrote:
Hi Robert,
if TLSv1.2 is needed, then why not put it explicitly into the pom in
line 266 [0] instead of using ${https.protocols}?
Cheers, Clemens
[0]
https://github.com/apache/maven-release/blob/a94c76f77ef8df1b82e9eef370412ce9b23083a0/maven-release-plugin/pom.xml#L266
Am 23.07.2019 um 19:33 schrieb Robert Scholte:
Hi Clemens,
please see
https://central.sonatype.org/articles/2018/May/04/discontinued-support-for-tlsv11-and-below/
We'll need to contact Sonatype and verify if they included
http://uk.maven.org/maven2/ as well (they should...)
However, AFAIK nowadays there's no need anymore to explicitly refer
to uk, it is already handled by Central CDN
thanks,
Robert
On 23-7-2019 00:01:06, Clemens Quoss wrote:
Hi Robert,
thanks for the insight. Shouldn't it fail with JDK 7 Update 80 even
with this parameter since the backport for TLSv1.2 came with Update
95 [0]?
Since when does this requirement exist? Just checked it: I'm using
UK
mirror [1]. This works without TLSv1.2. Maybe thats why i didn't
noticed before.
But we had problem at work contacting the Atlassian Repo from our
Nexus
that ran with JDK 7 Update 80. In that case we switched back to JDK 6
Update 211.
Cheers, Clemens
[0]
https://stackoverflow.com/questions/49523052/how-to-enable-tlsv1-2-in-java-7u80-client
[1] http://uk.maven.org/maven2/
Am 22.07.2019 um 23:45 schrieb Robert Scholte:
The plugin is indeed still Java 7 compatible, but that means you must
execute it with -Dhttps.protocols=TLSv1.2 when building it with JDK
7,
otherwise it'll fail because this is a requirement when downloading
from Central.
Our CI server scripts already add this argument when running with
Java
7, on your local machine it must be done by hand. This is not
restricted to the integration tests. Try to remove your local repo
and
start any project running with Maven and Java 7, it'll fail very
fast,
i.e. by the first plugin.
thanks,
Robert
On Sun, 14 Jul 2019 11:52:15 +0200, Clemens Quoss
wrote:
Hello everyone,
I have provided a PR for MRELEASE-229 [1] and added some JUnit tests
recently.
Now I was wondering if i should provide an IT, too, and had a look
into it:
Running
mvn verify -Prun-its
with Maven 3.6.1 and JDK 7 Update 80 fails:
...
[INFO] Building: projects\perform\MRELEASE-459\pom.xml
[INFO] run post-build script verify.groovy
[INFO] The post-build script did not succeed. assert
matcher.find()
| |
| false
java.util.regex.Matcher[pattern=\Q[DEBUG] Additional
arguments: \E(?:-Dhttps.protocols=TLSv1.2
)?-P(.+)\Q-DperformRelease=true -f pom.xml\E region=0,154745
lastmatch=]
[INFO] projects\perform\MRELEASE-459\pom.xml
FAILED (10.4 s)
...
IMHO it has something to do with TLSv1.2 not being backported to JDK
7 Update 80. But i may be wrong.
With JDK 8 Update 212 the tests run successfully.
My question is: Should the IT still run with JDK 7? I thought so
since maven-release can still be build with it. If some versions of
JDKs are not capable of being used for IT, shouldn't the IT run fail
fast (by enforcing the eligible versions)?
That was one question I have now redarding the ITs of maven-rele
Re: [maven-surefire] 01/01: TLS 1.2 passed to maven-invoker-plugin via system property
Please change
TLSv1.2
to
${https.protocols}
so it is only set when required, and we don't need to update the tests
when there are new requirements for https protocols.
thanks,
Robert
On Thu, 25 Jul 2019 00:17:44 +0200, wrote:
This is an automated email from the ASF dual-hosted git repository.
tibordigana pushed a commit to branch TLS1.2
in repository https://gitbox.apache.org/repos/asf/maven-surefire.git
commit 6425a679178d8ca73993d475eb800e82f4213900
Author: tibordigana
AuthorDate: Thu Jul 25 00:16:49 2019 +0200
TLS 1.2 passed to maven-invoker-plugin via system property
---
maven-failsafe-plugin/pom.xml | 1 +
1 file changed, 1 insertion(+)
diff --git a/maven-failsafe-plugin/pom.xml
b/maven-failsafe-plugin/pom.xml
index 2e85275..2bc4a14 100644
--- a/maven-failsafe-plugin/pom.xml
+++ b/maven-failsafe-plugin/pom.xml
@@ -334,6 +334,7 @@
${failsafe-integration-test-port}
${failsafe-integration-test-stop-port}
+
TLSv1.2
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Site Plugin version 3.8.2
0 (mainly because you know what I'm thinking about this 1.7 thing... but I'm not here to block anything...) release note is a bit "back to the future" containing both controversial informations * [MSITE-828] - Jdk 1.8 required * [MSITE-829] - Upgrade Jetty to 9.4.12 AND * [MSITE-843] - Downgrade Jetty to 9.2.28 * [MSITE-844] - Downgrade to Java 7 so this might need some clarification. On Thu, 25 Jul 2019 at 05:59, Michael Osipov wrote: > Hi, > > We solved 13 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923&version=12343145 > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20resolution%20%3D%20Unresolved > > Staging repo: > https://repository.apache.org/content/repositories/maven-1521/ > > https://repository.apache.org/content/repositories/maven-1521/org/apache/maven/plugins/maven-site-plugin/3.8.2/maven-site-plugin-3.8.2-source-release.zip > > Source release checksum(s): > maven-site-plugin-3.8.2-source-release.zip > sha512: > > 3567b4cb0cee7806ced776243d5d6764eed8f5b09a478b127044f2ccfd9fe9ec8ad4e6f9473aace41482e8c66733731da2d71a2d0d8e91cdf7876a4d6d2ecf52 > > Staging site: > https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > 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: [VOTE] Release Maven Site Plugin version 3.8.2
On 24 Jul 2019, at 21:59, Michael Osipov wrote: > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 +1 :) Regards, Graham — smime.p7s Description: S/MIME cryptographic signature
Re: ITs in maven-release
typo: TLSv1.2
On Thu, Jul 25, 2019 at 12:14 AM Tibor Digana
wrote:
> I think a good compromise would be to introduce default value "TLS1.2" for
> "https.protocols" in the POM section "properties" which can be overridden
> in command line.
>
>
> TLS1.2
>
>
> On Wed, Jul 24, 2019 at 11:37 PM Clemens Quoss wrote:
>
>> Hi Robert,
>> well it is already handled in the POM only for JDK 7:
>>
>> ...
>>
>>jdk7
>>
>> (,1.7]
>>
>>
>>
>>
>> org.apache.maven.plugins
>> maven-invoker-plugin
>>
>>
>> ${https.protocols}
>> -Dhttps.protocols=${https.protocols}
>>
>>
>>
>>
>>
>>
>> ...
>>
>> Of course, this only takes care of when you release something with the
>> plugin using JDK 7. When building maven-release itself you will have to
>> provide the system property for JDK 7, but not when using UK mirror ;-)
>>
>> Cheers, Clemens
>>
>> Am 24.07.2019 um 23:20 schrieb Robert Scholte:
>> > Hi Clemens,
>> >
>> > We need to stay as close as possible to the real world.
>> > With JDK8+ it should work without its being set, so the preferred way
>> > it to execute it without the value being set.
>> > And this way, once we must move TLS 1.3 we don't have to change all
>> > our tests.
>> > Here's how we do it with our Jenkins script[1], only activate it for
>> > Java 7.
>> >
>> > Robert
>> >
>> > [1]
>> >
>> https://github.com/apache/maven-jenkins-lib/blob/master/vars/asfMavenTlpPlgnBuild.groovy#L128-L131
>> >
>> > On Wed, 24 Jul 2019 23:03:22 +0200, Clemens Quoss
>> > wrote:
>> >
>> >> Hi Robert,
>> >> if TLSv1.2 is needed, then why not put it explicitly into the pom in
>> >> line 266 [0] instead of using ${https.protocols}?
>> >>
>> >> Cheers, Clemens
>> >>
>> >> [0]
>> >>
>> https://github.com/apache/maven-release/blob/a94c76f77ef8df1b82e9eef370412ce9b23083a0/maven-release-plugin/pom.xml#L266
>> >>
>> >> Am 23.07.2019 um 19:33 schrieb Robert Scholte:
>> >>> Hi Clemens,
>> >>>
>> >>> please see
>> >>>
>> https://central.sonatype.org/articles/2018/May/04/discontinued-support-for-tlsv11-and-below/
>> >>> We'll need to contact Sonatype and verify if they included
>> >>> http://uk.maven.org/maven2/ as well (they should...)
>> >>>
>> >>> However, AFAIK nowadays there's no need anymore to explicitly refer
>> >>> to uk, it is already handled by Central CDN
>> >>>
>> >>> thanks,
>> >>> Robert
>> >>> On 23-7-2019 00:01:06, Clemens Quoss wrote:
>> >>> Hi Robert,
>> >>> thanks for the insight. Shouldn't it fail with JDK 7 Update 80 even
>> >>> with this parameter since the backport for TLSv1.2 came with Update
>> >>> 95 [0]?
>> >>> Since when does this requirement exist? Just checked it: I'm using
>> UK
>> >>> mirror [1]. This works without TLSv1.2. Maybe thats why i didn't
>> >>> noticed before.
>> >>> But we had problem at work contacting the Atlassian Repo from our
>> Nexus
>> >>> that ran with JDK 7 Update 80. In that case we switched back to JDK 6
>> >>> Update 211.
>> >>>
>> >>> Cheers, Clemens
>> >>>
>> >>> [0]
>> >>>
>> https://stackoverflow.com/questions/49523052/how-to-enable-tlsv1-2-in-java-7u80-client
>> >>>
>> >>> [1] http://uk.maven.org/maven2/
>> >>>
>> >>> Am 22.07.2019 um 23:45 schrieb Robert Scholte:
>> The plugin is indeed still Java 7 compatible, but that means you must
>> execute it with -Dhttps.protocols=TLSv1.2 when building it with JDK
>> 7,
>> otherwise it'll fail because this is a requirement when downloading
>> from Central.
>> Our CI server scripts already add this argument when running with
>> Java
>> 7, on your local machine it must be done by hand. This is not
>> restricted to the integration tests. Try to remove your local repo
>> and
>> start any project running with Maven and Java 7, it'll fail very
>> fast,
>> i.e. by the first plugin.
>>
>> thanks,
>> Robert
>>
>> On Sun, 14 Jul 2019 11:52:15 +0200, Clemens Quoss
>> wrote:
>>
>> > Hello everyone,
>> >
>> > I have provided a PR for MRELEASE-229 [1] and added some JUnit tests
>> > recently.
>> >
>> > Now I was wondering if i should provide an IT, too, and had a look
>> > into it:
>> >
>> > Running
>> >
>> > mvn verify -Prun-its
>> >
>> > with Maven 3.6.1 and JDK 7 Update 80 fails:
>> >
>> > ...
>> >
>> > [INFO] Building: projects\perform\MRELEASE-459\pom.xml
>> > [INFO] run post-build script verify.groovy
>> > [INFO] The post-build script did not succeed. assert
>> matcher.find()
>> > | |
>> > | false
>> > java.util.regex.Matcher[pattern=\Q[DEBUG] Additional
>> > arguments: \E(?:-Dhttps.protocols=TLSv1.2
>> > )?-P(.+)\Q-DperformRelease=true -f pom.xml\E region=0,154745
>> > lastmatch=]
>> > [INFO] projects\perform\MRELEASE-459\pom.xml
Re: ITs in maven-release
I think a good compromise would be to introduce default value "TLS1.2" for
"https.protocols" in the POM section "properties" which can be overridden
in command line.
TLS1.2
On Wed, Jul 24, 2019 at 11:37 PM Clemens Quoss wrote:
> Hi Robert,
> well it is already handled in the POM only for JDK 7:
>
> ...
>
>jdk7
>
> (,1.7]
>
>
>
>
> org.apache.maven.plugins
> maven-invoker-plugin
>
>
> ${https.protocols}
> -Dhttps.protocols=${https.protocols}
>
>
>
>
>
>
> ...
>
> Of course, this only takes care of when you release something with the
> plugin using JDK 7. When building maven-release itself you will have to
> provide the system property for JDK 7, but not when using UK mirror ;-)
>
> Cheers, Clemens
>
> Am 24.07.2019 um 23:20 schrieb Robert Scholte:
> > Hi Clemens,
> >
> > We need to stay as close as possible to the real world.
> > With JDK8+ it should work without its being set, so the preferred way
> > it to execute it without the value being set.
> > And this way, once we must move TLS 1.3 we don't have to change all
> > our tests.
> > Here's how we do it with our Jenkins script[1], only activate it for
> > Java 7.
> >
> > Robert
> >
> > [1]
> >
> https://github.com/apache/maven-jenkins-lib/blob/master/vars/asfMavenTlpPlgnBuild.groovy#L128-L131
> >
> > On Wed, 24 Jul 2019 23:03:22 +0200, Clemens Quoss
> > wrote:
> >
> >> Hi Robert,
> >> if TLSv1.2 is needed, then why not put it explicitly into the pom in
> >> line 266 [0] instead of using ${https.protocols}?
> >>
> >> Cheers, Clemens
> >>
> >> [0]
> >>
> https://github.com/apache/maven-release/blob/a94c76f77ef8df1b82e9eef370412ce9b23083a0/maven-release-plugin/pom.xml#L266
> >>
> >> Am 23.07.2019 um 19:33 schrieb Robert Scholte:
> >>> Hi Clemens,
> >>>
> >>> please see
> >>>
> https://central.sonatype.org/articles/2018/May/04/discontinued-support-for-tlsv11-and-below/
> >>> We'll need to contact Sonatype and verify if they included
> >>> http://uk.maven.org/maven2/ as well (they should...)
> >>>
> >>> However, AFAIK nowadays there's no need anymore to explicitly refer
> >>> to uk, it is already handled by Central CDN
> >>>
> >>> thanks,
> >>> Robert
> >>> On 23-7-2019 00:01:06, Clemens Quoss wrote:
> >>> Hi Robert,
> >>> thanks for the insight. Shouldn't it fail with JDK 7 Update 80 even
> >>> with this parameter since the backport for TLSv1.2 came with Update
> >>> 95 [0]?
> >>> Since when does this requirement exist? Just checked it: I'm using UK
> >>> mirror [1]. This works without TLSv1.2. Maybe thats why i didn't
> >>> noticed before.
> >>> But we had problem at work contacting the Atlassian Repo from our Nexus
> >>> that ran with JDK 7 Update 80. In that case we switched back to JDK 6
> >>> Update 211.
> >>>
> >>> Cheers, Clemens
> >>>
> >>> [0]
> >>>
> https://stackoverflow.com/questions/49523052/how-to-enable-tlsv1-2-in-java-7u80-client
> >>>
> >>> [1] http://uk.maven.org/maven2/
> >>>
> >>> Am 22.07.2019 um 23:45 schrieb Robert Scholte:
> The plugin is indeed still Java 7 compatible, but that means you must
> execute it with -Dhttps.protocols=TLSv1.2 when building it with JDK 7,
> otherwise it'll fail because this is a requirement when downloading
> from Central.
> Our CI server scripts already add this argument when running with Java
> 7, on your local machine it must be done by hand. This is not
> restricted to the integration tests. Try to remove your local repo and
> start any project running with Maven and Java 7, it'll fail very fast,
> i.e. by the first plugin.
>
> thanks,
> Robert
>
> On Sun, 14 Jul 2019 11:52:15 +0200, Clemens Quoss
> wrote:
>
> > Hello everyone,
> >
> > I have provided a PR for MRELEASE-229 [1] and added some JUnit tests
> > recently.
> >
> > Now I was wondering if i should provide an IT, too, and had a look
> > into it:
> >
> > Running
> >
> > mvn verify -Prun-its
> >
> > with Maven 3.6.1 and JDK 7 Update 80 fails:
> >
> > ...
> >
> > [INFO] Building: projects\perform\MRELEASE-459\pom.xml
> > [INFO] run post-build script verify.groovy
> > [INFO] The post-build script did not succeed. assert matcher.find()
> > | |
> > | false
> > java.util.regex.Matcher[pattern=\Q[DEBUG] Additional
> > arguments: \E(?:-Dhttps.protocols=TLSv1.2
> > )?-P(.+)\Q-DperformRelease=true -f pom.xml\E region=0,154745
> > lastmatch=]
> > [INFO] projects\perform\MRELEASE-459\pom.xml
> > FAILED (10.4 s)
> >
> > ...
> >
> > IMHO it has something to do with TLSv1.2 not being backported to JDK
> > 7 Update 80. But i may be wrong.
> >
> > With JDK 8 Update 212 the tests run successfully.
> >
>
Re: ITs in maven-release
Hi Robert,
well it is already handled in the POM only for JDK 7:
...
jdk7
(,1.7]
org.apache.maven.plugins
maven-invoker-plugin
${https.protocols}
-Dhttps.protocols=${https.protocols}
...
Of course, this only takes care of when you release something with the
plugin using JDK 7. When building maven-release itself you will have to
provide the system property for JDK 7, but not when using UK mirror ;-)
Cheers, Clemens
Am 24.07.2019 um 23:20 schrieb Robert Scholte:
Hi Clemens,
We need to stay as close as possible to the real world.
With JDK8+ it should work without its being set, so the preferred way
it to execute it without the value being set.
And this way, once we must move TLS 1.3 we don't have to change all
our tests.
Here's how we do it with our Jenkins script[1], only activate it for
Java 7.
Robert
[1]
https://github.com/apache/maven-jenkins-lib/blob/master/vars/asfMavenTlpPlgnBuild.groovy#L128-L131
On Wed, 24 Jul 2019 23:03:22 +0200, Clemens Quoss
wrote:
Hi Robert,
if TLSv1.2 is needed, then why not put it explicitly into the pom in
line 266 [0] instead of using ${https.protocols}?
Cheers, Clemens
[0]
https://github.com/apache/maven-release/blob/a94c76f77ef8df1b82e9eef370412ce9b23083a0/maven-release-plugin/pom.xml#L266
Am 23.07.2019 um 19:33 schrieb Robert Scholte:
Hi Clemens,
please see
https://central.sonatype.org/articles/2018/May/04/discontinued-support-for-tlsv11-and-below/
We'll need to contact Sonatype and verify if they included
http://uk.maven.org/maven2/ as well (they should...)
However, AFAIK nowadays there's no need anymore to explicitly refer
to uk, it is already handled by Central CDN
thanks,
Robert
On 23-7-2019 00:01:06, Clemens Quoss wrote:
Hi Robert,
thanks for the insight. Shouldn't it fail with JDK 7 Update 80 even
with this parameter since the backport for TLSv1.2 came with Update
95 [0]?
Since when does this requirement exist? Just checked it: I'm using UK
mirror [1]. This works without TLSv1.2. Maybe thats why i didn't
noticed before.
But we had problem at work contacting the Atlassian Repo from our Nexus
that ran with JDK 7 Update 80. In that case we switched back to JDK 6
Update 211.
Cheers, Clemens
[0]
https://stackoverflow.com/questions/49523052/how-to-enable-tlsv1-2-in-java-7u80-client
[1] http://uk.maven.org/maven2/
Am 22.07.2019 um 23:45 schrieb Robert Scholte:
The plugin is indeed still Java 7 compatible, but that means you must
execute it with -Dhttps.protocols=TLSv1.2 when building it with JDK 7,
otherwise it'll fail because this is a requirement when downloading
from Central.
Our CI server scripts already add this argument when running with Java
7, on your local machine it must be done by hand. This is not
restricted to the integration tests. Try to remove your local repo and
start any project running with Maven and Java 7, it'll fail very fast,
i.e. by the first plugin.
thanks,
Robert
On Sun, 14 Jul 2019 11:52:15 +0200, Clemens Quoss
wrote:
Hello everyone,
I have provided a PR for MRELEASE-229 [1] and added some JUnit tests
recently.
Now I was wondering if i should provide an IT, too, and had a look
into it:
Running
mvn verify -Prun-its
with Maven 3.6.1 and JDK 7 Update 80 fails:
...
[INFO] Building: projects\perform\MRELEASE-459\pom.xml
[INFO] run post-build script verify.groovy
[INFO] The post-build script did not succeed. assert matcher.find()
| |
| false
java.util.regex.Matcher[pattern=\Q[DEBUG] Additional
arguments: \E(?:-Dhttps.protocols=TLSv1.2
)?-P(.+)\Q-DperformRelease=true -f pom.xml\E region=0,154745
lastmatch=]
[INFO] projects\perform\MRELEASE-459\pom.xml
FAILED (10.4 s)
...
IMHO it has something to do with TLSv1.2 not being backported to JDK
7 Update 80. But i may be wrong.
With JDK 8 Update 212 the tests run successfully.
My question is: Should the IT still run with JDK 7? I thought so
since maven-release can still be build with it. If some versions of
JDKs are not capable of being used for IT, shouldn't the IT run fail
fast (by enforcing the eligible versions)?
That was one question I have now redarding the ITs of maven-release.
I post my other questions in separate mails.
Regards,
Clemens
[1] https://github.com/apache/maven-release/pull/29
-
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
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mai
Re: ITs in maven-release
Hi Tibor, as I already stated I was completely unaware of this whole TLS-not-being-supported-below-1.2 anymore issue. And i just tried and build maven-release successfully with JDK 7 Update 80, but using the UK mirror eplicitly in my settings. I just tried it on my laptop with maven 3.6.1 and JDK 7 Update 80 and not using the UK mirror and i get, as expected: Caused by: javax.net.ssl.SSLException: Received fatal alert: protocol_version OK, then I provided -Dhttps.protocols=TLSv1.2 and it worked. Still, for the plugin i suggest to change lines 265/266 of POM to TLSv1.2 -Dhttps.protocols=TLSv1.2 since no other TLS version makes sense here, IMHO. Then there would be no need to provide a property when running the release plugin with JDK 7. Cheers, Clemens Am 24.07.2019 um 19:00 schrieb Tibor Digana: Hi Clemens, Does JDK 7u80 work for you on fresh empty local repo? It does not for me on Surefire project! The Maven fails downloading the artifacts from Maven Central this month. Before the build was okay. So I issued the ticket https://issues.apache.org/jira/browse/INFRA-18775 and I hope that our INFRA team will accept Zulu JDK from Azul Systems. The Zulu JDK is being maintained quite long. Of course the best decision would be to have extended support from the Oracle and use latest JDK but I am sceptical about it due to the Oracle's LTS is not free. Cheers Tibor On Tue, Jul 23, 2019 at 7:34 PM Robert Scholte wrote: Hi Clemens, please see https://central.sonatype.org/articles/2018/May/04/discontinued-support-for-tlsv11-and-below/ We'll need to contact Sonatype and verify if they included http://uk.maven.org/maven2/ as well (they should...) However, AFAIK nowadays there's no need anymore to explicitly refer to uk, it is already handled by Central CDN thanks, Robert On 23-7-2019 00:01:06, Clemens Quoss wrote: Hi Robert, thanks for the insight. Shouldn't it fail with JDK 7 Update 80 even with this parameter since the backport for TLSv1.2 came with Update 95 [0]? Since when does this requirement exist? Just checked it: I'm using UK mirror [1]. This works without TLSv1.2. Maybe thats why i didn't noticed before. But we had problem at work contacting the Atlassian Repo from our Nexus that ran with JDK 7 Update 80. In that case we switched back to JDK 6 Update 211. Cheers, Clemens [0] https://stackoverflow.com/questions/49523052/how-to-enable-tlsv1-2-in-java-7u80-client [1] http://uk.maven.org/maven2/ Am 22.07.2019 um 23:45 schrieb Robert Scholte: The plugin is indeed still Java 7 compatible, but that means you must execute it with -Dhttps.protocols=TLSv1.2 when building it with JDK 7, otherwise it'll fail because this is a requirement when downloading from Central. Our CI server scripts already add this argument when running with Java 7, on your local machine it must be done by hand. This is not restricted to the integration tests. Try to remove your local repo and start any project running with Maven and Java 7, it'll fail very fast, i.e. by the first plugin. thanks, Robert On Sun, 14 Jul 2019 11:52:15 +0200, Clemens Quoss wrote: Hello everyone, I have provided a PR for MRELEASE-229 [1] and added some JUnit tests recently. Now I was wondering if i should provide an IT, too, and had a look into it: Running mvn verify -Prun-its with Maven 3.6.1 and JDK 7 Update 80 fails: ... [INFO] Building: projects\perform\MRELEASE-459\pom.xml [INFO] run post-build script verify.groovy [INFO] The post-build script did not succeed. assert matcher.find() | | | false java.util.regex.Matcher[pattern=\Q[DEBUG] Additional arguments: \E(?:-Dhttps.protocols=TLSv1.2 )?-P(.+)\Q-DperformRelease=true -f pom.xml\E region=0,154745 lastmatch=] [INFO] projects\perform\MRELEASE-459\pom.xml FAILED (10.4 s) ... IMHO it has something to do with TLSv1.2 not being backported to JDK 7 Update 80. But i may be wrong. With JDK 8 Update 212 the tests run successfully. My question is: Should the IT still run with JDK 7? I thought so since maven-release can still be build with it. If some versions of JDKs are not capable of being used for IT, shouldn't the IT run fail fast (by enforcing the eligible versions)? That was one question I have now redarding the ITs of maven-release. I post my other questions in separate mails. Regards, Clemens [1] https://github.com/apache/maven-release/pull/29 - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apac
Re: ITs in maven-release
Hi Clemens,
We need to stay as close as possible to the real world.
With JDK8+ it should work without its being set, so the preferred way it
to execute it without the value being set.
And this way, once we must move TLS 1.3 we don't have to change all our
tests.
Here's how we do it with our Jenkins script[1], only activate it for Java
7.
Robert
[1]
https://github.com/apache/maven-jenkins-lib/blob/master/vars/asfMavenTlpPlgnBuild.groovy#L128-L131
On Wed, 24 Jul 2019 23:03:22 +0200, Clemens Quoss wrote:
Hi Robert,
if TLSv1.2 is needed, then why not put it explicitly into the pom in
line 266 [0] instead of using ${https.protocols}?
Cheers, Clemens
[0]
https://github.com/apache/maven-release/blob/a94c76f77ef8df1b82e9eef370412ce9b23083a0/maven-release-plugin/pom.xml#L266
Am 23.07.2019 um 19:33 schrieb Robert Scholte:
Hi Clemens,
please see
https://central.sonatype.org/articles/2018/May/04/discontinued-support-for-tlsv11-and-below/
We'll need to contact Sonatype and verify if they included
http://uk.maven.org/maven2/ as well (they should...)
However, AFAIK nowadays there's no need anymore to explicitly refer to
uk, it is already handled by Central CDN
thanks,
Robert
On 23-7-2019 00:01:06, Clemens Quoss wrote:
Hi Robert,
thanks for the insight. Shouldn't it fail with JDK 7 Update 80 even
with this parameter since the backport for TLSv1.2 came with Update 95
[0]?
Since when does this requirement exist? Just checked it: I'm using UK
mirror [1]. This works without TLSv1.2. Maybe thats why i didn't
noticed before.
But we had problem at work contacting the Atlassian Repo from our Nexus
that ran with JDK 7 Update 80. In that case we switched back to JDK 6
Update 211.
Cheers, Clemens
[0]
https://stackoverflow.com/questions/49523052/how-to-enable-tlsv1-2-in-java-7u80-client
[1] http://uk.maven.org/maven2/
Am 22.07.2019 um 23:45 schrieb Robert Scholte:
The plugin is indeed still Java 7 compatible, but that means you must
execute it with -Dhttps.protocols=TLSv1.2 when building it with JDK 7,
otherwise it'll fail because this is a requirement when downloading
from Central.
Our CI server scripts already add this argument when running with Java
7, on your local machine it must be done by hand. This is not
restricted to the integration tests. Try to remove your local repo and
start any project running with Maven and Java 7, it'll fail very fast,
i.e. by the first plugin.
thanks,
Robert
On Sun, 14 Jul 2019 11:52:15 +0200, Clemens Quoss
wrote:
Hello everyone,
I have provided a PR for MRELEASE-229 [1] and added some JUnit tests
recently.
Now I was wondering if i should provide an IT, too, and had a look
into it:
Running
mvn verify -Prun-its
with Maven 3.6.1 and JDK 7 Update 80 fails:
...
[INFO] Building: projects\perform\MRELEASE-459\pom.xml
[INFO] run post-build script verify.groovy
[INFO] The post-build script did not succeed. assert matcher.find()
| |
| false
java.util.regex.Matcher[pattern=\Q[DEBUG] Additional
arguments: \E(?:-Dhttps.protocols=TLSv1.2
)?-P(.+)\Q-DperformRelease=true -f pom.xml\E region=0,154745
lastmatch=]
[INFO] projects\perform\MRELEASE-459\pom.xml
FAILED (10.4 s)
...
IMHO it has something to do with TLSv1.2 not being backported to JDK
7 Update 80. But i may be wrong.
With JDK 8 Update 212 the tests run successfully.
My question is: Should the IT still run with JDK 7? I thought so
since maven-release can still be build with it. If some versions of
JDKs are not capable of being used for IT, shouldn't the IT run fail
fast (by enforcing the eligible versions)?
That was one question I have now redarding the ITs of maven-release.
I post my other questions in separate mails.
Regards,
Clemens
[1] https://github.com/apache/maven-release/pull/29
-
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
-
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: [VOTE] Release Maven Site Plugin version 3.8.2
+1 On Wed, Jul 24, 2019 at 9:59 PM Michael Osipov wrote: > Hi, > > We solved 13 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923&version=12343145 > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20resolution%20%3D%20Unresolved > > Staging repo: > https://repository.apache.org/content/repositories/maven-1521/ > > https://repository.apache.org/content/repositories/maven-1521/org/apache/maven/plugins/maven-site-plugin/3.8.2/maven-site-plugin-3.8.2-source-release.zip > > Source release checksum(s): > maven-site-plugin-3.8.2-source-release.zip > sha512: > > 3567b4cb0cee7806ced776243d5d6764eed8f5b09a478b127044f2ccfd9fe9ec8ad4e6f9473aace41482e8c66733731da2d71a2d0d8e91cdf7876a4d6d2ecf52 > > Staging site: > https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: ITs in maven-release
Hi Robert,
if TLSv1.2 is needed, then why not put it explicitly into the pom in
line 266 [0] instead of using ${https.protocols}?
Cheers, Clemens
[0]
https://github.com/apache/maven-release/blob/a94c76f77ef8df1b82e9eef370412ce9b23083a0/maven-release-plugin/pom.xml#L266
Am 23.07.2019 um 19:33 schrieb Robert Scholte:
Hi Clemens,
please see
https://central.sonatype.org/articles/2018/May/04/discontinued-support-for-tlsv11-and-below/
We'll need to contact Sonatype and verify if they included
http://uk.maven.org/maven2/ as well (they should...)
However, AFAIK nowadays there's no need anymore to explicitly refer to uk, it
is already handled by Central CDN
thanks,
Robert
On 23-7-2019 00:01:06, Clemens Quoss wrote:
Hi Robert,
thanks for the insight. Shouldn't it fail with JDK 7 Update 80 even
with this parameter since the backport for TLSv1.2 came with Update 95 [0]?
Since when does this requirement exist? Just checked it: I'm using UK
mirror [1]. This works without TLSv1.2. Maybe thats why i didn't
noticed before.
But we had problem at work contacting the Atlassian Repo from our Nexus
that ran with JDK 7 Update 80. In that case we switched back to JDK 6
Update 211.
Cheers, Clemens
[0]
https://stackoverflow.com/questions/49523052/how-to-enable-tlsv1-2-in-java-7u80-client
[1] http://uk.maven.org/maven2/
Am 22.07.2019 um 23:45 schrieb Robert Scholte:
The plugin is indeed still Java 7 compatible, but that means you must
execute it with -Dhttps.protocols=TLSv1.2 when building it with JDK 7,
otherwise it'll fail because this is a requirement when downloading
from Central.
Our CI server scripts already add this argument when running with Java
7, on your local machine it must be done by hand. This is not
restricted to the integration tests. Try to remove your local repo and
start any project running with Maven and Java 7, it'll fail very fast,
i.e. by the first plugin.
thanks,
Robert
On Sun, 14 Jul 2019 11:52:15 +0200, Clemens Quoss
wrote:
Hello everyone,
I have provided a PR for MRELEASE-229 [1] and added some JUnit tests
recently.
Now I was wondering if i should provide an IT, too, and had a look
into it:
Running
mvn verify -Prun-its
with Maven 3.6.1 and JDK 7 Update 80 fails:
...
[INFO] Building: projects\perform\MRELEASE-459\pom.xml
[INFO] run post-build script verify.groovy
[INFO] The post-build script did not succeed. assert matcher.find()
| |
| false
java.util.regex.Matcher[pattern=\Q[DEBUG] Additional
arguments: \E(?:-Dhttps.protocols=TLSv1.2
)?-P(.+)\Q-DperformRelease=true -f pom.xml\E region=0,154745 lastmatch=]
[INFO] projects\perform\MRELEASE-459\pom.xml
FAILED (10.4 s)
...
IMHO it has something to do with TLSv1.2 not being backported to JDK
7 Update 80. But i may be wrong.
With JDK 8 Update 212 the tests run successfully.
My question is: Should the IT still run with JDK 7? I thought so
since maven-release can still be build with it. If some versions of
JDKs are not capable of being used for IT, shouldn't the IT run fail
fast (by enforcing the eligible versions)?
That was one question I have now redarding the ITs of maven-release.
I post my other questions in separate mails.
Regards,
Clemens
[1] https://github.com/apache/maven-release/pull/29
-
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
-
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: [VOTE] Release Maven Site Plugin version 3.8.2
Am 2019-07-24 um 21:59 schrieb Michael Osipov: Hi, We solved 13 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923&version=12343145 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20resolution%20%3D%20Unresolved Staging repo: https://repository.apache.org/content/repositories/maven-1521/ https://repository.apache.org/content/repositories/maven-1521/org/apache/maven/plugins/maven-site-plugin/3.8.2/maven-site-plugin-3.8.2-source-release.zip Source release checksum(s): maven-site-plugin-3.8.2-source-release.zip sha512: 3567b4cb0cee7806ced776243d5d6764eed8f5b09a478b127044f2ccfd9fe9ec8ad4e6f9473aace41482e8c66733731da2d71a2d0d8e91cdf7876a4d6d2ecf52 Staging site: https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. +1, my last try... - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Maven Site Plugin version 3.8.2
Hi, We solved 13 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923&version=12343145 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20resolution%20%3D%20Unresolved Staging repo: https://repository.apache.org/content/repositories/maven-1521/ https://repository.apache.org/content/repositories/maven-1521/org/apache/maven/plugins/maven-site-plugin/3.8.2/maven-site-plugin-3.8.2-source-release.zip Source release checksum(s): maven-site-plugin-3.8.2-source-release.zip sha512: 3567b4cb0cee7806ced776243d5d6764eed8f5b09a478b127044f2ccfd9fe9ec8ad4e6f9473aace41482e8c66733731da2d71a2d0d8e91cdf7876a4d6d2ecf52 Staging site: https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: ITs in maven-release
Hi Clemens, Does JDK 7u80 work for you on fresh empty local repo? It does not for me on Surefire project! The Maven fails downloading the artifacts from Maven Central this month. Before the build was okay. So I issued the ticket https://issues.apache.org/jira/browse/INFRA-18775 and I hope that our INFRA team will accept Zulu JDK from Azul Systems. The Zulu JDK is being maintained quite long. Of course the best decision would be to have extended support from the Oracle and use latest JDK but I am sceptical about it due to the Oracle's LTS is not free. Cheers Tibor On Tue, Jul 23, 2019 at 7:34 PM Robert Scholte wrote: > Hi Clemens, > > please see > https://central.sonatype.org/articles/2018/May/04/discontinued-support-for-tlsv11-and-below/ > We'll need to contact Sonatype and verify if they included > http://uk.maven.org/maven2/ as well (they should...) > > However, AFAIK nowadays there's no need anymore to explicitly refer to uk, > it is already handled by Central CDN > > thanks, > Robert > On 23-7-2019 00:01:06, Clemens Quoss wrote: > Hi Robert, > thanks for the insight. Shouldn't it fail with JDK 7 Update 80 even > with this parameter since the backport for TLSv1.2 came with Update 95 [0]? > Since when does this requirement exist? Just checked it: I'm using UK > mirror [1]. This works without TLSv1.2. Maybe thats why i didn't > noticed before. > But we had problem at work contacting the Atlassian Repo from our Nexus > that ran with JDK 7 Update 80. In that case we switched back to JDK 6 > Update 211. > > Cheers, Clemens > > [0] > > https://stackoverflow.com/questions/49523052/how-to-enable-tlsv1-2-in-java-7u80-client > [1] http://uk.maven.org/maven2/ > > Am 22.07.2019 um 23:45 schrieb Robert Scholte: > > The plugin is indeed still Java 7 compatible, but that means you must > > execute it with -Dhttps.protocols=TLSv1.2 when building it with JDK 7, > > otherwise it'll fail because this is a requirement when downloading > > from Central. > > Our CI server scripts already add this argument when running with Java > > 7, on your local machine it must be done by hand. This is not > > restricted to the integration tests. Try to remove your local repo and > > start any project running with Maven and Java 7, it'll fail very fast, > > i.e. by the first plugin. > > > > thanks, > > Robert > > > > On Sun, 14 Jul 2019 11:52:15 +0200, Clemens Quoss > > wrote: > > > >> Hello everyone, > >> > >> I have provided a PR for MRELEASE-229 [1] and added some JUnit tests > >> recently. > >> > >> Now I was wondering if i should provide an IT, too, and had a look > >> into it: > >> > >> Running > >> > >> mvn verify -Prun-its > >> > >> with Maven 3.6.1 and JDK 7 Update 80 fails: > >> > >> ... > >> > >> [INFO] Building: projects\perform\MRELEASE-459\pom.xml > >> [INFO] run post-build script verify.groovy > >> [INFO] The post-build script did not succeed. assert matcher.find() > >> | | > >> | false > >> java.util.regex.Matcher[pattern=\Q[DEBUG] Additional > >> arguments: \E(?:-Dhttps.protocols=TLSv1.2 > >> )?-P(.+)\Q-DperformRelease=true -f pom.xml\E region=0,154745 lastmatch=] > >> [INFO] projects\perform\MRELEASE-459\pom.xml > >> FAILED (10.4 s) > >> > >> ... > >> > >> IMHO it has something to do with TLSv1.2 not being backported to JDK > >> 7 Update 80. But i may be wrong. > >> > >> With JDK 8 Update 212 the tests run successfully. > >> > >> My question is: Should the IT still run with JDK 7? I thought so > >> since maven-release can still be build with it. If some versions of > >> JDKs are not capable of being used for IT, shouldn't the IT run fail > >> fast (by enforcing the eligible versions)? > >> > >> That was one question I have now redarding the ITs of maven-release. > >> I post my other questions in separate mails. > >> > >> Regards, > >> > >> Clemens > >> > >> [1] https://github.com/apache/maven-release/pull/29 > >> > >> > >> > >> - > >> 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 > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)
Il mer 24 lug 2019, 10:02 Tibor Digana ha scritto: > Hi Enrico, > > Do we have a statement from vendors of PMD and/or Checkstyle libraries that > their rules would turn to platform independence? > I know there was a pull request on GitHub and a promis with the release (I > guess PMD). > Once we would have these libraries with modified default values in favor of > platform non-sensitive EOL rules, we would not have to apapt our > integration tests to platform. > I think that Checkstyle has been released and we should upgrade it. Enrico > Cheers > Tibor > > > On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli > wrote: > > > I will get a windows box and try to reproduce. > > It is weird that on ASF Jenkins the build is passing even on windows > > > > Enrico > > > > -- Forwarded message - > > Da: Enrico Olivelli > > Date: mar 14 mag 2019, 13:58 > > Subject: Re: [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0 > > To: Maven Developers List > > > > > > Eric and Tibor, > > Thank you so much for your effort in testing Maven Checkstyle Plugin. > > > > This is the "official" VOTE thread, here we have to decide if the staged > > artifacts are good to be released or not. > > > > Feel free to cast a -1 if you think that the staged artifacts are not > > "stable" or there is any showstopper problem for the release. > > > > Let's move this discussion to a separate thread, something like > "Validation > > failures in Windows over current checkstyle plugin master branch") > > > > Enrico > > > > > > > > > > Il giorno mar 14 mag 2019 alle ore 13:51 Eric Lilja < > mindcoo...@gmail.com> > > ha scritto: > > > > > Tried overriding line.separator when running using > -Dline.separator="\n", > > > but then the builds fails (early) in maven-plugin-plugin: > > > [ERROR] Failed to execute goal > > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor > > > (default-descriptor) on project maven-checkstyle-plugin: Execution > > > default-descriptor of goal > > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: > > > Requested line separator is invalid. -> [Help 1] > > > [ERROR] > > > [ERROR] To see the full stack trace of the errors, re-run Maven with > the > > -e > > > switch. > > > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > > > [ERROR] > > > [ERROR] For more information about the errors and possible solutions, > > > please read the following articles: > > > [ERROR] [Help 1] > > > > > > http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException > > > > > > Tried upgrading maven-plugin-plugin to 3.6.0 (lots of stuff > > > upgradeable...), but same error > > > > > > I also happened to notice this (probably unrelated, but wanted to bring > > it > > > to attention anyway so it can be fixed) warning: > > > [INFO] java-annotations mojo extractor found 4 mojo descriptors. > > > [WARNING] > > > > > > Unexpected situation: destinationDirectory not defined in > > > maven-plugin-help.properties during help mojo source generation but > > > expected during XML descriptor generation. > > > [WARNING] Please check helpmojo goal version used in previous build > > phase. > > > [WARNING] If you just upgraded to plugin-tools >= 3.2 you must run a > > clean > > > build at least once. > > > [WARNING] Trying default location: target\generated-sources\plugin > > > > > > - Eric L > > > > > > On Tue, May 14, 2019 at 11:04 AM Eric Lilja > > wrote: > > > > > > > I tried bumping checkstyle to 8.20, plus a few of the plexus > > > dependencies, > > > > but that just brought an additional failure... (to > > > > MCHECKSTYLE-70-multi-sourcefolder\pom.xml) :-) > > > > > > > > I suppose the problem might be that the files has linux-style line > > breaks > > > > (this is desired for me, I don't want to convert to windows-style > line > > > > breaks locally), but the test think I should have windows-style line > > > > separators. It seems these files are generated by the tests because I > > > tried > > > > changing them to Windows style line breaks for re-running just to see > > if > > > > that would work, but those changes were overwritten) > > > > > > > > - Eric L > > > > > > > > On Tue, May 14, 2019 at 10:38 AM Eric Lilja > > > wrote: > > > > > > > >> I also see a failure for MCHECKSTYLE-54 on Windows. (Sorry, I didn't > > try > > > >> the source zip, just cloned master) > > > >> > > > >> I tested on one of our corporate laptops: > > > >> Windows 10 > > > >> Cygwin 64-bit (I use it to clone the repo and use Maven) > > > >> Maven 3.6.0 > > > >> Java 8 update 202 > > > >> > > > >> The build log says: > > > >> [INFO] There are 2 errors reported by Checkstyle 8.19 with > > > sun_checks.xml > > > >> ruleset. > > > >> [ERROR] > > > >> > > > > > > src\main\java\org\apache\maven\plugins\checkstyle\mcheckstyle54\Mcheckstyle54.java:[1] > > > >> (misc) NewlineAtEndOfFile: File does not end with a newline. > > > >> [ERROR] > > > >> > > > > > > src\main\java\org\apache\maven\pl
Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)
Hi Enrico, Do we have a statement from vendors of PMD and/or Checkstyle libraries that their rules would turn to platform independence? I know there was a pull request on GitHub and a promis with the release (I guess PMD). Once we would have these libraries with modified default values in favor of platform non-sensitive EOL rules, we would not have to apapt our integration tests to platform. Cheers Tibor On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli wrote: > I will get a windows box and try to reproduce. > It is weird that on ASF Jenkins the build is passing even on windows > > Enrico > > -- Forwarded message - > Da: Enrico Olivelli > Date: mar 14 mag 2019, 13:58 > Subject: Re: [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0 > To: Maven Developers List > > > Eric and Tibor, > Thank you so much for your effort in testing Maven Checkstyle Plugin. > > This is the "official" VOTE thread, here we have to decide if the staged > artifacts are good to be released or not. > > Feel free to cast a -1 if you think that the staged artifacts are not > "stable" or there is any showstopper problem for the release. > > Let's move this discussion to a separate thread, something like "Validation > failures in Windows over current checkstyle plugin master branch") > > Enrico > > > > > Il giorno mar 14 mag 2019 alle ore 13:51 Eric Lilja > ha scritto: > > > Tried overriding line.separator when running using -Dline.separator="\n", > > but then the builds fails (early) in maven-plugin-plugin: > > [ERROR] Failed to execute goal > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor > > (default-descriptor) on project maven-checkstyle-plugin: Execution > > default-descriptor of goal > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: > > Requested line separator is invalid. -> [Help 1] > > [ERROR] > > [ERROR] To see the full stack trace of the errors, re-run Maven with the > -e > > switch. > > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > > [ERROR] > > [ERROR] For more information about the errors and possible solutions, > > please read the following articles: > > [ERROR] [Help 1] > > > http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException > > > > Tried upgrading maven-plugin-plugin to 3.6.0 (lots of stuff > > upgradeable...), but same error > > > > I also happened to notice this (probably unrelated, but wanted to bring > it > > to attention anyway so it can be fixed) warning: > > [INFO] java-annotations mojo extractor found 4 mojo descriptors. > > [WARNING] > > > > Unexpected situation: destinationDirectory not defined in > > maven-plugin-help.properties during help mojo source generation but > > expected during XML descriptor generation. > > [WARNING] Please check helpmojo goal version used in previous build > phase. > > [WARNING] If you just upgraded to plugin-tools >= 3.2 you must run a > clean > > build at least once. > > [WARNING] Trying default location: target\generated-sources\plugin > > > > - Eric L > > > > On Tue, May 14, 2019 at 11:04 AM Eric Lilja > wrote: > > > > > I tried bumping checkstyle to 8.20, plus a few of the plexus > > dependencies, > > > but that just brought an additional failure... (to > > > MCHECKSTYLE-70-multi-sourcefolder\pom.xml) :-) > > > > > > I suppose the problem might be that the files has linux-style line > breaks > > > (this is desired for me, I don't want to convert to windows-style line > > > breaks locally), but the test think I should have windows-style line > > > separators. It seems these files are generated by the tests because I > > tried > > > changing them to Windows style line breaks for re-running just to see > if > > > that would work, but those changes were overwritten) > > > > > > - Eric L > > > > > > On Tue, May 14, 2019 at 10:38 AM Eric Lilja > > wrote: > > > > > >> I also see a failure for MCHECKSTYLE-54 on Windows. (Sorry, I didn't > try > > >> the source zip, just cloned master) > > >> > > >> I tested on one of our corporate laptops: > > >> Windows 10 > > >> Cygwin 64-bit (I use it to clone the repo and use Maven) > > >> Maven 3.6.0 > > >> Java 8 update 202 > > >> > > >> The build log says: > > >> [INFO] There are 2 errors reported by Checkstyle 8.19 with > > sun_checks.xml > > >> ruleset. > > >> [ERROR] > > >> > > > src\main\java\org\apache\maven\plugins\checkstyle\mcheckstyle54\Mcheckstyle54.java:[1] > > >> (misc) NewlineAtEndOfFile: File does not end with a newline. > > >> [ERROR] > > >> > > > src\main\java\org\apache\maven\plugins\checkstyle\mcheckstyle54\package-info.java:[1] > > >> (misc) NewlineAtEndOfFile: File does not end with a newline. > > >> > > >> These two files end with unix-style line breaks (as expected with my > > >> setup). > > >> > > >> - Eric L > > >> > > >> > > >> On Tue, May 14, 2019 at 8:10 AM Enrico Olivelli > > >> wrote: > > >> > > >>> Il lun 13 mag 2019, 23:48 Tibor Digana ha > > >>> scritto: > > >>> > > >>> > Robert, I did *not*
