This didn't help because there was no module-info.java. 
     
    carlos andres de la rosa wrote on
      9/23/19 5:04 AM: 
     
    
      
      Hello folks
          
         
        I already pass for this javadoc plugin issue with java 11
          on mp fault tolerance spec if you wanna check below is a pull
          request that is compiling with java 11 
        
         
         
        I hope that maybe can help you 
         
         
        Thank you 
         
         
        Best 
         
         
       
       
      
        
        On
          9/21/19 1:13 AM, Bill Shannon wrote: 
          > Thanks for the pointers, Lukas.  The jaxb-api approach
          seems to work 
          > pretty well. 
           
          the drawback of this particular solution is that the
          correctness of  
          module descriptor is not being checked at compile time by
          javac - ie if  
          ServiceLoader is used by the code being compiled, javac can
          detect  
          missing 'use' declaration in module-info and fail eventually;
          in the  
          setup used by jaxb-api, module-info is compiled against class
          files, so  
          no such check is being done. 
           
          This as such may or may not be a problem depending on the
          complexity of  
          the project in question and personal knowledge of its
          internals. 
           
          >  
          > However, javadoc isn't working: 
          >  
          > [ERROR] Failed to execute goal 
          >
          org.apache.maven.plugins:maven-javadoc-plugin:3.1.1:javadoc
          (default) on project 
          > jakarta.activation: An error has occurred in Javadoc
          report generation: 
          > [ERROR] javadoc: error - No source files for package
          javax.activation 
          >  
          > I even tried "mvn javadoc:javadoc" on the jaxb-api
          project and it fails 
          > for a different reason: 
           
          blame buggy maven-javadoc-plugin here[1]; what must work for
          me is 'mvn  
          clean install' and 'mvn clean install -Poss-release' (with  
          -Dgpg.skip=true eventually). I treat 'javadoc:javadoc' as nice
          to have  
          thing, so unless there is a strong wish and demand for that,
          it is  
          unlikely that I'll be putting in some solution for it (read as
          "IMHO too  
          much work for a little gain") 
           
          >  
          > [ERROR] Failed to execute goal 
          >
          org.apache.maven.plugins:maven-javadoc-plugin:3.1.1:javadoc
          (default-cli) on 
          > project jakarta.xml.bind-api: An error has occurred in
          Javadoc report generation: 
          > [ERROR] Exit code: 1 - error: module not found:
          java.xml.bind 
          >  
          > I played around with the javadoc tool by hand, using the
          options the 
          > maven-javadoc-plugin generates, and I can't figure out
          how to generate 
          > the javadocs for a module.  Have you made this work? 
           
          yes, I made that work - removing lines related to
          '--patch-module' and  
          '--module-source-path' options and explicitly adding
          '--source-path'  
          pointing to the main source roots (src/main/java etc) helped 
           
          thanks, 
          --lukas 
           
          [1]: https://issues.apache.org/jira/browse/MJAVADOC-622 
           
          >  
          >  
          > Bill Shannon wrote on 9/19/19 11:01 AM: 
          >> Lukas Jungmann wrote on 9/19/19 5:12 AM: 
          >>> Hi Bill, 
          >>> 
          >>> On 9/19/19 2:29 AM, Bill Shannon wrote: 
          >>>> What's the state of the art for building a
          jar file that contains class 
          >>>> files that will work on JDK 8, and a
          module-info.class that will work 
          >>>> on JDK 11? 
          >>> 
          >>> Are you looking just for this or also for ability
          to have multi-release jars? 
          >> 
          >> I don't need a multi-release jar file. 
          >> 
          >>> Are you looking for slightly more advanced things
          like module-info being altered 
          >>> by the build as needed - ie because you have a
          main-class in one of the projects 
          >>> (maven-jar-plugin:3.1.2+ is required), or you
          want to include project version in 
          >>> module info (maven-compiler-plugin:3.8.1+ is
          required) etc? 
          >> 
          >> I don't think I need that. 
          >> 
          >>> All JAXB/JAXWS related projects are somehow
          dealing with this as all of them are 
          >>> java modules for some time already and some of
          them are also multi-release jars; 
          >>> jsonp/yasson are another projects to look at
          eventually - should I pick up some 
          >>> examples, jaxb-api can be one of them - it is
          small project with module-info, a 
          >>> multi-release jar and compiles everything exactly
          ones[1], a project which is 
          >>> not MR jar but contains "old" tests which are now
          being run within JPMS can be 
          >>> metro-policy[2] (its double-compilation is going
          to be fixed in the (near) 
          >>> future). Old JAXB/SAAJ/JAXWS 'RI's are another
          examples should you be looking 
          >>> for bigger projects - note that I'm updating them
          these days to adopt recent 
          >>> changes in maven plugins, so what is there today,
          may be different tomorrow (or 
          >>> day after :-))... 
          >>> 
          >>>   Based on my experience, if you get on this
          path, my recommendation is to use 
          >>> Maven 3.6.0. 3.6.1 is safe if you don't need to
          use Eclipse Tycho, with 3.6.2, 
          >>> the copyright plugin does not work[3]. If there
          is a need for Ant, make sure 
          >>> 1.10.6+ is used because older versions do not
          work correctly out-of-the-box if 
          >>> the build uses a task from a library which is a
          multi-release jar[4]. 
          >>>   As for what maven build plugins to use -
          general advice is to always use the 
          >>> latest versions. 
          >> 
          >> Thanks for the pointers, I'll look at those projects. 
          >> 
          >>> thanks, 
          >>> --luksa 
          >>> 
          >>> [1]: https://github.com/eclipse-ee4j/jaxb-api/blob/master/jaxb-api/pom.xml 
          >>> [2]: https://github.com/eclipse-ee4j/metro-policy/blob/master/policy/pom.xml 
          >>> [3]: https://github.com/eclipse-ee4j/glassfish-copyright-plugin/issues/7 
          >>> [4]: https://bz.apache.org/bugzilla/show_bug.cgi?id=62952 
          >>> 
          >>>    The last time I looked at this all I found
          were kludges 
          >>>> that resulted in compiling everything twice,
          or very complex Maven 
          >>>> configurations that depended on using
          multiple versions of the JDK 
          >>>> to compile.  Is there a better way?  Is there
          an existing project 
          >>>> that would be a good example? 
          >>>>
          _______________________________________________ 
          >>>> jakarta.ee-community mailing list 
          >>>> jakarta.ee-community@xxxxxxxxxxx 
          >>>> To change your delivery options, retrieve
          your password, or unsubscribe from 
          >>>> this list, visit 
          >>>> https://www.eclipse.org/mailman/listinfo/jakarta.ee-community 
          >>>> 
          >>> _______________________________________________ 
          >>> jakarta.ee-community mailing list 
          >>> jakarta.ee-community@xxxxxxxxxxx 
          >>> To change your delivery options, retrieve your
          password, or unsubscribe from 
          >>> this list, visit 
          >>> https://www.eclipse.org/mailman/listinfo/jakarta.ee-community 
          >> _______________________________________________ 
          >> jakarta.ee-community mailing list 
          >> jakarta.ee-community@xxxxxxxxxxx 
          >> To change your delivery options, retrieve your
          password, or unsubscribe from this list, visit 
          >> https://www.eclipse.org/mailman/listinfo/jakarta.ee-community 
          >> 
          _______________________________________________ 
          jakarta.ee-community mailing list 
          jakarta.ee-community@xxxxxxxxxxx 
          To change your delivery options, retrieve your password, or
          unsubscribe from this list, visit 
          https://www.eclipse.org/mailman/listinfo/jakarta.ee-community 
         
       
       
       
       
      --  
      
        
          
            
              
                
                  
                    Carlos
                          Andres De La Rosa | Software Architect 
                    
                    
                   
                 
               
             
           
         
       
       
      
      _______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
 
     
     
  
 |