Re: ITs in maven-release
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 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 > > 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 > > 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 > >> > >> > >> wrote: > >> > >> > Just one remark from me
Re: ITs in maven-release
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 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 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 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": > -Dhttps.protocols=TLSv1.2 > 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! > > > TLSv1.2 > > > Thx for clarification in advance! > Tibor > > > On Thu, Jul 25, 2019 at 8:38 AM Robert Scholte > 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 >> wrote
Re: ITs in maven-release
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 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 > > 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": > > -Dhttps.protocols=TLSv1.2 > > 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! > > > > > > TLSv1.2 > > > > > > Thx for clarification in advance! > > Tibor > > > > > > On Thu, Jul 25, 2019 at 8:38 AM Robert Scholte > > 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 > >> 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 > >> > > >> > > >> > ${
Re: ITs in maven-release
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 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": -Dhttps.protocols=TLSv1.2 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! TLSv1.2 Thx for clarification in advance! Tibor On Thu, Jul 25, 2019 at 8:38 AM Robert Scholte 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 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 machin
Re: ITs in maven-release
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": -Dhttps.protocols=TLSv1.2 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! TLSv1.2 Thx for clarification in advance! Tibor On Thu, Jul 25, 2019 at 8:38 AM Robert Scholte 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 > 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 Mav
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: 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: 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: 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: ITs in maven-release
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: Naming of ITs in maven-release
Hi Robert, having put some more thought into it I was thinking: maybe the IT should prove that the jira issue integrates with the plugin. In that case the name would be OK and I would also have a path for providing an IT for MRELEASE-229. As of now there are no ITs for release:rollback. I will have to set that up completely from scratch. This will take some time. Cheers, Clemens Am 22.07.2019 um 23:39 schrieb Robert Scholte: Hi Clemens, since the codebase is already rather old, you'll see that naming convention has changed over the years. Nowadays I prefer to to start with the JIRA id, followed by a very short statement of the IT. In the end I'm more important that there is at least a test than the name. Just keep in mind that in general things will succeed. But what if one test breaks for a certain reason. Having the JIRA id is very handy to identify if you're introducing regression or not. thanks, Robert On Sun, 14 Jul 2019 12:06:31 +0200, Clemens Quoss wrote: Hello everyone, one more question regarding the name of the ITs in maven-release (or maybe generally): Seeing that the tests are named after the jira issues i am wondering if that would be the right thing to do. Shouldn't they be named after the functionality they are testing? I for my part, being new to the whole thing, have provided a PR for MRELEASE-229 (implementing RemoveScmTagPhase with some unit tests) [1]. Now i would like to see if there are IT for ScmTagPhase to help me in my orientation. For goal prepare there seem to exist the following: ... 10.07.2019 08:16 completion-goals 17.02.2019 23:40 flat-multi-module 10.07.2019 08:16 forked-basic 10.07.2019 08:16 invoker-basic 10.07.2019 08:16 833 invoker.properties 10.07.2019 08:15 MRELEASE-128 10.07.2019 08:15 MRELEASE-156 10.07.2019 08:15 MRELEASE-161 10.07.2019 08:15 MRELEASE-161-dependencyManagement 10.07.2019 08:15 MRELEASE-420 10.07.2019 08:15 MRELEASE-483 10.07.2019 08:15 MRELEASE-533 10.07.2019 08:15 MRELEASE-571_M3 10.07.2019 08:16 MRELEASE-618 10.07.2019 08:16 MRELEASE-667 17.02.2019 23:40 MRELEASE-834 10.07.2019 08:16 MRELEASE-966 10.07.2019 08:16 MRELEASE-976 10.07.2019 08:16 regular-multi-module ... Maybe one of the MRELEASE-... ITs does something with ScmTagPhase, maybe not. I will have to look into everyone of them to decide. Would there be a test or tests named 'scm-tag-phase' or 'scm-tag-phase-MRELEASE-...' this would be of help, at least to me. Or have I misunderstood some fundamental concept here? 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: ITs in maven-release
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: ITs in maven-release
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
Re: Naming of ITs in maven-release
Hi Clemens, since the codebase is already rather old, you'll see that naming convention has changed over the years. Nowadays I prefer to to start with the JIRA id, followed by a very short statement of the IT. In the end I'm more important that there is at least a test than the name. Just keep in mind that in general things will succeed. But what if one test breaks for a certain reason. Having the JIRA id is very handy to identify if you're introducing regression or not. thanks, Robert On Sun, 14 Jul 2019 12:06:31 +0200, Clemens Quoss wrote: Hello everyone, one more question regarding the name of the ITs in maven-release (or maybe generally): Seeing that the tests are named after the jira issues i am wondering if that would be the right thing to do. Shouldn't they be named after the functionality they are testing? I for my part, being new to the whole thing, have provided a PR for MRELEASE-229 (implementing RemoveScmTagPhase with some unit tests) [1]. Now i would like to see if there are IT for ScmTagPhase to help me in my orientation. For goal prepare there seem to exist the following: ... 10.07.2019 08:16 completion-goals 17.02.2019 23:40 flat-multi-module 10.07.2019 08:16 forked-basic 10.07.2019 08:16 invoker-basic 10.07.2019 08:16 833 invoker.properties 10.07.2019 08:15 MRELEASE-128 10.07.2019 08:15 MRELEASE-156 10.07.2019 08:15 MRELEASE-161 10.07.2019 08:15 MRELEASE-161-dependencyManagement 10.07.2019 08:15 MRELEASE-420 10.07.2019 08:15 MRELEASE-483 10.07.2019 08:15 MRELEASE-533 10.07.2019 08:15 MRELEASE-571_M3 10.07.2019 08:16 MRELEASE-618 10.07.2019 08:16 MRELEASE-667 17.02.2019 23:40 MRELEASE-834 10.07.2019 08:16 MRELEASE-966 10.07.2019 08:16 MRELEASE-976 10.07.2019 08:16 regular-multi-module ... Maybe one of the MRELEASE-... ITs does something with ScmTagPhase, maybe not. I will have to look into everyone of them to decide. Would there be a test or tests named 'scm-tag-phase' or 'scm-tag-phase-MRELEASE-...' this would be of help, at least to me. Or have I misunderstood some fundamental concept here? 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
Re: Naming of ITs in maven-release
Clemens, why the issues cannot use Jira ID only? If somebody wants to know more, she/he can still open Jira and see. Another position is when you develop a new feature and then human readable name should be used. This way we know that we have more ITs for bug than originally TDD features, or oposite ;-) On Wed, Jul 17, 2019 at 11:24 PM Clemens Quoss wrote: > Hi, > I wrote unit tests with scm mocked away [0]. > But IT: I do not know how and what. > Cheers, Clemens > [0] > > https://github.com/apache/maven-release/pull/29/files#diff-bd93f43863e2917722a94ccc46af95a8 > > Am 17.07.2019 um 08:22 schrieb Olivier Lamy: > > Hi > > I understand it can be complicated to write such it which need some scm.. > > Maybe write a unit at least? > > > > On Tue, 16 Jul 2019 at 05:20, Clemens Quoss wrote: > > > >> Hi Olivier, > >> yeah, could do that. Would be a great idea. But i am stuck on what to > >> put into this IT: > >> RemoveScmTag does what the name suggests: it uses maven-scm to remove > >> the tag during release:rollback. > >> In the unit tests maven-scm is mocked away and i think in the ITs of > >> maven-release maven-scm is out of scope, too. > >> Then there is not really much left to test there. > >> Maybe someone out there has a different opinion? And we can discuss > >> this further in private mail? > >> TIA > >> Clemens > >> > >> Am 15.07.2019 um 02:12 schrieb Olivier Lamy: > >>> Hi > >>> I agree the name is a bit confusing... > >>> maybe name the IT: MRELEASE-229-RemoveScmTagPhase? > >>> > >>> > >>> On Sun, 14 Jul 2019 at 20:06, Clemens Quoss wrote: > >>> > >>>> Hello everyone, > >>>> > >>>> one more question regarding the name of the ITs in maven-release (or > >>>> maybe generally): > >>>> > >>>> Seeing that the tests are named after the jira issues i am wondering > if > >>>> that would be the right thing to do. > >>>> > >>>> Shouldn't they be named after the functionality they are testing? > >>>> > >>>> I for my part, being new to the whole thing, have provided a PR for > >>>> MRELEASE-229 (implementing RemoveScmTagPhase with some unit tests) > [1]. > >>>> > >>>> Now i would like to see if there are IT for ScmTagPhase to help me in > my > >>>> orientation. > >>>> > >>>> For goal prepare there seem to exist the following: > >>>> > >>>> ... > >>>> > >>>> 10.07.2019 08:16 completion-goals > >>>> 17.02.2019 23:40 flat-multi-module > >>>> 10.07.2019 08:16 forked-basic > >>>> 10.07.2019 08:16 invoker-basic > >>>> 10.07.2019 08:16 833 invoker.properties > >>>> 10.07.2019 08:15 MRELEASE-128 > >>>> 10.07.2019 08:15 MRELEASE-156 > >>>> 10.07.2019 08:15 MRELEASE-161 > >>>> 10.07.2019 08:15 MRELEASE-161-dependencyManagement > >>>> 10.07.2019 08:15 MRELEASE-420 > >>>> 10.07.2019 08:15 MRELEASE-483 > >>>> 10.07.2019 08:15 MRELEASE-533 > >>>> 10.07.2019 08:15 MRELEASE-571_M3 > >>>> 10.07.2019 08:16 MRELEASE-618 > >>>> 10.07.2019 08:16 MRELEASE-667 > >>>> 17.02.2019 23:40 MRELEASE-834 > >>>> 10.07.2019 08:16 MRELEASE-966 > >>>> 10.07.2019 08:16 MRELEASE-976 > >>>> 10.07.2019 08:16 regular-multi-module > >>>> > >>>> ... > >>>> > >>>> Maybe one of the MRELEASE-... ITs does something with ScmTagPhase, > maybe > >>>> not. I will have to look into everyone of them to decide. > >>>> > >>>> Would there be a test or tests named 'scm-tag-phase' or > >>>> 'scm-tag-phase-MRELEASE-...' this would be of help, at least to me. > >>>> > >>>> Or have I misunderstood some fundamental concept here? > >>>> > >>>> 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: Naming of ITs in maven-release
Hi, I wrote unit tests with scm mocked away [0]. But IT: I do not know how and what. Cheers, Clemens [0] https://github.com/apache/maven-release/pull/29/files#diff-bd93f43863e2917722a94ccc46af95a8 Am 17.07.2019 um 08:22 schrieb Olivier Lamy: Hi I understand it can be complicated to write such it which need some scm.. Maybe write a unit at least? On Tue, 16 Jul 2019 at 05:20, Clemens Quoss wrote: Hi Olivier, yeah, could do that. Would be a great idea. But i am stuck on what to put into this IT: RemoveScmTag does what the name suggests: it uses maven-scm to remove the tag during release:rollback. In the unit tests maven-scm is mocked away and i think in the ITs of maven-release maven-scm is out of scope, too. Then there is not really much left to test there. Maybe someone out there has a different opinion? And we can discuss this further in private mail? TIA Clemens Am 15.07.2019 um 02:12 schrieb Olivier Lamy: Hi I agree the name is a bit confusing... maybe name the IT: MRELEASE-229-RemoveScmTagPhase? On Sun, 14 Jul 2019 at 20:06, Clemens Quoss wrote: Hello everyone, one more question regarding the name of the ITs in maven-release (or maybe generally): Seeing that the tests are named after the jira issues i am wondering if that would be the right thing to do. Shouldn't they be named after the functionality they are testing? I for my part, being new to the whole thing, have provided a PR for MRELEASE-229 (implementing RemoveScmTagPhase with some unit tests) [1]. Now i would like to see if there are IT for ScmTagPhase to help me in my orientation. For goal prepare there seem to exist the following: ... 10.07.2019 08:16 completion-goals 17.02.2019 23:40 flat-multi-module 10.07.2019 08:16 forked-basic 10.07.2019 08:16 invoker-basic 10.07.2019 08:16 833 invoker.properties 10.07.2019 08:15 MRELEASE-128 10.07.2019 08:15 MRELEASE-156 10.07.2019 08:15 MRELEASE-161 10.07.2019 08:15 MRELEASE-161-dependencyManagement 10.07.2019 08:15 MRELEASE-420 10.07.2019 08:15 MRELEASE-483 10.07.2019 08:15 MRELEASE-533 10.07.2019 08:15 MRELEASE-571_M3 10.07.2019 08:16 MRELEASE-618 10.07.2019 08:16 MRELEASE-667 17.02.2019 23:40 MRELEASE-834 10.07.2019 08:16 MRELEASE-966 10.07.2019 08:16 MRELEASE-976 10.07.2019 08:16 regular-multi-module ... Maybe one of the MRELEASE-... ITs does something with ScmTagPhase, maybe not. I will have to look into everyone of them to decide. Would there be a test or tests named 'scm-tag-phase' or 'scm-tag-phase-MRELEASE-...' this would be of help, at least to me. Or have I misunderstood some fundamental concept here? 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: Naming of ITs in maven-release
Hi I understand it can be complicated to write such it which need some scm.. Maybe write a unit at least? On Tue, 16 Jul 2019 at 05:20, Clemens Quoss wrote: > Hi Olivier, > yeah, could do that. Would be a great idea. But i am stuck on what to > put into this IT: > RemoveScmTag does what the name suggests: it uses maven-scm to remove > the tag during release:rollback. > In the unit tests maven-scm is mocked away and i think in the ITs of > maven-release maven-scm is out of scope, too. > Then there is not really much left to test there. > Maybe someone out there has a different opinion? And we can discuss > this further in private mail? > TIA > Clemens > > Am 15.07.2019 um 02:12 schrieb Olivier Lamy: > > Hi > > I agree the name is a bit confusing... > > maybe name the IT: MRELEASE-229-RemoveScmTagPhase? > > > > > > On Sun, 14 Jul 2019 at 20:06, Clemens Quoss wrote: > > > >> Hello everyone, > >> > >> one more question regarding the name of the ITs in maven-release (or > >> maybe generally): > >> > >> Seeing that the tests are named after the jira issues i am wondering if > >> that would be the right thing to do. > >> > >> Shouldn't they be named after the functionality they are testing? > >> > >> I for my part, being new to the whole thing, have provided a PR for > >> MRELEASE-229 (implementing RemoveScmTagPhase with some unit tests) [1]. > >> > >> Now i would like to see if there are IT for ScmTagPhase to help me in my > >> orientation. > >> > >> For goal prepare there seem to exist the following: > >> > >> ... > >> > >> 10.07.2019 08:16 completion-goals > >> 17.02.2019 23:40 flat-multi-module > >> 10.07.2019 08:16 forked-basic > >> 10.07.2019 08:16 invoker-basic > >> 10.07.2019 08:16 833 invoker.properties > >> 10.07.2019 08:15 MRELEASE-128 > >> 10.07.2019 08:15 MRELEASE-156 > >> 10.07.2019 08:15 MRELEASE-161 > >> 10.07.2019 08:15 MRELEASE-161-dependencyManagement > >> 10.07.2019 08:15 MRELEASE-420 > >> 10.07.2019 08:15 MRELEASE-483 > >> 10.07.2019 08:15 MRELEASE-533 > >> 10.07.2019 08:15 MRELEASE-571_M3 > >> 10.07.2019 08:16 MRELEASE-618 > >> 10.07.2019 08:16 MRELEASE-667 > >> 17.02.2019 23:40 MRELEASE-834 > >> 10.07.2019 08:16 MRELEASE-966 > >> 10.07.2019 08:16 MRELEASE-976 > >> 10.07.2019 08:16 regular-multi-module > >> > >> ... > >> > >> Maybe one of the MRELEASE-... ITs does something with ScmTagPhase, maybe > >> not. I will have to look into everyone of them to decide. > >> > >> Would there be a test or tests named 'scm-tag-phase' or > >> 'scm-tag-phase-MRELEASE-...' this would be of help, at least to me. > >> > >> Or have I misunderstood some fundamental concept here? > >> > >> 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 > > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: ITs in maven-release
Hi Tibor, will look at the Readmes, and see what I can do, though I didn't came to look at them in the first place. Not sure what you meant with the CLI documentation, though. Maybe you can help me with that in direct mail. As to the Java SE roadmaps [0]: JDK 7 Update 80 was the last free update (non-premier / non-extended). For paying customers Oracle has extended support until end of july 2022. Do not ask me about the difference between premier and extended support, but you have to have an Oracle Customer Support Identifier (CSI) connected to your Oracle Account to get the further updates. My company account is connected to our companies CSI and i am eligible to download these versions. For instance, we are still using JDK 6 Update 211 in our productive environments. Update 211 being the last one issued (extended support ended after December 2018). But we are migrating ;-) But i think not only paying but also non-profit customers like Apache can get extended support. And i suppose someone must be eligible at Apache, even at maven, to use extended support. Why do i think this? Look at the bottom of this page: [1] It states the Surefire Report was build using JDK 7 Update 181. While digging up this page again for reference I found a lot of interesting links on infrastructure, the CI ecosystem and IT and a lot of other stuff I will now start reading (should have done that before, i know ...) Just one last word as to the system property (https.protocols). Since the backport for JDK 7 was in Update 131, there is no need to provide it in Update 80. But I think there is logic hidden somewhere propagating this parameter without checking if it is set, so resulting in -Dhttps.protocols=_null_ (only for jdk 7). Cheers, Clemens [0] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html [1] https://maven.apache.org/core-its/core-it-suite/ Am 15.07.2019 um 02:59 schrieb Tibor Digana: Hi Clemens, Simply I am using JDK 1.7.0_80-b15 and our Jenkins also has this version. I could not find and download later update of JDK 1.7 neither the Update 131. So that's maybe the reason why I recommended to use TLS 1.2 in the system property. Our build system also specifies the property only while running the build on the top of JDK 1.7. If you want to help us and contribute in Maven project, you can open Pull Requests in GitHub and update README.txt or README.md. This would be helpful for all users and devs. Thx. Of course you can better document the CLI with all these specifics. Ping us on the mailing list when you are done! Our projects in GitHub are typically named: apache/maven apache/maven-release apache/maven-surefire etc. See all "Apache Maven" projects https://gitbox.apache.org/repos/asf/ or list of plugins https://maven.apache.org/plugins/ Cheers Tibor On Sun, Jul 14, 2019 at 9:46 PM Clemens Quoss wrote: Hi Tibor, with this system property set it works with JDK 7. Why is it a pre-requisite? It works with JDK 7 Update 80 that has no backport for TLS 1.2. It came with Update 131 [1]. Are you simply running all the IT on your side with this system property set when using JDK 7? What Update of JDK 7 are you normally using for ITs? So this property was already around when IT for MRELEASE-459 was written? That would explain it. One mor question, please: How would I have been able to avoid all this noise in the dev-mail-group? Where could I have read about this system property? Is it documented somewhere? Cheers, Clemens [1] https://stackoverflow.com/questions/39157422/how-to-enable-tls-1-2-in-java-7 Am 14.07.2019 um 18:58 schrieb Tibor Digana: Did you already run the build like this on J7? mvn verify -P run-its -Dhttps.protocols=TLSv1.2 and you have got those errors as in previous email? Cheers Tibor On Sun, Jul 14, 2019 at 6:32 PM Clemens Quoss wrote: Hi Tibor, by looking further into it I noticed this: MRELEASE-459/build.log (JDK 7): ... [DEBUG] Additional arguments: -Dhttps.protocols=null -P custom-release -DperformRelease=true -f pom.xml ... MRELEASE-459/build.log (JDK 8): ... [DEBUG] Additional arguments: -P custom-release -DperformRelease=true -f pom.xml ... Additional arg '-Dhttps.protocols=null' appears with JDK 7 (or vanishes with JDK 8, your choice). This seems to break the match in verify.groovy - i am not an regexp expert: ... def addArgsExpr = /\Q[DEBUG] Additional arguments: \E(?:-Dhttps.protocols=TLSv1.2 )?-P(.+)\Q-DperformRelease=true -f pom.xml\E/ ... But: where does this additonal arg come from in the first place? Should the match be re-written? Cheers, Clemens Am 14.07.2019 um 18:22 schrieb Tibor Digana: Hi Clemens, I think you are right, I also have to add -Dhttps.protocols=TLSv1.2 in to CLI when using J7. The Jenkinsfile does it [1] already but we should investigate the ITs and add TLS in CLI of the ITs as well unless it's in there. [1]: https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=va
Re: Naming of ITs in maven-release
Hi Olivier, yeah, could do that. Would be a great idea. But i am stuck on what to put into this IT: RemoveScmTag does what the name suggests: it uses maven-scm to remove the tag during release:rollback. In the unit tests maven-scm is mocked away and i think in the ITs of maven-release maven-scm is out of scope, too. Then there is not really much left to test there. Maybe someone out there has a different opinion? And we can discuss this further in private mail? TIA Clemens Am 15.07.2019 um 02:12 schrieb Olivier Lamy: Hi I agree the name is a bit confusing... maybe name the IT: MRELEASE-229-RemoveScmTagPhase? On Sun, 14 Jul 2019 at 20:06, Clemens Quoss wrote: Hello everyone, one more question regarding the name of the ITs in maven-release (or maybe generally): Seeing that the tests are named after the jira issues i am wondering if that would be the right thing to do. Shouldn't they be named after the functionality they are testing? I for my part, being new to the whole thing, have provided a PR for MRELEASE-229 (implementing RemoveScmTagPhase with some unit tests) [1]. Now i would like to see if there are IT for ScmTagPhase to help me in my orientation. For goal prepare there seem to exist the following: ... 10.07.2019 08:16 completion-goals 17.02.2019 23:40 flat-multi-module 10.07.2019 08:16 forked-basic 10.07.2019 08:16 invoker-basic 10.07.2019 08:16 833 invoker.properties 10.07.2019 08:15 MRELEASE-128 10.07.2019 08:15 MRELEASE-156 10.07.2019 08:15 MRELEASE-161 10.07.2019 08:15 MRELEASE-161-dependencyManagement 10.07.2019 08:15 MRELEASE-420 10.07.2019 08:15 MRELEASE-483 10.07.2019 08:15 MRELEASE-533 10.07.2019 08:15 MRELEASE-571_M3 10.07.2019 08:16 MRELEASE-618 10.07.2019 08:16 MRELEASE-667 17.02.2019 23:40 MRELEASE-834 10.07.2019 08:16 MRELEASE-966 10.07.2019 08:16 MRELEASE-976 10.07.2019 08:16 regular-multi-module ... Maybe one of the MRELEASE-... ITs does something with ScmTagPhase, maybe not. I will have to look into everyone of them to decide. Would there be a test or tests named 'scm-tag-phase' or 'scm-tag-phase-MRELEASE-...' this would be of help, at least to me. Or have I misunderstood some fundamental concept here? 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
Re: ITs in maven-release
Hi Clemens, Simply I am using JDK 1.7.0_80-b15 and our Jenkins also has this version. I could not find and download later update of JDK 1.7 neither the Update 131. So that's maybe the reason why I recommended to use TLS 1.2 in the system property. Our build system also specifies the property only while running the build on the top of JDK 1.7. If you want to help us and contribute in Maven project, you can open Pull Requests in GitHub and update README.txt or README.md. This would be helpful for all users and devs. Thx. Of course you can better document the CLI with all these specifics. Ping us on the mailing list when you are done! Our projects in GitHub are typically named: apache/maven apache/maven-release apache/maven-surefire etc. See all "Apache Maven" projects https://gitbox.apache.org/repos/asf/ or list of plugins https://maven.apache.org/plugins/ Cheers Tibor On Sun, Jul 14, 2019 at 9:46 PM Clemens Quoss wrote: > Hi Tibor, > with this system property set it works with JDK 7. > Why is it a pre-requisite? It works with JDK 7 Update 80 that has no > backport for TLS 1.2. It came with Update 131 [1]. > Are you simply running all the IT on your side with this system property > set when using JDK 7? What Update of JDK 7 are you normally using for ITs? > So this property was already around when IT for MRELEASE-459 was > written? That would explain it. > One mor question, please: How would I have been able to avoid all this > noise in the dev-mail-group? Where could I have read about this system > property? Is it documented somewhere? > > Cheers, Clemens > [1] > > https://stackoverflow.com/questions/39157422/how-to-enable-tls-1-2-in-java-7 > > Am 14.07.2019 um 18:58 schrieb Tibor Digana: > > Did you already run the build like this on J7? > > > > mvn verify -P run-its -Dhttps.protocols=TLSv1.2 > > > > and you have got those errors as in previous email? > > > > Cheers > > Tibor > > > > On Sun, Jul 14, 2019 at 6:32 PM Clemens Quoss wrote: > > > >> Hi Tibor, > >> > >> by looking further into it I noticed this: > >> > >> MRELEASE-459/build.log (JDK 7): > >> > >> ... > >> > >> [DEBUG] Additional arguments: -Dhttps.protocols=null -P custom-release > >> -DperformRelease=true -f pom.xml > >> > >> ... > >> > >> MRELEASE-459/build.log (JDK 8): > >> > >> ... > >> > >> [DEBUG] Additional arguments: -P custom-release -DperformRelease=true -f > >> pom.xml > >> > >> ... > >> > >> Additional arg '-Dhttps.protocols=null' appears with JDK 7 (or vanishes > >> with JDK 8, your choice). > >> > >> This seems to break the match in verify.groovy - i am not an regexp > expert: > >> > >> ... > >> > >> def addArgsExpr = /\Q[DEBUG] Additional arguments: > >> \E(?:-Dhttps.protocols=TLSv1.2 )?-P(.+)\Q-DperformRelease=true -f > >> pom.xml\E/ > >> > >> ... > >> > >> But: where does this additonal arg come from in the first place? Should > >> the match be re-written? > >> > >> Cheers, > >> > >> Clemens > >> > >> Am 14.07.2019 um 18:22 schrieb Tibor Digana: > >>> Hi Clemens, > >>> > >>> I think you are right, I also have to add -Dhttps.protocols=TLSv1.2 in > to > >>> CLI when using J7. > >>> The Jenkinsfile does it [1] already but we should investigate the ITs > and > >>> add TLS in CLI of the ITs as well unless it's in there. > >>> [1]: > >>> > >> > https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/asfMavenTlpStdBuild.groovy;h=b0d1d0d2d70172e03754e1666c78aa13d0d38b34;hb=HEAD#l65 > >>> Tibor > >>> > >>> On Sun, Jul 14, 2019 at 11:52 AM 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
Re: Naming of ITs in maven-release
Hi I agree the name is a bit confusing... maybe name the IT: MRELEASE-229-RemoveScmTagPhase? On Sun, 14 Jul 2019 at 20:06, Clemens Quoss wrote: > Hello everyone, > > one more question regarding the name of the ITs in maven-release (or > maybe generally): > > Seeing that the tests are named after the jira issues i am wondering if > that would be the right thing to do. > > Shouldn't they be named after the functionality they are testing? > > I for my part, being new to the whole thing, have provided a PR for > MRELEASE-229 (implementing RemoveScmTagPhase with some unit tests) [1]. > > Now i would like to see if there are IT for ScmTagPhase to help me in my > orientation. > > For goal prepare there seem to exist the following: > > ... > > 10.07.2019 08:16 completion-goals > 17.02.2019 23:40 flat-multi-module > 10.07.2019 08:16 forked-basic > 10.07.2019 08:16 invoker-basic > 10.07.2019 08:16 833 invoker.properties > 10.07.2019 08:15 MRELEASE-128 > 10.07.2019 08:15 MRELEASE-156 > 10.07.2019 08:15 MRELEASE-161 > 10.07.2019 08:15 MRELEASE-161-dependencyManagement > 10.07.2019 08:15 MRELEASE-420 > 10.07.2019 08:15 MRELEASE-483 > 10.07.2019 08:15 MRELEASE-533 > 10.07.2019 08:15 MRELEASE-571_M3 > 10.07.2019 08:16 MRELEASE-618 > 10.07.2019 08:16 MRELEASE-667 > 17.02.2019 23:40 MRELEASE-834 > 10.07.2019 08:16 MRELEASE-966 > 10.07.2019 08:16 MRELEASE-976 > 10.07.2019 08:16 regular-multi-module > > ... > > Maybe one of the MRELEASE-... ITs does something with ScmTagPhase, maybe > not. I will have to look into everyone of them to decide. > > Would there be a test or tests named 'scm-tag-phase' or > 'scm-tag-phase-MRELEASE-...' this would be of help, at least to me. > > Or have I misunderstood some fundamental concept here? > > 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 > > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: ITs in maven-release
Hi Tibor, with this system property set it works with JDK 7. Why is it a pre-requisite? It works with JDK 7 Update 80 that has no backport for TLS 1.2. It came with Update 131 [1]. Are you simply running all the IT on your side with this system property set when using JDK 7? What Update of JDK 7 are you normally using for ITs? So this property was already around when IT for MRELEASE-459 was written? That would explain it. One mor question, please: How would I have been able to avoid all this noise in the dev-mail-group? Where could I have read about this system property? Is it documented somewhere? Cheers, Clemens [1] https://stackoverflow.com/questions/39157422/how-to-enable-tls-1-2-in-java-7 Am 14.07.2019 um 18:58 schrieb Tibor Digana: Did you already run the build like this on J7? mvn verify -P run-its -Dhttps.protocols=TLSv1.2 and you have got those errors as in previous email? Cheers Tibor On Sun, Jul 14, 2019 at 6:32 PM Clemens Quoss wrote: Hi Tibor, by looking further into it I noticed this: MRELEASE-459/build.log (JDK 7): ... [DEBUG] Additional arguments: -Dhttps.protocols=null -P custom-release -DperformRelease=true -f pom.xml ... MRELEASE-459/build.log (JDK 8): ... [DEBUG] Additional arguments: -P custom-release -DperformRelease=true -f pom.xml ... Additional arg '-Dhttps.protocols=null' appears with JDK 7 (or vanishes with JDK 8, your choice). This seems to break the match in verify.groovy - i am not an regexp expert: ... def addArgsExpr = /\Q[DEBUG] Additional arguments: \E(?:-Dhttps.protocols=TLSv1.2 )?-P(.+)\Q-DperformRelease=true -f pom.xml\E/ ... But: where does this additonal arg come from in the first place? Should the match be re-written? Cheers, Clemens Am 14.07.2019 um 18:22 schrieb Tibor Digana: Hi Clemens, I think you are right, I also have to add -Dhttps.protocols=TLSv1.2 in to CLI when using J7. The Jenkinsfile does it [1] already but we should investigate the ITs and add TLS in CLI of the ITs as well unless it's in there. [1]: https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/asfMavenTlpStdBuild.groovy;h=b0d1d0d2d70172e03754e1666c78aa13d0d38b34;hb=HEAD#l65 Tibor On Sun, Jul 14, 2019 at 11:52 AM 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: ITs in maven-release
Did you already run the build like this on J7? mvn verify -P run-its -Dhttps.protocols=TLSv1.2 and you have got those errors as in previous email? Cheers Tibor On Sun, Jul 14, 2019 at 6:32 PM Clemens Quoss wrote: > Hi Tibor, > > by looking further into it I noticed this: > > MRELEASE-459/build.log (JDK 7): > > ... > > [DEBUG] Additional arguments: -Dhttps.protocols=null -P custom-release > -DperformRelease=true -f pom.xml > > ... > > MRELEASE-459/build.log (JDK 8): > > ... > > [DEBUG] Additional arguments: -P custom-release -DperformRelease=true -f > pom.xml > > ... > > Additional arg '-Dhttps.protocols=null' appears with JDK 7 (or vanishes > with JDK 8, your choice). > > This seems to break the match in verify.groovy - i am not an regexp expert: > > ... > > def addArgsExpr = /\Q[DEBUG] Additional arguments: > \E(?:-Dhttps.protocols=TLSv1.2 )?-P(.+)\Q-DperformRelease=true -f > pom.xml\E/ > > ... > > But: where does this additonal arg come from in the first place? Should > the match be re-written? > > Cheers, > > Clemens > > Am 14.07.2019 um 18:22 schrieb Tibor Digana: > > Hi Clemens, > > > > I think you are right, I also have to add -Dhttps.protocols=TLSv1.2 in to > > CLI when using J7. > > The Jenkinsfile does it [1] already but we should investigate the ITs and > > add TLS in CLI of the ITs as well unless it's in there. > > [1]: > > > https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/asfMavenTlpStdBuild.groovy;h=b0d1d0d2d70172e03754e1666c78aa13d0d38b34;hb=HEAD#l65 > > > > Tibor > > > > On Sun, Jul 14, 2019 at 11:52 AM 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 > >
Re: ITs in maven-release
Hi Tibor, by looking further into it I noticed this: MRELEASE-459/build.log (JDK 7): ... [DEBUG] Additional arguments: -Dhttps.protocols=null -P custom-release -DperformRelease=true -f pom.xml ... MRELEASE-459/build.log (JDK 8): ... [DEBUG] Additional arguments: -P custom-release -DperformRelease=true -f pom.xml ... Additional arg '-Dhttps.protocols=null' appears with JDK 7 (or vanishes with JDK 8, your choice). This seems to break the match in verify.groovy - i am not an regexp expert: ... def addArgsExpr = /\Q[DEBUG] Additional arguments: \E(?:-Dhttps.protocols=TLSv1.2 )?-P(.+)\Q-DperformRelease=true -f pom.xml\E/ ... But: where does this additonal arg come from in the first place? Should the match be re-written? Cheers, Clemens Am 14.07.2019 um 18:22 schrieb Tibor Digana: Hi Clemens, I think you are right, I also have to add -Dhttps.protocols=TLSv1.2 in to CLI when using J7. The Jenkinsfile does it [1] already but we should investigate the ITs and add TLS in CLI of the ITs as well unless it's in there. [1]: https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/asfMavenTlpStdBuild.groovy;h=b0d1d0d2d70172e03754e1666c78aa13d0d38b34;hb=HEAD#l65 Tibor On Sun, Jul 14, 2019 at 11:52 AM 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
Re: ITs in maven-release
Hi Clemens, I think you are right, I also have to add -Dhttps.protocols=TLSv1.2 in to CLI when using J7. The Jenkinsfile does it [1] already but we should investigate the ITs and add TLS in CLI of the ITs as well unless it's in there. [1]: https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/asfMavenTlpStdBuild.groovy;h=b0d1d0d2d70172e03754e1666c78aa13d0d38b34;hb=HEAD#l65 Tibor On Sun, Jul 14, 2019 at 11:52 AM 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 > >
Re: ITs in maven-release
Il dom 14 lug 2019, 11:52 Clemens Quoss ha scritto: > 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? Yes Enrico 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 > >
Naming of ITs in maven-release
Hello everyone, one more question regarding the name of the ITs in maven-release (or maybe generally): Seeing that the tests are named after the jira issues i am wondering if that would be the right thing to do. Shouldn't they be named after the functionality they are testing? I for my part, being new to the whole thing, have provided a PR for MRELEASE-229 (implementing RemoveScmTagPhase with some unit tests) [1]. Now i would like to see if there are IT for ScmTagPhase to help me in my orientation. For goal prepare there seem to exist the following: ... 10.07.2019 08:16 completion-goals 17.02.2019 23:40 flat-multi-module 10.07.2019 08:16 forked-basic 10.07.2019 08:16 invoker-basic 10.07.2019 08:16 833 invoker.properties 10.07.2019 08:15 MRELEASE-128 10.07.2019 08:15 MRELEASE-156 10.07.2019 08:15 MRELEASE-161 10.07.2019 08:15 MRELEASE-161-dependencyManagement 10.07.2019 08:15 MRELEASE-420 10.07.2019 08:15 MRELEASE-483 10.07.2019 08:15 MRELEASE-533 10.07.2019 08:15 MRELEASE-571_M3 10.07.2019 08:16 MRELEASE-618 10.07.2019 08:16 MRELEASE-667 17.02.2019 23:40 MRELEASE-834 10.07.2019 08:16 MRELEASE-966 10.07.2019 08:16 MRELEASE-976 10.07.2019 08:16 regular-multi-module ... Maybe one of the MRELEASE-... ITs does something with ScmTagPhase, maybe not. I will have to look into everyone of them to decide. Would there be a test or tests named 'scm-tag-phase' or 'scm-tag-phase-MRELEASE-...' this would be of help, at least to me. Or have I misunderstood some fundamental concept here? 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
ITs in maven-release
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