On Tue, Mar 10, 2009 at 2:08 PM, Dave McLoughlin
<dave.mclough...@openlogic.com> wrote:

> The only way that we have found to do this would be to create a separate
> repository for each group that has a set of commercial binaries that
> they need to build against.  We'd rather not take this approach because
> (1) it reduces the reuse of maven and really defeats the purpose of
> having shared binaries and (2) we are concerned that it will not scale
> to 500-2000 repositories.

At what level would you need to control authorization?  Would groupId
work, or would you need it all the way down to the artifact level, or
even down to the version?

I'm not sure what you mean by "it reduces the reuse of maven and
defeats the purpose of having shared binaries" ?  They're still
shared... you're just restricting who can see them.

Here's an idea [untested] ... set up a separate managed repository for
each set of commercial binaries, and grant the repository observer
roles to the appropriate users.

Then create a repository group, and put all of your repositories in
it.  The authorization rules *should* apply to the repos behind the
group, so that everyone retrieves all of their artifacts from
http://repo.mycompany.com/archiva/repository/all, but each user can
only "see" the artifacts he or she should.

You'd need to make sure to keep local repos and credentials separate
if you're using a shared build server.  Once something gets into the
local repo, it will be visible to all builds from then on.

I do share your concerns about scaling this to 2000 repos, I'm not
sure how the virtual repository group would perform with that many
managed repos behind it.

This is a hard problem to solve, it's really the same one others have
written about wrt governance of who is allowed to use which open
source artifacts.  In the environment I work in, artifacts are
approved for use in building certain projects, it's not done at the
user level.  And worse, it's time sensitive since an approval may
expire.

-- 
Wendy

Reply via email to