> > * The relational viewpoint concerns information about artefacts such as
> > dependencies - and here we start see language specifics. For example
> > a jar
> > file with structural dependencies. This leads to the necessity to
> > a artefact descriptors. One example is the Maven POM - but its not
> > example at this level of abstract because its a descriptor of build
> > and test
> > time dependencies (amongst other things).
> The POM is not an artifact descriptor at all. The work done by Michal is
> more akin to what you speak of where types of artifacts themselves are
> described and controlled by handlers associated with the type. This idea
> has been thoroughly discussed in Maven-land.
The POM does contain information regarding describing the artifacts
generated by a project. The dependencies are what I think are being
referred to here by Steve. Or perhaps the fact that some of the info is
There but its not the sole purpose for the POM.
> > * The application viewpoint is where a repository really shines. For
> > example
> > the Maven project uses a repository as the source of build-time
> > The Avalon team are using the repository as a source of artefacts for
> > things
> > like dynamic classloader hierarchy creation, automated bootstrapping
> > components, coordinated management of apis, spis and implementations.
> > this level what is largely missing in the underlying repository
> service is
> > a flexible meta-model and an efficient protocol.
> As far as building applications, I have been doing this for well over a
> year with Plexus and its runtime builder. The Loom and Pico folks are
> also doing similiar things so we have a wealth of information and
> experience to gain from those folks too. Michal has been working on
> Wagon and has had many discussions with Peter Donald who has some
> fantastic ideas vis-a-vis repositories and application production and
> application runtime.
This is all the more reason to go to incubation with this. We want all
the players to be part of a discussion ( referring to Nicola's email ).
> > In order to address these limitations we are currently extending our
> > existing
> > repository model to support bootstrapping of alternative back-end
> > strategies and protocols - with LDAP as the primary candidate (based on
> > collaboration with the Apache Directory Project team).
> Again, as I've mentioned before information as a decoration is certainly
> valuable. LDAP is certainly one possibility, object stores using
> something like OJB and Prevayler are also things I've personally
> experimented with.
Yes decorations are good. But LDAP or any database functionality
should be a central facility offered by the repository. Why not
put POM deployment data into the repository this way? It can be
queried and projects can be cross referenced and made relational.
Leave it up to the user to determine project specific attributes
that can be added. Use a decorator pattern to enable this feature
but it should be added. Whether used or not is an application
specific decision but something tells me it will be used extensively.
Let's face it the maven repo at ibiblio is a directory of artifacts
and all you're missing is a hierarchical database to associate these
artifacts with attributes. I don't care (maybe a little) if you
use webdav or LDAP to do that but the value proposition is huge
when it comes to facilitating development life-cycle models. The
implications to the field of SCM alone are huge.
Directories and the repository notion fit extremely well together.
Think about the hierarchy and dependency synergy. Think about how
the repository is used: read frequently written to very infrequently.
LDAP is also a very fast line protocol to front end a hierarchical
attribute database. The power of referrals also makes it a very
attractive proposition to create cross references between projects
tying several distributed repositories together into a directory
system. Also consider the replication capability needed for
high availability (did not mean for that to rhyme). LDAP is great
for replicating (mirroring) these attributes. No other access model
gives you such a bang in one tight package.
As I said before Maven took an incredible leap with the innovation of
the repository used for the build process. The concept here is massive
and bigger than all of us. We need to bring everything together to
take it even further and be open to all the possibilities. That's
why perhaps Nicola's attempts to make it an incubator project are
> But really I think the notion of a repository is really not that complex
> and I will work this weekend in order to submit a proposal based on the
> valuable experience I've gained from Maven usesr and some of the ideas
> we've come up while developing Wagon (which will be showing up in a
> repository near you asap).
You know I'm still confused about what Wagon is.
> > There is also
> > some initial work going on with respect to a repository plugin for
> > that is aiming at drag-and-drop component assembly relative to
> > content.
I drool thinking about this every night!