Eric Bruneton wrote:
I think so. I'm trying to update the ASM project to take these guidelines into account (I attach the corresponding source package). I think it follows items 1, 2, 3 (see build.properties), 4, 5, 6 (see build.properties again), 7, 8, 9, 10, 11, 14, 16 & 17. Tell me if something is still wrong.
Next time, giving a URL to the source code might be better ;) I'm going to mix comments concerning the page itself and ASM. Can we clarify #6?``Make specifying the build classpath easy using either command line switches of property files (and document it).''
currently we use `export CLASSPATH', how does this fit in? Note that a build.xml using only properties cannot easily be used with our
`build-classpath' script. For #8:We should add that all jars should have a manifest (but without Class-Path). Ant can autogenerate a manifest, or does, I forget?
For #9:I'm not sure how this applies to most developers, or even developers of tomcat for example, as they aren't going to have `ant install' use this layout
For #12:Just what exactly is `clear versioning'. Here's how I see it (please comment):
Unix versioning is usually name (lowercase), followed by '-', followed by a numeric version, e.g. x.y or x.y.z. Letters in version numbers are not recommended.
The source code should be in a directory, not top-level like most zip files (I can't stress this enough---I don't know how many times I unzipped a pile of source code to my home directory).
The directory should have the same name as the archive, i.e. name-version. Sometimes simply `name' is used, but it's not recommended.
An ant task exists to do this for you.Sometimes, it's typical for Java developers to put *binaries* in the archive like this and append -src to the source archive. I don't recommend this. Instead, maybe append -bin to the binary archive and leave the -src archive as <name>-<version>.tar.gz.
Similarly, we might go as far as to recommened that the jars produced have versions in them.
So concerning ASM: our package name looks like: asm-1.4.1-1jpp So you might provide asm-1.4.1.tar.gz and optionally a asm-1.4.1.tar.bz2.In asm-1.4.1-bin.tar.gz you might include asm-1.4.1.jar and whatever dependencies I guess. It may be a good idea to provide one with and one without dependencies, but I don't have strong feelings either way.
For #13. Provide a cryptographically (GPG) signed hash of your archivesI realize this is a pain. I probably wouldn't even want to do it. But it's crucial in a `secure' environment that the integrity of the archives can be verified. The md5 sum can tell me if the archive was damaged or not. It cannot tell me if it's authentic. That's why md5+gpg is recommeneded.
For #16:Concerning ASM: Here you have a README file that seems to have come from another package. Neither of the 4 directories reference exist, just a perf directory, and it's not referenced. Note that if these aren't unit tests, I don't think that the packager should run them. Maybe we should add something to that effect? Of course, including any kind of tests you want is perfectly fine---I just want to clarify when they are part of the build process.
-- Sincerely, David Walluck <david@anti-microsoft.org>
Attachment:
signature.asc
Description: OpenPGP digital signature