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. > 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? > > You can merge this Pull Request by running: > > git pull https://github.com/merscwog/gradle warEnhancement > > Or you can view, comment on it, or merge it online at: > > https://github.com/gradle/gradle/pull/43 > > -- Commit Summary -- > > * Adds a restoreJar() method to the War Task > > -- File Changes -- > > M subprojects/docs/src/docs/userguide/warPlugin.xml (3) > M subprojects/docs/src/samples/webApplication/customised/build.gradle (6) > M subprojects/plugins/src/main/groovy/org/gradle/api/plugins/WarPlugin.java > (9) > M > subprojects/plugins/src/main/groovy/org/gradle/api/tasks/bundling/War.groovy > (60) > > -- Patch Links -- > > https://github.com/gradle/gradle/pull/43.patch > https://github.com/gradle/gradle/pull/43.diff > > -- > Reply to this email directly or view it on GitHub: > https://github.com/gradle/gradle/pull/43 -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
