On 25/10/2012, at 5:54 AM, Luke Daley wrote: > I'm working through the ivy metadata customisation stuff. I'm wondering where > the responsibilities lie for certain things going forward. > > Spec for this work is here: > https://github.com/gradle/gradle/blob/master/design-docs/publication-model.md > > What would the responsibility of an upload task be? > > 1. Upload one or more publications to one or more repositories? > 2. Upload one publication to one or more repositories? > 3. Upload one publication to one repository? > > For my money, #3 is the best. It's far simpler and more common, and you can > still fulfil #1 and #2 via adding more upload tasks. > > The immediate question is whether the new Publication concept should be added > to: > > 1. Repository (somehow) > 2. Upload > > I think #2 makes the most sense. All and upload task should be is the glue > between a Publication and a Repository, and be the execution point. > > If we're on track so far,
I think so. > then we have an immediate issue in how to deal with the fact that we abstract > over Ivy and Maven. > > Here's my plan for Ivy: > > 1. Add setPublication(IvyPublication) to Upload > 2. Apply (use to influence what is uploaded) uploadTask.publication to each > uploadTask.repositories that is not a MavenResolver > 3. Wire publications.ivy to uploadTasks.publication This sounds fine. I'd have setPublication() take a Publication instead of an IvyPublication (as you suggest below). We should make the publication property optional, so that we continue to work in a backwards compatible way. One question is what to do with the Upload.configuration property, as eventually the information that we use from Configuration is going to come from the Publication. This would be a potentially breaking change, as the information can be different (this is the whole point of the change). I think at that point, we'd need to introduce a new Publish task type and deprecate Upload. > > Here's my plan for Maven: > > 1. Add setPublication(MavenPublication) to MavenResolver > 2. Wire publications.maven to the publication of uploadTask.repositories that > are MavenResolver There needs to be a MavenPublication per MavenPom that the resolver uses. So, if I call MavenResolver.addFilter(), there would need to be a second MavenPublication added to the publications container and attached to the new MavenPom that the filter uses. I was hoping that the MavenPublication implementation could simply be an adapter over MavenPom, such that the MavenPom doesn't know or care about the new API and that the MavenPublication instance delegates to the backing MavenPom instance. Failing that, I would try to add MavenPom.getPublication() but not setPublication(). These objects are too tightly coupled to for it to make sense to point a given MavenPublication instance at a different MavenPom instance, and vice versa. Failing that, the setter needs to be internal and used only at construction time. We should also deprecate MavenResolver.setMavenPom() and PomFilter.setPomTemplate(). These should fail hard if called when the 'maven-publish' plugin has been applied. This is because the migration path is only going to work with the MavenPom instances that we create and manage. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
