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
