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
    
    
   
_______________________________________________