First off, I think this has been a great topic of discussion, and a lot of
very good ideas are coming out of it. As somewhat of a "test" to see what
will pan out as the best solution, how much work would it be to try out this
idea using the dependency properties? This would alleviate the need to make
changes to the POM (adding a kind element), and do a semi-formal trial of
the implementation. Would this be more or less work than actually changing
the POM and necessary plugins?
<dependency>
<groupId>foo</groupId>
<artifactId>bar</artifactId>
<type>jar</type>
<version>1.2</version>
<properties>
<maven.dependency.type>runtime|compile|test</maven.dependency.type>
</properties>
<dependency>
I think runtime should be the default property if none is specified.
Ryan
-----Original Message-----
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Friday, January 09, 2004 11:11 AM
To: Maven Users List
Subject: RE: Dependency issues for junit tests [brain dump]
On Fri, 2004-01-09 at 05:07, Maczka Michal wrote:
> I don't like neither this idea nor what Jason has proposed.
>
> First of all I will explain why dislike the idea of using
<type>test</type>.
>
> I would like to have a match between Project and Dependency tags
> (<artifactId>, <groupId>, <type>, <version>).
> This breaks it.
> Other thing: those four tags are used for defing the location of artifact
> in the repository and I wouldn't like to mix two concerns: using <type>
tag.
>
> It's far more explicit, powerful and easier to understand and also to code
> if those concerns will be seperated.
> I think that another tag in dependency block should be used (like <kind>)
>
>
>
> <dependency>
> <groupId>foo</groupId>
> <artifactId>baa</artifactId>
> <type>jar</type>
> <kind>test</kind>
> <version>1.2</version>
> <dependency>
>
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.
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.
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.
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.
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.
> 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.
>
>
> So next approximation can look like:
>
> <dependency>
> <groupId>foo</groupId>
> <artifactId>baa</artifactId>
> <type>jar</type>
> <kinds>
> <kind>compile-time</kind>
> <kind>runtime</kind>
> <kind>test</kind>
> </kinds>
> <version>1.2</version>
> <dependency>
No, I really don't like that at all. I'm positive you can do everything
with a "type" element. Compile time I believe is obvious, runtime can be
dealt with via transitive dependencies and the packaging is almost
always a jar and a specific handler will deal with any path variations
as we have with plugins where they are packaged in JARs but are stored
in the "plugins" directory.
I think it is a far better option to leave a single "type" and create
different handlers as required. So far I don't see the "kind" element
really adding anything except long deps entries.
> But this is not all. When transitive dependencies will become reality
(hope
> that very soon)
> We can imagine the following:
>
> <dependency>
> <groupId>jaxp</groupId>
> <artifactId>jaxp</artifactId>
> <type>jar</type>
> <kinds>
> <kind>runtime</kind>
> <kind>compile</kind>
> </kinds>
> <version>1.2</version>
> <dependency>
>
>
> <dependency>
> <groupId>xerces</groupId>
> <artifactId>xerces</artifactId>
> <type>jar</type>
> <kinds>
> <kind>test</kind>
> </kinds>
> <version>2.5</version>
> <dependency>
>
>
>
> So somehow we are here thinking in terms of <specification> and
> <implementation>
>
> jaxp is a dependency on specification, while xerces is a dependency on
> certain implementation
>
>
> It should be promoted practice to "export" as weak dependencies as
possible
> (so we can have lazy binding of specification to implementation).
> For example jaxp should be promoted instead of xerces.
-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.
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.
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]
