> This way, your package could go to main, which is a very good thing. > Another approach would be to build the package with some jdk's (1.4 and > 1.5 are enough) and add jdk14 and jdk15 to the binary name. > > Maybe you can have a look at libpg-java I think it builds several jars > for different jdk's.
Okay, so I tracked down some minor errors in the build scripts of the
source release, and got everything built for the 1.4 JDK using only free
tools. Now I need to figure out the right way to distribute these
packages. At the very least, there will be the following:
libbcprov-java
libbcmail-java
libbcpg-java
The problem with this is that different jars are needed for each
supported JDK (even if I build them all with free tools). Being
consistent with the Bouncy Castle distribution would result in:
libbcprov-jdk14-java
libbcmail-jdk14-java
libbcpg-jdk14-java
And so on for each JDK for which a package was created. You seem to
suggest above creating a single package with different jars for each
JDK, though it is not obvious to me how this would work, as classpaths
would need to be updated accross upgrades (and I didn't find different
jars for different JDKs in libpg-java; are there any other places I
could look for an example of this?). It is unclear to me which of these
two packaging choices would be preferable.
At the same time, it seems that it may be sufficient to simply package
using the JDK version that is currently supported by free-java-sdk.
Any suggestions?
Charles
--
The band
For which
The grand stand roots
Is not made up
Substi-toots!
Burma-Shave
http://burma-shave.org/jingles/1951/the_band
signature.asc
Description: Digital signature
