Hi,

For pom->ivy translation, it seems like a separate "sources" conf is not the
best approach. At least based on my evolving understanding of ivy.

I think there are three reasons: 

1) It overlaps with the type=jar|source functionality. 

The master conf could have both the jar and source artifacts in it. If
people only want the jars, they could add "type=jar" limitation to their
resolver, if they want both jar and source, they could just resolve all
types. 

2) Separating source artifacts from the master conf hurts transitive source
retrieval. 

As it is now, if a project you depend on only maps their dependencies as
master->master instead of master->master;sources->sources, then you're stuck
with their decision of source artifacts not being important and cannot
transitively retrieve them.

3) When multiple confs do exist, it makes source artifact placement
arbitrary. 

E.g. if I have conf A, and conf B, with a.jar, a-src.jar, b.jar, and
b-src.jar, what conf do I put a-src.jar and b-src.jar in? If I follow the
separate "sources" conf convention, they either both go in "sources" (but
then people that only want conf A's a.jar+a-src.jar will also get the
b-src.jar), or I make separate "a-sources" and "b-sources" confs, which
leads to lots of extra confs and ugly downstream mappings (e.g.
master->a,a-sources). 

Putting source artifacts in the same conf as their corresponding jar
artifact seems to solve all of these problems, while keeping the ability to
distinguish type=jar|source and only download the artifacts you are
interested in as an orthogonal concern. 

Is it too late to change something like this, e.g. for the automatic maven
pom->ivy translation?

Am I missing something obvious?

Thanks, 
Stephen 

-- 
View this message in context: 
http://www.nabble.com/sources-as-conf-or-type-tp26088439p26088439.html
Sent from the Ant - Dev mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Reply via email to