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