Hallo David,
* David Walluck wrote:
>``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.
I think it means that you should NOT use hardcoded path, but expose
such path to the buildscripts options.
So instead of writing
<javac ... classpath="c:\xerces.jar;..." .../>
write
<property name="xerces.jar" value="c:\xerces.jar"/>
[...]
<javac ... classpath="${xerces.jar};..." ... />
This way you can overwrite the xerces location without patching the
build file.
It would even be better to use a kind of ./configure to build a
properties file and pass that to ant. We could add that in the end of
our discussion, when we have agreed upon a common packaging way.
>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?
BTW: I never yet touched Manifests, what are they actually for? :)
>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
The problem is, that upstream isn't aware of it. Currently eclipse has
to make use of a lot of symlinks. Just because it assumes, that native
libraries are in a subdirectory of eclipse, which is itself located in
/usr/share...
>For #12:
>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).
signed! It also means taht it has to repackaged for debian, as debian
expects the source in a directory of its own.
>The directory should have the same name as the archive, i.e.
>name-version. Sometimes simply `name' is used, but it's not recommended.
signed. Also expected by dpkg.
>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.
Signed! Actually they shouldn't be any differnt than the normal
upstream source tarballs provided by any other language.
>Similarly, we might go as far as to recommened that the jars produced
>have versions in them.
IMO, they should go with the same strategy as the normal libaries:
Changing names only when a API changed.
So if 1.5 is API compatible to 1.4, the the jar should still be
name-1.4.jar (or at least a symlink :) But if 1.5.3 breaks something,
it should get name-1.5.3.jar.
This is alos part of teh proposed debian policy. Debian will rename
the jars in this manner, if that is accepted.
>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.
signed!
Somehow I just relize, that we are putting up a list with points, but
just rewriting rules, which are in use in c or any other language
releases since ages :). I wonder if they had once the same problems :)
Jan
--
Jan Schulz [EMAIL PROTECTED]
"Wer nicht fragt, bleibt dumm."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
