From: Adam Murdoch <[email protected]> >To: [email protected] >Sent: Thursday, September 15, 2011 5:07 PM >Subject: [gradle-dev] Re: [gradle] Adds a restoreJar() method to the War Task >(#43) > > > >transferring to dev list ... > > >On 16/09/2011, at 5:17 AM, Spencer Allain wrote: > >Adds a "wars" configuration when applying the War Plugin >>Re-adds the JAR artifact to archives configuration >>Removes the WAR artifact from the archives configuration >>Makes the war include the generated jar instead of classes >> > > >To me, whether or not the jar is bundled seems like a separate concern. That >is, sometimes you might want to bundle the jar without making the jar >available outside the project. And, sometimes, you might want to still bundle >the classes but make the jar available outside the project. So, I would >separate these 2 aspects in the DSL. >You are correct.
Adds the WAR artifact to the wars configuration >> >>Could not quite figure out how to get the DSL to pick up the >>groovydoc, even though the restoreJar() method shows up >>just fine in the generated groovydoc. >> > > >I'm not so sure about this approach. I'd rather fix the underlying problem >than work around it. > > >The basic problem is that Gradle (or the Java plugin, more correctly) assumes >that the artifacts published by a project == the runtime classpath of that >project. Which isn't true once you start producing a WAR, or EAR, or source >jar, or signatures, or native binaries or whatever. > > >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). > > > > > >>It is also missing automated test cases. >> >>Wanted to get this out there for review/incorporation so that >>this long standing issue can be mitigated. >> > > >Thank you for pushing on this issue. It is really quite nasty how things >behave now. > > >Would you be interested in implementing one of the above options, with help >from the dev team? >I am definitely interested on working on option 2 with help from the dev team. -Spencer
