Right now things are broken for publication if applying the war and ear plugins together, so the question really is, should I: [1] remove the war artifact from archives as well if the ear plugin is installed
or should I: [2] change documentation so that Merlyn's nice pattern for handling multiple artifact publication via extensions is added? http://forums.gradle.org/gradle/topics/maven_pom_generation_and_multiple_archive_artifacts_doesnt_work [1] and [2] only affect people who attempt to uploadArchives. [1] is least disruptive to some, but [2] is something that several are going to want to do anyway, so it isn't clear what the "best" solution is in this instance. I personally like [2] better, because then archives truly contains all of the archive products produced by the project, and then it's just a matter of filtering for the ones you really wish to publish -- acknowledging that it is a breaking change for anyone already depending upon the jar being removed when the war plugin is applied, but also recognizing that a very common question is how to undo what the current war plugin does. -Spencer >________________________________ >From: Adam Murdoch <[email protected]> >To: [email protected] >Sent: Wednesday, October 5, 2011 1:05 AM >Subject: Re: [gradle-dev] [gradle] Adds a restoreJar() method to the War Task >(#43) > > > > >On 02/10/2011, at 7:54 AM, Spencer Allain wrote: > >So it seems retaining the jar file for the war task (and presumably the ear >task - didn't see an integration test for that yet) really makes the >SamplesMavenPomGenerationIntegrationTests fail because it uses the archives >configuration, and it refuses to work if there are multiple artifacts. >> >> >>Caused by: org.gradle.api.InvalidUserDataException: A POM can not have >>multiple main artifacts. Already have MavenArtifact mywar:jar:jar:null, >>trying to add MavenArtifact mywar:war:war:nullat >>org.gradle.api.publication.maven.internal.DefaultArtifactPom.addArtifact(DefaultArtifactPom.java:86 >>This is probably why the jar was removed when the war task was originally >>added. >> >> >> >>Suggestions on how to break apart the artifacts for maven upload publication? >> > > >I think it is not just maven publication where this is a problem. When you >apply the 'java' and 'war' plugins, and you're publishing to ivy or maven, you >probably want only the war to be published. And sometimes, but probably less >often, you want both to be published. > > >I'd say the solution for now, is that the war and ear plugins continue to >remove the jar from the 'archives' configuration, but they no longer disable >it. This way, we can get the important piece of the change in (ie decouple the >runtime configuration from the archives configuration). > > >Later on, we could either: >* use a convention mapping or some other lazy collection to decide the >collection of artifacts to be published, and you can change this if it's not >what you want. The default could be that we publish the ear, if the 'ear' >plugin is applied, otherwise the war if the 'war' plugin is applied, otherwise >the jar if the 'java' plugin is applied. >* Don't publish anything by default. > > > > >> >>-Spencer >> >> >> >>>________________________________ >>>From: Spencer Allain <[email protected]> >>>To: "[email protected]" <[email protected]> >>>Sent: Saturday, October 1, 2011 7:49 PM >>>Subject: Re: [gradle-dev] [gradle] Adds a restoreJar() method to the War >>>Task (#43) >>> >>> >>>Ok, so I've finally gotten some time to play with this. >>> >>> >>>Having default no longer extend from default and adding the jar to the >>>runtime configuration all the integration tests pass except for the >>>SamplesJavaBaseIntegrationTest.groovy file no longer compiles with the >>>custom build.gradle in the prod subdirectory. This is a very good sign, >>>since it takes so long to run the complete test suite :-) >>> >>> >>>I hope to get all the necessary changes, including modifications to the war >>>plugin/task pushed up to github tomorrow, but not making any promises. >>> >>> >>> >>>-Spencer >>> >>> >>> >>> >>>>________________________________ >>>>From: Adam Murdoch <[email protected]> >>>>To: [email protected] >>>>Sent: Monday, September 19, 2011 12:35 AM >>>>Subject: Re: [gradle-dev] [gradle] Adds a restoreJar() method to the War >>>>Task (#43) >>>> >>>> >>>> >>>> >>>>On 19/09/2011, at 12:31 PM, Spencer Allain wrote: >>>> >>>>Without additional configurations or filtering, how would the below >>>>scenarios be satisfied? >>>>> >>>>> >>>>>2 war projects, A and B. The B war depends upon A. Would B grab all of >>>>>A's class files now instead of the jar, and place them into the classes >>>>>war directory instead of the jar going into lib? That would certainly >>>>>generate a valid war, but it wouldn't necessarily be the "expected" >>>>>behavior. >>>>> >>>> >>>> >>>>B would grab the jar of A, since it's included as an artifact in the >>>>'runtime' configuration of A. >>>> >>>> >>>>> >>>>>Now what about C that is an ear project. How does it grab the correct >>>>>jar/war from A and/or B, since the default configuration no longer >>>>>includes the jar/war archives? An ear can contain multiple ejb-jar jar >>>>>files and/or war files, so there needs to be some explicit way to get the >>>>>proper artifact from A or B. I'm not sure what that is without some >>>>>additional filtering or discrete configurations. >>>>> >>>> >>>> >>>>I'd probably add a standard configuration for the purpose of assembling an >>>>EAR, called, say 'earComponents'. The producing project adds the artifacts >>>>which are available for inclusion in an EAR to this configuration. The >>>>consuming project declares a dependency on this configuration. So, we do >>>>something like: >>>> >>>> >>>>* Change the war plugin to add the war to the 'earComponents' configuration >>>>as well as the 'artifacts' configuration. >>>>* Add an 'ejb-jar' plugin, which extends the 'java' plugin. All it would do >>>>for now is add the jar to the 'earComponents' configuration. It later might >>>>add some tasks/convention for dealing with the ejb deployment descriptor. >>>>Or some deployment tasks. Or some nice arquillian integration, or ... >>>>* Add some way for the ear plugin to declare that any dependency in the >>>>(incoming) 'deploy' configuration should default to the (outgoing) >>>>'earComponents' configuation in the target project or module, unless >>>>explicitly specified. >>>> >>>> >>>>At this point, I'd also think about: >>>>* Changing the base plugin to add a rule that any artifact added to any >>>>configuration is also added to the 'artifacts' configuration. >>>>* Renaming the 'deploy' and 'earlibs' configurations added by the ear >>>>plugin. >>>>* Inferring 'earlibs' from the runtime dependencies of the included ejb >>>>jars, plus the runtime dependencies of the included wars (ie those that >>>>are not bundled in the war, aka 'provided' dependencies). >>>> >>>> >>>> >>>> >>>>> >>>>>-Spencer >>>>> >>>>> >>>>> >>>>> >>>>>>________________________________ >>>>>>From: Adam Murdoch <[email protected]> >>>>>>To: [email protected] >>>>>>Sent: Sunday, September 18, 2011 10:11 PM >>>>>>Subject: Re: [gradle-dev] [gradle] Adds a restoreJar() method to the War >>>>>>Task (#43) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>On 19/09/2011, at 11:38 AM, Spencer Allain wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>>________________________________ >>>>>>>>From: Adam Murdoch <[email protected]> >>>>>>>> >>>>>>>> >>>>>>>>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. >>>>>>>> >>>>>>> >>>>>>>Isn't there still the problem with both the Jar and War in the archives >>>>>>>configuration? >>>>>>> >>>>>>>I specifically pulled the war out of the archives configuration to get >>>>>>>around the warning from javac. I can see if the compile dependency uses >>>>>>>classes instead of the jar that just stuffing it into the runtime would >>>>>>>be sufficient, but I didn't think that was how project dependencies >>>>>>>worked yet. >>>>>>> >>>>>>>I must be missing something if just those simple changes (plus the changes to ear) remove the issues. If default is still used for project dependencies, then what is actually included in that configuration? Would compile dependencies point to depended-upon project runtime? >>>>>>> >>>>>> >>>>>> >>>>>>A project dependency, by default, uses the 'default' configuration from >>>>>>the target project. The first change above breaks the connection between >>>>>>'default' and 'archives', so that adding stuff to 'archives' does not >>>>>>affect what consumer projects see in their classpaths. That is, we can >>>>>>add wars or ears or documentation archives or whatever to 'archives' and >>>>>>these are not made visible to consumers. The second change above adds the >>>>>>jar to both 'runtime' and 'archives', so that it is both made available >>>>>>in the classpaths of consumer projects, and for publication in the >>>>>>producing project using the 'uploadArchives' task. >>>>>> >>>>>>I think we should be good. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>-- >>>>>>Adam Murdoch >>>>>>Gradle Co-founder >>>>>>http://www.gradle.org/ >>>>>>VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting >>>>>>http://www.gradleware.com >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>>-- >>>>Adam Murdoch >>>>Gradle Co-founder >>>>http://www.gradle.org >>>>VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting >>>>http://www.gradleware.com >>>> >>>> >>>> >>>> >>> >>> > > >-- >Adam Murdoch >Gradle Co-founder >http://www.gradle.org >VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting >http://www.gradleware.com > > > >
