Okay. I see where you are coming from. If we are using multiple datasources - traditional pom object hierachy, RDF, Lucene index, XML stores - then we need a 1) common API (for application developers); 2) SPI (from Maven); 3) adapters (from framework developers). The SPI would need (at a minimum) to cover transaction management because in the case you outlined there may be multiple data sources used simultaneously.
In the past, I developed JCA implementations for SOAP and JXTA data-sources; and my guess is that JCA could be useful in this case as well. Shane On 8/1/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > > On 1 Aug 07, at 4:39 PM 1 Aug 07, Shane Isbell wrote: > > > 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. > > Again this is simply an API for accessing artifacts, and not just the > binary artifacts but the metadata as well. So to anything using this > API the underlying store, and query mechanism can be the > responsibility of the particular provider. > > > > > 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. > > If that's what a particular provider did sure. > > > 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 final API for artifact manipulation must also take into account > metadata. It does already but needs improvement. > > > 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. > > The API will cover both, and no direct access to things like RDF will > happen. A provider mechanism can easily provide direct access to an > underlying query mechanism as well. Much like ORM provide direct/ > native access provided the object format returned conforms to the > API. So you can use RDF and SPARQL, and I can use a Lucene database > and Lucene queries. I know of a fellow who has slurped all the POMs > into a an XML database and used XQuery. It really won't matter. What > matters is the API, then to things like the assembly plugin or > anything else that might directly use the artifact mechanism it's > really a matter of configuration of the provider. An API that doesn't > encompass the acquisition and analysis of metadata is not very > useful. I don't see any value in storing metadata with RDF and using > that directly. As a provider it can be like anything else, and the > overall API will allow for high-fidelity transitions from one format > to another so if I wanted to take file system of POMs and create a > database, or an RDF document it shouldn't matter. > > As to the above I don't RDF being an interface. I see having an API > which can certainly have REST/SOAP accessible methods but it will all > revolve around an API which encompasses notions of metadata. > > > > > 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] > >> > >> > > 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] > >
