Mailing-List: contact archiva-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: archiva-dev@maven.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-Id: <7544D436-E27F-4F9F-B2DB-22AC74C02EDD@apache.org>
From: Brett Porter <brett@apache.org>
To: archiva-dev@maven.apache.org
In-Reply-To: <32472CC9-DAA7-4CCA-94E5-238AA1A49DE1@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: Archiva 1.1 Roadmap
Date: Thu, 7 Feb 2008 22:08:42 +1100
References: <1202105219.28501.40.camel@heck>
 <1a57a2980802052248o2c231c18y51c4e320069efdad@mail.gmail.com>
 <32472CC9-DAA7-4CCA-94E5-238AA1A49DE1@apache.org>

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
brett@apache.org
http://blogs.exist.com/bporter/