That didn't change the behavior. I still get module javadocs.
Lukas Jungmann wrote on 9/23/19 4:39
PM:
Can you try to explicitly point sourcepath to the
folder with module-info together with using sourceFileExcludes?
Just a wild guess...
—lukas
I'm working on Jakarta
Activation.
I figured out that if I remove
<subpackages>javax.activation</subpackages> then
it will generate javadocs for the module, showing only the
exported classes.
That's progress, but since the module isn't part of the API
spec, I'd like to generate non-module javadocs, even though
the source contains a module-info.java file. I tried using
<sourceFileExcludes> to exclude the module-info.java,
but it didn't work; I still got module javadocs.
If I actually remove the module-info.java I can get what I
want; I don't know why excluding it doesn't work.
I've pushed my latest changes to the repo. It now requires
building with JDK 9+ and it only builds JDK9+ class files for
now.
Werner Keil wrote on 9/23/19 1:44
PM:
Is there a particular github repo you try
this?
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
_______________________________________________
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
|