On 12/12/22 7:26 AM, Alan Bateman wrote:
On 03/12/2022 18:15, Matej Turcel wrote:
:
So far, jdeps with the --api-only flag seems like the perfect tool,
except
there is a little problem -- we have packages (dozens of them) which
exist in multiple modules. For example, package `com.foo` exists in
three separate modules (meaning each of these modules has a class in
that
package). That means package-private "stuff" (members +
constructor/method
signatures) is a part of module's API. So to infer correct types of
gradle
module dependencies using jdeps, we need jdeps to consider
package-private
stuff a part of the API.
The scenario seems a bit unusual in that API elements with package
access aren't usually considered to be part of the API. Does the
javadoc published for users of these components include the API
elements with package access? I realize Gradle may define "module" to
mean something else but for the Java platform, a module is a set of
packages.
I haven't seen any opinions from others but my initial reaction is
that it wouldn't be a good idea to change --api-only to consider API
elements with package access to be part of the API. If jdeps were
changed then it would need a new option.
I also agree that it's not a good idea to change --api-only as this
option is meant to find dependencies from exported packages and the
module's API.
I considered in the past to provide options similar to javadoc -package,
-private, -protected, -public that specify if
private/package/protected/public types and members are shown.
--api-only is like javadoc -protected and it analyzes protected/public
types and members. I'm open to add jdeps options similar to javadoc
-package, -private, -protected, -public but a different name since jdeps
-package is used already. More consideration would be needed if this
should restrict to exported packages and how to select other packages.
Mandy
