Carlos,
You replaced Java 8 with 11 in your MP tool chain, I cannot see any
double execution of Maven Compiler, so you may have fixed the Javadoc
issue at the cost of no longer working with Java 8.
The Moneta RI builds against Java 9 to 11 without problems, but we also
use the dual compile option of Maven Compiler and both API and RI work
with Java 8 demos.
Werner
carlos andres de la rosa <kusanagi12002@xxxxxxxxx
<mailto:kusanagi12002@xxxxxxxxx>> schrieb am Mo., 23. Sep. 2019, 14:04:
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
https://github.com/eclipse/microprofile-fault-tolerance/pull/443
I hope that maybe can help you
Thank you
Best
On Mon, Sep 23, 2019 at 1:28 PM Lukas Jungmann
<lukas.jungmann@xxxxxxxxxx <mailto:lukas.jungmann@xxxxxxxxxx>> wrote:
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
<mailto: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
<mailto: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
<mailto: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
<mailto: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*
Mobile: + <tel:%2B57-3163226522>32465445631
Skype: carlosa.dlr
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
<mailto: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
