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