My "managed" repository are on another windows Box (for corporate reason) and are proxied as file:// URLs. I have to manage them by hand as the DAV server doesn't support windows SMB file format "\\server\path" (that gets "normalized" to "\server\path"). That's not an issue for me as there is nothing to manage (only sometime deploy new artifacts).
My "maven" managed repository duplicates those corporate repos, and also mirors public internet ones. I only use archiva as a proxy and cache, so don't care about scanner-based features on my corporate repos. Hand based management is enough for me on those one. If I configure them as managed repos, I may get artifact twice on browse ... to be honest I also don't use the browse feature ! For my use case, archiva is just a replacement of the good old maven-proxy I used for maven1, with the HUGE benefict I can manage a single maven2 repository and still have my old m1 projects (I still have lots) get the required artifacts. I have a second "managed" repository for snapshots as http://server/archiva/repository/snapshot with the required <mirror> in settings.xml for apache.snapshots & codehaus.snapshots This configuration is simple for user but not very clean on server side. I can't take advantage of archiva features on my managed repos (even I don't need/use them now, they still are interesting). The "virtual repository" concept would solve the configuration issue but not my "unsuported samba share filesystem" issue :-( Nico. 2008/2/4, Fabrice Bellingard <[EMAIL PROTECTED]>: > > Nicolas, > > concerning your "maven" managed repository: are you currently really doing > that with archiva? It seems indeed interesting, as it simplifies the > configuration of the settings.xml file. However, I have a couple of > questions: > - this means that this "maven" repository duplicates every artifact > handled > in your other managed repositories, right? So when you browse artifacts in > Archiva, you see managed artifacts twice, don't you? > - do you use the same principle for snapshots repositories? I mean, > metadata > files would conflict with release repositories, so you need another > "virtual" repository for snapshots. > > Fabrice > > On Feb 4, 2008 9:38 AM, nicolas de loof <[EMAIL PROTECTED]> wrote: > > > Early version of archiva had on admin menu a "sync repository" entry. > > > > Not sure if the original idea was to manage a classical rsync-like miror > > or > > to isolate local cache for remote proxied repositories. > > > > > > I would suggest some "virtual" repository > > > > A simple example is my corporate use case : many user don't know maven > > well > > and have no idea what a repository is (and how to configure), so we have > > configured settings.xml to mirror all common repositories to the archiva > > instance : http://server/archiva/repository/maven > > > > The "maven" managed repository is an aggregate of proxied (central, > > java.net, > > jboss, ...) and managed ones : corporate builds, restricted jars (SUN > > apis, > > oracle driver) and sources bundles (missing in public repos) > > > > This repository, declared in archiva configuration as "managed" is NOT > the > > one we have to manage ! It only is a facade to other managed and proxied > > repositories. > > > > > > Nico. > > > > > > > > > > One item I wanted to single out is the separation between managed > > > > repositories used for publishing and those used for caching > artifacts > > > > from remote repositories. I don't think it makes much sense to have > a > > > > managed repository that can do both. > > > > > > > > > a big +1 here :) a lot of people has been confused over this > especially > > > when > > > there are quite a handful of repositories being managed. > > > > > > > > > > > > > > > > > > This separation would allow us to have: > > > > * Provide indexing, browsing and search only for "publishing" (See > > foot > > > > note) > > > > * RSS feeds for new artifacts in published repositories. > > > > > > > > Foot note: > > > > Allowing to search proxied data is a broken idea - its an incomplete > > > > view of a remote repositories and when your dealing with tens of > > > > gigabytes of metadata and artifacts this becomes painful and slow. > > > > > > > > Anyway, I look forward to your comments. > > > > > > > > Thanks, > > > > James Dumay > > > > > > > > > > > Thanks, > > > Deng > > > > > >
