| On 11/30/18 11:10 AM, Romain Grecourt wrote: 
 
      
      On 11/30/18 10:17 AM, arjan tijms wrote:The actual culprit is under appserver/admin/admin-core, there is
    only one test: UpgradeTest.
 
        
        Here is the state of my current investigations...
          
            
              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). 
 
 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.
 
 Forcing surefire into forkMode=always fixes the problem. I'm now
    looking at the test itself.
 
 
      
        
        
 _______________________________________________
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
 
 |