[doap-interest] Project Dependencies

[Mike Stanley]

hello DOAP Team...

I'm new to the list (and I have to admit, I haven't looked at the
archives, so i apologize in advance if I repeat anything).

I'm a developer.  Right tool for the right job.  period.  I develop with
a wide range of technologies.  (primarily J2EE).  Anyone who spends as
much time in this space as I do, knows, inter-project dependency
management sucks.  JAR's, Classloaders, Manifest, etc.  is the worst. 
(This however, is a trend across many technologies, so Java is the only
applicable domain).  

I come from some background with the Maven project 
http://maven.apache.org  I'm not sure if you are familiar with the
project, but in short, it is a build tool which utilizes a project
object model, and common collection of build goals.  The Project
Descriptor is very similar to the DOAP schema. 
http://maven.apache.org/reference/project-descriptor.html

The DOAP schema however, is IMO, a much better approach.  The Maven
project descriptor was/is an attempt to describe all the details of a
project to free the developer from build/documentation hassles.  A novel
idea, and a decent first-cut at it.  I believe the goals of DOAP -
define a vocabulary for open source projects.  I believe with these rich
semantics great tools will come, such as a build tools, documentation,
inter-linked network of developers (brain-trust), and so forth.  Maven
has it backwards.  

And I also am a true believer in the power of semantics.  Building off
RDF, OWL, DC, FOAF, and RSS will create opportunities not even
imaginable yet.  Bottom Line -  DOAP is Dope! ;-)

Ok - nothing is complete without an immediate problem and some low
hanging fruit (where the sky is the vision).  As my subject line stated
--  for me I need to manage my project dependencies.  Again, the maven
project took a stab at this, with their repository
http://www.ibiblio.org/maven/  I hate this approach, but at least it's a
functional start.  And of course another reference of a dependency
repository is the .NET Global Assembly Cache.  

I would like to try and define an RDF vocabulary for describing (1) a
project's dependencies and (2) a repositories resources.  -- Most likely
these will be the same or built off each other.  This makes sense as a
sub-type in the DOAP schema.

I've been thinking about this for a long time.  (in fact about 1 1/2
years ago I brought up a conversation about a decentralized repository
to the Maven repository.   The thread can be seen here -   
http://www.mail-archive.com/turbine-maven-dev@jakarta.apache.org/msg08340.html

Since then I changed jobs, moved, and been engulfed with a lot of time
consuming projects, so that conversation didn't lead anywhere....

Until now that is.  Missing in my original thoughts was a semantic
vocabulary.  Maven's Project Object Model doesn't cut it.  DOAP,
however, does.

I'd like to get a proof of concept together utilizing the foundation of
DOAP.  I'd like to keep it as simple as possible at first so that I can
actually accomplish something other than a winded email.  

I've looked closely at .NET Assemblies and the GAC, the maven project
descriptor, and JAR Manifest files.  Since my primary concern right now
is JAR management.  I also want to take something away from CPAN, RPM,
and other package management solutions.  (I would definitely need some
support though in those areas).  I'm focusing on a POC for Java, but I'd
still like the vocabulary to be applicable to other languages.    

Any interest in something like this becoming part of DOAP?  Has there
been any work or any thoughts in this area?   

Some Inspirational References:
- http://maven.apache.org/reference/project-descriptor.html#dependency
- http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#JAR%20Manifest
- http://www.perl.com/CPAN/
- http://www.codeproject.com/dotnet/demystifygac.asp
- http://www.rpm.org/RPM-HOWTO/build.html
- http://www.python.org/pypi

Here is my thoughts on an initial list -
- unique name for the resource/package
- group name space (organization URI)
- version number (<major>.<minor>.<increment>.<build>)
- version quality (pre-alpha | alpha | beta | rc X | final)
- description
- culture
- package check sum
- package contents
   - name
   - checksum
   - description
- dependencies



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.usefulinc.com/pipermail/doap-interest/attachments/20040928/a318f3b6/attachment.html