To clarify: NMaven uses RDF for its local repository store (and has abstractions of an AssemblyResolver/ProjectDao for the API). It does not require that the remote repository contain RDF, but rather parses and stores the information from the remote pom artifact into the RDF store. There is also an RDF repository converter that takes the local repository and RDF store and converts it into the default local repository format, generating the pom files. This allows maven plugins like the assembler to still function.
Under its current form, RDF is only used locally, with the RDF<-->pom conversion occurring for remote repos. The way I see it eventually working is to be able to execute SPARQL ( http://www.w3.org/TR/rdf-sparql-query/) queries against the remote repo. This doesn't preclude any other format or interface from working. A good way to look at it is to separate out the concepts of the meta-data from the concept of binary artifacts (like jar, dll, exe). The binary artifacts can be in any repository format: it doesn't matter. The meta-data however, needs multiple interfaces (RDF, SOAP, pom files, etc). A good repository manager would need to be able to support multiple adapters for these interfaces. Regards, Shane On 8/1/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > > On 1 Aug 07, at 12:25 AM 1 Aug 07, Shane Isbell wrote: > > > I would like to see if there is any general interest from the Maven > > community in using RDF for storing and retrieving of repository > > information. > > As the only means, and not accessed via some API shielding the > underlying store then my vote will always be -1. I hope that's not > what you've done with NMaven as that would be a fatal flaw. I'm > assuming there is some API sitting on top of it. > > > I switched NMaven's resolver implementation to one using RDF and am > > happy > > with the results. This implementation allows: 1) easily extending > > meta-data, > > Which I'm always skeptical of as we potentially wind up which schisms > and I'm not sure what kind of extension you need for purely > dependency information which the resolver is concerned with. > > > in my case for attaching requirements to an artifact; 2) writing > > queries > > against the repo, as opposed to reading and manipulating the > > hierarchy of > > poms. This also results in cleaner, simpler code; > > This should be done with an API, not against a fixed datastore. Using > RDF and only RDF is not something I would ever support because I know > of two implementations of repository managers that use their own > internal format. Proximity uses one and I use Lucene indices so the > unifier will be an API. > > > 3) exporting all the > > meta-data to a single RDF/XML file, which has helped me with > > debugging and > > understanding the entire repository. A future benefit would be the > > ability > > to run distributed queries across multiple repos. > > It's sounding like you've build this on RDF which I don't think is > wise at all. For example this is not hard with any underlying store > with the right API. I don't think it would be hard for you to use an > API though. I'll never support a single storage format that isn't > accessed via an API. > > > > > One of the implications is that while the pom is still used for > > building, > > the local and remote repositories would just contain RDF/XML files: > > this > > would, of course, be a big change. I would just like to run this > > idea by the > > general group; if there is enough interest, I would be happy to do > > some > > prototype work to see how RDF would work within Maven core. You can > > look at > > one of NMaven's core classes that used RDF here: > > https://svn.apache.org/repos/asf/incubator/nmaven/trunk/components/ > > dotnet-dao/project/src/main/java/org/apache/maven/dotnet/dao/impl/ > > > > As a backing store for a rework of the artifact API sure, as the > primary means. I'd never support that myself. > > > Regards, > > Shane > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder and PMC Chair, Apache Maven > jason at sonatype dot com > ---------------------------------------------------------- > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
