On 30/10/2012, at 10:56 AM, Luke Daley wrote: > This is the continuation of a synchronous conversation I had with Adam, that > I'm putting on the dev list for anyone who is interested. > > We went from having a generic Publish task, to targeting more focussed tasks > like IvyPublish. I'm now questioning why we want to do this. > > Pros: > > 1. Additional type safety (Use IvyPublication and IvyArtifactRepository > instead of Publication and ArtifactRepository in the getters/setters) > 2. Opens up the potential for Ivy specific configuration options to be used > during publication that don't belong on Publication or ArtifactRepository
3. Better communicates the purpose of each task, i.e. what it does. 4. Doesn't model publishing as a one-size-fits-all action, but rather as an abstract action with multiple implementations. I think this is an important distinction to make, and the separation helps communicate this. > > Cons: > > 1. Initially, besides the stronger types there would be no difference with a > generic Publish in terms of impl > 2. Closes the door (in a sense) on being able to publish Ivy publications to > non “ivy” repositories that you can publish an Ivy type thing to (e.g. github) I don't think so. Taking the github example, we have a few options: * Model github downloads as an Ivy repository or a Maven repository or both, and you can use the existing stuff. * Add a GithubRepository type and a GithubPublish type and a GithubPublication type. * Add a GithubPublish task type and a GithubPublication type, but not a repository type. The task can just take the github user name and repo name as inputs. There are a couple of things you will be able to do with publications that you can't do right now: * Ask for the binary content and identifier for each artefact in the publication, including the meta-data. * Create stand-alone Ivy descriptors and Maven Poms and attach them arbitrary publications. You be able to use these to convert a publication to some custom publication type, or to just do something useful with the artefacts without modelling that useful thing as publication to a repository. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
