Hi Martin,
It is also a matter of numbers: I believe the current way of work of JPMS
with Maven is good enough and if there are issues, most of them should be
fixable. For me there's no reason to work on a proposal which is unlikely
to be implemented, since there are much more other issues which add more
value for the community.
If you want to work on a proposal, you should change your starting point
to get the best chance of success.
What you want is a new packaging-type with matching lifecycle. Lets call
it jpms-app, since the end-result is one application based on JPMS, it is
not a library. (and this also means that none of the sub-modules can be
shared, unless you write your own install/deploy plugins that can handle
this)
Next you should be able to apply new defaults to the pom and plugin
configuration. This in not possible in Maven (yet). Or write your own
plugins and bind them to the phases.
It will be a long, long road, I just have to give you this huge warning.
Also keep in mind: how well does it work with IDEs and how easy it for
contributors?
Are these tiny jpms-features really worth implementing?
thanks,
Robert
On Wed, 02 May 2018 10:58:41 +0200, Martin Desruisseaux
<[email protected]> wrote:
Hello Robert
Le 30/04/2018 à 21:00, Robert Scholte a écrit :
All seems to fall back to an issue with the maven-javadoc-plugin. What
if we try to fix that first?
That would help a lot. Getting Maven javadoc:aggregate goal to work
would address maybe 95% of the needs. But Javadoc is not the only Java
tools working on many Jigsaw modules at once. For example I don't know
today how to run annotation processors (with javac) on many modules at
once with Maven layout. Admittedly few peoples may want to do that, but
those who want may find it difficult currently. If we wanted that
functionality with Maven, we may need a kind of "javac:aggregate" goal.
There is also other Java tools working on many modules at once are
(jlink, …), but I do not yet know the implications for them.
Even for Javadoc, being able to use a Jigsaw layout may open interesting
possibilities. It would allow to create separated multi-modules javadoc
for different parts of a project. For example a multi-modules javadoc
for the core, and another multi-modules javadoc for the examples. An
example of such separation is proposed at [1] (proposal only - not yet
applied).
I was thinking if it could be another packaging mode, similar to
<packaging>war</packaging>? Implications:
* For maven-javac-plugin and maven-javadoc-plugin, the main
implications would be:
o to replace the --source-path option by --module-source-path;
o unconditionally (i.e. no need to scan for module-info.java)
replace the -classpath option by --module-path when depending on
another Maven artifact using this packaging;
o no need anymore to fix Maven javadoc:aggregate goal.
* The maven-jar-plugin could execute jar on each Jigsaw module; I have
verified that java --module-path /<directory>/ works if
/<directory>/ contains JAR files of Jigsaw modules, so other Maven
plugins using Java tools can still handle the output as if it was a
single Maven artifact, with a single --module-path option.
What about drafting a proposal on a Wiki page (or any other support)?
Martin
[1] https://github.com/opengeospatial/geoapi/issues/30
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
