Hi,
if we are talking about immutable classpath I agree. But there's something
else which needs to be improved.
Let me describe it with the maven-javadoc-plugin, but there are more
plugins suffering the same problem.
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.
I see two solutions:
- mark these fields in the plugin as being dependencies, which must be
resolved.
- add a custom field to the plugin-dependency in the pom.xml, so the
plugin knows which dependencies are used for which purpose.
With both solutions it should also be possible for the
maven-release-plugin to verify all used dependencies, which is impossible
right now.
thanks,
Robert
Op Sun, 06 Apr 2014 15:55:07 +0200 schreef Jason van Zyl <[email protected]>:
Hi,
I started making of list of things I'd like to remove in Maven 4.0.0,
but I would like to start getting some agreement on what we can yank and
this is the first concrete request. I would like to remove the ability
for plugins to magically inject dependencies. Plugins can either declare
their dependencies or instruct users to add dependencies to the plugins
in their POMs. This weird logic for plugins to add dependencies
dynamically is the cause of some extremely convoluted logic in the
resolution code and I want to remove it.
The original issue is here: http://jira.codehaus.org/browse/MNG-4363
I encountered this when trying to hoist all the resolution logic into
once place so that from our Aether provider resolution as it is done in
the core can be done everywhere. Right now we have plugins like the
assembly plugin, WAR plugin, dependency plugin that all do their own
weird, inconsistent thing and when I tried to put it all in one place so
that it can be analyzed, optimized and then executed this issue cropped
up. We never should have allowed this in the first place but carried it
over from 2.x for compatibilities sake. This might affect the code
coverage tools but we can find a cleaner way. This logic is totally
bizarro and needs to go.
If everyone agrees we can start systematically documenting what has been
removed, as we have lost track of this accurately in the past. I'd like
to make a 4.x branch in 4 weeks or so and this will be one of the first
things I'd like to cut. It will be one of those radical simplifications
that will start allowing people to get a better understanding of the
core as I can put the resolution logic in one place as it is currently
in many.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
We all have problems. How we deal with them is a measure of our worth.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
