"Dominique Devienne" <[EMAIL PROTECTED]> wrote ..
> > From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> > In the end the major difference is a philosophical one. What is the
> > central piece of the task, the repository or downloading of files.
> >
> > I guess I'm more on the side of the declarative approach dependencies
> > takes, but I do want those additional bells and whistles like MD5
> > checksum validations and timestamp checks if needed.
>
> I feel similarly. I prefer the declarative approach of <dependencies>,
> but would like timestamp checking for latest-like dependencies that get
> overwritten (which does need a pseudo-atomic copy-to-tmp+move scheme).
>
> Additionally, if the notion of what is a dependency could be abstracted
> a bit, it would be great. I'm not sure it's reasonable to ask for this
> now, but I'm throwing that it now so whatever design decision is made
> does not preclude it in the future. What I have in mind are zip
> dependencies containing jar+native-libs+descriptors+etc... We're in a
> mixed Java-C/C++ environment, and some dependencies are in fact C++
> libraries which export their public headers, import libs, and runtime
> .dll/.so as a zip.
the approach I have taken is to define libraries (3rd party), components
(project components), and general artifacts dependencies in a seperate ML.....
for example to define a component dependencies;
<comp:Component rdf:ID="SOME_PROJECT_COMPONENT">
<lib:depends rdf:ID="xercesj">
<version>
<query key="maturity" value="latest"/>
<query key="type" value="debug"/>
<version>
<artifact>
<query key="type" value="JAR"/>
<artifact>
</lib:depends>
<lib:depends rdf:ID="xercesj">
<version>
<query key="maturity" value="latest"/>
<query key="type" value="release"/>
<version>
<compatible>
<query key="compatible" rdf:Value="saxon"/>
</compatible>
<artifact>
<query key="type" value="JAR"/>
<artifact>
</lib:depends>
<comp:depends rdf:ID="SOME_OTHER_PROJECT_COMPONENT">
<version>
<query key="maturity" value="latest"/>
<query key="type" value="debug"/>
<version>
<artifact>
<query key="type" value="JAR"/>
<artifact>
</comp:depends>
</comp:Component>
a library dependency is as follows....
<lib:depends rdf:ID="xmlparser">
<version>
<query key="maturity" value="latest"/>
<query key="type" value="release"/>
<version>
<artifact>
<query key="type" value="JAR"/>
<artifact>
</lib:depends>
general artifacts follow the same format. Dependencies can be grouped up into
sets; e.g. dependencysets so that they can be referenced e.g. ...
<lib:dependset rdf:ID="xml_dependencies"/>
I then define all components, libraries, and artifacts using rdf:ID as link...
by structuring via query elements, it gives me an open ended definition for
defining new artifact types....like zip etc.
Currently this ML is processed with XSLT..though I am slowly migrating to RDF
processing and since I use Ant to control the entire process...might make a
task of it one day...
I have used RDF because I use the power of triples when asking questions of my
component dependencies....which I havent showed in the primative ML.
--Jim Fuller
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
