I considered adding an option to specify the packages to be exported. It may work fine for simple cases. It may take a prefix to avoid listing the packages individually. Itβs an idea on the list to implement. On the other hand, there will be cases that we would have to edit module-info.java to include `uses` and remove `exports` or qualify any export to a friend.
One useful option, `jdeps β-check` option provides suggestion to `requires transitive` that may not be needed and any unused qualified exports. After you edit module-info.java, compile it and rerun jdeps β-check that will analyze the exported API packages and suggest `requires` and `requires transitive`. It requires a compilation step which would be needed to run as a module anyway. About jdeps β-api-only, when running on a module, it looks at the module descriptor and analyzes only exported API packages. If the classes are on classpath (-cp), module-info.class is skipped. Mandy > On Mar 23, 2017, at 2:24 AM, Gunnar Morling <gun...@hibernate.org> wrote: > > Hi, > > I would like to suggest to add an option to jdeps for describing the > intended exported API of descriptors created by > --generate-module-info. This would have two benefits: > > * Limiting the number of exported packages in the generated descriptor > to the intended public API > * Adding the "transitive" modifiers only to those "requires" > statements whose types are used in the exported API > > While it's relatively simple to rework descriptors after generation > and remove any unwanted exports, that's not the case for removing > superfluous "transitive" modifiers. Identifying them would require to > parse the input JAR once more to find out whether a given dependence > is used in public/protected signatures of the exported API or not. > > If the intended exported API could be passed to jdeps - e.g. in form > of regular expressions or some other kind of exclude/include patterns > - no further post-processing would be needed for generating > descriptors with a well-defined API. > > I had a look at the --api-only option, but this seems only to be about > public/protected access and not the exported packages of a module. > > Thanks for your consideration, > > --Gunnar
