ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <>
Subject Re: sources as conf or type
Date Thu, 29 Oct 2009 02:52:43 GMT
Answers inline prefaced by MG:

On Wed, Oct 28, 2009 at 2:15 PM, Niklas Matthies <>wrote:

> On Wed 2009-10-28 at 13:29h, Mitch Gitman wrote on ivy-user:
> > 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.
> Not sure I agree. You generally have to add a bunch of configurations
> anyway (compile, runtime, api, test, javadoc, ...). For our in-house
> modules, we have an XML file defining the common configurations and
> mappings (it resides along the common build files which are initially
> retrieved via Ivy as well), and just <include> that file into each
> ivy.xml. And the mapping for the source configurations is just
> source->source(default), no difficulties there.
> MG: Niklas, to address your particular point, I can tell you that I used to
follow the "source conf" approach myself. And here's one critical drawback I
came across. Sure, one can stick an include in the configurations section of
every ivy.xml and have that included set of confs have a source conf. That
way, you don't have to remember to add the source conf every time. But
you're still going to have to add the mapping again and again to the
source->source OR source->source(default)

It's easy enough to forget to add this. Niklas, I'm not sure what you mean
by "mappings" when you write: "For our in-house modules, we have an XML file
defining the common configurations and mappings."

But beyond that, even if there is a way to avoid requiring the dev to
manually add the same mapping again and again, specifying the mapping is
still a case of putting protocol in front of essence. You're not adding much
semantically the way you are when you're saying the "test" conf needs these
particular dependencies while the "api" conf doesn't.

And this gets to the central argument against special source confs, and it's
a philosophical one. Suppose your Ivy module is publishing different binary
artifacts, one artifact or one combination for each conf. If you have confs
"a" and "b" and "c", do you then come up with "a-source" and b-source" and
"c-source" confs, and so on? Eventually, this starts smelling like an

A better way of thinking of source and Javadoc is that they are just a
couple other ways of representing the same "thing," just like the binary
with the .class files is a way of representing that "thing." It's the actual
combination of classes and resources that distinguishes the conf and its
deliverables, not whether it's represented at that particular time as a
binary or source or API docs.

> Using just filetype, on the other hand, complicates things if you have
> programmatic artifacts other than jar (ear, dll, ...). Then you'd have
> to figure out the right list of types to retrieve all required
> artifacts.
> If I understand correctly, you always specify type="jar" when
> retrieving programmatic artifacts? Or do you always retrieve the
> source along with it, even when packaging?
> MG: I agree with you on this score. The one drawback I've discovered about
putting binary and source and generated doc in the same conf is that you'll
wind up with unwanted artifacts in your deployment. This is why I made an
argument for an excludetype attribute in the *ivy:cachefileset* task. See my
message in this thread:

Then you could say excludetype="source,javadoc" if you know these are the
confs to avoid to avoid distributing the source and Javadoc. (Or hey, maybe
you do want the source in there.)

Now that I've had a chance to think more carefully about this problem, I
realize I could make a much more compelling argument in favor of that
feature than I did at the time, but I'll save that argument for another day.

And where do you put javadocs?
> -- Niklas Matthies

MG: P.S. There's one assumption I've been working from when it comes to
IvyDE, and I'm confident someone will be kind enough to correct me if I'm
wrong in this assumption. It's that IvyDE will only allow Eclipse to
automatically open the source for dependencies *if the source belongs to the
same Ivy conf as the associated binary*.

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