archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject work left to do on MRM-1025 branch
Date Tue, 16 Feb 2010 14:08:54 GMT

It's been a long time in the works, but this branch is now at the point that it is stable
enough that I'd like to merge it to trunk before it further diverges from the current trunk
(I'll start a separate vote thread given the size). It is big enough already and I'd like
to avoid a 'code bomb' that nobody can understand without re-learning the whole codebase.

I believe with some work we can incorporate it into 1.4. The main goal has been completed,
and then some - not just making the database optional, but removing it and JPOX altogether
without loss of functionality (at least for Archiva itself - the users database is unchanged).
In addition, I have started to move towards the target architecture we talked about, splitting
some functionality out (maven2 specifics support, metadata storage providers) into plugins,
and introducing the metadata model and repository API that can be used to tie everything together.
All going well, things should look much the same as they did, but quite a bit faster and more

The documentation to review is here: (just 5 pages
for now). We can continue the other thread to decide if this should be in SVN or the wiki.

As I said, there is still work to do, which I'll list briefly. If we go ahead, I will push
these into JIRA.

* The biggest thing to look at is metadata-repository-file. I threw this together with property
files quickly and there's no optimisation or even exception handling. We need to look at the
right way to approach this - a more robust implementation of a file system store (properties
or xml) is definitely workable, but would need to be combined with something like a Lucene
index (as in Archiva 0.9) to make some of the operations fast enough. What I would like to
look at instead is using JCR (with file system persistence - not a database!) to see how well
it reacts to a lot of operations. As you can tell from the docs, the storage is tailored to
living in a hierarchical content repository in whatever form that takes, and the storage is
isolated behind an API.

* Along those lines, the content model needs some revision, as there are still Maven specifics
baked in to some areas.

* I didn't spend a lot of time on Javadoc because the APIs were changing. I'd like to go back
and ensure that it is extremely high quality on the new code. There are some more things that
can be done to refine the API as well once a couple more systems are using it and we have
the metadata storage finalised.

* Deletion detection in scanning is still missing, though it would now be quite easy to add
back, I didn't get around to it.

* There are a number of other "TODO" markers in the code still - as I was focusing on making
the important bits work, I left some to come back to. It's not missing things, but small improvements
we should either make or decide not to do after all.

* While it should be very straightforward, we need to test some scenarios of upgrading from
Archiva 1.3.

* Finally, we need to go through JIRA and close out all the database related issues and re-test
things that this may have corrected. I managed to fix several bugs in the process already.

Beyond a 1.4 release, the types of things we might do with it are:
- refactoring to remove repository-layer and archiva-model. While the new design is similar
in intent, there is significantly less coupling from what grew over time, less reliance on
scanning, and the model is meant to be extensible. They co-operate just fine right now, but
it would benefit us to move it over quickly so that the code is more approachable.
- In particular, moving the proxy module and webdav modules (including groups) over to the
API will help ensure it is mature enough for such use cases.
- Changing redback to have a simple, non-database storage as well (which is all 90% of users
will need)

Any comments or questions on the above?


Brett Porter

View raw message