Hi Nicolas, I believe what you were pertaining in your scenario is like the repository grouping? Where in a number of managed repositories can be grouped together with that group having only one url. So you only need to specify that url in your settings.xml file and when Archiva receives a request via that url, it would look for that artifact from the repositories belonging to that group.
This functionality is really handy especially if the users are not very familiar with Maven as in your corporate use-case.. Thanks, Deng On Feb 4, 2008 6:58 PM, nicolas de loof <[EMAIL PROTECTED]> wrote: > 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 > > > > > > > > > >
