3

I am a bit concerned about our current build process. It smells of 'the wrong way' and causes our clients a lot of additional downloads.

We have a regular Java project that we publish through Webstart. It uses a variety of libraries that we supply as .jar files. Our JNLP looks like this:

<resources>
    <!-- Application Resources -->
    <j2se version="1.6+" href="http://java.sun.com/products/autodl/j2se" max-heap-size="512m" java-vm-args="-Xincgc" />
    <jar href="OurApp.jar" main="true" />
    <jar href="nimrodlf-1.2.jar" main="false" />
    <jar href="jackson-core-asl-1.9.10.jar" main="false" />
    <jar href="jackson-jaxrs-1.9.10.jar" main="false" />
    <!-- ... -->

So far so good. Now there is a problem with using jars signed by different certificates, I guess, or maybe that's only if one is singed with a self signed certificate. Either way, the solution found was that all jars have to be signed by the same certificate.

Subsequently, we copy all our jars, our own as well as the libraries, into the Webstart folder and sign them like so with Ant:

<target name="sign_jar" depends="check_publish">
    <signjar keystore="ourapp.keystore" alias="jenkins" storepass="private" verbose="true">
        <path>
            <fileset dir="${publish.folder}/" includes="**/*.jar" />
        </path>
    </signjar>
</target>

This all works fine, although it takes a long time signing every jar. But it also causes every client to redownload every library jar every time we publish a change to our own application jar (which is a lot). The libraries don't technically change, but the resigning makes them appear new.

Are we doing this right ? Is there a better way ? Can we somehow change our build process to make it so people can cache the library jars ?

4

1 回答 1

2

见signjar任务-lazy属性..

标志来控制签名文件的存在是否意味着 JAR 已签名。这仅在目标 JAR 与源 JAR 匹配时使用

于 2013-02-23T03:23:53.467 回答