Community
Participate
Working Groups
Technically, in most cases, if everything done just right, this would not hurt anything ... but ... we still shouldn't do it, just like we do not "re-sign" bundles from Orbit. (It does hurt things, if the original jars are signed, but not conditioned, as is unfortunately the case with ICU4J ... I expect ECF does things right (they do from my quick checks) but still ... best if we don't do it). There might be some relatively easy way to update the updatePackProperties target. My first thought was to use "generateExcludeList" to simply add to what we already do for Orbit. <target name="updatePackProperties"> <property name="packproperties" value="${buildDirectory}/updatePackProperties.txt" /> <generateExcludeList mapFile="${buildDirectory}/maps/org.eclipse.releng/maps/orbit.map" outputFile="${packproperties}" /> <generateExcludeList mapFile="${buildDirectory}/maps/org.eclipse.releng/maps/p2.map" outputFile="${packproperties}" /> But ... looking at the source for our custom "generateExcludeList" it would take some tweaking to a) append, not recreate, the "outputFile", and b) in this case be a little smarter about which "plugins" it picks from maps files, and only use those with "p2IU" protocol. For what its worth, both Orbit and WTP have slightly different methods of "picking" the ones to exclude", briefly described at http://wiki.eclipse.org/JarProcessor_Options/Examples The one from WTP is nice since takes least "human intervention" and simply takes a quick peek at the "to be signed" bundles and excludes them if already signed by Eclipse. (But, see bug 376265 ... even that code needs to be udpated every time there is a new Eclipse new certificate :( ...
Assuming my "fix" for bug 376032 (build running now) I think we can change this one to a feature request for the future. My "fix" was to simply move ECF bundles to the file call "orbit.map" (which already had other consumed bundles that did not come from Orbit, I expect for similar reasons). So if that works, we'll be all set for now, and may just improve it in future so not all "to be excluded" bundles have to go into one file.
If we do enhance the generateExcludeList another thing to look at is making sure the comments (and blank lines?) are handled properly. I'd made one line a comment similar to ! these bundles from ECF .... Which is a legal property file comment. But the end result had something like <normal entries>,plu(from ECF ...)ins .... <normal entries> Not sure what the effect of this was, but think it caused a few to be "missed". I then notice # were used in other comment lines (except the first) plus I avoided the word 'bundle' since think that's sometimes a key when it starts a line. We'll see how it works now that I've "cleaned up" comments ... but, thought best to make a note of this issue in case we get into that code.
Next problem, I see the generateExcludeList had some other hard assumptions ... like it doesn't recognize "fragment" at the beginning of an entry, so ends up with plugins/nt@ instead of plugins/ There's 6 of them: plugins/nt@org.eclipse.ecf.ssl_1.0.100.v20120319-0616.jar, plugins/nt@org.eclipse.ecf.ssl.source_1.0.100.v20120319-0616.jar, plugins/nt@org.eclipse.ecf.provider.filetransfer.ssl_1.0.0.v20120319-0616.jar, plugins/nt@org.eclipse.ecf.provider.filetransfer.ssl.source_1.0.0.v20120319-0616.jar, plugins/nt@org.eclipse.ecf.provider.filetransfer.httpclient.ssl_1.0.0.v20120319-0616.jar, plugins/nt@org.eclipse.ecf.provider.filetransfer.httpclient.ssl.source_1.0.0.v20120319-0616.jar So ... I'm thinking ... I have some vague memory that "it doesn't really matter" ... that for a map entry, you could call them "plugins" and everything else about map files would still work the same. It'd be nice if someone could confirm before we just "try it out"? The key for the signer/processor is that the "path match what ever is in the zip" ... which these obviously won't. (the zip will still say "fragment/org.eclipse.ect...." But, obviously another "improvement" needed for generateExcludeList.
I see now its commas that are causing problem in comment line, not, I believe, what character the comment starts with. I ended up with an comment of # from ECF, these were moved from p2.map, for build changes. See bug 376032. and in the pack.properties file (after the parsing/re-creation) it had an entry plugins/ ECF_ECF.jar,
Marking as major, since it "breaks" for fragments (missing function) but as P3 since I don't plan to fix before Juno.
I think no longer relevant (to us) with Maven/Tycho build, so marking as "won't fix".
