You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@archiva.apache.org by James William Dumay <ja...@atlassian.com> on 2008/02/04 07:06:59 UTC
Archiva 1.1 Roadmap
Hey guys,
Just wanted to help kick off our way to a 1.1 release
Here have been a few things that have been at the back of my mind. I
think this is a list we should pick and choose from:
* Reduce memory consumption
* Preemptive artifact synchronisation
* Eliminate client side blocking when artifacts are being downloaded
from remote repositories.
* Ability to take repositories (both managed and remote) offline (See
MRM-541)
* Communication with remote repositories should be done asynchronously
* Web UI for deploying artifacts
* Plugin subsystem. We already have this for consumers but we really
should have features like search, dependency graphing and browsing as
plugins so we can turn bad behaving features and also give a way for
users to create their own functionality.
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.
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
Re: Archiva 1.1 Roadmap
Posted by Fabrice Bellingard <be...@gmail.com>.
Yes, agreed. +1 for this functionnality, which could, IMO, be implemented
rapidely.
Fabrice
On Feb 5, 2008 8:40 AM, Maria Odea Ching <oc...@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 <ni...@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 <be...@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 <ni...@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
> > > > >
> > > >
> > >
> >
>
Re: Archiva 1.1 Roadmap
Posted by nicolas de loof <ni...@apache.org>.
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 <ah...@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 <ni...@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 <oc...@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 <ni...@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 <be...@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 <ni...@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
> ...........................................................
>
Re: Archiva 1.1 Roadmap
Posted by Arnaud HERITIER <ah...@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 <ni...@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 <oc...@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 <ni...@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 <be...@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 <ni...@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
...........................................................
Re: Archiva 1.1 Roadmap
Posted by nicolas de loof <ni...@apache.org>.
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 <oc...@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 <ni...@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 <be...@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 <ni...@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
> > > > >
> > > >
> > >
> >
>
Re: Archiva 1.1 Roadmap
Posted by Maria Odea Ching <oc...@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 <ni...@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 <be...@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 <ni...@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
> > > >
> > >
> >
>
Re: Archiva 1.1 Roadmap
Posted by nicolas de loof <ni...@apache.org>.
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 <be...@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 <ni...@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
> > >
> >
>
Re: Archiva 1.1 Roadmap
Posted by Fabrice Bellingard <be...@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 <ni...@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
> >
>
Re: Archiva 1.1 Roadmap
Posted by nicolas de loof <ni...@apache.org>.
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
>
Re: Archiva 1.1 Roadmap
Posted by Maria Odea Ching <oc...@apache.org>.
Thanks for putting this up James! Your proposal looks great :)
I've also listed below some other things I think we should consider or take
note of while planning the roadmap:
1. When is our target date for the 1.1 release? So that we could cut down
our roadmap and prioritize based on this target date.
2. Review the patches that have been previously submitted but not yet
applied (like MRM-216). We could include this in the roadmap as well if it
is already working.
3. I'd also like to suggest the following features/improvements for 1.1:
- review synchronization of the configuration object
- improve the tests where databases are being set-up (use mock objects
instead)
- statistical reports
On Feb 4, 2008 2:06 PM, James William Dumay <ja...@atlassian.com> wrote:
> Hey guys,
> Just wanted to help kick off our way to a 1.1 release
>
> Here have been a few things that have been at the back of my mind. I
> think this is a list we should pick and choose from:
>
> * Reduce memory consumption
+1
Snipp from #archiva have also brought this up and said he would observe this
in his Archiva installation too.
>
> * Preemptive artifact synchronisation
> * Eliminate client side blocking when artifacts are being downloaded
> from remote repositories.
> * Ability to take repositories (both managed and remote) offline (See
> MRM-541)
> * Communication with remote repositories should be done asynchronously
> * Web UI for deploying artifacts
> * Plugin subsystem. We already have this for consumers but we really
> should have features like search, dependency graphing and browsing as
> plugins so we can turn bad behaving features and also give a way for
> users to create their own functionality.
(I remember I encountered a synchronization or out of memory problem with
the searcher before, though I couldn't specifically remember what it was. We
might need to investigate this as well and improve the design of the
searcher.)
A thought to ponder for the last point.. how big a change would this be in
the current design of Archiva with regard to the search, dependency graphing
and browsing?
>
>
> 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
Re: Archiva 1.1 Roadmap
Posted by Maria Odea Ching <oc...@apache.org>.
Maybe we could do both..We don't want to cram everything in 1.1 :) Also, a
large portion of the issues in the 1.1 bucket are bug fixes. We could
probably move some of them to 1.0.2 or 1.0.x, wdyt?
Thanks also for updating the roadmap and jira Brett!
-Deng
On Feb 15, 2008 3:45 PM, Brett Porter <br...@apache.org> wrote:
> Thanks for putting the roadmap [1] in place Deng - I made a couple of
> cleanups and did a quick run through JIRA as well.
>
> I think we still need to cut back on the features for 1.1, since
> there's 62 issues in there... do we just timebox, or do we pick some
> features for 1.2 now?
>
> Cheers,
> Brett
>
> [1] http://docs.codehaus.org/display/MAVENUSER/Archiva+Roadmap
>
> On 11/02/2008, at 5:07 PM, Maria Odea Ching wrote:
>
> > On Feb 7, 2008 7:08 PM, Brett Porter <br...@apache.org> wrote:
> >
> >> I have some additions :)
> >>
> >> I also think we need to keep reviewing the types of problems people
> >> have and helping them diagnose them. It seems that figuring out repo
> >> whitelists and blacklists and the cause of proxy problems is still
> >> difficult - so maybe a UI configuration for the logging might be a
> >> good idea? Or a way to request it from a browser and get additional
> >> information (ie, 404 screen could capture all the logging even if
> >> it's
> >> not logged).
> >
> >
> > +1 :)
> >
> >
> >>
> >>
> >> Also, I'd like to finish the work of replacing the plexus runtime
> >> with
> >> a standalone jetty bundle that runs the war as is :)
> >
> >
> > I have a local copy of Archiva which includes the jetty-archetype you
> > started for this Brett, though I haven't been able to work on it
> > lately.
> > I'll try to put some time to complete it and check it in as soon as
> > I can.
> > Ill also file a jira to keep track of this.
> >
> > Thanks,
> > Deng
> >
> >
> >>
> >>
> >> On 07/02/2008, at 12:16 AM, Brett Porter wrote:
> >>
> >>> These all sound good to me. Really enjoying the discussion :)
> >>>
> >>> Some comments and additions:
> >>>
> >>> On 06/02/2008, at 5:48 PM, Maria Odea Ching wrote:
> >>>
> >>>> From the thread so far, these are the things to choose from for the
> >>>> 1.1roadmap:
> >>>>
> >>>> 1. Reduce memory consumption
> >>>> 2. Preemptive artifact synchronisation
> >>>> 3. Eliminate client side blocking when artifacts are being
> >>>> downloaded from
> >>>> remote repositories.
> >>>> 4. Ability to take repositories (both managed and remote) offline
> >>>> 5. Communication with remote repositories should be done
> >>>> asynchronously
> >>>> 6. Web UI for deploying artifacts
> >>>> 7. Plugin subsystem. We already have this for consumers but we
> >>>> really should
> >>>> have features like search, dependency graphing and browsing as
> >>>> plugins so we
> >>>> can turn bad behaving features and also give a way for users to
> >>>> create their
> >>>> own functionality.
> >>>> 8. Separation between managed repositories used for publishing and
> >>>> those
> >>>> used for caching artifacts from remote repositories. This
> >>>> separation would
> >>>> allow us to have:
> >>>> * Provide indexing, browsing and search only for "publishing"
> >>>> * RSS feeds for new artifacts in published repositories.
> >>>
> >>> I think this is something that is configurable, and set nicely by
> >>> default. I don't think we should completely separate proxy cache
> >>> managed repos from deployed repos, but having a default
> >>> configuration that does and recommending it is the way to go.
> >>>
> >>>>
> >>>> 9. Review synchronization of the configuration object
> >>>> 10. Improve the tests where databases are being set-up (use mock
> >>>> objects
> >>>> instead)
> >>>> 11. Statistical reports
> >>>> 12. Repository grouping
> >>>>
> >>>> Any more suggestions or comments for this? :)
> >>>
> >>> I'd just add "13. architectural simplification" - we talked about
> >>> some technology changes and while I don't think we need to rush into
> >>> any, it would be worth having them in mind if we can either
> >>> gradually move to them or if it becomes simpler to do than make a
> >>> change in the current set up. For instance, doing (10) might be
> >>> better at a time when we make changes to the database layer itself.
> >>>
> >>> Along these lines, architecturally I think we need to add: 14.
> >>> separate the subsystems better. In my view - the base system being
> >>> the tools (scanning, consumers, etc - with or without the database),
> >>> then the addition of the proxy/webdav on that (possibly without the
> >>> database), then the web application/visualisation on top of that
> >>> (this requires the databases and all other pieces of functionality).
> >>> We might later add web services as an option with or without the
> >>> webapp. These different deployment options would make it much more
> >>> flexible.
> >>>
> >>> Again I don't think this all needs to be done in one go - but
> >>> designing the target architecture and moving towards it would be a
> >>> good goal for 1.1 and beyond. Some of the above may actually be
> >>> plugins too, so we should consider the impact of that.
> >>>
> >>> Would be great to update the wiki with this list split into 1.1 and
> >>> beyond sections :)
> >>>
> >>>>
> >>>>
> >>>> Btw, what does everyone think of having the end of March as the
> >>>> target
> >>>> release date of 1.1?
> >>>
> >>> Great! We should probably aim to be feature complete a few weeks
> >>> before that then. This probably means only picking a few of the
> >>> above (there is a lot there!), and moving the rest to 1.2. Also need
> >>> to pick some important issues from the JIRA pool - as well as
> >>> cutting down the 60+ in there now :) We can keep working on critical
> >>> stuff in the 1.0.x line.
> >>>
> >>> Cheers,
> >>> Brett
> >>>
> >>
> >> --
> >> Brett Porter
> >> brett@apache.org
> >> http://blogs.exist.com/bporter/
> >>
> >>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: Archiva 1.1 Roadmap
Posted by Brett Porter <br...@apache.org>.
Thanks for putting the roadmap [1] in place Deng - I made a couple of
cleanups and did a quick run through JIRA as well.
I think we still need to cut back on the features for 1.1, since
there's 62 issues in there... do we just timebox, or do we pick some
features for 1.2 now?
Cheers,
Brett
[1] http://docs.codehaus.org/display/MAVENUSER/Archiva+Roadmap
On 11/02/2008, at 5:07 PM, Maria Odea Ching wrote:
> On Feb 7, 2008 7:08 PM, Brett Porter <br...@apache.org> wrote:
>
>> I have some additions :)
>>
>> I also think we need to keep reviewing the types of problems people
>> have and helping them diagnose them. It seems that figuring out repo
>> whitelists and blacklists and the cause of proxy problems is still
>> difficult - so maybe a UI configuration for the logging might be a
>> good idea? Or a way to request it from a browser and get additional
>> information (ie, 404 screen could capture all the logging even if
>> it's
>> not logged).
>
>
> +1 :)
>
>
>>
>>
>> Also, I'd like to finish the work of replacing the plexus runtime
>> with
>> a standalone jetty bundle that runs the war as is :)
>
>
> I have a local copy of Archiva which includes the jetty-archetype you
> started for this Brett, though I haven't been able to work on it
> lately.
> I'll try to put some time to complete it and check it in as soon as
> I can.
> Ill also file a jira to keep track of this.
>
> Thanks,
> Deng
>
>
>>
>>
>> On 07/02/2008, at 12:16 AM, Brett Porter wrote:
>>
>>> These all sound good to me. Really enjoying the discussion :)
>>>
>>> Some comments and additions:
>>>
>>> On 06/02/2008, at 5:48 PM, Maria Odea Ching wrote:
>>>
>>>> From the thread so far, these are the things to choose from for the
>>>> 1.1roadmap:
>>>>
>>>> 1. Reduce memory consumption
>>>> 2. Preemptive artifact synchronisation
>>>> 3. Eliminate client side blocking when artifacts are being
>>>> downloaded from
>>>> remote repositories.
>>>> 4. Ability to take repositories (both managed and remote) offline
>>>> 5. Communication with remote repositories should be done
>>>> asynchronously
>>>> 6. Web UI for deploying artifacts
>>>> 7. Plugin subsystem. We already have this for consumers but we
>>>> really should
>>>> have features like search, dependency graphing and browsing as
>>>> plugins so we
>>>> can turn bad behaving features and also give a way for users to
>>>> create their
>>>> own functionality.
>>>> 8. Separation between managed repositories used for publishing and
>>>> those
>>>> used for caching artifacts from remote repositories. This
>>>> separation would
>>>> allow us to have:
>>>> * Provide indexing, browsing and search only for "publishing"
>>>> * RSS feeds for new artifacts in published repositories.
>>>
>>> I think this is something that is configurable, and set nicely by
>>> default. I don't think we should completely separate proxy cache
>>> managed repos from deployed repos, but having a default
>>> configuration that does and recommending it is the way to go.
>>>
>>>>
>>>> 9. Review synchronization of the configuration object
>>>> 10. Improve the tests where databases are being set-up (use mock
>>>> objects
>>>> instead)
>>>> 11. Statistical reports
>>>> 12. Repository grouping
>>>>
>>>> Any more suggestions or comments for this? :)
>>>
>>> I'd just add "13. architectural simplification" - we talked about
>>> some technology changes and while I don't think we need to rush into
>>> any, it would be worth having them in mind if we can either
>>> gradually move to them or if it becomes simpler to do than make a
>>> change in the current set up. For instance, doing (10) might be
>>> better at a time when we make changes to the database layer itself.
>>>
>>> Along these lines, architecturally I think we need to add: 14.
>>> separate the subsystems better. In my view - the base system being
>>> the tools (scanning, consumers, etc - with or without the database),
>>> then the addition of the proxy/webdav on that (possibly without the
>>> database), then the web application/visualisation on top of that
>>> (this requires the databases and all other pieces of functionality).
>>> We might later add web services as an option with or without the
>>> webapp. These different deployment options would make it much more
>>> flexible.
>>>
>>> Again I don't think this all needs to be done in one go - but
>>> designing the target architecture and moving towards it would be a
>>> good goal for 1.1 and beyond. Some of the above may actually be
>>> plugins too, so we should consider the impact of that.
>>>
>>> Would be great to update the wiki with this list split into 1.1 and
>>> beyond sections :)
>>>
>>>>
>>>>
>>>> Btw, what does everyone think of having the end of March as the
>>>> target
>>>> release date of 1.1?
>>>
>>> Great! We should probably aim to be feature complete a few weeks
>>> before that then. This probably means only picking a few of the
>>> above (there is a lot there!), and moving the rest to 1.2. Also need
>>> to pick some important issues from the JIRA pool - as well as
>>> cutting down the 60+ in there now :) We can keep working on critical
>>> stuff in the 1.0.x line.
>>>
>>> Cheers,
>>> Brett
>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: Archiva 1.1 Roadmap
Posted by Maria Odea Ching <oc...@apache.org>.
On Feb 7, 2008 7:08 PM, Brett Porter <br...@apache.org> wrote:
> I have some additions :)
>
> I also think we need to keep reviewing the types of problems people
> have and helping them diagnose them. It seems that figuring out repo
> whitelists and blacklists and the cause of proxy problems is still
> difficult - so maybe a UI configuration for the logging might be a
> good idea? Or a way to request it from a browser and get additional
> information (ie, 404 screen could capture all the logging even if it's
> not logged).
+1 :)
>
>
> Also, I'd like to finish the work of replacing the plexus runtime with
> a standalone jetty bundle that runs the war as is :)
I have a local copy of Archiva which includes the jetty-archetype you
started for this Brett, though I haven't been able to work on it lately.
I'll try to put some time to complete it and check it in as soon as I can.
Ill also file a jira to keep track of this.
Thanks,
Deng
>
>
> On 07/02/2008, at 12:16 AM, Brett Porter wrote:
>
> > These all sound good to me. Really enjoying the discussion :)
> >
> > Some comments and additions:
> >
> > On 06/02/2008, at 5:48 PM, Maria Odea Ching wrote:
> >
> >> From the thread so far, these are the things to choose from for the
> >> 1.1roadmap:
> >>
> >> 1. Reduce memory consumption
> >> 2. Preemptive artifact synchronisation
> >> 3. Eliminate client side blocking when artifacts are being
> >> downloaded from
> >> remote repositories.
> >> 4. Ability to take repositories (both managed and remote) offline
> >> 5. Communication with remote repositories should be done
> >> asynchronously
> >> 6. Web UI for deploying artifacts
> >> 7. Plugin subsystem. We already have this for consumers but we
> >> really should
> >> have features like search, dependency graphing and browsing as
> >> plugins so we
> >> can turn bad behaving features and also give a way for users to
> >> create their
> >> own functionality.
> >> 8. Separation between managed repositories used for publishing and
> >> those
> >> used for caching artifacts from remote repositories. This
> >> separation would
> >> allow us to have:
> >> * Provide indexing, browsing and search only for "publishing"
> >> * RSS feeds for new artifacts in published repositories.
> >
> > I think this is something that is configurable, and set nicely by
> > default. I don't think we should completely separate proxy cache
> > managed repos from deployed repos, but having a default
> > configuration that does and recommending it is the way to go.
> >
> >>
> >> 9. Review synchronization of the configuration object
> >> 10. Improve the tests where databases are being set-up (use mock
> >> objects
> >> instead)
> >> 11. Statistical reports
> >> 12. Repository grouping
> >>
> >> Any more suggestions or comments for this? :)
> >
> > I'd just add "13. architectural simplification" - we talked about
> > some technology changes and while I don't think we need to rush into
> > any, it would be worth having them in mind if we can either
> > gradually move to them or if it becomes simpler to do than make a
> > change in the current set up. For instance, doing (10) might be
> > better at a time when we make changes to the database layer itself.
> >
> > Along these lines, architecturally I think we need to add: 14.
> > separate the subsystems better. In my view - the base system being
> > the tools (scanning, consumers, etc - with or without the database),
> > then the addition of the proxy/webdav on that (possibly without the
> > database), then the web application/visualisation on top of that
> > (this requires the databases and all other pieces of functionality).
> > We might later add web services as an option with or without the
> > webapp. These different deployment options would make it much more
> > flexible.
> >
> > Again I don't think this all needs to be done in one go - but
> > designing the target architecture and moving towards it would be a
> > good goal for 1.1 and beyond. Some of the above may actually be
> > plugins too, so we should consider the impact of that.
> >
> > Would be great to update the wiki with this list split into 1.1 and
> > beyond sections :)
> >
> >>
> >>
> >> Btw, what does everyone think of having the end of March as the
> >> target
> >> release date of 1.1?
> >
> > Great! We should probably aim to be feature complete a few weeks
> > before that then. This probably means only picking a few of the
> > above (there is a lot there!), and moving the rest to 1.2. Also need
> > to pick some important issues from the JIRA pool - as well as
> > cutting down the 60+ in there now :) We can keep working on critical
> > stuff in the 1.0.x line.
> >
> > Cheers,
> > Brett
> >
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: Archiva 1.1 Roadmap
Posted by Brett Porter <br...@apache.org>.
I have some additions :)
I also think we need to keep reviewing the types of problems people
have and helping them diagnose them. It seems that figuring out repo
whitelists and blacklists and the cause of proxy problems is still
difficult - so maybe a UI configuration for the logging might be a
good idea? Or a way to request it from a browser and get additional
information (ie, 404 screen could capture all the logging even if it's
not logged).
Also, I'd like to finish the work of replacing the plexus runtime with
a standalone jetty bundle that runs the war as is :)
On 07/02/2008, at 12:16 AM, Brett Porter wrote:
> These all sound good to me. Really enjoying the discussion :)
>
> Some comments and additions:
>
> On 06/02/2008, at 5:48 PM, Maria Odea Ching wrote:
>
>> From the thread so far, these are the things to choose from for the
>> 1.1roadmap:
>>
>> 1. Reduce memory consumption
>> 2. Preemptive artifact synchronisation
>> 3. Eliminate client side blocking when artifacts are being
>> downloaded from
>> remote repositories.
>> 4. Ability to take repositories (both managed and remote) offline
>> 5. Communication with remote repositories should be done
>> asynchronously
>> 6. Web UI for deploying artifacts
>> 7. Plugin subsystem. We already have this for consumers but we
>> really should
>> have features like search, dependency graphing and browsing as
>> plugins so we
>> can turn bad behaving features and also give a way for users to
>> create their
>> own functionality.
>> 8. Separation between managed repositories used for publishing and
>> those
>> used for caching artifacts from remote repositories. This
>> separation would
>> allow us to have:
>> * Provide indexing, browsing and search only for "publishing"
>> * RSS feeds for new artifacts in published repositories.
>
> I think this is something that is configurable, and set nicely by
> default. I don't think we should completely separate proxy cache
> managed repos from deployed repos, but having a default
> configuration that does and recommending it is the way to go.
>
>>
>> 9. Review synchronization of the configuration object
>> 10. Improve the tests where databases are being set-up (use mock
>> objects
>> instead)
>> 11. Statistical reports
>> 12. Repository grouping
>>
>> Any more suggestions or comments for this? :)
>
> I'd just add "13. architectural simplification" - we talked about
> some technology changes and while I don't think we need to rush into
> any, it would be worth having them in mind if we can either
> gradually move to them or if it becomes simpler to do than make a
> change in the current set up. For instance, doing (10) might be
> better at a time when we make changes to the database layer itself.
>
> Along these lines, architecturally I think we need to add: 14.
> separate the subsystems better. In my view - the base system being
> the tools (scanning, consumers, etc - with or without the database),
> then the addition of the proxy/webdav on that (possibly without the
> database), then the web application/visualisation on top of that
> (this requires the databases and all other pieces of functionality).
> We might later add web services as an option with or without the
> webapp. These different deployment options would make it much more
> flexible.
>
> Again I don't think this all needs to be done in one go - but
> designing the target architecture and moving towards it would be a
> good goal for 1.1 and beyond. Some of the above may actually be
> plugins too, so we should consider the impact of that.
>
> Would be great to update the wiki with this list split into 1.1 and
> beyond sections :)
>
>>
>>
>> Btw, what does everyone think of having the end of March as the
>> target
>> release date of 1.1?
>
> Great! We should probably aim to be feature complete a few weeks
> before that then. This probably means only picking a few of the
> above (there is a lot there!), and moving the rest to 1.2. Also need
> to pick some important issues from the JIRA pool - as well as
> cutting down the 60+ in there now :) We can keep working on critical
> stuff in the 1.0.x line.
>
> Cheers,
> Brett
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: Archiva 1.1 Roadmap
Posted by Brett Porter <br...@apache.org>.
These all sound good to me. Really enjoying the discussion :)
Some comments and additions:
On 06/02/2008, at 5:48 PM, Maria Odea Ching wrote:
> From the thread so far, these are the things to choose from for the
> 1.1roadmap:
>
> 1. Reduce memory consumption
> 2. Preemptive artifact synchronisation
> 3. Eliminate client side blocking when artifacts are being
> downloaded from
> remote repositories.
> 4. Ability to take repositories (both managed and remote) offline
> 5. Communication with remote repositories should be done
> asynchronously
> 6. Web UI for deploying artifacts
> 7. Plugin subsystem. We already have this for consumers but we
> really should
> have features like search, dependency graphing and browsing as
> plugins so we
> can turn bad behaving features and also give a way for users to
> create their
> own functionality.
> 8. Separation between managed repositories used for publishing and
> those
> used for caching artifacts from remote repositories. This separation
> would
> allow us to have:
> * Provide indexing, browsing and search only for "publishing"
> * RSS feeds for new artifacts in published repositories.
I think this is something that is configurable, and set nicely by
default. I don't think we should completely separate proxy cache
managed repos from deployed repos, but having a default configuration
that does and recommending it is the way to go.
>
> 9. Review synchronization of the configuration object
> 10. Improve the tests where databases are being set-up (use mock
> objects
> instead)
> 11. Statistical reports
> 12. Repository grouping
>
> Any more suggestions or comments for this? :)
I'd just add "13. architectural simplification" - we talked about some
technology changes and while I don't think we need to rush into any,
it would be worth having them in mind if we can either gradually move
to them or if it becomes simpler to do than make a change in the
current set up. For instance, doing (10) might be better at a time
when we make changes to the database layer itself.
Along these lines, architecturally I think we need to add: 14.
separate the subsystems better. In my view - the base system being the
tools (scanning, consumers, etc - with or without the database), then
the addition of the proxy/webdav on that (possibly without the
database), then the web application/visualisation on top of that (this
requires the databases and all other pieces of functionality). We
might later add web services as an option with or without the webapp.
These different deployment options would make it much more flexible.
Again I don't think this all needs to be done in one go - but
designing the target architecture and moving towards it would be a
good goal for 1.1 and beyond. Some of the above may actually be
plugins too, so we should consider the impact of that.
Would be great to update the wiki with this list split into 1.1 and
beyond sections :)
>
>
> Btw, what does everyone think of having the end of March as the target
> release date of 1.1?
Great! We should probably aim to be feature complete a few weeks
before that then. This probably means only picking a few of the above
(there is a lot there!), and moving the rest to 1.2. Also need to pick
some important issues from the JIRA pool - as well as cutting down the
60+ in there now :) We can keep working on critical stuff in the 1.0.x
line.
Cheers,
Brett
Re: Archiva 1.1 Roadmap
Posted by Maria Odea Ching <oc...@apache.org>.
>From the thread so far, these are the things to choose from for the 1.1roadmap:
1. Reduce memory consumption
2. Preemptive artifact synchronisation
3. Eliminate client side blocking when artifacts are being downloaded from
remote repositories.
4. Ability to take repositories (both managed and remote) offline
5. Communication with remote repositories should be done asynchronously
6. Web UI for deploying artifacts
7. Plugin subsystem. We already have this for consumers but we really should
have features like search, dependency graphing and browsing as plugins so we
can turn bad behaving features and also give a way for users to create their
own functionality.
8. Separation between managed repositories used for publishing and those
used for caching artifacts from remote repositories. This separation would
allow us to have:
* Provide indexing, browsing and search only for "publishing"
* RSS feeds for new artifacts in published repositories.
9. Review synchronization of the configuration object
10. Improve the tests where databases are being set-up (use mock objects
instead)
11. Statistical reports
12. Repository grouping
Any more suggestions or comments for this? :)
Btw, what does everyone think of having the end of March as the target
release date of 1.1?
Thanks,
Deng
On Feb 4, 2008 2:06 PM, James William Dumay <ja...@atlassian.com> wrote:
> Hey guys,
> Just wanted to help kick off our way to a 1.1 release
>
> Here have been a few things that have been at the back of my mind. I
> think this is a list we should pick and choose from:
>
> * Reduce memory consumption
> * Preemptive artifact synchronisation
> * Eliminate client side blocking when artifacts are being downloaded
> from remote repositories.
> * Ability to take repositories (both managed and remote) offline (See
> MRM-541)
> * Communication with remote repositories should be done asynchronously
> * Web UI for deploying artifacts
> * Plugin subsystem. We already have this for consumers but we really
> should have features like search, dependency graphing and browsing as
> plugins so we can turn bad behaving features and also give a way for
> users to create their own functionality.
>
> 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.
>
> 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
>
>