archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arnaud HERITIER" <aherit...@gmail.com>
Subject Re: Archiva 1.1 Roadmap
Date Tue, 05 Feb 2008 08:15:32 GMT
I had also this idea of virtual repositories (i talk with brett about it
some monthes ago) because it simplify user settings and moreover it reduces
the bandwith and the access time if the network isn't really good. Maven has
to do only one request for each artifact.
For snapshots and dependencies with a range it's less easy to develop
because you have to check in all repositories to see where is the newest
version.
Another problem is that I would like to have like nicolas only two
repositories  : one for snapshots and one for releases. But actually in the
maven side I can't have a mirror * for snapshots and another for releases.

Arnaud

On Feb 5, 2008 9:03 AM, nicolas de loof <nicolas@apache.org> wrote:

> Yes, that's the idea of a "vitrual" repository URL to acces a set
> ("group")
> of managed repositories.
>
> For my personnal use case I also have to look at the Dav server
> implementation to add support for Windows UNC file path.
>
> Nico.
>
> 2008/2/5, Maria Odea Ching <oching@apache.org>:
> >
> > 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 <nicolas@apache.org> 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 <bellingard@gmail.com>:
> > > >
> > > > 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 <nicolas@apache.org> 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
> > > > > >
> > > > >
> > > >
> > >
> >
>



-- 
..........................................................
Arnaud HERITIER
..........................................................
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..........................................................
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...........................................................

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message