On 12/09/2011, at 4:01 PM, Daz DeBoer wrote:
> G'day
>
> I'm just implementing a convenience for creating an ivy repository
> with a base url. For now, I'm using the maven pattern for artifacts
> and ivy files; does anyone have a better idea for a reasonable
> default?
>
> Is there a de-facto standard that I'm not aware of? If not, what would
> we like it to be?
>
> ie:
> ivy {
> url = 'http://localhost'
> }
>
> is the same as
> ivy {
> artifactPattern
> 'http://localhost/[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier])(.[ext])'
> ivyPattern
> 'http://localhost/[organisation]/[module]/[revision]/ivy-[revision].xml'
> }
This is a reasonable default, I think. Until, of course, we get further along
the native binaries path (unless we jam all the variant meta-data for an
artifact into the classifier or the artifact name. But let's no do that).
One question is whether [organisation] is expanded using the Ivy or Maven
convention. ie do we do organisation.replace('.', '/') when expanding the
pattern?
Even if we go with the Ivy convention, we will eventually want some way to
specify 'use the maven layout for this repository'. Which doesn't fit into a
pattern. It needs logic (albeit very simple logic). So, I think we want to move
away from using patterns for our repo definitions, and move towards reusable
layout logic, ie layout strategies, where using patterns is one possible
strategy.
I think we eventually want the repository DSL to allow me to:
* Define an ivy repo by specifying a base URL + one of the canned layouts.
There'd probably be 2 layouts to start with: Maven and a Gradle defined one.
One of these would be the default.
* Define an ivy repo by specifying one or more patterns.
* Define an ivy repo by specifying a custom layout.
* Define an ivy repo by specifying one or more 'pattern' closures:
repositories {
ivy {
// delegates to an Artifact instance, and can return anything that
Project.uri() can convert to a URL
artifacts { "http://localhost/${organisation.replace('.',
'/')}/${module}/${artifact}-${revision}.${ext}" }
}
}
One question is whether instead of having the url add some default patterns, we
go straight to the layout based approach, with 3 fixed layout implementations
for now: Maven, Gradle Ivy, and pattern based? I think this will help us move
towards the fuller DSL later in a backwards-compatible way, and means we don't
have to expose things like the m2compatible flag on our DSL, but can still
handle that use case.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
