Not quite,

1. Developers build as always using ibiblio. Most likely they have local repositories on their machines. You may use maven-proxy to make your builds faster (snapshot checking is faster under a maven-proxy with snapshot caching tuned). Downloads for new users are faster too as they retrieve all artifacts internally over the intranet.

2. Create a "certified" repository on your intranet.  Only certified artifacts are 
placed in there.  Expose this repository via http (maven-proxy can be used for this, but any 
http server will do).  Developers may add this as a remote repository, but it probably won't 
have much value

3. "production build user" has it's own local repository, completely separate from the 
developers.  Set maven.repo.remote to the "certified repository"


That's all you need.



Where I saw maven-proxy being handy is in the creation of a certified repository. It allows you to map together several local repositories / remote repositories into a single virtual repository. In your case, you wouldn't have any remote repositories configured. In our maven-proxy, we have
1) Global repo (the default storage location in maven-proxy)
2) work-repo (all our finalised work artifacts)
3) damagecontrol-repo (where damagecontrol spits it's snapshot builds)
4) sun-repo (where all the evilly licenced sun jars go)
5) www.ibiblio.org/maven
6) dist.codehaus.org


This lets us separate sun jars from the standard jars, lets us release snapshot instantly via the proxy without pushing them anywhere etc.


The use case I thought might exist is the promotion of artifacts to "certified" status, and whether adding some workflow into maven-proxy to allow this via the interface was useful and desired. Copying the jars in manually is pretty easy mind you.


Cheers,

Ben

Helck, Christopher wrote:

I'd like to make sure I understand what you are saying:

1. Developers build as always using ibiblio. Most likely they have local
repositories on their machines.

2. One of the local repositories will also serve as certification's
remote repository.

3. Certification builds using this remote repository.

4. Certification runs maven-proxy so that it can access the local
repository as if it were a remote repository?

I don't understand the need for Step 4. Could certification just share
the local repository the same way that developers do?

Won't the local repository contain downloaded stuff as well as locally
built stuff (via jar:install)? Of course we could more carefully control
the shared local repository.

Thanks,
Chris




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to