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 pro
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,
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
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
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-invoke
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 any
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
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
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}
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 JD
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 J
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:3
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 o
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 refe
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
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
n
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
e 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 ne
IA
> >> 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?
> >>>
> >>>
> >>>
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
;
> > 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
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 upd
: 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
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
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 t
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 JD
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/buil
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 -Dperfo
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.gi
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
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 f
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\MRELEAS
32 matches
Mail list logo