We have an RCP Product based on 3.5M6 SDK that we build headlessly. I can
turn on JAR signing with the following build.properties:
jarProcessor.unsign = true
signJars=true
sign.alias=<alias>
sign.keystore=<path to keystore>
sign.storepass=<storepass>
sign.keypass=<keypass>

This builds our product (and incidentally its P2 repository) but results
in replacement of most Eclipse signatures with our own. I would rather
leave Eclipse signatures alone, as they are trusted and replacing them
takes time. Is there a straightforward way to have PDE just sign our JARs,
resulting in a signed Product and its repository?

msacarny a écrit :
> We have an RCP Product based on 3.5M6 SDK that we build headlessly. I
> can turn on JAR signing with the following build.properties:
> jarProcessor.unsign = true
> signJars=true
> sign.alias=<alias>
> sign.keystore=<path to keystore>
> sign.storepass=<storepass>
> sign.keypass=<keypass>
>
> This builds our product (and incidentally its P2 repository) but results
> in replacement of most Eclipse signatures with our own. I would rather
> leave Eclipse signatures alone, as they are trusted and replacing them
> takes time. Is there a straightforward way to have PDE just sign our
> JARs, resulting in a signed Product and its repository?
>
> Thanks,
> Mike
>

I'm interested in the same thing. sign.excludes looks promising, only I
don't want to have to write a property entry that has a comma delimited
list of every JAR that is not ours. Especially when that list might
change if I add another Eclipse dependency in a feature somewhere. It
doesn't look like wildcards are supported. Is there any other magic I
can use here?

Thanks
Ben

Mickael Istria wrote:
> msacarny a écrit :
>> We have an RCP Product based on 3.5M6 SDK that we build headlessly. I
>> can turn on JAR signing with the following build.properties:
>> jarProcessor.unsign = true
>> signJars=true
>> sign.alias=<alias>
>> sign.keystore=<path to keystore>
>> sign.storepass=<storepass>
>> sign.keypass=<keypass>
>>
>> This builds our product (and incidentally its P2 repository) but
>> results in replacement of most Eclipse signatures with our own. I
>> would rather leave Eclipse signatures alone, as they are trusted and
>> replacing them takes time. Is there a straightforward way to have PDE
>> just sign our JARs, resulting in a signed Product and its repository?
>>
>> Thanks,
>> Mike
>>
>
> Hello Mike,
>
> Maybe this page can help you to exclude Eclipse jars from signing:
> http://wiki.eclipse.org/JarProcessor_Options using "sign.excludes" option.
>
> Hope that helps
> Mickael

I've got an Ant task that will create a properties file with
sign.excludes set to all the JARs I want to exclude. I realized that the
sign.excludes property has to be in a pack.properties file, not in the
main build.properties. This is a bit difficult to achieve without
creating a custom PDE build, since pack.properties has to live in the
"input" directory to JarProcessor, which is the repository that gets
created when I turn on p2.gathering. Getting the properties file in the
right place is probably doable so I will leave that alone for now..

For whatever reason, I'm not seeing the JARs get excluded. If I step
through JarProcessor it only seems to look at sign.excludes as its
processing individual JAR file entries, not the JARs themselves.

Am I misunderstanding how sign.excludes is supposed to work? Is it still
supported on 3.5? Is there a better way to do this?

Any help here would be appreciated

Cheers
Ben

Ben Vitale wrote:
> I'm interested in the same thing. sign.excludes looks promising, only I
> don't want to have to write a property entry that has a comma delimited
> list of every JAR that is not ours. Especially when that list might
> change if I add another Eclipse dependency in a feature somewhere. It
> doesn't look like wildcards are supported. Is there any other magic I
> can use here?
>
> Thanks
> Ben
>

Rather than using JarProcessor and the signing properties already
available in build.properties, I decided to go the "customAssembly"
route. I'm hooking into "post.gather.bin.parts", and I just call the Ant
signJar task directly. I pass it a fileset, rooted at the
buildRepo/plugins directory, that only includes my company's JARs.

Hope that helps someone else.

Cheers
Ben

Ben Vitale wrote:
> A follow-up on this one..
>
> I've got an Ant task that will create a properties file with
> sign.excludes set to all the JARs I want to exclude. I realized that the
> sign.excludes property has to be in a pack.properties file, not in the
> main build.properties. This is a bit difficult to achieve without
> creating a custom PDE build, since pack.properties has to live in the
> "input" directory to JarProcessor, which is the repository that gets
> created when I turn on p2.gathering. Getting the properties file in the
> right place is probably doable so I will leave that alone for now..
>
> For whatever reason, I'm not seeing the JARs get excluded. If I step
> through JarProcessor it only seems to look at sign.excludes as its
> processing individual JAR file entries, not the JARs themselves.
>
> Am I misunderstanding how sign.excludes is supposed to work? Is it still
> supported on 3.5? Is there a better way to do this?
>
> Any help here would be appreciated
>
> Cheers
> Ben
>
> Ben Vitale wrote:
>> I'm interested in the same thing. sign.excludes looks promising, only
>> I don't want to have to write a property entry that has a comma
>> delimited list of every JAR that is not ours. Especially when that
>> list might change if I add another Eclipse dependency in a feature
>> somewhere. It doesn't look like wildcards are supported. Is there any
>> other magic I can use here?
>>
>> Thanks
>> Ben
>>

