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
