|
Re: Headless signing just our JARs [message #57066 is a reply to message #56826] |
Mon, 20 April 2009 08:20 |
Eclipse User |
|
|
|
Originally posted by: mickael.istria.openwide.fr
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
|
|
|
|
|
Re: Headless signing just our JARs [message #68286 is a reply to message #66752] |
Fri, 17 July 2009 01:14 |
Ben Vitale Messages: 247 Registered: July 2009 |
Senior Member |
|
|
Might as well close the loop on this..
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
>>
|
|
|
Re: Headless signing just our JARs [message #595883 is a reply to message #56826] |
Mon, 20 April 2009 08:20 |
|
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
|
|
|
|
|
Re: Headless signing just our JARs [message #599474 is a reply to message #66752] |
Fri, 17 July 2009 01:14 |
Ben Vitale Messages: 247 Registered: July 2009 |
Senior Member |
|
|
Might as well close the loop on this..
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
>>
|
|
|
Powered by
FUDForum. Page generated in 0.04079 seconds