Regression in GroovyDoc behavior in 1.6.2

[chrylis]

Updating to 1.6.2 to try to fix the problem in #100 led to failures because I was including the groovy-groovydoc dependency as provided scope, which is generally the preferred option for a build-only tool. The switch from compile-time to runtime dependencies apparently no longer includes provided. As far as I can tell, there's no simple way to grab the provided-scoped dependencies specifically in the Maven API, but would it be possible to merge the compile and runtime scopes for the purposes of doc generation?

[keeganwitt]

Sorry for the late reply, and sorry for the roadbump. It's hard to anticipate all the ways someone might set up their project. Provided wasn't something I considered when I made this change, but it is described that way: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope.

A Mojo can only declare one dependency resolution requirement -- I can merge both classpaths (both being compile and runtime -- there is no getProvidedClasspathElements() in the API), but I'm not sure it'd be safe since they haven't both necessarily been resolved by Maven. I'm not sure at this moment the best way to fix this. Both the old code and the new code force users not to be able to use one scope (runtime) or another (provided).

[keeganwitt]

One workaround would be to have a separate profile for GroovyDoc where you use compile or runtime scope of the groovydoc dependency.

[keeganwitt]

Now that you have the ability to include dependencies in the plugin definition (by enabling useSharedClassLoader), does that offer a solution to this problem?

[zman0900]

Shared classloader works for me at least. I added groovy-groovydoc as a dependency to the plug-in, then only enable shared classloader in separate executions for generating groovydoc.

[keeganwitt]

It's not a perfect solution (I constantly worry about the little edge cases), but I haven't come up with anything better yet.