Jason, > 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 specific path. 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 > itself. 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. Alex
