Any response to this? I am willing to do all the legwork to get this
done if some common approach can be worked out.
On Sun, Sep 19, 2010 at 1:51 PM, Peter Donald <pe...@realityforge.org> 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
>
--
Cheers,
Peter Donald
