Re: Archiva 1.1 Roadmap
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 a
Re: Archiva 1.1 Roadmap
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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Archiva 1.1 Roadmap
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 [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Archiva 1.1 Roadmap
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
>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 <[EMAIL PROTECTED]> 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 > >
Re: Archiva 1.1 Roadmap
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 , 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 <[EMAIL PROTECTED]>:
>
> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
> > >
> > > 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 <[EMAIL PROTECTED]> 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
> > 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 <[EMAIL PROTECTED]>:
> > > > >
> > > > > 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" repo
Re: Archiva 1.1 Roadmap
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
> >
> > 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 <[EMAIL PROTECTED]> 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
> 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 <[EMAIL PROTECTED]>:
> > > >
> > > > 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 <[EMAIL PROTECTED]> 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
> > > > >
Re: Archiva 1.1 Roadmap
Yes, agreed. +1 for this functionnality, which could, IMO, be implemented rapidely. Fabrice On Feb 5, 2008 8:40 AM, Maria Odea Ching <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 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 <[EMAIL PROTECTED]>: > > > > > > 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 <[EMAIL PROTECTED]> 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. > > > > > > > >
Re: Archiva 1.1 Roadmap
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 <[EMAIL PROTECTED]> 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 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 <[EMAIL PROTECTED]>: > > > > 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 <[EMAIL PROTECTED]> 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 > > > > >
Re: Archiva 1.1 Roadmap
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 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 <[EMAIL PROTECTED]>: > > 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 <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> 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
