Community
Participate
Working Groups
Created attachment 138496 [details] list of unsigned bundles as of RC3 I'll attach full list, but seems there's 1 from emf.teneo several from rap and hundreds from reina Plus, there's several that I'm not sure where they are from (some third party jars).
The org.eclipse.emf.teneo.hibernate.libraries_1.0.0.v200806111928 plugin is particularly nasty! I'm pretty sure that it should not exist in Galileo at all. The reason that it is there seems to be that it exports a whole bunch of 3rd party packages and it even does not contain these packages. The whole plugin is a relict which gets pulled in because the package exports are not versioned. Nor are the package imports in Teneo upstream plugins. Now one of my plugins from emf.cdo *optionally* imports some packages from hibernate. Normally this should not cause problems because Hibernate is not in Galileo and my dependencies are optional. Problem 1: Where does the Galileo build get this old and obsolete libraries plugin from? Possibly related to Bug #279372 ? Problem 2: Teneo should version its imported and exported packages so that upstream plugins can exclude this malicious libraries bundle.
The org.eclipse.emf.teneo.hibernate.libraries_1.0.0.v200806111928 is a plugin which was released in june 2008 for Ganymede. It is not part of the teneo sdk which I promoted to Ganymede. Neither is it part of the teneo sdk for Galileo. It seems to get drawn in somehow because cdo has optional dependencies on hibernate. As Eike noted I should use versions on export packages. However, that is a separate issue and not related to this one afaics. Even if I would have used versions then it is still incorrect that this plugin is available on update sites and afaics also that the Galileo build draws in these old plugins. So afaics there are three issues that need to be solved: 1) the galileo build should not draw in old plugins from previous releases. I can't solve this one. 2) I should check/ensure that this plugin (the new version) is available on an update site, and if I can solve it do that. I noticed that this plugin is part of the all-in-one-update-site-zip, so it should probably be removed from there. I can't change old builds on update sites, so maybe they need to be removed. 3) Unrelated to this issue: I should set versions on export packages. My first question however is why the version of the plugin is not used as a default, does anyone know? gr. Martin
(In reply to comment #2) > 1) the galileo build should not draw in old plugins from previous releases. I > can't solve this one. The Galileo Builder uses the P2 planner to compute the best resolution possible for the contributions. It has no way of discriminating some optional bundles while allowing others. To skip all optional bundles doesn't strike me as a feasible since that will mean that no optional bundles will be present in the final distribution. The two solutions possible is to either accept the plug-ins (and hence sign them) or remove them from the update site used for the contribution. So #1 is a wontfix IMO. The Galileo Builder will not resolve this for you.
(In reply to comment #1) > Where does the Galileo build get this old and obsolete libraries plugin from? > From one of the contributed repositories. > Possibly related to Bug #279372 ? > I doubt that. I cannot reproduce that problem with the Galileo Builder code.
Hi Thomas, The teneo plugin mentioned here is not part of a Galileo (it is from june 2008..., Ganymede...). Afaik it is and has not been promoted to a Galileo update site. You mention that the p2 planner is used to resolve these dependencies. Is it possible for you to see where the p2 planner gets this plugin? Maybe in a log somewhere? Then I can check and remove it from there. gr. Martin
(In reply to comment #5) > > You mention that the p2 planner is used to resolve these dependencies. Is it > possible for you to see where the p2 planner gets this plugin? Maybe in a log > somewhere? Then I can check and remove it from there. > Pretty easy to find ... there's two of them. I started by seeing what repository that emf-teno.build specifies It is /modeling/emf/updates/milestones/ So, looking there from a shell script, under plugins ... pretty easy to spot. david_williams@build:~/downloads/modeling/emf/updates/milestones/plugins> ll org.eclipse.emf.teneo.hibernate.libraries* -rw-rwxr--+ 1 mtaal modeling.emf.website 20755 2008-06-12 13:10 org.eclipse.emf.teneo.hibernate.libraries_1.0.0.v200806111928.jar -rw-rwxr--+ 1 mtaal modeling.emf.website 14415 2008-06-12 13:10 org.eclipse.emf.teneo.hibernate.libraries_1.0.0.v200806111928.jar.pack.gz -rw-rw-r--+ 1 mtaal modeling.emf.website 15314110 2009-06-02 00:47 org.eclipse.emf.teneo.hibernate.libraries_1.1.0.v200906012353.jar -rw-rw-r--+ 1 mtaal modeling.emf.website 5976627 2009-06-02 00:47 org.eclipse.emf.teneo.hibernate.libraries_1.1.0.v200906012353.jar.pack.gz Take care, though, that something in your build script is not building them or adding them back each time.
Created attachment 138538 [details] improved list I mistakenly included some "old" jars in checking ... about the same story, but this list does not contain any from 'rap' project.
I removed all occurences of org.eclipse.emf.teneo.hibernate.libraries from the /downloads/modeling/emf/updates/. The rc4 build and promote, I did yesterday evening, did not add a new one. So hopefully this plugin won't appear again. gr. Martin
Note to riena team: You mentioned "you've been signing since RC1", but your pack.gz files still show up as unsigned. You do create those from the signed jars, right? Another possible hint. There are two _jar_ files showing up as signed. Not sure why those are not pack.gz files ... but, there are only jars, and they are signed. org.eclipse.riena.build.feature.core.sdk_1.1.0.RC4.jar org.eclipse.riena.build.feature.samples.sdk_1.1.0.RC4.jar
Created attachment 139104 [details] unsigned jars in current staging directory
From what I can tell, only riena has unsigned jars, so changing title. Well, except there is also the capabilities plugins .. but that's being tracked in bug 279369.
I am probably too stupid to solve this. So maybe one of the other build masters can help me. I am doing a pack200 and then a sign. Should I first sign my jars and then let them be repacked and pack200 ?? Is that the trick ? Because only the pack200 ist what David are calling as unsigned.
The more I think about it thats probably it. Its a jarsigner and not a pack200 signer. So I need to sign the jars and then also create pack200 files and I am good.
(In reply to comment #13) > The more I think about it thats probably it. Its a jarsigner and not a pack200 > signer. So I need to sign the jars and then also create pack200 files and I am > good. > Almost. It's essential that the bits never changes after signing so you need to normalize before you sign. Pack200 is an extremely efficient way of compressing Java class files. So efficient in fact, that a decompression will sometimes create a slightly different result. At least the first time. By first compressing, then decompressing (a.k.a. normalizing) you make sure that subsequent compressing+decompressing will yield the exact same bits. This is why it's essential to: 1. Normalize 2. Sign (with jarsigner) 3. Pack
And, by the way, I think the standard path through Eclipse.org signing will normalize the jars for you by default.
Oh, and one final tip ... be sure to re-generate your site's meta data as the very last step ... as some of this process can change checksum values.
there is already a bugzilla somewhere where we did forget to regenerate the metadata. so I made sure I do that as the very last step. I am almost sure that Riena is in nearly every bugzilla concerning build issues now :-) that is cross project.
Sweet! The list of unsigned jars is short, and well understood ... well, except for rap.sdk. We are looking quiet professional. Thanks everyone. org.eclipse.rap.sdk_1.2.0.20090616-1425.jar: commonj.sdo_2.1.1.v200905221342.jar: org.eclipse.rap.ui.capabilities_1.2.0.v20090608-1802.jar: org.eclipse.emf.ecoretools.ui.capabilities_0.9.0.v20090507-0818.jar: org.eclipse.emf.capabilities_1.0.0.v20090513-1506.jar: org.eclipse.rse.ui.capabilities_1.0.0.v20090608-2045.jar: org.eclipse.gef.examples.ui.capabilities_3.5.0.v20090501-1920.jar: org.eclipse.gmf.ui.capabilities_1.0.0.v20090608-1103.jar: org.eclipse.actf.ui.capabilities_0.7.0.v20090615-0725.jar: org.eclipse.galileo_1.0.0.v20090608-1634.jar: org.eclipse.datatools.capabilities_1.0.0.v20090611-0411.jar.pack.gz: org.eclipse.uml2.capabilities_1.0.0.v20090420-1756.jar: org.eclipse.uml2tools.capabilities_0.9.0.v20090615-1317.jar: org.eclipse.mylyn.ide.capabilities_3.2.0.v20090429-0837.jar: org.eclipse.tptp.ui.capabilities_4.6.0.v20090406-1250.jar:
Maybe we can remove riena from the title of this bug again (since we finally made it) :-)
