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]
