Community
Participate
Working Groups
From examining a recent N-build, it appears that currently the "marked jar" annotation consists of the current time, when condidtioned, and "true". #Wed May 10 00:52:29 EDT 2006 pack200.conditioned=true This whole process assumes that the update command to actually pack the jars, is the same one as the one that conditions the jars ... that is, makes the same assumptions on parameters passed to "pack", and, i'd assume, the same version of pack200. (That is, pack200 might change, or bugs be fixed, etc., from one version to another?). Therefore, I suggest that when this annotation is created and written to the jar file, that the version of update that does the work include its own version in the annotation, and, even the version of pack200 that is used. This enables 2 things 1) the "pack" portion of the command could always check, and print a warning if different version of update was being used, or different version of pack200 was being used. and 2) at least gives some hope that in future, some "backwords" compatibity could in theory be provided, so that if update was changed to work differently (new rules for example) it could provide the ability to keep the old rules around, and apply those if it ever found an old version was requested to be packed. And, if not obvious, I'd suggest that '1' be done (print warning) but no action is needed on '2' at this time, other than to be sure the version info is there. This, to me, is just like the principle of providing serialversionUID's for serializable classes ... just provides a good means of at least checking for compatibility, and potentially actually providing some migration path ... if ever needed (which is, admittedly, unlikely .. but, you know how these things work out in the field :)
agreed. The proprty value should be something that indicates how the conditioning was done. Andrew, can you look at this for RC4? Dejan/Branko, any issues on your side with doing this?
On the surface it seems transparent to the Update operation. I assume a patch will be attached at some point.
Because the JarProcessor is capable of being standalone from update.core we wouldn't want to write the version of the update.core that contains it (and in general we don't actually know that version), but instead maintain a separate version for the jarprocessor itself. We can add this versioning in the future, and because we can just say true = 1.0.0, we don't necessarily need to do it right now. The version of the pack200 executable is a different kind of problem. If the options used to condition the jar must be preserved in the packing to ensure the unpack produces the same output, then the version of the pack200 by itself is not enough. We would need to actually record the options used in the conditioning. Then from there comes the ability to use those recorded options when packing instead of the options passed in. I would say that the first part is not needed until such time that we actually have a version change. The second part is a bit bigger and not something I would be able to finish in time for RC4
so, the jarProcessor is what writes to eclipse.inf in the conditioned jar? Then should jardesc produce a version for the jarProcessor jar? (and, that be used instead?) And, BTW, I'm not looking for any elaborate processing here -- there's no use case that currently justifies it ... just some safeguard such that is the same basic process that conditioned the jar can be applied while packing the jar (or, a warning produced if not an exact match) ... user could still decide to use the results, they might know it not a significant difference. And, I don't think the absence of a version number is the same as explicit version number, since ... that's just another assumption. I'll admit this seems like a small risk now ... but ... I've just seen similar processes happening with dozens of components, thousands of jars (bigger than callisto :) and know how hard it is it to keep things straight (and error free). Plus, even "version 1" of JarProcessor should check if the version is one its can deal with ... what if, in the future, someone provides a "version 2" conditioned jar to a build team that is still using a version 1 JarProcessor? No warning? (and, if you think this sort of thing could never happen, please just try to visualize scores of teams, hundreds of people, thousands of jars :)
Created attachment 41237 [details] patch Attached is a very basic patch that will write a version (1.0) instead of true. When running with verbose it will warn if the conditioned jar does not have a matching version number. A conditioned jar with "true" will be treated as 1.0
Guys, it is getting a bit late - do we want this in for RC4 and if so, can get get some votes?
Note this bug is still open but targetting a milestone in the past.
marking for 3.2.1
Comment on attachment 41237 [details] patch bug 146066 updates the properties read & written to the eclipse.inf, including the version.
Again, is this criticla for 3.2.1? What are the interplays with this and old packed/conditioned JARs?
Old jars that have been conditioned are treated as version 1.0.0. Currently the only effect of the version is a warning when in verbose mode when processing a jar with a different version number. This is mostly of a cosmetic/book-keeping nature. Note that the version recorded is the version of the processor and not the version of the pack200. The importance I think would be a reflection of how much work we plan on doing on this processor tool in the future. If we never make changes enough to increase say the minor version number, then its use is somewhat limited. Perhaps David could comment on how much he wants this :)
The Eclipse Update component is no longer under development, and no longer exists in the Eclipse Platform 4.x stream. If this problem still occurs in Eclipse Platform 4.2 or later, please enter a new bug report against Equinox p2.
