On 18/09/2011, at 3:12 AM, Adam Murdoch <[email protected]> wrote:
> 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. Is this going to show up in the pom then? If not, which mechanism excludes it? > * 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'. I wonder if it's worth introducing a "jar" plugin at this point to get people using apply: "jar" now to lessen the break in the future. It would probably simply delegate to the java plugin initially. It might be more trouble than it's worth though. It might be better to make such a significant breaking change all at once and make it the focus of a 1.x minor release. > > > > 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 >
