I expect such a tool to generate module-info.class to materialise. I
personally use ClassWriter from the JDK tools for that. Anyone with a
JDK has that module and can write that tool trivially.
The JBoss Modules use-case (and the Ceylon distrib one) is rather
uncommon, though, IMO. Most people deal with modules as Maven modules
and they can't really rewrite the descriptors as in most cases they're
not in the jar and Maven will only use descriptors from the repos and
not in any flat folder where you have Maven jars (I think). In
Maven-land you deal with this via external (to the modules being
overridden) overrides, which Java Modules don't support ATM.
OSGi is already a pain to override because you have to extract the
manifest, edit it and put it back. Here a tool would help. Overriding
Ceylon modules is done via external overrides too, otherwise you'd have
to extract the manifest (which is also a .class), edit it and put it
back, for which we'd have generated tooling if there was ever demand for
that (but there hasn't been yet).
All that to say, in general after-packaging editing of module
descriptors is already either rare or hard. I don't think
module-info.class changes that much.
On 11/05/16 16:44, David M. Lloyd wrote:
On 05/11/2016 09:21 AM, Stephane Epardaud wrote:
I don't understand the problem with the module-info.java class. We also
repackage jars to add module descriptors (for OSGi, Maven and JBoss
Modules) and for Jigsaw we generate the `module-info.class` file when we
need to repackage them. Between this binary format and XML or
MANIFEST.MF, I don't see why it makes a big difference?
I wouldn't recompile the module, though, just as I don't recompile them
when we change the other manifests.
If you have a .class file, you have to generate it with something. I
think Alan is arguing that it should be done with javac, but we'd
likely end up using something else. In our case, just editing an XML
file and doing "git commit" is easier than running a tool to read and
update a binary descriptor inside an artifact though, particularly as
we don't package the actual artifacts. Thus we'd have to package a
textual descriptor of some sort, to which we'd then have to apply a
tool in order to update our final packaged artifacts, making it that
much more difficult to use artifacts that already exist (e.g. from
Maven).
In addition it is common for our users to examine or modify module
descriptors; having them be external is very useful for this purpose.
We also allow features like specification of properties for modules
which can be read, specification of module permission sets, and
filtering of artifact resources and module dependencies in various ways.
