> > With the single "type" element a particular handler should > > know what to do. Might a dependency need more than one type > > of attribute? I honestly don't think so.
I totally disagree. There are two flavors of "type" and they mix. One (which I'll call "type") answers the question "what is this thing?". Possible values are .jar, .war, etc. This already exists in Maven. The other (which I call "scope") answers the question "how is this used?". Conceptually, values would be "runtime", "compile time", "test time". Unlike the "type", the "scope" values are not mutually exclusive; they would be or'd together. Part of this concept exists already in maven with the various *.bundle properties (e.g. war.bundle), which indicate that a dependency should be included in one kind of runtime artifact. Most dependencies will have all three scopes, as they do now. It is unlikely that "runtime" would ever be used by itself, but the other two would. Dependencies of "compile time" only would be those where the dependency is already included in the runtime platform. This would include activation.jar and often would include mail.jar, j2ee.jar, etc. Another (very important) type of "compile time" dependency is a dependency that is used by the Maven code. If, for example, your maven.xml contains taskdefs, the jar to which you are linking must currently be in the classpath. Dependencies of "test time" would be anything used by the testing process that is not released. Such things are usually test drivers or reporters of some kind. > > Really, all you want are compile time dependencies in POM. > > The runtime should be figured out so that during unit testing > > all requirements are gathered. Right! The problem is that the POM does not give enough information for such runtime information to be figured out completely. A bunch of extra stuff (that will not be there in production) may be added, with no way to remove it. > > Eventually we don't want to have people require statement of > > runtime dependencies as that's what the transitive dep > > mechanism will pull out for users. I agree that telepathic software would be nice to have. > Reading XML is not easy and when you have 20 dependencies for a > project you have to navigate 2+ pages of XML that all > basically looks the same and it's really hard to find what you > need. Disagree here. Never had a problem. Specifying hierarchies is what XML is good at. > > Ultimately I think it boils down to tagging a dependency with > > a single type or kind. From there maven looks up the handler > > for that type and deals with it. I really don't think it's > > any more complicated than that. I don't see how you will be able to build a 'single type system' (actually, using my definitions above, you seem to be talking more about a 'single scope system') without requiring ONE of the following: 1) Specification of the dependency's filename (and possibly path) in the POM, which you currently do not have to do. 2) A 'type' that mixes all combinations of file type and scope, e.g. (runtime-jar, runtime-war, ...). Number 1 seems doable. Number 2 would suck. > I see where you are coming from. I'm weary of constructs > where one defines different types of kinds or usages Using many kinds of different "settings" is only legitimate if one condition applies: the different kinds of settings actually control completely different things. This condition definitely applies to the 'type' and 'scope' settings (as defined above). They have nothing to do with each other. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
