> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 09, 2004 3:12 AM
> To: Maven Users List
> Subject: Re: Dependency issues for junit tests
>
>
> "Cary Coulter" <[EMAIL PROTECTED]> wrote on 09/01/2004
> 11:29:38 AM:
>
> > Wouldn't it just be better to add the
> <dependencies>...</dependencies>
> to
> > the <unitTest> block rather than adding some type of property
> > <type>test</type>" to the regular <dependencies>...</dependencies>
> area??
>
> That makes lots of sense.
> --
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>
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
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:
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>
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.
Say that we are creating the runtime for project A, B, C and all of them
were "polite" and "exported" runtime dependency
"foo_specification:foo_specification:jar". For creating the runtime we need
to finally find some valid implementation
for given specification.
So my next approximation (reflecting only this aspect) is:
<dependency>
<specification>
<groupId>jaxp</groupId>
<artifactId>jaxp</artifactId>
<type>jar</type>
<version>1.2</version>
</specification>
<implementation>
<groupId>xerces</groupId>
<artifactId>xerces</artifactId>
<type>jar</type>
<version>2.5</version>
</implementation>
<dependency>
<implementation> block serves as a hint what can be a substitute of jaxp if
one needs to be found.
I feel that this can be important aspect also for maven once maven plugins
will be plexus services.
We will have lot of dependencies on service specification. For example we
will have the specifiaction "java_parser"
with implementation like "javac", "aspectj" "jikes".
I am not saying that what I have shown makes a lot of sense ( rather doesn't
as I feel sick today and canot think cleary - there is an epidemy of flu in
Europe :( ).
My intention was to draw a "big picuture" and show what can be considered
when final decision how those things will look like
is made.
For example I am still not seeing how transitive dependencies for various
"kinds" are working.
At the moment I am believing that test dependencies are not transitive.
What I would like to see for example is that blocks like
<dependency>
..
<properties>
<war.bundle>true</true>
<properties>
</dependency>
go away.
All runtime dependencies (including resolved transitive dependencies) should
be added to war.
This will be impossible to add mark-up like <war.bundle>true</true> to
every POM.
Those my use-cases.
Michal
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
