ITs in maven-release

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

ITs in maven-release

Clemens Quoss
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ITs in maven-release

Clemens Quoss
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 <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ITs in maven-release

Robert Scholte-8
Hi Tibor,

off topic, but step 3 should of course be verify...

I can't reproduce it, nor can Jenkins@ASF, see
https://builds.apache.org/job/maven-box/job/maven-resolver/job/master/

Based on the exception I would expect that the runtime is Java 7, not Java  
8.
Please verify the complete logfile, ensure it starts with mvn -V to see  
the version output.

thanks,
Robert


On Fri, 26 Jul 2019 16:41:58 +0200, Tibor Digana <[hidden email]>  
wrote:

> Hi Robert,
>
> I have very similar issue in  apache/maven-resolver on my PC.
> I don't know if the root cause is identical with the one you described in
> your email regarding the parameter mavenOpts and shared environment
> variable but I am sure you can reproduce it too.
> These are my reprosteps:
>
> 1. clone the project apache/maven-resolver
> 2. use JDK 1.8 in JAVA_HOME
> 3. run the build "mvn install -P run-its"
>
> The build fails with:
>
> [ERROR] The following builds failed:
> The following builds failed:
> *  build-and-run-its\pom.xml
> *  build-archetype\pom.xml
> *  build-ignore-eol\pom.xml
>
> When you open
> maven-archetype-plugin/target/it/projects/build-and-run-its/build.log you
> will have the error which is typical for JDK7. The issue is that I  
> executed
> the build with JDK8.
> "Received fatal alert: protocol_version".
>
> Here is my console output:
>
> [INFO] [INFO] --------------------------------[ jar
> ]---------------------------------
> [INFO] [INFO] Downloading from local.central:
> file:///C:/vcs/github/maven-archetype/maven-archetype-plugin/target/local-repo/org/apache/maven/plugins/maven-resources-plugin/2.6/maven-resources-plugin-2.6.pom
> [INFO] [INFO] Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-resources-plugin/2.6/maven-resources-plugin-2.6.pom
> [INFO] [INFO]  
> ------------------------------------------------------------------------
> [INFO] [INFO] BUILD FAILURE
> [INFO] [INFO]  
> ------------------------------------------------------------------------
> [INFO] [INFO] Total time:  1.286 s
> [INFO] [INFO] Finished at: 2019-07-26T14:15:54+02:00
> [INFO] [INFO]  
> ------------------------------------------------------------------------
> [INFO] [ERROR] Plugin
> org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its
> dependencies could not be resolved: Failed to read artifact descriptor
> for org.apache.maven.plugins:maven-resources-plugin:jar:2.6: Could not
> transfer artifact
> org.apache.maven.plugins:maven-resources-plugin:pom:2.6 from/to
> central (https://repo.maven.apache.org/maven2): Received fatal alert:
> protocol_version -> [Help 1]
> [INFO] org.apache.maven.plugin.PluginResolutionException: Plugin
> org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its
> dependencies could not be resolved: Failed to read artifact descriptor
> for org.apache.maven.plugins:maven-resources-plugin:jar:2.6
> [INFO]     at  
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve
> (DefaultPluginDependenciesResolver.java:117)
> [INFO]     at  
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor
> (DefaultMavenPluginManager.java:182)
>
>
>
>
>
>
> On Fri, Jul 26, 2019 at 1:23 PM Robert Scholte <[hidden email]>  
> wrote:
>
>> Looks like the same issue as there was with the maven site plugin: the
>> failing it was using mavenOpts as well.
>> I'm pretty sure that mavenOpts is not isolated and can be changed by any
>> other process on the same server.
>> Instead one should be using test.properties to pass those properties,
>> which are isolated.
>>
>> Robert
>>
>> On Thu, 25 Jul 2019 14:20:53 +0200, Tibor Digana  
>> <[hidden email]>
>>
>> wrote:
>>
>> > Just one remark from me:
>> > I have got successful build with Surefire but it is strange because I
>> > cannot explain why my change did it successful ;-) - pls help to
>> explain
>> > it:
>> > https://builds.apache.org/job/maven-box/job/maven-surefire/job/TLS1.2/
>> >
>> > Before I did this in the configuration of "maven-invoker-plugin":
>> > <mavenOpts>-Dhttps.protocols=TLSv1.2</mavenOpts>
>> > and the the build always failed on JDK7.
>> >
>> > Then I pushed a branch named "TLS1.2" and added system property:
>> > The build is successful now!. But why? The Maven JVM is a forked  
>> process,
>> > isn't it?
>> > Both, the MAVEN_OPTS and system properties should go to the CLI
>> > arguments,
>> > right? So there should not be any difference but obviously there is!
>> >
>> > <properties>
>> >     <https.protocols>TLSv1.2</https.protocols>
>> > </properties>
>> >
>> > Thx for clarification in advance!
>> > Tibor
>> >
>> >
>> > On Thu, Jul 25, 2019 at 8:38 AM Robert Scholte <[hidden email]>
>> > wrote:
>> >
>> >> 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 <[hidden email]>
>> >> wrote:
>> >>
>> >> > Hi Robert,
>> >> > well it is already handled in the POM only for JDK 7:
>> >> >
>> >> > ...
>> >> >      <profile>
>> >> >        <id>jdk7</id>
>> >> >        <activation>
>> >> >          <jdk>(,1.7]</jdk>
>> >> >        </activation>
>> >> >        <build>
>> >> >          <plugins>
>> >> >            <plugin>
>> >> > <groupId>org.apache.maven.plugins</groupId>
>> >> > <artifactId>maven-invoker-plugin</artifactId>
>> >> >              <configuration>
>> >> >                <properties combine.children="merge">
>> >> > <https.protocols>${https.protocols}</https.protocols>
>> >> > <arguments>-Dhttps.protocols=${https.protocols}</arguments>
>> >> >                </properties>
>> >> >              </configuration>
>> >> >            </plugin>
>> >> >          </plugins>
>> >> >        </build>
>> >> >      </profile>
>> >> > ...
>> >> >
>> >> > 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  
>> <[hidden email]>
>> >> >> 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 <[hidden email]> 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: [hidden email]
>> >> >>>>>> For additional commands, e-mail: [hidden email]
>> >> >>>>>
>> >> ---------------------------------------------------------------------
>> >> >>>>> To unsubscribe, e-mail: [hidden email]
>> >> >>>>> For additional commands, e-mail: [hidden email]
>> >> >>>>>
>> >> >>>>
>> >> ---------------------------------------------------------------------
>> >> >>>> To unsubscribe, e-mail: [hidden email]
>> >> >>>> For additional commands, e-mail: [hidden email]
>> >> >>>>
>> >> >>
>> >> >>  
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: [hidden email]
>> >> >> For additional commands, e-mail: [hidden email]
>> >> >>
>> >> >
>> >> >  
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: [hidden email]
>> >> > For additional commands, e-mail: [hidden email]
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ITs in maven-release

