On Apr 6, 2014, at 8:32 PM, Benson Margulies <[email protected]> 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.
For each Mojo execution a filter is created based on the scope of resolution
the Mojo requests, this filter is set and is used when calling
MavenProject.getArtifacts(). This method is used to create the classpath for
the compiler for example, or is what you get if you inject ${project.artifacts}
into your Mojo . If you use the artifact resolution mechanism yourself in a
plugin you can do whatever you want. So depending on the your context and use
it can be orthogonal but I believe this is the issue. Where plugins are
performing something pertinent to scope the scope needs to be used, if the
plugin is doing something orthogonal to scope then you don't necessarily need
to consider scope. I don't believe they are orthogonal but rather scope is
relevant depending on what you're doing. Compiling, compiling tests, running
tests, and packaging something generally have something to do with scope.
>
> 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.
>
This I believe is captured for the most part in what Robert and I discussed
where you have an <artifacts/> element in a plugin which grabs a set of
artifacts and a plugin is free do with these what it wishes.
> 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.
I believe a type of artifact handler with some brains might account for this,
or general actions like: unpack and use this directory or take a projection of
this archive.
<dependency>
<groupId>com</groupId>
<artifactId>crazy</artifactId>
<version>1.0</version>
<type>aar</type>
</dependency>
With an artifact handler like mechanism it would know to unpack the archive
find the bits inside that it needs added to the classpath and adds them to the
classpath. Or something specified in the dependency:
<dependency>
<groupId>com</groupId>
<artifactId>crazy</artifactId>
<version>1.0</version>
<using>
<pathWithinArchive>fileOrDirectory</pathWithinArchive>
</using>
</dependency>
Might not want this in Maven proper but I consider this a provisioning
operation and is the only part of the system where I think a DSL is
appropriate. But you get the idea where some action is execute to achieve
getting the bits out of the archive that you need.
So in summary I think the scopes are necessary and contribute to the classpath
depending on the context, you need to have additional capabilities for what the
Javadoc plugin requires and I believe we need a more sophisticated way to
provide provisioning like operations above without people having to use the
resolver directly. You can do anything with the resolver but I don't think this
is desirable, exposes too much and caused our Aether transition issues and
forces everyone in plugins to do their own thing.
If we enumerate the plugins and what they do exactly we can account for it all.
I think between the javadoc, assmebly, enforcer, dependency, WAR, and Jetty
plugin we can account for most things. If this was codified we can even have a
standard way to make classloaders with sets of artifacts and alleviate that
burden from plugin developers as well.
>
>
> 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]
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
