Answers inline prefaced by MG: On Wed, Oct 28, 2009 at 2:15 PM, Niklas Matthies <[email protected]>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 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." 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 anti-pattern. 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: http://www.nabble.com/IvyDE-automatically-include-javadoc-and-source-td24746732.html 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*.
