Yes, agreed. +1 for this functionnality, which could, IMO, be implemented rapidely.
Fabrice On Feb 5, 2008 8:40 AM, Maria Odea Ching <[EMAIL PROTECTED]> wrote: > 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 > > > > > > > > > > > > > > >
