You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Maczka Michal <mi...@imtf.ch> on 2004/01/09 11:07:28 UTC
RE: Dependency issues for junit tests [brain dump]
> -----Original Message-----
> From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> Sent: Friday, January 09, 2004 3:12 AM
> To: Maven Users List
> Subject: Re: Dependency issues for junit tests
>
>
> "Cary Coulter" <ca...@hotmail.com> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Dependency issues for junit tests [brain dump]
Posted by Michal Maczka <mm...@interia.pl>.
[...]
> > 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.
>
Sure there maybe unlimited number of types. But what I want is to
have fixed intuitive information where given artifact can be located in
repository.
With my implementation of repository layout you can easily do things
test=${groupId}/$jars/${artifactId}-${version}.${jar}
whatever_else=${groupId}/$jars/${artifactId}-${version}.${jar}
but I think it makes it harder to understand if <type> is used for few
things.
At the moment we have bijection between repository and projects:
We know how to point to given artifact and how it was generated.
At this have a great value.
In fact when I was starting to play around with maven-artifact module
I wanted to do things exactly like (with <type>test</type>)
but after some time I started to have an impression that this makes things
more magical
and simplicity is lost. I still believe that other tag/hint in dependency is
a better option.
I am almost sure that you are right that one tag will do the thing. I just
doubt if this will be simpler.
> I honestly don't think "compile-time" and "runtime" are things that we
> will need to differentiate.
>
I think we do.
For example most of plexus services need avalon-framework-api to be compiled
but
they rather don't need to at the runtime as it will be provided by
container.
> 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.
>
I hope that this will be possible.
[...]
> > 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.
I know this was too complicated. I don't think that POM should look like
this.
I really wanted to draw attention that there many issues with transitive
dependencies
and it will be better to see how they will really work and experiment with
them before deciding
on simpler things like test/compile dependencies. I fell that this is a
piece of cake comparing
to graphs of transitive dependencies and the shape of <dependencies> block
will be decided by
requirements of tras. dep.
For example <implementation> tag can go to POM
( and POM of Xerces can contain
<project>
..
<specification>jaxp 1.2<specification>
</project>
)
There is a place in JAR Manifest for such things:
http://robocode.alphaworks.ibm.com/docs/jdk1.3/guide/jar/jar.html#Main%20Att
ributes
And there are probably many other options.
One thing which bothers me about transitive dependencies is that we can have
situation like
Project A: depends on JAXP
Project B: depends on XERCES
Project C: depends on CRIMSON
and now project D depends on project: A, B, C
All three artifact provide probably the same asset, but there is probably no
way to find it out and possibly
warn that there are duplicates or native API of Xerces is used (you have to
assume that).
But maybe I am wrong and we won't have situation like this?
Let's play around with transitive dependencies then spent time trying to
predict the best option without any knowledge!
That's why I will rather wait with <type>test</type> thing.
Wait!
After thinking (don't happen often :)): Maybe you are right that test
dependencies should be separated in first round?
Most of the POMs are probobably un-real in that sense that "test"
dependencies are covering the true picture.
For example most of plexus-components has horribly long list of dependencies
just for unit tests.
Michal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Dependency issues for junit tests [brain dump]
Posted by Jason van Zyl <jv...@maven.org>.
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
jason@zenplex.com
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org