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/