> The "type" and "kind" elements are really doing the same > function which is really providing attribute information of a sort. > > I honestly don't think you would gain more with several > "kind" elements over several "type" elements. > > What has happened though is the type has come to represent > part of the path to the artifact but to my mind there really > wouldn't be much distinction to a first time onlooker between > "type" and "kind" to me they mean essentially the same thing.
Many who participated in this thread want to specify the following properties for a dependency: .jar, .war, .ejb, .class, .zip, .ear and anything else that is a legal CLASSPATH element in Java. Whether this is called a "type" or "kind" or "extension" is just a matter of doing it. It doesn't really matter. You're right that <type> has manifested itself as part of the artifact file name. Maybe it isn't needed? How often are dependency elements differentiated only on type? Like commons-lang-1.0.jar and commons-lang-1.0.zip. I really don't know. My example is silly but I don't do much EJB stuff where maybe one would differentiate artifacts by .ejb or .jar. To me this is simply a conveinent way of specifying the path entries in the CLASSPATH. This says absolutely nothing about how the CLASSPATH is created (besides the obvious that there is a <dependency> element.) > To me if you you look at that block above someone might guess > the "type" really refers to the packaging and the path in the > repository. > > What we are essentially after is that the handler for a > particular type deal with the how that type is packaged, how > it can be found, how it is processed and how it is integrated > into the build. > > 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. > > With the type = test we are making the assumption that the > packaging and path refers to a JAR and that it shouldn't be > part of the standard classpath. This is the issue - why is that a valid assumption? A CLASSPATH can contain any number of valid entries. It can contain a .zip, .class, .jar, .ear, even a directory! (well that can't fit in the artifact model). For a developer who wants to add the Oracle classes12.zip artifact only to his unit tests, I don't know how that would look. <dependency> <groupId>oracle</groupId> <artifactId>classes12</artifactId> <type>test</type> <dependency> Under your model Maven would try to find the classes12.jar file and that doesn't exist. One could also build, for example, test EJB implementations different than production EJB implementations (for instance that don't have to do round trips to the server.) So doing something like <dependency> <groupId>company.com</groupId> <artifactId>test-ejb</artifactId> <type>test</type> <dependency> Again would try to find test-ejb.jar and NOT test-ejb.ejb which is not the desired effect. > If there is another requirement for a particular artifact for > testing then you simply make another handler that deals with > that type. > > > > > > > What's not OK with adding dependecies to <unitTest> block? > > > > > > First of all I think that there could be more then two "kind" of > > dependecies. I see at least three kinds: compile-time, runtime, test > > There could be an unlimited number of types of dependencies > as people may decide to arbitrarily handle those in specifiec > ways with a specific handler but these dependencies but I > think having them within the unitTest element (at some point > in the future just <test/> might be more > appropriate) I think it's very clear what they are for. > > I honestly don't think "compile-time" and "runtime" are > things that we will need to differentiate. For a period of time I felt the same way as you did but there was opposition at my work about this and they did bring up a legitimate point. We use commons.log for our logging package and our commons-log implementor is log4j. So log4j is a runtime dependency but not a compile-time dependency. That is, we want developers only to write Java code with commons.log. If they put log4j logging statements in the code we should get a compile error indicating that the log4j package cannot be resolved. So it is necessary in this case to specify that an artifact is compile-time or runtime. This actually brings up another point about the discussion of handlers mentioned. Log4j is a legitimate compile-time and runtime dependency. There might be other projects that only want to use log4j. In that case it's a compile-time dependency. So an artifact can play more than one role. In that case you have to preserve the attribute information (groupId, versionId, artifactId so you can find it in the repository) and then use an additional property to indicate when it is supposed to be added to the CLASSPATH. > Currently most of the time people add runtime requirements or > testing which the transitive dependency mechanism should handle. > > Really, all you want are compile time dependendencies in POM. > The runtime should be figured out so that during unit testing > all requirements are gathered. This sounds good in theory but I'm not sure how well that could be implemented in practice. Part of the software development process is distributing your product to your customers and that means having a well tested product in a production environment. A production environment means only using the product with runtime dependencies. Maven becomes less useful of a tool if it can compile and jar your product but it can't deploy your product for production readiness. > But again, even if you did have runtime and compile-time they > are just another type with certain characteristics and > actions associated with them during the build phase or testing phase. I agree. One attribute indicates how to locate the artifact in the repository. Perhaps we don't even need the <type> attribute in this case? The current repository layout suggests we do need it but maybe you could just do with groupId, artifactId, and versionId. > > SO if we have distinction between test and non-test > dependencies (and > > that's what this idea sells) it's still not enough and > there is no way > > to distinguish compile-time dependencies from runtime-dependencies. > > And if we are going to have such distinion it will be > simpler to do it once: > > We could do that now simply by doing type = "compile" or type > = "runtime". I think explicity stating the packaging which > will almost always be a JAR and several "kind" elements is overkill. > > 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. That would be brillant if the transitive dep mechanism can figure that out. I still don't know how though if the developer doesn't indicate the "usage" of the artifact. [ snip ] > -1 > > This simply isn't up to us. Any dependency is selected by the > project and the implementation/specification thing just seems > overly complicated. Ulimately we are looking at dep elements > that are 20 lines long. I honestly don't see any benefit in > doing this as opposed to letting the developers of a project > specifically choose their dependencies. Really, I think just > too abstract to be fundamentally useful. I agree too (I know my vote doesn't count). Dependency lists are long right now anyway. 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. Adding more XML tags as wrappers around the dependencies or long lists of <kind> elements makes managing the deps node really difficult. > 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 see where you are coming from. I'm weary of constructs where one defines different types of kinds or usages or there are groups of dependencies (like what Sourceforge Ruper can do which just seems like bloat to me). In the end I would love it if Maven could build an appropriate classpath for 1) compiling, 2) testing, and 3) runtime. #1 and #2 are more important than #3. But as I mentioned above #3 is critical. As a digression I actually advocate using the word "usage" instead of "kind". So either: <dependency usage="compile"> <groupId>commons-log</groupId> <artifactId>commong-log</artifactId> <versionId>1.0.3</versionId> <dependency> or <dependency> <groupId>commons-log</groupId> <artifactId>commong-log</artifactId> <versionId>1.0.3</versionId> <usage>compile</usage> <dependency> and I prefer the former because it's easier to read. > Where dependencies go is really all we need to hash out. > Where is it most clear. Within <unitTest/> is definitely > clear what they belong to and the type is implicit but then > we have plugins and who knows what else will come along so > maybe it's not a great idea to put them within the > <unitTest/> element. I'm not really sure. > > But also the alignment of a project and dependency is > important and we already have that with the simple type. > Projects are implicity of type = jar right now but that is > something we could add to the <project/> level for explicitness. > > -- > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
