Jason van Zyl wrote: > 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.
It's possible that more orthogonal qualities will show over time. I think that it would be good to keep them visually separated in the POM to make it more readeable to humans. I don't have strong opinion on the internal representation though - if it's easier to keep all the hinting information in single place it's OK with me. >>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. I may be not up to date with maven-new internal, but I imaging this like that: A plugin is invoked (because a goal defined by in was requested), then it picks up a predefined set of dependencies and processes each one in turn. The exact actions taken for the dependency may depend on the dependency type of course (a tld is processed differently than a jar by the war plugin for example). >>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 meant what set/collection the dependency shows up. I think that in most contexts it makes little sense to extract information from each dependency in turn and pile it up together. If you look at properties declared per-dependency, consolidating them makes not sense. >>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. No I didn't mean that. I meant that war plugin could declare a depencency set specific to itself in paralell to sets "build" "runtime" and "test" declared by the core. Later on I noticed that the war plugin should be using the "runtime" set really. >>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. It was suposed to mimic css class notation. When there is more than one you put them all into the attribute, whitespace separated. >>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. I agree. R. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
