On Sat, 2003-06-07 at 17:53, Rafal Krzewski wrote: > Jason van Zyl wrote: > > > 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.
We'll probably find there are more orthogonal sets of qualities as you put it. Whatever is more clear I'm fine with. To me the type is just another piece of information. > Type determines the filename, and repository location of the artifact, > but does not affect the kind of processing the artifact will recieve. Currently in maven-new it is the only thing that determines the kind of processing, but it won't stay like that. > Kind (class, nature?) determines in which of the productions you've > mentioned the artifact show up. Artifact or anything else that is derived from a dependency. > I don't think that we should mix > those two qualities together, because IMO this will effectively > *decrease* consistency. The notation isn't cast in stone. > > 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, True enough. I wouldn't want that either. > because it's supposed to be specific > for the war plugin. I'd much rather have: > > <dependency-set>war</dependency-set> You mean defining a set of properties that are valid for use with the WAR plugin? Yup, that will be necessary for other things as well. > Or along the lines of David's comment > > <dependency class="war"> > </dependency> What if you have more than one class? Sorry, don't understand this one. > 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. You wouldn't even have to specify this as the WAR plugin could pick up the standard runtime jar list production. I see that one as a standard one. You could do that in conjunction with an exclude option on the depedency. Just so long as the user can control exactly what goes into the WAR and what doesn't. Inclusion of a standard production with exclusions would probably make more sense with the WAR plugin I think. > > 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 Who knows what you might want to parameterize. I figure a property style notation can't hurt. > <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> I'm sure we'll figure out the notation. > > 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] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
