One thing I've noticed when referencing the documentation for various classes, interfaces, packages, etc. is that it's not always clear on which dependency I should install to get a particular package and get the classes/interfaces/annotations within.
I would like to offer to update the package level JavaDocs for the packages in this repository to include information on where to get the package from, such as including pom.xml
's dependency tags, or the configuration for build.gradle
. Do you consider this to be a welcome suggestion? If so, are there any guidelines or whatnot on how to approach this?
Comment From: sbrannen
Are you saying you would like for the module name to be present in every package description?
For example, are you suggesting that the package description for org.springframework.aop
would contain something along the lines of "(module spring-aop
)"?
If we were ever to provide module-info
files, I suppose that would take care of itself, since the generated Javadoc would then be modular.
In the interim, I'm not sure if we want to address this, but we will discuss it within the team.
In any case, if we do decide to address this in the interim, I suppose we would want to automate it -- for example by injecting " module current-module-name
)" in the generated package-level Javadoc HTML.
Comment From: PrittSpadeLord
@sbrannen Oh that does sound like a neat idea, but no that's not what I meant
What I mean is, say for example I am observing the package org.springframework.context
. The package-info.java
would be updated to include the Maven dependency from where the package may be obtained. In this example it would be:
"This package is found in the following Maven dependency. Install it to use this package in your projects by using for Maven"
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
</dependency>
</dependencies>
and ofc the corresponding one for Gradle as well (I haven't added it here for brevity)
Comment From: sbrannen
Thanks for the clarification.
Though, I don't foresee the team wanting to include build tool configuration in the Javadoc.
If we do anything, I think the artifact ID alone would suffice, or potentially the group ID and artifact ID even though the group ID would always be org.springframework
.
Comment From: PrittSpadeLord
@sbrannen Are you sure I can't convince you further?
I've had some trouble while referencing the docs.spring.io that mentions a class, but it's not always quite so clear where I would download that class from. I suppose I could always search through the spring projects' codebases to find it and the corresponding directory its under, but I do feel like making it easier to identify might make things a lot easier and faster.
However, if the Spring framework desires to have it's codebase be build-tool agnostic, then that is also understandable. In that case, as you've mentioned rightfully, the group id, artifact id would be sufficient to uniquely identify the package anyway.