[GitHub] maven pull request: [MNG-5613] Avoid NPE when dependency graph cre...
GitHub user dbroeglin opened a pull request: https://github.com/apache/maven/pull/12 [MNG-5613] Avoid NPE when dependency graph creation fails As described in MNG-5613 a NPE occurs if the dependency graph creation fails. Errors where properly catched and added to the result. However, after the call to createProjectDependencyGraph, the resulting projectDependencyGraph was null and as result was not checked for exceptions the call to projectDependencyGraph.getSortedProjects() resulted in a NPE. You can merge this pull request into a Git repository by running: $ git pull https://github.com/dbroeglin/maven master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven/pull/12.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #12 commit 2e5ea4379fe39f083c27d0d965b6d64ddf0d6a7a Author: Dominique Broeglin dominique.broeg...@gmail.com Date: 2014-04-06T09:29:55Z [MNG-5613] Avoid NPE when dependency graph creation fails --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Permissions change on cwiki?
I can no longer see the edit button on a page I created: https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 Anyone else having permissions issues on cwiki? Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa
[Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies
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
Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies
Hm.
Removing the possibility for plugins to manipulate the classpath is - in my
opinion - a rather poor idea.
If we have a problem with plugins contaminating downstream classpath, then
we should provide a simple means for plugins to define Dependencies which
would be added to the classpath of the project *while the plugin executes*.
Key meaning here is that the Maven plugin API should provide these
mechanics (as opposed to plugin developers reinventing the wheel to achieve
this effect again and again) and then automagically remove the dependency
when the plugin's execute method is over.
If we have a problem with plugins concealing true classpath for reports,
then we need to revise how we expose and harvest data for these reports.
I would suggest we need something which works similar to the @Before and
@After annotations from jUnit 4, but which is limited to Dependency
management for plugins and acted upon by Maven - not left to the plugin
developer to invent on their own.
Using compiled-in annotations for static Dependency declarations in the
plugin code would not be good enough, since plugins have loads of good
reasons to add dependencies dynamically - like, for example, different
dependencies used in different JVMs (think JAXB/SAX/DOM, bytecode
manipulation or similar).
I'm suggesting that we could do something like:
@AddToClasspathDuringThisPluginExecutionOnly
public ListDependency getDependenciesForPluginExecution() { ... }
... where the annotation (really silly name here, but illustrates my point)
would indicate that the Dependency would be added to the project's
classpath during the plugin's execution only.
Our reporting and analytics could simply introspect the plugin for methods
annotated with said annotation to find out if they add some dynamically
computed dependencies to their own execution. While it would be impossible
acquire the correct report unless the plugin was actually run, we could
indicate that the classpath may have been manipulated by the plugin during
its execution phase.
2014-04-06 15:55 GMT+02:00 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
--
--
+==+
| Bästa hälsningar,
| [sw. Best regards]
|
| Lennart Jörelid
| EAI Architect Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@jguru.se
| URL: www.jguru.se
| Phone
| (skype):jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==+
Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies
On Apr 6, 2014, at 10:38 AM, Lennart Jörelid lennart.jore...@gmail.com wrote:
Hm.
Removing the possibility for plugins to manipulate the classpath is - in my
opinion - a rather poor idea.
I believe the opposite in that magically manipulating the classpath is a poor
idea. As evidenced in the convoluted logic in the core. There are a number of
other ways for plugins to alter the classpath, and if it is required of a
project to have additions that a plugin requires then it should be explicit. If
something is required on the classpath for test execution then it can be added
as a test scoped dependency. Adding all the complexity below as you describe is
akin to what we have and it's not worth it.
If we have a problem with plugins contaminating downstream classpath, then
we should provide a simple means for plugins to define Dependencies which
would be added to the classpath of the project *while the plugin executes*.
Key meaning here is that the Maven plugin API should provide these
mechanics (as opposed to plugin developers reinventing the wheel to achieve
this effect again and again) and then automagically remove the dependency
when the plugin's execute method is over.
If we have a problem with plugins concealing true classpath for reports,
then we need to revise how we expose and harvest data for these reports.
I would suggest we need something which works similar to the @Before and
@After annotations from jUnit 4, but which is limited to Dependency
management for plugins and acted upon by Maven - not left to the plugin
developer to invent on their own.
Using compiled-in annotations for static Dependency declarations in the
plugin code would not be good enough, since plugins have loads of good
reasons to add dependencies dynamically - like, for example, different
dependencies used in different JVMs (think JAXB/SAX/DOM, bytecode
manipulation or similar).
I'm suggesting that we could do something like:
@AddToClasspathDuringThisPluginExecutionOnly
public ListDependency getDependenciesForPluginExecution() { ... }
... where the annotation (really silly name here, but illustrates my point)
would indicate that the Dependency would be added to the project's
classpath during the plugin's execution only.
Our reporting and analytics could simply introspect the plugin for methods
annotated with said annotation to find out if they add some dynamically
computed dependencies to their own execution. While it would be impossible
acquire the correct report unless the plugin was actually run, we could
indicate that the classpath may have been manipulated by the plugin during
its execution phase.
2014-04-06 15:55 GMT+02:00 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
--
--
+==+
| Bästa hälsningar,
| [sw. Best regards]
|
| Lennart Jörelid
| EAI Architect Integrator
|
| jGuru Europe AB
| Mölnlycke -
Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies
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 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
Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies
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? 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
Re: Permissions change on cwiki?
Can anyone else edit that page. Just checking to make sure it's just me before I ask infra to look. On Apr 6, 2014, at 9:41 AM, Jason van Zyl ja...@takari.io wrote: I can no longer see the edit button on a page I created: https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 Anyone else having permissions issues on cwiki? Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
Re: Permissions change on cwiki?
I can edit it. And the page says that no restrictions are defined. thanks, Robert Op Sun, 06 Apr 2014 21:17:35 +0200 schreef Jason van Zyl ja...@takari.io: https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies
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
Re: Permissions change on cwiki?
A couple of weeks ago infra disabled editing for all accounts due to an excessive spam influx. IIRC any admin can restore edit privileges. Martijn On Sun, Apr 6, 2014 at 9:17 PM, Jason van Zyl ja...@takari.io wrote: Can anyone else edit that page. Just checking to make sure it's just me before I ask infra to look. On Apr 6, 2014, at 9:41 AM, Jason van Zyl ja...@takari.io wrote: I can no longer see the edit button on a page I created: https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 Anyone else having permissions issues on cwiki? Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Permissions change on cwiki?
Jason’s account was not in the maven-committers group. Now fixed. Dan On Apr 6, 2014, at 5:08 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: A couple of weeks ago infra disabled editing for all accounts due to an excessive spam influx. IIRC any admin can restore edit privileges. Martijn On Sun, Apr 6, 2014 at 9:17 PM, Jason van Zyl ja...@takari.io wrote: Can anyone else edit that page. Just checking to make sure it's just me before I ask infra to look. On Apr 6, 2014, at 9:41 AM, Jason van Zyl ja...@takari.io wrote: I can no longer see the edit button on a page I created: https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 Anyone else having permissions issues on cwiki? Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition -- Become a Wicket expert, learn from the best: http://wicketinaction.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies
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
Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies
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
Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies
On 7 Apr 2014, at 12:32, Benson Margulies wrote: 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. If we change/break this - can we PLEASE make the compilation path IGNORE transitive dependencies of 'compile' dependencies - if I -need- it to compile, -I- should depend on it up front. Mark - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Permissions change on cwiki?
Danke. On Apr 6, 2014, at 5:11 PM, Daniel Kulp dk...@apache.org wrote: Jason’s account was not in the maven-committers group. Now fixed. Dan On Apr 6, 2014, at 5:08 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: A couple of weeks ago infra disabled editing for all accounts due to an excessive spam influx. IIRC any admin can restore edit privileges. Martijn On Sun, Apr 6, 2014 at 9:17 PM, Jason van Zyl ja...@takari.io wrote: Can anyone else edit that page. Just checking to make sure it's just me before I ask infra to look. On Apr 6, 2014, at 9:41 AM, Jason van Zyl ja...@takari.io wrote: I can no longer see the edit button on a page I created: https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 Anyone else having permissions issues on cwiki? Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition -- Become a Wicket expert, learn from the best: http://wicketinaction.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - 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
Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies
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
Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies
https://cwiki.apache.org/confluence/display/MAVEN/Resolution+scenarios+for+plugins On Apr 6, 2014, at 4:47 PM, Robert Scholte rfscho...@apache.org wrote: 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
