Op Sun, 06 Apr 2014 20:54:24 +0200 schreef Jason van Zyl <ja...@takari.io>:
On Apr 6, 2014, at 2:24 PM, Robert Scholte <rfscho...@apache.org> wrote:
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.
So the generic category is the downloading of artifacts that are passed
into the command line of an executable? So the plugin already has a
dependencies element but the javadoc plugin has a special element such
that you can get hold of these dependencies to feed into the command
line. Yes? I believe we can make this generic and prevent plugins from
having to do their own resolution logic.
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.
The think the second would be better. We already have a <dependencies/>
element which are added to the classpath of the executing plugin, but
another element like, say, <artifacts/> can just be downloaded and
injected into the plugin such that it can do what it likes with the
files of the downloaded artifacts. Would this satisfy the requirement of
the javadoc plugin?
I think this will work. A quick look at the javadoc plugin shows me the
following <artifacts/>:
- additionalDependencies: capability to add optionnal dependencies to the
javadoc classpath.
- bootclasspathArtifacts: Specifies the artifacts where the boot classes
reside.
- docletArtifacts: Specifies multiple artifacts containing the path for
the doclet starting class file (specified with the -doclet option).
- resourcesArtifacts: A list of artifacts containing resources which
should be copied into the Javadoc output directory (like stylesheets,
icons, etc.).
- tagletArtifacts: Specifies several Taglet artifacts containing the
taglet class files (.class). These taglets class names will be auto-detect
and so no need to specify them.
These are artifacts which must be downloaded, and they are all specified
as groupId/artifactId/version. I don't see additional elements, but we
need to investigate other plugins as well.
Maybe worth a separate wiki page.
thanks,
Robert
Striving for plugins not having to specify and resolution is the goal
and this would certainly help. If we stepped through all the plugins
that we know of which employ their own resolution logic we can push it
back into the core. This also eliminates having to expose most of the
resolution system which would go a long way in not having to expose
Aether. Being purely declarative, as we should, is best. It's just sort
of slipped in many places because we let people get at the resolution
internals.
Ultimately this means that what gets exposed is a very simple
Artifact-like entity and a simple graph for things like the dependency
plugin and enforcer and we eliminate exposing the underbelly of
resolution which is a huge problem right now. Also if the artifact-like
entity had actions that could be attached then very sophisticated things
like what the Android people need would not require using the resolution
system at all. Not sure how many people are familiar with p2 but it has
the notion of actions that are associated with artifacts. So you might
say I want this artifact downloaded, unpack it, and add this directory
in the unpacked structure to my classpath.
It would be a radical simplification to basically shear off all access
to the resolution system. If we had this years ago we would not have
these problems we have with the switches between Maven Artifact,
Sonatype Aether, and Eclipse Aether. This means that many plugins need
to be remade but they will be far simpler. For Maven 4.0.0 I say go big,
go simple, or go home.
I've been noodling around for a couple months and there are a few simple
mistakes we made in the past and they have bloomed into relatively large
problems. I think they are all fixable provided we just bite the bullet
and start removing the janky code.
(I can't seem to edit anything in Confluence or I would have written
more there)
thanks,
Robert
Op Sun, 06 Apr 2014 15:55:07 +0200 schreef Jason van Zyl
<ja...@takari.io>:
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: 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
---------------------------------------------------------
You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.
-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
