[MPLUGIN-437] Fixes to the plugin descriptor generation #167
Conversation
|
Can you create issue for it? |
gnodet
changed the title
gnodet
force-pushed
the
plugin-generator-fixes
branch
from
1dca0a7
to
c502601
Compare
| @@ -81,13 +80,6 @@ public JavaClassConverterContext( JavaClass mojoClass, JavaClass declaringClass, | |||
| Map<String, MojoAnnotatedClass> mojoAnnotatedClasses, | |||
| JavadocLinkGenerator linkGenerator, int lineNumber ) | |||
| { | |||
| if ( !( mojoClass.getJavaClassLibrary() instanceof SourceLibrary ) | |||
There was a problem hiding this comment.
why has this been removed? Access to import statements is still crucial for resolving javadoc references.
There was a problem hiding this comment.
I did remove the fact that the generation will throw an exception, not the fact that it will be used. Resolving javadoc reference is an order less important than having the plugin generate the descriptor. In my use case, it was throwing an exception and failed the whole build.
There was a problem hiding this comment.
I understand this, but how can it work correctly? The exception was a good indicator to ease debugging.
There was a problem hiding this comment.
Well, in my case, the parent class was not part of the module being built, and the declaringClass.getJavaClassLibrary() is an instance of ClassLoaderLibrary.
The generation will still work, even if some links can not be resolved. But the plugin as a whole can not fail for this reason. And it's a valid use case, so even a warning may be too much, unless it can be disabled.
There was a problem hiding this comment.
I think at least a warning is reasonable if javadoc links cannot be resolved.
There was a problem hiding this comment.
Also how can meta information from the parent mojos be extracted which are not part of the binary (i.e. coming from javadoc like description, since or deprecated)? I think this requires evaluation of the parent's plugin descriptor....
There was a problem hiding this comment.
Also how can meta information from the parent mojos be extracted which are not part of the binary (i.e. coming from javadoc like description, since or deprecated)? I think this requires evaluation of the parent's plugin descriptor....
I guess they don't. But in my case, the plugin is used internally during the build, so the documentation is not much of a problem.
Instead of warning upfront, I think it would be better to display a warning at the time the information can not be retrieved. That would avoid irrelevant warnings to be displayed. For example if the parent class does not contain any parameter definition, a warning would be irrelevant noise.
There was a problem hiding this comment.
Agree, not sure how to accomplish this with QDox, though.
When a mojo inherits from a mojo in a different project, the plugin descriptor generation fails.
Another problem is when the source artifact is being built in the same reactor, I had a case where the resolved artifacts file was pointing to a directory.