> There is absolutely nothing stopping you, with the structure of the
> current Maven repository, from keeping a directory of available
> components for use with, say, Merlin or Plexus. I believe the discussion
> of dynamic component deployment is beyond the scope of the discussion
> here. I'm definitely interested but I don't think it's a notion that
> should be baked into the notion of the repository.
> I currently keep a primitive list of components that can be used with
> Plexus and users can select them. Anything that I've needed I have been
> able to add to the repository simply as another artifact type. So in our
> case it may be a component descriptor which you may want to process in
> whatever way is necessary to make it work with your component model and
> component deployment model.
I don't think anyone is saying that the repo has to support
the needs of avalon for the sake of the runtime aspects of
component deployment. The attempt is to express the specific
application space Avalon is interested in. This as well as
countless other application will require a meta data facility
to be able to tag components with attributes.
Some of these attributes may be maven specific and for the
build process and some will be application specific. Once that
is agreed upon the Avalon folks can follow their application
The key is to agree on the common set of functionality that
will support every possible application. This means keeping
it simple and generic.
Building in the ability to query meta-data attributes on artifacts
is all that I'm personally asking. This is not over complicating
the repository concept. It's a natural progression.
> Service deploy, and Repository Aware applications are outside the scope
> of the repository. You can build whatever information stores you want
> and deploy them to the repository for use. I am ardently opposed to
> baking any of these specific notions into the repository structure
Again sorry for sounding like a broken record I don't think the trail
is about that. It's a use case justification for the need to associate
meta-data (attributes) with an artifact.
> > Can you give me a URL to the Wagon iniative?
> Not yet, but I will be able to soon. The Maven PMC members are
> discussing the finer details now.
I don't intend to inflame anyone so please don't take it in the wrong way
but the Maven PMC sounds like a closed society to me. The maven-new details
are hidden pending some PMC conclusions. The Wagon details are hidden
as well again pending PMC conclusions. There just seems to me to be an
extreme amount of caution/secrecy with regard to involving the community
which counteracts the benefits of having one in the first place.
> In summary I would say we keep the notions simple.
100% agree but don't stop the evolution of an idea because it may
seems to add more complexity.
I am convinced that
> the discussion of the repository need not delve into topics of service
> deployment or repository aware applications. This is entirely within the
> domain of the implementors of these systems and I am one them so I speak
Right these are use case examples that support the need for meta-data
Attributes in the repo.
> from some practical experience in the matter. Plexus and Merlin may both
> have their own component deployment model and repository aware
> applications and I have certainly thought of these things and I have yet
> to be hindered with what currently exists. Additionally there is no way
> you could ever standardize on these things given the existence of Pico,
> Nano, Loom, Plexus, Carbon, Merlin, Spring, SOFA, Fractal just to name a
Nothing is impossible.
> few of the existing containers and component models. There is simply no
> chance you're going to get them all to converge and you don't have to.
That's a very gloomy picture for the confused user who spends as
much time trying to find the right container. It has become a real
mess out there for the user.