Bugzilla – Full Text Bug Listing
| Summary: | JarProcessor support for explicit packaging decision | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Henrich Kraemer <henrich.kraemer> | ||||||
| Component: | Update (deprecated - use Eclipse>Equinox>p2) | Assignee: | Platform-Update-Inbox <platform-update-inbox> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | david_williams | ||||||
| Version: | 3.2 | ||||||||
| Target Milestone: | 3.2.1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
Adding this kind of control to the jar itself will no doubt be useful. It also opens the door to additional options like specifying custom pack200 arguments to use while packing. Because nested jars also will have their own eclipse.inf file, this provides a context to these control options that is missing from the external properties file that we currently support when the input is a zip file. Created attachment 46045 [details]
patch
The attached patch will consider properties in the eclipse.inf when processing a jar.
- jarprocessor.exclude : (in) if true, then exclude this jar from all processing
- jarprocessor.exclude.pack : (in) if true, exclude from pack200, but still sign
- jarprocessor.exclude.sign : (in) if true, exclude from sign, but still do pack200
- pack200.args : (in & out) if set, a comma separated list of arguments to use when conditioning or packing this jar. If custom arguments were used during conditioning via the pack.properties <jarname>.pack.args in the .zip input, then those arguments are written to that jar's pack200.args property so that they will be used again during packing.
-jarprocessor.version : (out) this property is written when processing a jar. If packing a jar that has been conditioned with a different version, then a warning will be output in verbose mode.
Is this need in 3.2.1? I think the ability for a component to explicitly mark its jar to not be processed regardless of the -processAll flag is important. Currently the most common reason to exclude a jar will be file permissions which are lost during the pack process. This would be an issue for example if we manage to have the launchers updatable. This is the biggest one that Henrich raised for his product. Ok. I suggest we do as little as possible for 3.2.1 Created attachment 47083 [details] updated patch Updated patch without the version number changes that are really part of bug 141195 There is a pack200 bug causing problems for the org.eclipse.swt.gtk.solaris.sparc fragment (see bug 153367). The workaround is to pass an option -E4 to pack200 for that fragment. This patch would make fixing problems like that very simple. Without this change, the fix is complicated by changing version numbers in the jar name. committed |
The pack200.conditioned=[true|false] property in file META-INF/eclipse.inf tracks whether a a jar has been conditioned. The JarProcessor does not support a way to capture the decision whether a jar should be packed or not. Having JarProcessor provide this seems beneficial as it will provide a standard way of achieving this. This could be accomplished by a property, perhaps: pack200={true|false} - true stands for include this jar in normalize and pack processing - false means that this jar should not be normalized or packed. A missing value or eclipse.inf file would be interpreted as true. A pack200-false value tells the JarProcessor to never process this file.