On 11/30/18 12:05 PM, Romain Grecourt wrote:
On 11/30/18 11:10 AM, Romain Grecourt wrote:
On 11/30/18 10:17 AM, arjan tijms wrote:
Hi,
When doing a PR against GlassFish, it runs into
the dreaded trust anchors issue:
Failed
to execute goal on project jsf-connector: Could not
resolve dependencies for project
org.glassfish.main.web:jsf-connector:glassfish-jar:5.0.1-SNAPSHOT:
Failed to collect dependencies at
org.glassfish:jakarta.faces:jar:2.3.9: Failed to
read artifact descriptor for
org.glassfish:jakarta.faces:jar:2.3.9: Could not
transfer artifact
org.glassfish:jakarta.faces:pom:2.3.9 from/to
sonatype-nexus-staging (https://oss.sonatype.org/content/repositories/staging):
java.lang.RuntimeException: Unexpected error:
java.security.InvalidAlgorithmParameterException:
the trustAnchors parameter must be non-empty
This is probably a setup issue.
Can someone perhaps make the trust anchors
non-empty? (most often can be solved by either
pointing the JDK explicitly to a trust store, or
simply by resuming the build).
Here is the state of my current investigations...
JDK1.8u181 does bundle a cacerts file that does not include
amazon root ca certificates.
Both oss.sonatype.org and maven.java.net are signed by amazon.
Note that the docker image has updated cacerts, see https://github.com/docker-library/openjdk/blob/7a33416016b60c045cf0ba99e82617ed6c130595/8/jdk/Dockerfile
The issue does *only* occur in some part of the Maven reactor.
Using "dependency:get" before the build just works...
It does work when setting
-Djavax.net.ssl.trustStore=$JAVA_HOME/jre/lib/security/cacerts
in MAVEN_OPTS.
It does also work when using -DskipTests.
This makes me think that this is caused by some test that's
running in the same JVM as Maven.
There are ugly workarounds we could use right now to un-block
this, like settings -Djavax.net.ssl.trustStore or refresh the
cacerts in the workspace.
I'd prefer to get to the bottom of this and identify the real
culprit.
The actual culprit is under appserver/admin/admin-core, there is
only one test: UpgradeTest.
Forcing surefire into forkMode=always fixes the problem. I'm now
looking at the test itself.
This test feels wrong, I don't want to touch it. I'll go ahead with
forkMode=always.
_______________________________________________
ee4j-build mailing list
ee4j-build@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-build
_______________________________________________
ee4j-build mailing list
ee4j-build@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-build
_______________________________________________
ee4j-build mailing list
ee4j-build@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-build
|