Tibor Digana
Hi Robert,

I was investigating this issue long. The problem was with IDEA. Yesterday I
installed new version 2019.2 and set JDK 1.7 as system JAVA_HOME but the
project used JDK 1.8, see [1].
Suddenly, the maven-invoker-plugin used JAVA_HOME from the system and not
from IDEA settings. It wasn't problem of invoker but IDEA which used system
Java. I don't have explanation why it is so however Maven prented right
Java [1].

After I used native  commandline, the build has passed successfully.
To confirm this, I used build-helper-maven-plugin, wrote BeanShell script,
printed JAVA_HOME in the integration test "build-archetype".

Altogether, our Jenkins is okay on apache/maven-resolver. The only problem
was with my development tool!
No worries in this case!

[1]:
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T21:00:29+02:00)
Maven home: C:\Program Files\JetBrains\IntelliJ IDEA Community Edition
2019.2\plugins\maven\lib\maven3
Java version: 1.8.0_212, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.8.0_212\jre



On Fri, Jul 26, 2019 at 8:55 PM Robert Scholte <[hidden email]> wrote:

> Hi Tibor,
>
> off topic, but step 3 should of course be verify...
>
> I can't reproduce it, nor can Jenkins@ASF, see
> https://builds.apache.org/job/maven-box/job/maven-resolver/job/master/
>
> Based on the exception I would expect that the runtime is Java 7, not
> Java
> 8.
> Please verify the complete logfile, ensure it starts with mvn -V to see
> the version output.
>
> thanks,
> Robert
>
>
> On Fri, 26 Jul 2019 16:41:58 +0200, Tibor Digana <[hidden email]>
>
> wrote:
>
> > Hi Robert,
> >
> > I have very similar issue in  apache/maven-resolver on my PC.
> > I don't know if the root cause is identical with the one you described in
> > your email regarding the parameter mavenOpts and shared environment
> > variable but I am sure you can reproduce it too.
> > These are my reprosteps:
> >
> > 1. clone the project apache/maven-resolver
> > 2. use JDK 1.8 in JAVA_HOME
> > 3. run the build "mvn install -P run-its"
> >
> > The build fails with:
> >
> > [ERROR] The following builds failed:
> > The following builds failed:
> > *  build-and-run-its\pom.xml
> > *  build-archetype\pom.xml
> > *  build-ignore-eol\pom.xml
> >
> > When you open
> > maven-archetype-plugin/target/it/projects/build-and-run-its/build.log you
> > will have the error which is typical for JDK7. The issue is that I
> > executed
> > the build with JDK8.
> > "Received fatal alert: protocol_version".
> >
> > Here is my console output:
> >
> > [INFO] [INFO] --------------------------------[ jar
> > ]---------------------------------
> > [INFO] [INFO] Downloading from local.central:
> >
> file:///C:/vcs/github/maven-archetype/maven-archetype-plugin/target/local-repo/org/apache/maven/plugins/maven-resources-plugin/2.6/maven-resources-plugin-2.6.pom
> > [INFO] [INFO] Downloading from central:
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-resources-plugin/2.6/maven-resources-plugin-2.6.pom
> > [INFO] [INFO]
> > ------------------------------------------------------------------------
> > [INFO] [INFO] BUILD FAILURE
> > [INFO] [INFO]
> > ------------------------------------------------------------------------
> > [INFO] [INFO] Total time:  1.286 s
> > [INFO] [INFO] Finished at: 2019-07-26T14:15:54+02:00
> > [INFO] [INFO]
> > ------------------------------------------------------------------------
> > [INFO] [ERROR] Plugin
> > org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its
> > dependencies could not be resolved: Failed to read artifact descriptor
> > for org.apache.maven.plugins:maven-resources-plugin:jar:2.6: Could not
> > transfer artifact
> > org.apache.maven.plugins:maven-resources-plugin:pom:2.6 from/to
> > central (https://repo.maven.apache.org/maven2): Received fatal alert:
> > protocol_version -> [Help 1]
> > [INFO] org.apache.maven.plugin.PluginResolutionException: Plugin
> > org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its
> > dependencies could not be resolved: Failed to read artifact descriptor
> > for org.apache.maven.plugins:maven-resources-plugin:jar:2.6
> > [INFO]     at
> >
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve
> > (DefaultPluginDependenciesResolver.java:117)
> > [INFO]     at
> >
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor
> > (DefaultMavenPluginManager.java:182)
> >
> >
> >
> >
> >
> >
> > On Fri, Jul 26, 2019 at 1:23 PM Robert Scholte <[hidden email]>
> > wrote:
> >
> >> Looks like the same issue as there was with the maven site plugin: the
> >> failing it was using mavenOpts as well.
> >> I'm pretty sure that mavenOpts is not isolated and can be changed by any
> >> other process on the same server.
> >> Instead one should be using test.properties to pass those properties,
> >> which are isolated.
> >>
> >> Robert
> >>
> >> On Thu, 25 Jul 2019 14:20:53 +0200, Tibor Digana
> >> <[hidden email]>
> >>
> >> wrote:
> >>
> >> > Just one remark from me:
> >> > I have got successful build with Surefire but it is strange because I
> >> > cannot explain why my change did it successful ;-) - pls help to
> >> explain
> >> > it:
> >> >
> https://builds.apache.org/job/maven-box/job/maven-surefire/job/TLS1.2/
> >> >
> >> > Before I did this in the configuration of "maven-invoker-plugin":
> >> > <mavenOpts>-Dhttps.protocols=TLSv1.2</mavenOpts>
> >> > and the the build always failed on JDK7.
> >> >
> >> > Then I pushed a branch named "TLS1.2" and added system property:
> >> > The build is successful now!. But why? The Maven JVM is a forked
> >> process,
> >> > isn't it?
> >> > Both, the MAVEN_OPTS and system properties should go to the CLI
> >> > arguments,
> >> > right? So there should not be any difference but obviously there is!
> >> >
> >> > <properties>
> >> >     <https.protocols>TLSv1.2</https.protocols>
> >> > </properties>
> >> >
> >> > Thx for clarification in advance!
> >> > Tibor
> >> >
> >> >
> >> > On Thu, Jul 25, 2019 at 8:38 AM Robert Scholte <[hidden email]>
> >> > wrote:
> >> >
> >> >> 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 <[hidden email]>
> >> >> wrote:
> >> >>
> >> >> > Hi Robert,
> >> >> > well it is already handled in the POM only for JDK 7:
> >> >> >
> >> >> > ...
> >> >> >      <profile>
> >> >> >        <id>jdk7</id>
> >> >> >        <activation>
> >> >> >          <jdk>(,1.7]</jdk>
> >> >> >        </activation>
> >> >> >        <build>
> >> >> >          <plugins>
> >> >> >            <plugin>
> >> >> > <groupId>org.apache.maven.plugins</groupId>
> >> >> > <artifactId>maven-invoker-plugin</artifactId>
> >> >> >              <configuration>
> >> >> >                <properties combine.children="merge">
> >> >> > <https.protocols>${https.protocols}</https.protocols>
> >> >> > <arguments>-Dhttps.protocols=${https.protocols}</arguments>
> >> >> >                </properties>
> >> >> >              </configuration>
> >> >> >            </plugin>
> >> >> >          </plugins>
> >> >> >        </build>
> >> >> >      </profile>
> >> >> > ...
> >> >> >
> >> >> > 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
> >> <[hidden email]>
> >> >> >> 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 <[hidden email]> 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: [hidden email]
> >> >> >>>>>> For additional commands, e-mail: [hidden email]
> >> >> >>>>>
> >> >> ---------------------------------------------------------------------
> >> >> >>>>> To unsubscribe, e-mail: [hidden email]
> >> >> >>>>> For additional commands, e-mail: [hidden email]
> >> >> >>>>>
> >> >> >>>>
> >> >> ---------------------------------------------------------------------
> >> >> >>>> To unsubscribe, e-mail: [hidden email]
> >> >> >>>> For additional commands, e-mail: [hidden email]
> >> >> >>>>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: [hidden email]
> >> >> >> For additional commands, e-mail: [hidden email]
> >> >> >>
> >> >> >
> >> >> >
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: [hidden email]
> >> >> > For additional commands, e-mail: [hidden email]
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: [hidden email]
> >> >> For additional commands, e-mail: [hidden email]
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>