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
