ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: sources as conf or type
Date Wed, 28 Oct 2009 20:29:44 GMT
I think it's fair to say that the established best practice is to NOT make a
separate Ivy conf for things like source or Javadoc.

For one thing, it becomes a transitive dependency nightmare to keep on
having to create a source conf in your Ivy module and then have your source
conf depend on its dependencies' source Ivy confs--which means you need to
add source Ivy confs to those Ivy modules, and so on and so on.

For another thing, IvyDE will only automatically locate and open the source
for a dependency in Eclipse if the source is in the same conf as the binary
in question. In addition, the source artifact's name should have one of the
suffixes configured in IvyDE, like -source or -src.

What this means is that the ivy.xml generated by the automated pom->Ivy
translation should be viewed very much as an intermediate artifact to be
manually massaged rather than a finished product. I'm not sure the extra
smarts involved in that manual massaging should get incorporated into the
purview of that automated translation since the translation is trying to be
literal.

On Fri, Oct 23, 2009 at 8:26 AM, stephenh <stephen@exigencecorp.com> wrote:

>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message