Re: Re: Merging repository discussions
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
Re: Maven Repository @ Apache
Joshua Slive wrote: maven.repo.remote = [preferred]/avalon,http://www.ibiblio.org/maven Sorry, I'm not on [EMAIL PROTECTED] (Do we have any mirror maintainers on that list?) But I don't believe this is a particularly smart thing to do. hmm. Good point. I've disabled this feature for now. A shame though :D cheers, - Leo PS: note this was not something discussed on [EMAIL PROTECTED] just seemed a good idea at the time :D
RE: Proposals
On Fri, 7 Nov 2003 [EMAIL PROTECTED] wrote: not as much bandwidth... So lets design this a bit better then = make sure that it allows for the authoritative source to be on ASF[*] hardware (perhaps with an ASF signed key, sha1 or md5) - but it can be mirrored out through ibiblio, my local disk, or wherever - without compromsing trust, oversight, etc. If that means we need to maintain a 'master' list of checksums or something else signed on trusted hardware - that can be arranged. Either as a web page or through some clever DNS/urn naptr mechanism. But there is no reason not to decouple the trust/authoritative chain and/or metadata from the actual bulk payload. Dw *: or whoever else is authoritative on the package.
Re: Proposals
I concur, it is just shifting the the problem. Is xerces in XML or Web Services or Text Processing or Library or Core or Utility or Base or Transormation or . :-) You ask me, then I would say XML-Parser. I unerstand it is hard to group them into one, but every project focuses on one thing, if it falls under the already existing one, put it under that, if not create something specific. I will probably agree with the same old URI, but I just want to look at it from a user point of view ( Use case - isn't this user focussed :-) With repositories growing fast, it needs to be searched and there should be a keyword search that assists faster search ( speaking from the established UDDI Repository and Database point of view ). With no responses supporting this idea, I guess I will put this idea to rest in peace ;-) regards, -Anou _ Concerned that messages may bounce because your Hotmail account is over limit? Get Hotmail Extra Storage! http://join.msn.com/?PAGE=features/es
Re: Proposals
Anou Manavalan wrote: With repositories growing fast, it needs to be searched and there should be a keyword search that assists faster search ( speaking from the established UDDI Repository and Database point of view ). With no responses supporting this idea, I guess I will put this idea to rest in peace ;-) Added a may / second phase goal. We will need evenetually some metadata and metadata serach facilities. But later after the base URI is agreed upon. regards, -Anou _ Concerned that messages may bounce because your Hotmail account is over limit? Get Hotmail Extra Storage! http://join.msn.com/?PAGE=features/es smime.p7s Description: S/MIME Cryptographic Signature
Re: Proposals
Stephen McConnell wrote: Anou Manavalan wrote: With no responses supporting this idea, I guess I will put this idea to rest in peace ;-) Searching is certainly on the my agenda. We need it for IDE related development, repository management, and intelligent query based artifact aquisition (and HTTP in this context is not an ideal solution). HTTP is fine for searches http://repo.apahce.org/search/?keyword=cool Or something. returns some XML format or another. But first the simple URL then the search interfaces. smime.p7s Description: S/MIME Cryptographic Signature
