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 Tue, 05 Feb 2008 08:35:18 GMT
Not sure about this as I didn't experiment, but what's maven behaviour when
accessing a repository configured with snapshots=disabled and receiving
meta-datas with snapshots ?

The idea is :

in my settings.xml, configure archiva for mirroOf=*, and have a "grouped"
archiva repository , that groups all my repos (snapshots & releases)

when maven request a released artifact all is fine.
when maven request a snapshot and reads meta-datas, it should get the latest
snapshot

The only possible issue here (AFAIK) is that I could get a snapshot for a
plugin when there is no version set in the POM. As I have set all commons
plugins version in my corporate POM <pluginManagement>, I'm safe with this
(I can also use a maven-enforcer-plugin rule for this).

Using such a config (if we supose there is no side-effect), what is the
benefict of having separate release and snapshot repositories ?

Nico.

2008/2/5, Arnaud HERITIER <aheritier@gmail.com>:
>
> 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