ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Matthies <>
Subject Re: sources as conf or type
Date Thu, 29 Oct 2009 16:11:19 GMT
On Wed 2009-10-28 at 19:52h, Mitch Gitman wrote on ivy-user:
> On Wed, Oct 28, 2009 at 2:15 PM, Niklas Matthies wrote:
> 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 dependencies:
> 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."

I'm talking about the defaultconfmapping attribute of the
configurations element contained in the included file. This way you
don't have to add source->source on every single dependency.

> 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.

Well, it depends (no pun). With source->source you specify that the
dependencies use the same naming convention for the source artifact
configuration as the current module. It's really not different from
api->api in that respect. Either you somehow force all modules
(including third-party ones) to all use the same convention, or else
you need to (be able to) specify a mapping.

When using just type="source" (or is it "src"?), you just presume that
all modules involved use the convention to put source artifacts in the
"regular" configurations (and also mark them with type="source" and
not some other type), and a module doesn't have the chance to specify
that its source artifacts actually reside in a different conf.

> 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 anti-pattern.

We don't really have that case, at least as far as the module's own
sources are concerned. Different sources mean different modules. All
artifacts of a module are built from the same set of sources that
belong together, as they are versioned together. I can see how it
could be useful for the sources of the dependencies, to reduce the
number of sources to download, but so far we havn't had a problem with
that. In cases were it would become a problem, then yes I imagine we
might define multiple source confs. Is that your motivation, not
having to download too many dependent sources?

> 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.

I can follow that point. But are your "things" so different that they
have significantly different APIs, for example? My guess is that we'd
place sufficiently different "things" in different modules.

> 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.)

Yeah, but in the end it's just the same problem backwards, in that it
really is an open-ended list. Maybe you actually need
excludetype="source,javadoc,pdfmanual,debugsymbols" or whatever.

In any case, it's an interesting discussion, as both approaches have
drawbacks, and it isn't perfect either way.

> And where do you put javadocs?

In a javadoc conf. We also generate interlinked javadocs to a network
drive location. Meaning that given an API dependency B;1.1->A;1.5,
when publishing A 1.5, its javadocs are published so some directory
docs/A/1.5/, and then when publishing B 1.1. it publishes docs to
docs/B/1.1/ that link to the A 1.5 docs wherever they reference A.
So over time we build a versioned javadoc repository that way that we
can directly browse.

> 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*.

I use NetBeans, so... :)

-- Niklas Matthies

View raw message