archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deng Ching <>
Subject Re: work left to do on MRM-1025 branch
Date Tue, 16 Feb 2010 16:28:15 GMT
On Tue, Feb 16, 2010 at 10:08 PM, Brett Porter <> wrote:

> Hi,
> 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
> predictable.


> 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.

In the Configuration section in , it
was mentioned that the config should be shadowed to a file in the file
system. Is this a one-to-one relationship (e.g. one repository == one config

> 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.

In trunk now and in the previous releases, new artifacts are detected based
on its modified date and the last repo scan.. I assume it's still the same?

> * 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.

..and also upgrading from the lower versions :)

> * 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?
> Thanks,
> Brett
> --
> Brett Porter
I haven't finished reviewing everything and I'm pretty tired (brain isn't
working properly now) so I'll just continue looking over this tomorrow :)

Thanks for all the efforts in this Brett!


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message