Bugzilla – Full Text Bug Listing
| Summary: | [NewProject] Workflow doesn't use properties file | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Moritz Eysholdt <moritz.eysholdt> | ||||
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | Holger.Schill, sebastian.zarnekow, sven.efftinge | ||||
| Version: | 1.0.0 | Flags: | sven.efftinge:
helios+
|
||||
| Target Milestone: | RC3 | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Moritz Eysholdt
When the file has been deleted the Generator generates a new one. The properties are used at runtime (see Abstract<MyDsl>RuntimeModule) That is not transparent to the user. In the last Workshop some users asked me what for the properties-file is. Before that they deleted it. I think we should point out where it is used in a comment in the fileor we should use the values in the mwe2 file. Moritz suggested to remove the *.properties file and add configureFileExtension() to the generated runtime module. I think that's a good idea. We should as well introduce configureLanguageName(), i.e. move the binding which is currently generated into the configure() method and therefore unmodifiable to a separate overridable binding. See also #309437. What about configureEditorId() in the UI-module? (In reply to comment #5) > What about configureEditorId() in the UI-module? I think we should fix that issue (#309437) after the release but should solve this bugzilla now. It is not completely clear which usages of languageName should become editorID. For instance we reused the languageName for the preferences key, etc. A change may break existing clients. Consider a client who added additional entries to the properties file. Those ones will no longer be bound after regenerating the language. Therefore I'ld vote for postponing this ticket to Indigo. Maybe we should fix this ticket by means of altering the wizard to not create a properties file but let the workflow generate this file if absent? Created attachment 170363 [details]
Properties-Bug-314851
This patch modifies the code generator so that a properties file is loaded if it does exist. If it doesn't exist, configure...() methods add bindings for language name and file extensions.
This guarantees backwards compatibility while eliminating the need for the wizard and code generator to create a properties file.
Please review.
The properties file contains entries for grammarURI, file.extensions, projectName but the change will only bind the languageName if no propertiesFile is found so I guess there will be no languageName bound if a properties file is present and the language was regenerated. I do not quite understand the rational behind this late RC3 change. This is neither a blocker nor a major problem. The complexitiy will increase while I personally don't see the benefit. Should we really push this one into Helios? Sebastian is right, that the if(!useProperties) predicate for languageName needs to be removed and of course this needs to be carefully tested. Other than that it looks good to me. We also need to change the wizard so that it does no longer produce the properties file and remove the properties file from our code base (at least from the examples) and regenerate those languages. (In reply to comment #9) > The properties file contains entries for > grammarURI, file.extensions, projectName > but the change will only bind the languageName if no propertiesFile is found so > I guess there will be no languageName bound if a properties file is present and > the language was regenerated. I didn't find any usages of grammarURI and I wouldn't recommend to use it. If someone is interested in the grammar, the IGrammarAccess provides it. Furthermore, since property files are still loaded if they exist, the binding for grammarURI will be available as long as the properties file is kept. > I do not quite understand the rational behind this late RC3 change. This is > neither a blocker nor a major problem. The complexitiy will increase while I > personally don't see the benefit. Should we really push this one into Helios? Currently, properties are declared redundant: In the properties and in the workflow. Only one location should be needed. I find this important as this is a place that people who approach Xtext spot very early. (In reply to comment #10) > Sebastian is right, that the if(!useProperties) predicate for languageName > needs to be removed and of course this needs to be carefully tested. Other than > that it looks good to me. The predicate ensures that the configure...() methods only have an impact if there is no property file. Otherwise there would be a conflict between the property file and the configure...() methods if they register bindings for the same name. Why would you want to remove it? Surely it would make the code simpler, but it would break compatibility with projects that have registered more than just file.extensions and the language name. I've committed the change so that we still have the chance to do more testing before RC3. The fix includes: - The fix as proposed in the patch. I am aware that we didn't finish the the discussion about it but I can't think of a better solution at the moment. If we come up with one, I'll change it. - All language-specific property files are removed from CVS now. Maybe this will already leads to a speedup during sync! :) - The wizards for new projects and ecore2xtext now don't create property files anymore. Moritz, you misunderstood Sebastian's and my comments. Sebastian pointed out a bug in the compatibility mechanism. The configuration of the 'languageName' property now depends on the existence of a properties file. But that property had never been configured using a property file. As a consequence if someone still had a properties file, the languageName property wouldn't be configured at all and nothing would work. So we need to remove that predicate just for that property (not for file.extensions). And we need to test both situations (with and without properties). Also the MWE2 language needs to be updated accordingly. As soon as you have fixed that, the bug can closed. I fixed the mention issue regarding the languageName and will now update MWE2. ok, thx. I was just about to do the same for the predicate, but I can't adapt MWE2 since I'm not a committer. updated MWE2 Closing bug which were set to RESOLVED before Eclipse Neon.0. |