On 07/10/2011, at 7:30 AM, Spencer Allain wrote: > So it seems that the maven deployer/installer is a bit more magical than I > first thought. It'll blow up on jars/wars/ears together in the archives > because it wants to create poms for things that it recognizes, but it works > just fine with zip files in the archives configuration or probably anything > else that it'll randomly install that doesn't match the expected extensions > for the known project types: (pom, jar, maven-plugin, ejb, war, ear, rar, > par). > > I guess I'm now leaning towards removing the war artifact from archives as > well if the ear plugin is installed -- the alternative would be to change the > default PublishFilter to not match anything (but that'd likely have > additional side-effects). > > I'm moving forward with option [1]. As much as I prefer the multiple > artifact deployment as the default, currently writing the correct filters is > not something that will be trivial for a novice -- as sometimes you'll want > to override the default filter, and other times actually add filters.
I see option 1 as just a first step, rather than the final destination. We can keep going with this. I would think about deprecating the filters entirely, and model a maven publication explicitly: ie an object with properties such as 'mainArtifact', 'artifacts', 'pom', 'scopes.compile' and so on. > > I do like the suggestion of automatically publishing the dominant products > jar < war < ear... but having messed around with the filters, you have to be > very careful to not drop other things from the archives that are supposed to > get published (like misc. zip bundles), and I'd rather not tackle that just > at the moment as I don't see an easy way to change the default filter to > ignore jars if War/Ear plugin installed or wars if Ear plugin installed. > > -Spencer > > From: Spencer Allain <[email protected]> > To: "[email protected]" <[email protected]> > Sent: Wednesday, October 5, 2011 9:10 AM > Subject: Re: [gradle-dev] [gradle] Adds a restoreJar() method to the War Task > (#43) > > 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: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? > > 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 > > > > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
