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.
I wouldn't necessarily model this case as a repository. All we need for publishing is something that can be converted to a Publisher, and all we need for resolving is something that can be converted to a Resolver. So, we might keep Repository as something that can do both, and introduce new types that may or may not be related to Repository to represent a read-only source and a write-only destination. There are 3 basic approaches we can take here: * A Repository type with optional publish and resolve operations. Convert to a Resolver when resolving and a Publisher when publishing. * A ResolvableRepository that can resolve, and a PublishableRepository that can publish. Convert to a Resolver when resolving and a Publisher when publishing. * Both of the above. I don't think it really matters which of the above we choose, to be honest. This might change as we add more tweakable stuff for resolving and publishing. Something that would also help here is to split out the building blocks that make up a repository: * Layout. * Meta-data providers. * Transport. A repository/resolver/publisher is just a particular wiring of these components. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