msacarny a écrit :
> We have an RCP Product based on 3.5M6 SDK that we build headlessly. I
> can turn on JAR signing with the following build.properties:
> jarProcessor.unsign = true
> signJars=true
> sign.alias=<alias>
> sign.keystore=<path to keystore>
> sign.storepass=<storepass>
> sign.keypass=<keypass>
>
> This builds our product (and incidentally its P2 repository) but results
> in replacement of most Eclipse signatures with our own. I would rather
> leave Eclipse signatures alone, as they are trusted and replacing them
> takes time. Is there a straightforward way to have PDE just sign our
> JARs, resulting in a signed Product and its repository?
>
> Thanks,
> Mike
>

I'm interested in the same thing. sign.excludes looks promising, only I
don't want to have to write a property entry that has a comma delimited
list of every JAR that is not ours. Especially when that list might
change if I add another Eclipse dependency in a feature somewhere. It
doesn't look like wildcards are supported. Is there any other magic I
can use here?

Thanks
Ben

Mickael Istria wrote:
> msacarny a écrit :
>> We have an RCP Product based on 3.5M6 SDK that we build headlessly. I
>> can turn on JAR signing with the following build.properties:
>> jarProcessor.unsign = true
>> signJars=true
>> sign.alias=<alias>
>> sign.keystore=<path to keystore>
>> sign.storepass=<storepass>
>> sign.keypass=<keypass>
>>
>> This builds our product (and incidentally its P2 repository) but
>> results in replacement of most Eclipse signatures with our own. I
>> would rather leave Eclipse signatures alone, as they are trusted and
>> replacing them takes time. Is there a straightforward way to have PDE
>> just sign our JARs, resulting in a signed Product and its repository?
>>
>> Thanks,
>> Mike
>>
>
> Hello Mike,
>
> Maybe this page can help you to exclude Eclipse jars from signing:
> http://wiki.eclipse.org/JarProcessor_Options using "sign.excludes" option.
>
> Hope that helps
> Mickael

I've got an Ant task that will create a properties file with
sign.excludes set to all the JARs I want to exclude. I realized that the
sign.excludes property has to be in a pack.properties file, not in the
main build.properties. This is a bit difficult to achieve without
creating a custom PDE build, since pack.properties has to live in the
"input" directory to JarProcessor, which is the repository that gets
created when I turn on p2.gathering. Getting the properties file in the
right place is probably doable so I will leave that alone for now..

For whatever reason, I'm not seeing the JARs get excluded. If I step
through JarProcessor it only seems to look at sign.excludes as its
processing individual JAR file entries, not the JARs themselves.

Am I misunderstanding how sign.excludes is supposed to work? Is it still
supported on 3.5? Is there a better way to do this?

Any help here would be appreciated

Cheers
Ben

Ben Vitale wrote:
> I'm interested in the same thing. sign.excludes looks promising, only I
> don't want to have to write a property entry that has a comma delimited
> list of every JAR that is not ours. Especially when that list might
> change if I add another Eclipse dependency in a feature somewhere. It
> doesn't look like wildcards are supported. Is there any other magic I
> can use here?
>
> Thanks
> Ben
>

Rather than using JarProcessor and the signing properties already
available in build.properties, I decided to go the "customAssembly"
route. I'm hooking into "post.gather.bin.parts", and I just call the Ant
signJar task directly. I pass it a fileset, rooted at the
buildRepo/plugins directory, that only includes my company's JARs.

Hope that helps someone else.

Cheers
Ben

Ben Vitale wrote:
> A follow-up on this one..
>
> I've got an Ant task that will create a properties file with
> sign.excludes set to all the JARs I want to exclude. I realized that the
> sign.excludes property has to be in a pack.properties file, not in the
> main build.properties. This is a bit difficult to achieve without
> creating a custom PDE build, since pack.properties has to live in the
> "input" directory to JarProcessor, which is the repository that gets
> created when I turn on p2.gathering. Getting the properties file in the
> right place is probably doable so I will leave that alone for now..
>
> For whatever reason, I'm not seeing the JARs get excluded. If I step
> through JarProcessor it only seems to look at sign.excludes as its
> processing individual JAR file entries, not the JARs themselves.
>
> Am I misunderstanding how sign.excludes is supposed to work? Is it still
> supported on 3.5? Is there a better way to do this?
>
> Any help here would be appreciated
>
> Cheers
> Ben
>
> Ben Vitale wrote:
>> I'm interested in the same thing. sign.excludes looks promising, only
>> I don't want to have to write a property entry that has a comma
>> delimited list of every JAR that is not ours. Especially when that
>> list might change if I add another Eclipse dependency in a feature
>> somewhere. It doesn't look like wildcards are supported. Is there any
>> other magic I can use here?
>>
>> Thanks
>> Ben
>>