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