> I have been out of commission for the better part of this year but > Plexus was slated to integrate Maven's repositories directly. Of late > I've been discussing this with the Loom folk and ~10 people who have > access to the Plexus-based version of Maven.
Yes, I remember checking out maven-new from the maven cvs repository. If you remember, you told me of its eventual move to Codehaus. So it's new home is there I take it? Is there a way I can take a look at it? Also I'm not thinking of the repository as only part of a component container or just a Maven thing. I'm concerned with creating a single free repository. All the folks out there across projects can use it including Loom and Plexus at Codehaus. It should not matter what project uses it. The key is to make it a standard and not have a dozen implementations out there causing incompatibilities. > One of the the first tools to be released is something called Wagon > which Michal has been refactoring since the first versions of the > artifact handling mechanisms were checked into the maven-new repository. > It's Michal's baby and I will definitely encourage him to join this > list. Wagon was at first dependent on Plexus but that has now changed to > be more PicoComponent-esque whereby it can be embedded or used in any > Java tool or application. Michal has actually endeavoured to make Wagon > work with Loom as Peter Donald will most likely get to using Wagon in > Loom before I get to using it in Plexus. So Wagon is a repository API implemented at Codehaus? <snip/> > Right, the Component Software nirvanna :-) If you haven't read Component > Software by Syperski I highly recommend it. There are also a plethora of > papers at citeseer on the topic of confederated repositories of > components so really just artifacts in essence. It's always nice to dream ;-). However outcome is not my primary goal. I just want a standard repository API for all repo aware apps to use. I also want to explore the use of directories coupled with this idea. > > > The ideas being discussed revolve around the notion of an attribute > > database to be used to centrally manage project related artifact > > attributes. This way the repository becomes a queriable artifact directory > > as well as a artifact store. > > I think as a decoration many things can be built on the notion of the Yes the decorator pattern is what I was inferring to - good catch. What about putting the POM and potentially other related app specific info extending the POM and keeping it allin a queriable centralized directory? > repository. There is certainly no reason that hinting types of artifacts > can't be introduced in order to enable the construction of large > metadata repositories for querying. Perhaps we want to get away from having properties files or XML files floating around just to mark up the repo with metadata. Even thought this can server as a make shift solution for now. We need to manage the relational info in a form that can be indexed and queried not one that requres it to be snarfed down and parsed et. cetera. Without a database solution the repo may become very difficult to manage with several metadata files as it grows. > > > Are these ideas appealing to the Maven community? > > Most certainly and is definitely in sync with the component form that > Maven will start to take in the next couple of months. That's great to hear. Is this maven-new you are referring to? Is maven-new going to come back to Apache? I took your advice and chilled out rather than trying to componentize maven. I'm glad to see you've gotten so far with it. Thanks, Alex
