On 19/09/2011, at 11:38 AM, Spencer Allain wrote: > > From: Adam Murdoch <[email protected]> > > Hi, > > I'd rather we went with a variation on option 3. It's actually very simple: > * Change the BasePlugin so that the default configuration no longer extends > archives. > * Change the JavaPlugin so that it adds the Jar to both the runtime and > archives configurations. > * Change the WarPlugin so that it no longer disables the Jar task or removes > it from any configuration. > > Isn't there still the problem with both the Jar and War in the archives > configuration? > > I specifically pulled the war out of the archives configuration to get around > the warning from javac. I can see if the compile dependency uses classes > instead of the jar that just stuffing it into the runtime would be > sufficient, but I didn't think that was how project dependencies worked yet. > > I must be missing something if just those simple changes (plus the changes to > ear) remove the issues. If default is still used for project dependencies, > then what is actually included in that configuration? Would compile > dependencies point to depended-upon project runtime?
A project dependency, by default, uses the 'default' configuration from the target project. The first change above breaks the connection between 'default' and 'archives', so that adding stuff to 'archives' does not affect what consumer projects see in their classpaths. That is, we can add wars or ears or documentation archives or whatever to 'archives' and these are not made visible to consumers. The second change above adds the jar to both 'runtime' and 'archives', so that it is both made available in the classpaths of consumer projects, and for publication in the producing project using the 'uploadArchives' task. I think we should be good. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
