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/ > >
