On 26/10/2012, at 8:12 PM, Luke Daley wrote: > The spec for publication > (https://github.com/gradle/gradle/blob/master/design-docs/publication-model.md) > treats a repository that is something that is used for both consumption and > publication. > > I want to explore this a little to make sure it's right. Something about it > makes me uneasy, but I can't construct a really solid argument as to why. So > I'm just going to walk through the concepts to see if we all agree it makes > sense. > > The proposed model has the following components: > > 1. Resolver - can be used to find/retrieve artifacts from somewhere > 2. Publisher - can be used to transfer artifacts to somewhere > 3. Repository - A description of “somewhere” and how to access it, can > provide a Resolver and/or a Publisher > > From a DSL/user POV, only Repository is exposed. Users configure Repository > objects for the purpose of resolving *and* publication. Resolver and > Publisher may be public one day, but this would be part of the extension API > for plugging in new “somewhere” types. > > There's an assumption in here that: > > 1. The exact same set of information that needs to be configured for > resolving is the same that is needed for publication, or > 2. Repository types expose certain configuration that is particular to > resolving or publication > > Some questions: > > 1. What would we do when you consume via http, but publish via sftp (to the > same somewhere)? Are these two different Repository objects? > 2. What if I consume over http, but publish over https (with everything else > being the same)? > 3. When would we ever reuse the same Repository object for consumption and > publication? > > > It feels like we have something missing here. That is, I think Repository is > the wrong commonality here. What is common is how to determine the address > that some artifact should be found at (for consumption or publication), which > is something like a Layout I think. > > The only thing I see that converging on Repository gives us is DSL > consistency in two different spaces, but I also see this as a risk in that we > need to make this DSL coherent for both cases. > > > Also, who says we are publishing to a consumable repository? What if > publication means calling a SOAP web service and we have no need of ever > consuming from this guy for resolution? We'd have to have a Repository impl > with the Resolver part empty.
Another complication is that 'publish' has a bunch of different meanings here: * An abstract meaning: take the artefacts produced by the build and copy them to wherever they need to go, ready for reuse outside the build. * A concrete meaning: take the artefacts produced by the build and make them available as a maven module or ivy module in a binary artefact repository. Let's call the first case "publishing" and the second case "publishing to a binary artefact repository" for now. Publishing to a binary repository is-a type of publishing. We don't necessarily need to model all publishing in the same way. We definitely want the abstract concept, but the what and how may vary according to the use case. So, we might not model your "publish to a web service" use case above as "publishing to a repository". We might instead model it as "publishing to a web service". The DSL for publishing to a web service might not share anything at all with the DSL for publishing to a repository. Or they might share, say, the concept of an http endpoint and of credentials, but not the concept of a repository. Same with the implementation. They might share, say, the http transport and the meta-data providers, but nothing else. In the publication model spec, I added a 'publish' lifecycle task as the abstract concept. Given this, I wonder if we should make the Publish task more specific, so that we have an IvyPublish task that takes an IvyPublication and IvyRepository and a MavenPublish task that takes a MavenPublication and a MavenRepository. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
