<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.0.10">
</HEAD>
<BODY>
hello DOAP Team...<BR>
<BR>
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).<BR>
<BR>
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). <BR>
<BR>
I come from some background with the Maven project <A HREF="http://maven.apache.org">http://maven.apache.org</A> 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. <A HREF="http://maven.apache.org/reference/project-descriptor.html">http://maven.apache.org/reference/project-descriptor.html</A><BR>
<BR>
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. <BR>
<BR>
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! ;-)<BR>
<BR>
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 <A HREF="http://www.ibiblio.org/maven/">http://www.ibiblio.org/maven/</A> 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. <BR>
<BR>
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.<BR>
<BR>
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 - <BR>
<A HREF="http://www.mail-archive.com/turbine-maven-dev@jakarta.apache.org/msg08340.html">http://www.mail-archive.com/turbine-maven-dev@jakarta.apache.org/msg08340.html</A><BR>
<BR>
Since then I changed jobs, moved, and been engulfed with a lot of time consuming projects, so that conversation didn't lead anywhere....<BR>
<BR>
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.<BR>
<BR>
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. <BR>
<BR>
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. <BR>
<BR>
Any interest in something like this becoming part of DOAP? Has there been any work or any thoughts in this area? <BR>
<BR>
Some Inspirational References:<BR>
- <A HREF="http://maven.apache.org/reference/project-descriptor.html#dependency">http://maven.apache.org/reference/project-descriptor.html#dependency</A><BR>
- <A HREF="http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#JAR%20Manifest">http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#JAR%20Manifest</A><BR>
- <A HREF="http://www.perl.com/CPAN/">http://www.perl.com/CPAN/</A><BR>
- <A HREF="http://www.codeproject.com/dotnet/demystifygac.asp">http://www.codeproject.com/dotnet/demystifygac.asp</A><BR>
- <A HREF="http://www.rpm.org/RPM-HOWTO/build.html">http://www.rpm.org/RPM-HOWTO/build.html</A><BR>
- <A HREF="http://www.python.org/pypi">http://www.python.org/pypi</A><BR>
<BR>
Here is my thoughts on an initial list -<BR>
- unique name for the resource/package<BR>
- group name space (organization URI)<BR>
- version number (<major>.<minor>.<increment>.<build>)<BR>
- version quality (pre-alpha | alpha | beta | rc X | final)<BR>
- description<BR>
- culture<BR>
- package check sum<BR>
- package contents<BR>
- name<BR>
- checksum<BR>
- description<BR>
- dependencies<BR>
<BR>
<BR>
<A HREF="http://www.cauldronsolutions.com"><FONT COLOR="#808080" SIZE="1"></FONT></A><BR>
</BODY>
</HTML>