Community
Participate
Working Groups
By default new headers are appended at the end of the Manifest. Therefore operations which don't change the actual content of the Manifest still end up with Manifests which textually differ. Ideally the Manifest headers should be inserted in a deterministic order to avoid these unnecessary differences. This can easily happen in practice when a header has not many entries, for example when there is only one Service-Component or a low amount of exported/imported packages. When working on them one might end up with an intermediate state in which the header is removed and then later added again. Now the Manifest shows a difference although the content is the same.
Hi Stefan Yes, this would be useful for team work. Do you have an idea how this "deterministic order" should look like?
Hi Alexander! Personally I would just sort them alphabetically where possible. When we restrict the changes to only insert alphabetically then the problem would sort itself out over time. Of course there could then still be a long period of time where removing and re-adding the same header would lead to changes. Alternatively we could just sort on every save, however this would lead to many changes in Manifests which are just slightly touched.
(In reply to Stefan Dirix from comment #2) > Hi Alexander! > > Personally I would just sort them alphabetically where possible. I don't think this works quite well given that users can edit manifest per hand... Also note that there are some headers that are required at certain positions: >> Manifest-Version and Signature-Version must be first, and in exactly that >> case (so that they can be recognized easily as magic strings). >> Other than that, the order of attributes within a main section is not >> significant. https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#JAR_Manifest In general I don't think that any tooling in PDE must handle the case of *removal* and than *adding* the same content... anyways if it should, one could reuse the Edit-History to gather the information where the header was placed last time.
I have thought a little more about this and think PDE should support a flag for adding/updating a manifest header with "deterministicOrder=true" which behaves in the following way: - For the case where a header already present the order is not touched and we have a real replace operation - If the header is not present: 1) create a list of all current headers 2) add the new header name 3) order the list ignoring case but give 'Manifest-Version' the highest precedence as it has to come always first [1] 4) now find the Header that is the predecessor of the header to add and add it after this header That way a header with "deterministicOrder=true" will always be placed at a deterministic position without requiring that all headers are strictly sorted! An example of a Manifest then might looks like this: > Import-Package: > Require-Bundle: > Export-Package: > Bundle-ActivationPolicy: The 'Service-Component' Header will always be placed after the 'Require-Bundle' header. Of course if we later on add more headers or remove headers this might change again but as long as other headers stay constant order will stay constant and I think that's enough to prevent the usual cases where e.g. a full clean of a project changes header order. [1] https://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Manifest_Specification
This is a great suggestion that I think would be very useful. Personally I prefer to have my Manifests fully sorted, which also simplifies comparing them for two different plug-ins. I have already created a company-internal plug-in to achieve exactly this and I intended to contribute such feature to PDE (since the the functionality is not too complex and it can be done better when integrated into PDE directly I think it is better the re-write it from scratch). Regarding the sorting order, in my case I created a List to specify the order for the most common headers in a way I found suitable and used alphabetical order as fall back. I suggest to make it configurable in the preferences to either sort the headers based on a (also configurable/extensible) list of headers that specifies the order or to sort alphabetically. Alphabetical would be the fall-back for the first case. Of course technical requirements have to be met in all cases. Christoph's suggestion to only sort-in newly add new headers seems reasonable, to avoid many unintended changes. But since the location where a new entry was added is arbitrary at the moment, I think there does not need to add a switch to enable this behaviour. This can just become the new behaviour. I don't know why one would want new entries placed at the bottom. Furthermore I would add an in-editor button to sort all entries according to the configured order. So if one intents to sort an existing Manifest now it can be done this way. @Stefan do you want to implement this feature? If not I can take care of this later.
I think we should keep this simple :-) If better comparing is desired, it might make sense to add special compare functionality for manifests (e.g. comparing currently suffers to compare added/removed packages in a nice way anyway...)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
