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. 
    
    
      
        
         
        
        _______________________________________________
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
 
     
     
  
 |