Mailing-List: contact dev-help@archiva.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@archiva.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <C647F4E6-F036-4669-BE8A-90126E8623A6@apache.org>
From: Brett Porter <brett@apache.org>
To: dev@archiva.apache.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v926)
Subject: Target architecture
Date: Thu, 14 Aug 2008 17:41:56 +1000

Hi,

It's come up a couple of times about what the architecture of Archiva  
should be like, as there are a couple of things that we're not happy  
with. I thought it'd be good to try and agree on what the "end point"  
might be so that anyone wanting to move in that direction is free to  
do so.

I took a stab at this here: http://people.apache.org/~brett/archiva-target-architecture.png

The key points:
* moving the database, etc, out of the "base" application (so this  
would be dependent on being able to operate based on the metadata/ 
repository API alone, which was the basis for the other thread)
* moving towards a plugin architecture for as much as possible (so  
while we might have 2 or 3 standard distributions, it should be  
possible to easily assembly just the functionality you want)
* clearly defined extension points (today, this is really just  
consumers). Note this is for the Archiva system itself, obviously  
there are similar points for the security, for example

I haven't really dealt with the plugin aspect of the webapp/web  
services where you might expose that in some pluggable fashion, nor  
considered using a particular plugin architecture - we've got some way  
to go in isolating the existing components before taking that step.

Did I miss any important pieces?

Other thoughts, questions, violent reactions? :)

Cheers,
Brett

--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/