archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "nicolas de loof" <nico...@apache.org>
Subject Re: Archiva 1.1 Roadmap
Date Mon, 04 Feb 2008 10:58:34 GMT
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