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. * Change the EarPlugin in the same way.
We could stop here, and things would be much improved. Optionally, to clean things up, we could: * Change the BasePlugin to add an 'artifacts' configuration. * Change the BasePlugin to add a rule so that any artifact added to 'archives' is also added to 'artifacts' * Change the BasePlugin to spit out a deprecation warning when an artifact is added to 'archives', or the 'uploadArchives' task is run. * Change the SigningPlugin to either add the signatures to the 'artifacts' configuration, or have 'artifacts' extend from 'signatures'. On 16/09/2011, at 11:30 PM, Spencer Allain wrote: > Option 2 with just the additional configurations should be an easier > shorter-term solution, but you make some great points about future > flexibility by enriching the model with some additional elements. > > -Spencer > > From: Luke Daley <[email protected]> > To: [email protected] > Sent: Friday, September 16, 2011 7:26 AM > Subject: Re: [gradle-dev] [gradle] Adds a restoreJar() method to the War Task > (#43) > > > On 15/09/2011, at 10:07 PM, Adam Murdoch wrote: > >> So, if we work around the problem for the war plugin, we still have exactly >> the same problem in the ear plugin, and the c++ plugin, and when you publish >> a source jar and javadoc jars (and the signing plugin, to some extent). >> >> There are some simple solutions to this problem, I think: >> >> Option 1: artifact type filtering >> * Change configurations so that they support filtering on an artifact's type >> when resolving. >> * Change the various compile and runtime configurations to accept artifacts >> of type 'jar'. >> * Change the war and ear plugins so that they do not disable and remove the >> jar. >> * Probably change the signing plugin so that it add the signatures to '*' >> (ie signatures are cross-cutting). >> >> Option 2: bust up archives configuration >> * Add 'jars', 'sources', 'javadocs', 'wars', 'ears', etc configurations. >> * Change the 'runtime' configuration to extend from 'jars' instead of >> 'archives'. >> * Add a 'publications' configuration which extends 'jars', 'sources', >> 'javadocs', 'wars', 'ears', 'signatures', etc. >> * Change the java plugin to add the jar to the 'jars' configuration. >> * Change the war plugin to add the war to the 'wars' configuration. >> * Change the ear plugin to add the ear to the 'ears' configuration. >> * Change the war and ear plugins so that they do not disable and remove the >> jar. >> >> User runs 'gradle uploadPublications' instead of 'gradle uploadArchives'. We >> might keep the 'archives' configuration, have it extend from 'publications', >> and deprecate 'archives' and 'uploadArchives'. >> >> Option 3: artifacts in multiple configurations >> * Change the ArtifactHandler so that it adds artifacts of type 'jar' to both >> the 'archives' and 'runtime' configurations. >> * Change the 'default' configuration so that it no longer extends from >> 'archives'. >> * Change the war and ear plugins so that they do not disable and remove the >> jar. >> >> We could potentially combine both options 2 and 3. For me, option 3 is the >> way to go, followed at some point by option 2. Later, we will need option 1, >> for more sophisticated resolution (eg for fixing how we treat transitive >> dependencies, and for dealing with native variants). > > I think the ideal solution is 2 with some extra work. > > * Rework the java plugin so it does not create a jar, but adds the tools for > java projects in general > * Add a “jars” plugin that provides a dsl for configuring jars to be built > (applies “java” plugin) > * Add a “jar” plugin that applies “jars” and preconfigures to create one jar. > * Follow this same pattern for the current war and ear plugins (e.g. “wars” > plugin adds the capability, “war” plugin preconfigures a single war). > > * Add a model element for each kind of thing in a container (e.g. jars.main, > wars.main) > * Add a top level element that is a synonym for jars.main (e.g. jar {} == > jars.main {}) > * Expose the configurations used by each thing through that element (e.g. > jars.main.dependencies.runtime instanceof Configuration) > * Allow assignment of configurations (e.g. jars.main.dependencies.runtime = > configurations.someConfiguration) > * Expose the publication for wiring into other configurations via some > interface that Configuration knows about that is implemented by the model > objects (i.e. jar, war, ear) > > war { > dependencies { > compile jars.main > } > } > > I think that should still give us the flexibility to dig into the jar model > and do things like just use the class files when compiling instead of using > the jar I think. > > > But, that's probably too much to achieve pre 1.0 and it's breaking as > applying the java plugin would no longer get you a jar. I would love to get > this done before 1.0 though as we are going to have to make this breaking > change at some point so this is my preference. > > But if we agree that's not possible to get done in time (or not desirable)… > > Instead of 3 I think we should at least add the model elements for things > produced during the build and use them for wiring project dependencies > instead of configurations (like my last “point” above). > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
