jira-importer commented on issue #724: URL: https://github.com/apache/maven-javadoc-plugin/issues/724#issuecomment-2957348357
**[Peter lynch](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=peterlynch)** commented [Michael Osipov](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=michael-o) The javadoc plugin accepts a generic archiver configuration for the javadoc-jar goal, yet silently prevents users from adding the descriptor as part of that configuration. This is an abuse of the generic archiver configuration. The maven descriptor files are located at a well known path and contains well known contents, a properties file and pom. The existence of the GA specific paths in the javadoc-jar archive can help identify the GA of the artifact without needing the original pom or original jar. There are cases I need to know the GA, but I do not have the 'main' jar or the pom separately. There is no easy way to automatically generate a maven descriptor like path or file and put this into the javadoc jar, without polluting the source tree with dummy class files which exist only to generate packages at certain GA paths. Adding complexity to a build process to generate such files is overkill and needless. Even then we still can't put these under META-INF to indicate this is meta information only. Certain organizations have strict policies around adding dummy class files with no operational purpose. All that is needed is to fix the bug where the archiver configuration is not respected when configured by plugin configuration - a single line to the javadoc plugin configuration - done. The javadoc and source plugin are the only two core plugins known to do this, yet there is no good reason documented. I suggest it was one plugin copied the other. If there was a good reason, I suggest the archiver configuration library should go to greater lengths to not have a generic option to add the descriptor. The existing forced, non-overridable blocking of the descriptor is confusing and not-consistent with standard archiver configuration use in the very least. The patch preserves backwards compatibility of the default behaviour just in case we cannot foresee a good reason why it was done this way. I can accept a plugin chooses defaults for the archiver configuration, but unless we can cite a solid reason not to respect user configured archiver configuration, like it breaks well established Maven tooling which would rely on it only existing except in the main jar ( even then one could argue it is at user discretion ), I urge this patch to be accepted. The source plugin has already moved ahead with a patch to fix this. See MSOURCES-81. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
