Community
Participate
Working Groups
The current FeatureParser has two of problems. 1. It is a black box, capable of parsing a feature source in the form of a folder or a jar. It can also parse the feature.xml alone but when that it does, there's no way to access the messageKeys that is built during parsing. 2. The feature.properties file is parsed twice. First to provide the 'messages' argument to the manifest parser (only to use its size) and then a second time when adding messages for locales. I think it would be cleaner if the FeatureParser is split in two classes. A 'FeatureParser', that parses the folder/jar and a 'FeatureManifestParser' that parses only the feature.xml based in an InputStream. One reason for this is that some build systems will not keep the feature.xml adjacent to the localization files at all times. Especially not after changing version qualifiers etc. A plain manifest parser can be used together with the LocalizationHelper in more ways the one.
Created attachment 127324 [details] Patch that implements the proposed split. This patch implements the proposed split of the FeatureParser class. It also fixes the problem with feature.properties being read twice. The patch also provides a public getMessageKeys() method on the FeatureManifestParser to make an integration with the LocalizationHelper possible by other users.
Some of the work I'm doing for EclipseCon is dependent on this bugzilla so it would be really helpful to know if the patch can get accepted or if I need to find other ways to resolve this. TIA
Hey Thomas, we are really swamped this week trying to wrap up API work for next week's API freeze. We have also been having trouble for the past two weeks producing a good quality build with no test failures, so want to avoid unnecessary changes. Would it still be helpful to you if this was done in M7?
Yes, absolutely. I can get by using my own patched version for now.
John could you please look at releasing Thomas's patch this week?
Merged, tested, and released to HEAD.
