Comments inline:
Ola Lundqvist wrote:
> Hi
>
> I have followed the java instalation issues thread. So I'l try
> to summarize and give some new proposals.
>
> Java libraries:
> * Java libraries should go to /usr/share/java if they are
> jar files and /usr/share/java/repository if they are a collection
> of classes.
> * Usage of jar files should be encouraged because they can
> be versioned.
> * The jar file should be named name-version.jar and defaults
> should be a symbolic link with the name name.jar
> Quite the same way as C-libraries.
Naming the jars with a package name convention would reduce name
clashes. For example there may be several XML parsers with a parser.jar
These should be named:
com.sun.parser.jar
org.apache.parser.jar
etc.
For my own stuff I specify the package name to the first branch in the
package nameing.
This convention will also encourage common classes to NOT be included
in many jar files (eg javax.servlet.* or org.sax.* etc.).
I don't think this naming policy should be policed, only encouraged.
> * Here is a proposal. API dependencies should be specified in
> a way so that it should be easy to set the classpath. I can
> create the bash script and place it in java-common if you like.
>
> Perhaps /usr/share/java/foo-ver.apidep just lists what
> jars it depends on. And then a script generates the classpath
> for the developer to use. Personally I would like to have this
> when building my java packages.
It should also indicate JVM dependancies eg ">1.2.2 & !ibm1.3.2"
It would be good to have a common shell script include that would
build classpaths and check JVM dependancies that could be included
in start scripts.
> Build:
> Is it possible to create a script that generates this automaticly?
> Like a dh_javadeps... It should also generate the dependencies
> in the control file...
>
> Jvm:
> * .so files should be placed in /usr/lib
> * We should find a way to make it possible to use switch between
> java virtual machines without having to reset the classpath or similar.
> But maybe this simply is too early.
> * Maybe putting jvm implementation jars in /usr/share/java/$impl
> is the solution. Packages that proviedes similar functionality
> should then have the same name. like tools.jar could point
> to classes.zip (in jdk1.1).
> * Or maybe each jvm should have its own dependency file that the
> dependency script could use.
>
> Java programs:
> * Should as before have a exec that fixes all issues. This will
> be easier if a dependency script is created (see above).
>
> Have I missed something?
>
> Regards,
>
> // Ola
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
