Re: [Fwd: Re: [architecture] Re: JPackages and ObjectWeb]

[Jan Schulz <default@katzien.de>]

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                     jasc@gmx.net
     "Wer nicht fragt, bleibt dumm."