[...]
> > 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
