ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Mapping source artifacts in Ivy
Date Thu, 03 Apr 2008 07:03:23 GMT
On Thu, Apr 3, 2008 at 8:49 AM, Adrian Sandor <> wrote:

> Hi, I'd like to ask about 2 problems I encountered in the process of
> building an Ivy repository:
> 1. Is it possible to define an artifact to belong to the "intersection" of
> 2 configurations?
> Generally, in my modules I have at least 2 configurations: compile and
> devel; compile is the minimum required to get the code to compile, and devel
> extends compile and is supposed to include sources and javadocs.
> In slf4j for example, I have several jar artifacts: slf4j-api,
> slf4j-jdk14, slf4j-log4j12 etc. So I defined some more configurations, such
> as jdk and log4j, extending compile.
> Now, for each jar artifact I also have a source artifact. But I only want
> the sources to be accessible in the devel configuration. So for example,
> slf4j-log4j12 sources should belong to the intersection of the devel and
> log4j configurations.
> Is there a way to define that in ivy? So far, the only solution I found is
> to define yet another configuration for each such case, e.g. devel-log4j
> extends log4j, and then that doesn't extends devel, so I have to write
> mappings like devel->devel,devel-log4j
> This is not just about source artifacts; as Archie mentioned in a previous
> email, each module may be configured along several "dimensions", and if that
> leads to exponential growth in the number of configurations (that need to be
> defined explicitly), then it can very quickly get out of hand.

This is something that has already been discussed and requested before, but
we never agreed on a solution. The problem is not easy, because
configurations in Ivy are resolved independently, and can be used in the
retrieve pattern. So, I think it would not fit in Ivy philosophy to have a
different result for the configuration "devel" or "log4j" depending on which
set of configurations you asked to be resolved. Therefore I think we need a
different mechanism to handle this use case. The question is, what mechanism
can we introduce, and how would it behave?

> 2. Can we have a way to define the source (or javadoc, or whatever)
> artifact(s) associated with a jar artifact?
> Currently, the convention seems to be to have artifacts with the same name
> and different type. E.g. artifact name="slf4j-api" type="source" associates
> with artifact name="slf4j-api" type="jar".
> But what if, for example, I have the source for all slf4j artifacts in
> It would be nice to have a way to define that as the same
> source artifact for all the jar artifacts. Same for javadocs.

Maybe we should introduce a relationship between artifacts which would let
us define the sources and javadocs. But there's always the option to
repackage your sources to match the current convention, so I don't see this
as a big issue.


> What do you think?
> Adrian
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Xavier Hanin - Independent Java Consultant

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message