I believe that <type> and <kind> can be replaced with a single set of hints. And here the hints are specifically artifact handler hints.
Maybe I just understand, but for me <type> (jar,war,tld...) and <kind> (compile,runtime,test,...) are orthogonal qualities of a dependency. Type determines the filename, and repository location of the artifact, but does not affect the kind of processing the artifact will recieve. Kind (class, nature?) determines in which of the productions you've mentioned the artifact show up. I don't think that we should mix those two qualities together, because IMO this will effectively *decrease* consistency.
Say we have the following POM:
<pom> <dependencies> <dependency> <groupId></groupId> <artifactId></artifactId> <hints> <type>jar</type> <war>true</war> </hints> </dependency> <dependency> <groupId></groupId> <artifactId></artifactId> <hints> <type>jar</type> <war>true</war> </hints> </dependency> <dependency> <groupId></groupId> <artifactId></artifactId> <hints> <type>jar</type> <test>true</test> </hints> </dependency> </dependencies> </pom>
So instead of an artifact being passed through only one artifact handler it passes through a chain of artifact handlers and each artifact handler does what it likes with the artifact based on hinting information.
So we may have some standard artifact handlers in the core, but I see many of the artifact handlers coming from plugins themselves. When a plugin is loaded the artifact handlers it provides are loaded into the artifact handler chain. When it's finished they can be removed. So for example with the WAR plugin it would have a simple artifact handler that looked for 'war=true' hint and if found would add that artifact to a production which was a list of artifacts you wanted packed into a WAR.
All of this is fine, perhaps except the notation. I'd hate to have <war> element declared in the POM schema, because it's supposed to be specific for the war plugin. I'd much rather have:
<dependency-set>war</dependency-set>
Or along the lines of David's comment
<dependency class="war"> </dependency>
Or even better along the lines of Michals latest propsal, one of the aboved with "war" replaceed by "runtime", and the war plugin knowing
that it should pick up all artifacts from "runtime" set/production
and bundle them together.
So I see the POM being able to store an arbitrary map of productions and it would be up to the artifact handler to name the production. So when the artifacts are processed any number of productions can be created and stored in the POM. When a plugin is executed it has access to the POM and can extract the productions it needs to carry out its task.
So this way everything is offloaded to the plugin. If the standard productions don't suit the plugin then the plugin provides 1..n artifact handlers to create the productions it needs. And the artifact handler is simply triggered by the hinting information.
The <hints> could also be <properties>, I don't really care. I'm just trying to stress that a single set of hints or properties would do the trick as all we are really trying to do is provide some arbitrary set of information to a plugin and I believe this will work.
At this moment I don't see any particular use for free-form key=value style properties attached to a dependency, but at the same time I cannot
deny that some artifact handler might need that. My preferable syntax for those would be
<dependency>
<properties>
<property name="name">value</property>
</properties>
</dependency>or in case we can't have XML attributes
<dependency>
<properties>
<property>
<name>name</name>
<value>value</value>
</property>
</property>
</dependency>We could also use the hinting information to access the artifact type directory or anything else that would be required in the artifact processing chain.
See at the top of the message.
I will actually send another message about transitive dependencies to keep the ideas separated.
Looking forward to it.
R.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
