Hi Donald,
Sorry if I didn't answer earlier, I was still munging on implications of
your design proposal.
I do see the immediate values of:
1) adding repositories.snapshot_to to upload SNAPSHOTs to a different repo
(if defined); this would be consistent with Maven practices and I think we
should support it.
2) adding download_from to an Artifact; this could be useful if only
one/some of many artifacts come from a different repo and we don't want to
pay the latency tax by querying this repo for all artifacts.
As for mirror_to, it seems to be largely duplicated by repositories.remoteor
download_from (assuming we add it). Given the download information is
typically in the same buildfile, I'm not sure when this would be useful.
I'm not clear on the value of uploading to different repositories. People
who need artifacts replicated typically set up repositories such that they
mirror (a subset or all) of each other. Granted, it doesn't add much
complexity but it doesn't seem like a widely needed features. (People
reading this, feel free to jump in if you think it's useful).
Stepping back a little bit, I'm wondering if adding metadata to artifacts is
a good approach. The alternative is to place artifacts in arrays or hashes
and manage these as sets, e.g.,
public_artifacts = [ list, of, artifacts, to, publish, to, public, repos ]
task :release do
# public_artifacts are also uploaded to bigco's repo.
public_artifacts.each do |a|
a.upload :url => 'ssh://release.bigco.com/repo', :username => 'foo',
:permissions => 0664
end
end
or even,
# This seemed to be another of your use-case
task :replicate_artifacts do
artifacts.each do |a|
a.download :repository => 'http://bigco.com/repo' # not available today
a.upload :url => 'http://example.com/repo', :username => 'foo'
end
end
Buildr has historically used this approach where artifacts are specified
in-context (e.g. compile.with ...) instead of adding metadata on them;
compare this with, say, Maven's approach of specifying the scope of
artifacts as metadata (e.g. compile, test, runtime, provided, etc.) The
result is that Buildr tends to be more flexible and explicit, albeit less
declarative.
Have you considered this approach? I'd be curious to hear if/why you think
using metadata is a better way to go.
alex
On Sat, Sep 18, 2010 at 8:51 PM, Peter Donald <[email protected]>wrote:
> Over the next little while I intend to put together some code that can
> manage our artifacts more effectively and I thought I would ask the
> list to see if it is something worth contributing back to the core of
> buildr.
>
> So we want to define the associated repositories with an artifact;
> * release_to: An array of repositories that non snapshot releases are
> uploaded to. (i.e. like repositories.release_to but an array)
> * snapshot_to: An array of repositories that snapshots are uploaded
> to. (i.e. like repositories.release_to but an array)
> * download_from: An array of repositories that an artifact can be
> downloaded from. (i.e. like repositories.remote)
> * mirror_to: An array of repositories that can hold a copy of
> artifacts. Typically this is checked first before going to
> download_from. This repository definition includes information for
> uploading and downloading. This allows for tools to be written that
> will download from dowload_from and upload to mirror_to repos.
>
> Somehow we need to associate metadata with each artifact so as to
> select the appropriate repositories for each artifact. It seems
> reasonable to have default values across the project as is currently
> done in buildr and then override for exceptions.
>
> One approach I had considered was attaching metadata to the spec
> definition of the artifact. The approach would allow an arbitrary set
> of key/value pairs at the end of the spec separated by a ; character.
>
> So to use the default repositories you may do something like
>
> 'org.example:my-project:jar:1.0'
>
> but to override the defaults you may use something like
>
>
> 'org.example:my-project:jar:1.0;upload_to=my_release_repo_key,my_other_release_repo;mirror_to='
>
> and this would indicate that the artifact is not to be mirrored but
> when a release occurs it should be released to the repos identified by
> the keys "my_release_repo_key" and "my_other_release_repo". (Of course
> there would need to be other code added to register repository
> information under a key)
>
> Rather than putting this in the spec you could also do it
> programatically via something like the following in your buildfile
>
> artifact('org.example:my-project:jar:1.0').tap do |a|
> a.meta['upload_to'] = ...
> end
>
> The advantage of attaching it to the spec IMHO is that you can easily
> do it in the build.yaml AND it makes it easier to use it in the future
> if you wanted to write a custom resolver for specs.
>
> So I guess my question is does this seem reasonable? Or do you have
> any suggestions that would make it more likely to be incorporated in
> buildr in the future. I was hoping to get some time over the next few
> weeks and put together a buildr plugin on github to see if it works as
> good in practice as it does in theory.
>
> Thoughts?
>
> --
> Cheers,
>
> Peter Donald
>
