Anki:  currently the pack-signed target looks like this in build-impl.xmls:
    <target name="pack-signed" if="sign.bundle">
        <java classname="${javacard.packagerClass}" dir="${javacard.home}/bin" classpath="${javacard.toolClassPath}"
fork="true" failonerror="true">
            <arg value="create"/>
            <arg value="--type"/>
            <arg value="${deployment.type.arg}"/>
            <arg value="--out"/>
            <arg file="${dist.bundle}"/>
            <arg value="--packageaid"/>
            <arg value="${package.aid}"/>
            <arg value="--sign"/>
            <arg value="-K"/>
            <arg file="${keystore.resolved}"/>
            <arg value="-P"/>
            <arg value="password"/>
            <arg value="-S"/>
            <arg value="password"/>
            <arg value="-A"/>
            <arg value="ri"/>
            <arg file="${build.dir}"/>
            <arg value="--force"/>
            <sysproperty key="jc.home" value="${javacard.home}"/>
        </java>
    </target>

I need to know what should be changed to support keystore & alias passwords + keystore alias properties.

I'm also concerned that this target is not portable across runtimes that don't want signing, or don't include a packager
class that takes the exact arguments we are passing here.  Two options:

1.  platform.properties can specify "signing.unsupported" and we add that to the "if" clause (but then we assume that
all java card vendors accept the exact same arguments that we do) - for compatibility, we probably want to assume
signing is supported unless a platform specifically specifies that it doesn't.

2.  Make a separate Ant sign-jar Ant task and expect vendors to provide this, possibly with some do-nothing fallback if
the task is undefined (or implement both 1. and 2. to handle the case).

Basically, it would be bad form for us to require someone to uncheck the Sign checkbox when changing deployment
platforms to one that doesn't support/provide signing.

I am working on 2 tasks some what similar to <jc-load>, <jc-unload> etc.. tasks. 
Nothing is specified in the build file itself, everything is read from project.properties.

it will look like

<jc-pack/>

<jc-sign/>

All the command line arguments are taken from project.properties.

With these 2 separate tasks, the signing part will be portable just like other load operations.

The <pack> target needs to be modified like the following

<target name="pack" depends="do-pack,do-sign"/>

<target name="do-pack">
    <jc-pack/>
</target>
    
<target name="do-sign" if="sign.bundle">
    <jc-sign/>
</target>


The long <pack-signed> and <pack-unsigned> needs to be removed. The definitions for these tasks will be added just like 
<jc-load> tasks.

The new properties that needs to be added for signing are
sign.storepass=password
sign.passkey=password
sign.alias=ri

The <jc-sign> depends on these new properties and few other existing properties

Anki, let me know when the Ant tasks have been updated, and I'll modify the pack targets.

I assume from your comments that no other changes to build-impl.xsl are needed, other than the ones you describe above -
i.e. the build script will not directly reference the properties sign.storepass, sign.passkey, and sign.alias.

These properties are already generated by the project customizer, but may not be present if the user has not set them
(so the signing task should fail gracefully and let the user know what to do if something is needed and missing).

Anki, reassigning this to you because it appears you've done some work on this but I'm not clear what the status is - please close if this is done.

I see jc.sign is now used in build script, we are resolving the keystore correctly, all of which looks good.  I guess the only question is if the default project template and the project updater are setting up these properties correctly?

No comment from Anki, appears to be fixed, closing.