Community
Participate
Working Groups
Both the language designer as well as the final language users should be able to configure the different outlets. For the language designer I propose a IGeneratorExtension1 interface which returns a description of outlets. The framework should stick with the current default behavior if the IGenerator doesn't support this new interface. For the end user the location of the different outlets should be configurable in the workspaces's and project's preferences.
A data structure for OutletConfiguration needs to be provided for each language implementation. It must contain information about the - name of the outlet - default project relative path - whether it overwrites - whether it cleans up generated files - whether it sets derived to true on generated files the list of OutletConfigurations is then used to implement the IFileSystemAccess. Language users should be able to change the properties of such a configuration using the project and workspace preferences. The name and the number of configuration instances are not changeable of course.
I think a description for the outlet may be helpful, too (e.g. as a tooltip in the preference page e.g. "Xtend will generate Java classes into this path".
I've pushed a new generic implementation of IBuilderParticipant. Now we need to change the initial OutputConfiguration using the preferences.
*** Bug 352473 has been marked as a duplicate of this bug. ***
Created attachment 203245 [details] proposed patch
Created attachment 203246 [details] proposed patch
I wasn't able to apply the patch locally in order to try it, but it looks good on a first glance. Please push it to the remote repository so we can work out the details. Thanks!
pushed to master
If I change the output folder, the resources derived from the current builder in the old output should be removed. And if there are no other resources left in that folder the whole source folder should be removed as well.
The name must not be displayed in the preferences, since it is a technical identifier.
The description shouldn't be updatable, but instead should be used the label only. As the number of outputs is fix, I'd prefer a foldable form like in the attached screenshot (for each outlet) instead of a master details view. Please also put the "Generate Automatically" Checkbox in a first section called "General". The preference page's name should be 'building' not 'builder' because that aligns better with the already existing preference pages.
Created attachment 203667 [details] preference page
Hi, shouldn't org.eclipse.xtext.generator.GeneratorComponent make use of the new possibilities too?
(In reply to comment #13) > Hi, > > shouldn't org.eclipse.xtext.generator.GeneratorComponent make use of the new > possibilities too? If you mean the plugin.xml contribution and corresponding binding should be done in GeneratorComponent instead of in BuilderIntegrationComponent, then yes. But I've changed that already.
No, i mean http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/tree/plugins/org.eclipse.xtext/src/org/eclipse/xtext/generator/GeneratorComponent.java which is used in the workflow that is generated next to the IGenerator Instance Xtend foreach Dsl. here the outlets are still "simple" name path pairs.
Ah, I see. Yes we should do that.
I pushed the following changes: 1) clean up is executed within a WorkspaceModifyOperation 2) Deactivated cleanup of empty folders, since we need to delete a source-folders using JDT and this needs to be done in a way that JDT doesn't become a mandatory library. 3) the job is no longer a singleton, but instead a new job is scheduled each time.
Closing all bugs that were set to RESOLVED before Neon.0
