On Sat, 2004-01-10 at 14:34, Steve Garcia wrote: > > > > 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?
Do you include your test dependencies as part of the classpath of your running application? Probably not. > A CLASSPATH can contain > any number of valid entries. It can contain a .zip, .class, .jar, .ear, > even a directory! Yes, so what's the problem? > (well that can't fit in the artifact model). Sure it does, that's why you have handlers for different types and if you have test stuff for your test classpath and it's in a zip file then we either have a little handler for that or use the <jar/> element to name it literally. > 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> A tiny handler would do the trick, or simply use the <jar/> as stated above. > 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. This is what the handlers are for. The type does not have to refer to the extenion as well. It can but doesn't necessarily have to. This is type specific and dealt with in a specific handler. > > 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. Then again we have a small handler for the type "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. Again, another type doing the desired behaviour. Ultimately what will fall out is a small handful of handlers that will cover 99% of all use cases. People can code their whacky ones as required. > > 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. It's nasty actually when it comes to resolving conflicting versions while integrating components into a final application but with some rules and ultimately a little tool to help a user make the final choice it's far from impossible. > 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. Yup, I've been building runtime environments with Maven and Plexus for over a year now and I've got all sorts of little gizmos to help me build, test and sheer the runtime mechanism down to the essentials. > > 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? No, the type does not only indicate it's location. The type refers to a handler that deals with location and behaviour. I think that's where you are confused about why things might not work. The type points to the handler and the handler deals with location, packaging, addition to the classpath or whatever. So type = weird might refer to a tarball which contains a set of jars and this tarball may reside in repo/<groupId>/blobs And only JARs beginning with the name "santa" are added to the runtime classpath and those beginning with "claus" are added to the test classpath. Odd, yes, but you see what I'm getting at. The handler deals with everything. It's a very simple mechanism but easy. As soon as you start making the artifact mechanism itself deal with these quirks the code turns to crap. If you have a special need, make a handler and away you go. > 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. In all cases your POM is the overriding factor, if you know something specifically about what the dependencies down the chain then you control it. > [ 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). Any opinion counts that rings of common sense. > 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. Hopefully nice tools in IDEs will soon help. To help navigate and to help resolve conflicts and help package things up for deployment under varied test cases and release scenerios. What you package may depend on any number of things. > > 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: No attributes are used, but if something seems more sensical than type that's fine with me. I have never used attributes in XML because I see them as similiar to attributes in classes. They are metadata not the object data. I rarely use attributes for data that gets mapped to an object. But anyway, if "usage", or "handler" is more appropriate that's cool. My only point is that one per dependency would work, you may end up with a few more handlers but that ultimately keeps the artifact handling code more simple and offloads any potential weirdisms to a handler. > <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. I guess that's a matter of opinion :-) I actually don't find it easier to read but I'm sure out of 10 people you'll get different answers. Some like the <property name="foo">bar</property> stuff. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
