Eclipse Community Forums: Buckminster

Help

Home

Home » Archived » Buckminster » Selective signing

Show: Today's Messages :: Show Polls :: Message Navigator

Selective signing [message #546286]

Mon, 12 July 2010 11:40

Carsten Reckord

Messages: 139
Registered: July 2009

Senior Member

Hi all,

I'm trying to get signing set up for our update site. I have the signing process itself running fine already. But now I'm facing the problem
that the site contains some org.eclipse.* artifacts that of course I don't want to sign.

So is there a way to selectively sign just a part of the site?

I already tried excluding the eclipse artifacts from the site in the first place (I don't really need them there, so that would have been a
plus). But I failed because that left the products on the site broken and unlaunchable: We have org.eclipse.rcp, the org.eclipse.ecf stuff
and a few others included in our product feature. I tried excluding them from the site by adapting the bundle.jars and feature.jars groups,
which worked fine as far as site contents were concerned. However that seems to fry the product because afterwards it fails to launch
because of a missing org.eclipse.core.runtime (which gets installed from anotehr site, but there seems to be something wrong with the
product's config.ini and related config files)

Best regards,
Carsten

Report message to a moderator

Re: Selective signing [message #546314 is a reply to message #546286]

Mon, 12 July 2010 12:57

Henrik Lindberg

Messages: 2509
Registered: July 2009

Senior Member

Hi,
Perhaps not the best way, but you could perhaps do this:
- create your site with only your things (all signed)
- use the b3 aggregator to set up a repository that you create the
product against, and that you can use as the update site.
- the repository you create can be a composite site pointing to your
built site and Eclipse Helios for instance.

- henrik

On 7/12/10 1:40 PM, Carsten Reckord wrote:
> Hi all,
>
> I'm trying to get signing set up for our update site. I have the signing
> process itself running fine already. But now I'm facing the problem that
> the site contains some org.eclipse.* artifacts that of course I don't
> want to sign.
>
> So is there a way to selectively sign just a part of the site?
>
> I already tried excluding the eclipse artifacts from the site in the
> first place (I don't really need them there, so that would have been a
> plus). But I failed because that left the products on the site broken
> and unlaunchable: We have org.eclipse.rcp, the org.eclipse.ecf stuff and
> a few others included in our product feature. I tried excluding them
> from the site by adapting the bundle.jars and feature.jars groups, which
> worked fine as far as site contents were concerned. However that seems
> to fry the product because afterwards it fails to launch because of a
> missing org.eclipse.core.runtime (which gets installed from anotehr
> site, but there seems to be something wrong with the product's
> config.ini and related config files)
>
>
> Best regards,
> Carsten

Report message to a moderator

Re: Selective signing [message #546359 is a reply to message #546314]

Mon, 12 July 2010 14:26

Carsten Reckord

Messages: 139
Registered: July 2009

Senior Member

Hi Henrik,

On 12.07.2010 14:57, Henrik Lindberg wrote:
> Hi,
> Perhaps not the best way, but you could perhaps do this:
> - create your site with only your things (all signed)
> - use the b3 aggregator to set up a repository that you create the
> product against, and that you can use as the update site.

I assume with "create the product" you mean the installation step, i.e. pulling the jars from the site and installing them using director?
In that case the problem still exists, because it appears that it's not the installation step that messes up the product, but the metadata
generated by the p2SiteGenerator in the site.p2 step.

I could just completely exclude the feature that defines our product from the site, however we'd prefer to have the product feature and
launchers on the site...

> - the repository you create can be a composite site pointing to your
> built site and Eclipse Helios for instance.
>
> - henrik
>
> On 7/12/10 1:40 PM, Carsten Reckord wrote:
>> Hi all,
>>
>> I'm trying to get signing set up for our update site. I have the signing
>> process itself running fine already. But now I'm facing the problem that
>> the site contains some org.eclipse.* artifacts that of course I don't
>> want to sign.
>>
>> So is there a way to selectively sign just a part of the site?
>>
>> I already tried excluding the eclipse artifacts from the site in the
>> first place (I don't really need them there, so that would have been a
>> plus). But I failed because that left the products on the site broken
>> and unlaunchable: We have org.eclipse.rcp, the org.eclipse.ecf stuff and
>> a few others included in our product feature. I tried excluding them
>> from the site by adapting the bundle.jars and feature.jars groups, which
>> worked fine as far as site contents were concerned. However that seems
>> to fry the product because afterwards it fails to launch because of a
>> missing org.eclipse.core.runtime (which gets installed from anotehr
>> site, but there seems to be something wrong with the product's
>> config.ini and related config files)
>>
>>
>> Best regards,
>> Carsten
>

Report message to a moderator

Re: Selective signing [message #546372 is a reply to message #546359]

Mon, 12 July 2010 15:04

Henrik Lindberg

Messages: 2509
Registered: July 2009

Senior Member

On 7/12/10 4:26 PM, Carsten Reckord wrote:
> Hi Henrik,
>
> On 12.07.2010 14:57, Henrik Lindberg wrote:
>> Hi,
>> Perhaps not the best way, but you could perhaps do this:
>> - create your site with only your things (all signed)
>> - use the b3 aggregator to set up a repository that you create the
>> product against, and that you can use as the update site.
>
> I assume with "create the product" you mean the installation step, i.e.
> pulling the jars from the site and installing them using director?

yes.

> In that case the problem still exists, because it appears that it's not
> the installation step that messes up the product, but the metadata
> generated by the p2SiteGenerator in the site.p2 step.
>

That is bad. I believe we do publish Buckminster products that are
signed this way - but I need Thomas to verify (don't know if he is back
from vacation yet).

- henrik

Report message to a moderator

Re: Selective signing [message #549039 is a reply to message #546286]

Fri, 23 July 2010 18:44

Thorsten Meinl

Messages: 85
Registered: July 2009

Member

Hi all,

I'm facing the same problem. We have some US that also contain external
bundles and when I create them, I only want our bundles to be signed. It's
sad that this seems not to be possible (yet?). I thought I could migrate
from our 1000+ lines PDE build file to Buckminster and only make few
modifications to existing stuff, but right now I'm already stuck in an early
stage :-(

Regards,

Thorsten

Report message to a moderator

Re: Selective signing [message #549097 is a reply to message #549039]

Sat, 24 July 2010 10:40

Axel Guckelsberger

Messages: 354
Registered: July 2009

Senior Member

Hi Thorsten,

maybe it is possible to separate the bundles not to be signed into a
different feature? Don't know if it works, but in theory you could then use
multiple build jobs with different configurations. For example you could
create one p2 site with all signed bundles and another one with only the
other features. With the b3 aggregator you can then create an aggregated
repository encapsulating all single repositories to a central place.

HTH
Axel

Thorsten Meinl wrote:

> Hi all,
>
> I'm facing the same problem. We have some US that also contain external
> bundles and when I create them, I only want our bundles to be signed. It's
> sad that this seems not to be possible (yet?). I thought I could migrate
> from our 1000+ lines PDE build file to Buckminster and only make few
> modifications to existing stuff, but right now I'm already stuck in an
> early stage :-(
>
> Regards,
>
> Thorsten

Report message to a moderator

Re: Selective signing [message #549122 is a reply to message #549097]

Sat, 24 July 2010 21:11

Thorsten Meinl

Messages: 85
Registered: July 2009

Member

--nextPart24175780.vaeNJFYEL5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit

OK, Buckminster isn't that bad ;-) I found a nice way to circumvent the
problem. I added a CSPECX to the US feature and altered the site.signed
actor so that it calls a custom ant script that only signs selected jars.
See the attached files. The sign.jars task was copied from the default
Buckminster task and slightly modified.
--nextPart24175780.vaeNJFYEL5
Content-Type: application/xml; name="buckminster.cspex"
Content-Disposition: attachment; filename="buckminster.cspex"
Content-Transfer-Encoding: base64

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGNzcGVj RXh0ZW5zaW9uIHht
bG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5z dGFuY2UiCgl4bWxu
czpiYz0iaHR0cDovL3d3dy5lY2xpcHNlLm9yZy9idWNrbWluc3Rlci9Db21t b24tMS4wIiB4bWxu
cz0iaHR0cDovL3d3dy5lY2xpcHNlLm9yZy9idWNrbWluc3Rlci9DU3BlYy0x LjAiPgkKCTxhY3Rp
b25zPgoJCTxwdWJsaWMgbmFtZT0ic2l0ZS5zaWduZWQiIGFjdG9yPSJhbnQi PgoJCQk8YWN0b3JQ
cm9wZXJ0aWVzPgoJCQkJPHByb3BlcnR5IGtleT0iYnVpbGRGaWxlIiB2YWx1 ZT0ic2lnbmluZy5h
bnQiIC8+CgkJCQk8cHJvcGVydHkga2V5PSJ0YXJnZXRzIiB2YWx1ZT0ic2ln bi5qYXJzIiAvPgoJ
CQk8L2FjdG9yUHJvcGVydGllcz4KCQkJPHByZXJlcXVpc2l0ZXMgYWxpYXM9 ImFjdGlvbi5yZXF1
aXJlbWVudHMiPgoJCQkJPGF0dHJpYnV0ZSBuYW1lPSJzaXRlLnJlcGFja2Vk IiBmaWx0ZXI9Iihz
aXRlLnBhY2syMDA9dHJ1ZSkiIC8+CgkJCQk8YXR0cmlidXRlIG5hbWU9InNp dGUuZmVhdHVyZS5l
eHBvcnRzIiBmaWx0ZXI9IighKHNpdGUucGFjazIwMD10cnVlKSkiIC8+CgkJ CTwvcHJlcmVxdWlz
aXRlcz4KCQkJPHByb2R1Y3RzIGFsaWFzPSJhY3Rpb24ub3V0cHV0IiBiYXNl PSIke2J1Y2ttaW5z
dGVyLm91dHB1dH0vc2l0ZS5zaWduZWQvIgoJCQkJdXBUb0RhdGVQb2xpY3k9 Ik1BUFBFUiIgLz4K
CQk8L3B1YmxpYz4KCTwvYWN0aW9ucz4KCTxhbHRlckFjdGlvbnM+CgkJPHJl bW92ZSBuYW1lPSJz
aXRlLnNpZ25lZCIgLz4KCTwvYWx0ZXJBY3Rpb25zPgo8L2NzcGVjRXh0ZW5z aW9uPgo=

--nextPart24175780.vaeNJFYEL5
Content-Type: text/plain; name="signing.ant"
Content-Disposition: attachment; filename="signing.ant"
Content-Transfer-Encoding: 8Bit

<project>
<property name="output.folder" location="${sp:action.output}" />

<target name="sign.jars">
<property name="local.keystore.path" value=""/>
<property name="local.keystore.alias" value=""/>
<property name="local.keystore.password" value=""/>
<buckminster.contextProperty name="local.keystore.path"/>
<buckminster.contextProperty name="local.keystore.alias"/>
<buckminster.contextProperty name="local.keystore.password"/>
<fail message="The properties 'local.keystore.path', 'local.keystore.alias', and 'local.keystore.password' must be set in order to do local jar signing">
<condition>
<not>
<and>
<length string="${local.keystore.path}" when="greater" length="0"/>
<length string="${local.keystore.alias}" when="greater" length="0"/>
<length string="${local.keystore.password}" when="greater" length="0"/>
</and>
</not>
</condition>
</fail>
<delete dir="${output.folder}" />
<mkdir dir="${output.folder}" />
<copy todir="${output.folder}">
<buckminster.valuefileset value="${fs:action.requirements}" />
</copy>
<signjar keystore="${local.keystore.path}" alias="${local.keystore.alias}" storepass="${local.keystore.password}">
<fileset dir="${output.folder}">
<include name="**/org.knime.*.jar"/>
<include name="**/com.knime.*.jar"/>
</fileset>
</signjar>
</target>
</project>

--nextPart24175780.vaeNJFYEL5--

Report message to a moderator

Previous Topic:	Target Platform for 3.4
Next Topic:	Dependency in build

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 11:30:04 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter