Dependency system specification
-------------------------------
- Libraries publish "library descriptor file" which is a simple XML file
describing the library's dependencies, latest release information and
where supported releases can be downloaded:
samskivert
2000-2002, Michael Bayne
mdb@samskivert.com
http://www.waywardgeeks.org/code/samskivert/
samskivert.ldf
1.1
2001-12-03
releases/samskivert-1.1.jar
1.01
2001-08-13
releases/samskivert-1.01.jar
This would be made available at:
http://www.waywardgeeks.org/code/samskivert/samskivert.ldf
Some sort of version information should be inserted into the JAR file so
that the downloader doesn't have to maintain a cached copy of the LDF
file it used to retrieve the JAR file. Perhaps an additional file
included in the jar:
META-INF/RELEASE.LDF:
samskivert
2000-2002, Michael Bayne
http://www.waywardgeeks.org/code/samskivert/
samskivert.ldf
1.1
2001-12-03
releases/samskivert-1.1.jar
This would be automatically generated by the depends system and inserted
into the jar file during the build process.
Perhaps it is desirable to support the publishing of multiple libraries
in a single LDF file?
- Projects reference dependencies via an ANT front-end or by other means
(eg. Maven). Perhaps using an external file:
depends.xml:
build.xml:
Or perhaps the dependencies should be specified directly in ant's build
file (which would probably involve more sophisticated extension of ant
than just implementing a task). This latter approach would make it more
difficult for external tools to inspect a project's dependencies, but
fewer files is also good.
- A developer could override the standard library location and specify a
dependency to a local build:
-->
url="file:/home/mdb/projects/samskivert/target/samskivert.ldf"/>
Because the build system would tag a library with a "release" date of
the current date at the time of the build, it would pick up the local
build so long as it was built more recently than any public build that
might be referenced in the dependency hierarchy.
- KISS: place as little information as is necessary in the library
descriptor files so as to minimize the possibility of that information
becoming out of date.
- Facilitate build stability: don't automatically check for or download
new libraries; provide an explicit mechanism for checking for updates
(separate build directive), a means for specifying "use the latest
version" and one for specifying "use a specific version".
- Facilitate the bleeding edge: a project should be able to include
libraries from the web site where the most recent stable release is
published, or build from CVS and reference their local build directly.
- Facilitate forward progress: report when a project depends on a version
of a library that is no longer supported (meaning it is no longer listed
in the library's descriptor).
- Facilitate dependency generation: check project's generated classfiles
for references to classes not enumerated in dependencies hierarchy;
report findings.
- Facilitate obsolete dependency removal: report dependencies that are not
referenced by any class in the project.