ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From stephenh <step...@exigencecorp.com>
Subject sources as conf or type
Date Fri, 23 Oct 2009 15:26:45 GMT

Hi,

For pom->ivy translation, it seems like a separate "sources" conf is not the
best approach.

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 in the game to change this? Am I missing something obvious?

Thanks,
Stephen

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


Mime
View raw message