I'd prefer
<kind>tests</kind><kind>runtime</kind>
over
<kind>tests, runtime</kind>
Then to dep groups - remove the whole war.bundle.jar and just make it <kind>war.bundle.jar</kind>
eg
<dependency> <artifactId>foo<artifactId> <groupId>baa</groupId> <version>1.0.0</version> <type>jar</type> <kind>test</kind> <kind>eclipse.dependecy</kind> <transitive>true</transitve>
</dependency>
Not really sure about the transitive stuff yet, I have a feeling that it could possibly be sucked inside the kind tag somewhere - eg. transitive per kind, but I could be horribly wrong.
(Also not sure on <kind> name, but that is irrelevant at this point) Michal Maczka wrote:
Hi David and others!
First of all this, what Paulo has described is just experimental feature of maven-new and there is no way to use it for the moment. I am not even sure that if those features will stay when maven-new will be released.
I want briefly explain what I am trying to achieve so you can provide your valuable feedback:
1. I want to support mapping between dependencies in POM and multiple classpaths.
I see a need of having at least 3 classpaths: compile, test, runtime. For the moment I am using 4th classpath: "global" which is used in case dependency should be visible in all 3 other classpaths and is also useful for backward compatibility.
I think that the right way of declaring such mapping is by introducing new tag inside <dependency>: <kind>
And use it like follows:
<kind>global</kind>(default value which is also used when tag was skipped) <kind>test</kind> <kind>runtime</kind> <kind>compile</kind>
There are few open points there (e.g. can we have: <kind>tests, runtime</kind> or <kind>cactus</kind> etc.)
For the moment I would like to discuss just the idea as w whole not those technical details. Once we will agree that such tag is needed in POM we can discuss lower level details
2. I want to prepare a field for <<transitive>> dependencies. I think that is should be controllable if given dependency is transitive or not.
So I am proposing to use:
<transitive>true</transitive> or <transitive>false</transitive> (default, can be skipped)
3. Other proposition is to change a bit a semantic of <properties> tag and instead of using:
<properties> <war.bundle.jar>true</war.bundle.jar> <ear.bundle.jar>true</ear.bundle.jar> </properties>
To make it:
<properties> war.bundle.jar=true ear.bundle.jar=true </properties>
There are at least two arguments for such change: a) It is very easy to implement (It's already done in maven-new :) ) b) It is easier to use for end user (it's shorter)
Example of declaration of dependency using all new tags:
<dependency> <artifactId>foo<artifactId> <groupId>baa</groupId> <version>1.0.0</version> <type>jar</type> <kind>test</kind> <transitive>true</transitve> <properties> eclipse.dependecy=true </properties> </dependency>
Each of those changes is separated idea and can be voted/criticized separately. I am waiting for your feedback! Please let me know what you think about them!
a) <kind> tag b) <transitive> tag c) <properties> tag
Michal
-----Original Message-----
From: David Zeleznik [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 3:35 AM
To: Maven Users List
Subject: RE: Refining dependencies for test and non-test
Hi Paulo,
Michal seems to be currently working in some tags for the dependecies, where you can say what <kind> of dependecy you have.
This way you can say to maven that servlet.jar is a compile dependecy, and not a runtime one, so it will not be copied to a war, for example. And you can define your own <kind>s.
This way you will be able to handle your tests classpath.
Thanks for the info, that sounds like it would help us out greatly. We are still using beta8 because we ran into so many bugs with beta9. Do you know if this new capability is in the current CVS head? If so, where would I look for a a good example of its usage?
Thanks,
-------------------------------------- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com --------------------------------------
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
