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