I like Robert's idea of getting all the variants in a wiki page. But I'd still like you guys to answer the initial query which was to agree on removing the magic of plugins adding things to the classpath and requiring it be specific.
On Apr 6, 2014, at 8:32 PM, Benson Margulies <bimargul...@gmail.com> wrote: > 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 <m...@talios.com> 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: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
