For anyone following, this moved to the forum: http://forums.gradle.org/gradle/topics/maven_pom_generation_and_multiple_archive_artifacts_doesnt_work
On 02/10/2011, at 3:54 PM, 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:null > at > 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? > > -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 > > > > > -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
