It seems to me we have several concepts that might benefit from some combing.
We have 'path-like' structures. When building Java programs, we have the compile and test classpaths. _Within_ these classpaths, we have scopes. In other words, I think that the concept of a path and the concept of a scope should be orthogonal. The scope controls whether it is included in compilation, runtime, or some packaging step. Instead of 'scope=test', I claim it would be clearer to say 'it's in the 'test' classpath, and the scope is either 'compile' or 'runtime'. When we specify a 'dependency', we put it in some path. We then have other logical classpaths. . Something like javadoc should be able to define another named classpath structure; combining the dependencies of the plugin's implementation with dynamic code (doclets, whatever) seems like a category confusion to me. Then we get to dependencies and path-like structures that are not java code. The current situation in which a project's dependencies can be a mixture of jar files and zip files and whatnot is not pretty. What if I needed a jar file that contained data to be unpacked instead of something to add to the classpath? Jason's reference to p2's ability for an artifact to self-route sounds handy; I'd settle for a declarative idea in the pom that there is more than one kind/path of dependencies. On Sun, Apr 6, 2014 at 7:19 PM, Mark Derricutt <[email protected]> wrote: > On 7 Apr 2014, at 6:24, Robert Scholte wrote: > >> You must be able to specify doclettags artifact. There are dependencies, >> but they are not added to the classpath. These jars are added to a different >> argument of the javadoc executable. > > > Would this be possible via plugin-level custom dependency <scope> types? > > Then the mojo, via some API gets the "docklet" scoped dependencies? > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
