The list below sound good. For the security framework, I'm most
interest in just simplifying what we have, and making it easily able
to plugin into different solutions. We don't really want to lose the
ability to keep the current user management, etc.
For me, I would still like to look at:
- reduce the impact of the database
- reduce the number of dependencies we use
- ability to deploy parts of the application separately.
The reasoning for this is memory usage. While Archiva doesn't allocate
a lot of memory itself, you'll find that there's a large initial
overhead in classloading, and the operation of derby.
Cheers,
Brett
On 16/07/2008, at 11:53 AM, James William Dumay wrote:
Hey guys,
With 1.1 almost out the door I'm already thinking about what we may
want
to-do for 1.2.
The last release cycle was pretty long - but we introduced a lot of
features and improvements (bugs, too, I'm sure.. :P ) but I think the
general consensus is that we want to shorten our release cycle.
I'm proposing that we choose a small amount of feature/improvement
issues for 1.2 and bump the rest to 1.3. Id personally prefer this
to be
more of a "engine room" release focusing on parts of Archiva that are
not so user visible.
While being less glamorous, this will allow us to clean up after the
big
feature work in 1.2.
Here are a few features/improvements I would like to see in the next
release:
* MRM-749 - Support m2eclipse index format
* MRM-832 - Investigate future security framework options (Spike?
Actual
work could probably be scheduled for 1.3)
* MRM-541 - convenient way to take proxies offline
* MRM-684 - clients timeout due to archiva blocking on downloading
large
files
Anyone got anymore? :)
Thanks
James
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
