archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fabrice Bellingard" <belling...@gmail.com>
Subject Re: Archiva 1.1 Roadmap
Date Tue, 05 Feb 2008 07:42:26 GMT
Yes, agreed. +1 for this functionnality, which could, IMO, be implemented
rapidely.

Fabrice

On Feb 5, 2008 8:40 AM, Maria Odea Ching <oching@apache.org> 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 <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
> > > > >
> > > >
> > >
> >
>

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