Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 353463

Summary: [BuilderParticipant] Allow configuration of outlets
Product: [Modeling] TMF Reporter: Sven Efftinge <sven.efftinge>
Component: XtextAssignee: Project Inbox <tmf.xtext-inbox>
Status: CLOSED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: Andreas.Muelder, christian.dietrich.opensource, clay, mail, sebastian.zarnekow
Version: 2.0.0Flags: sven.efftinge: indigo+
Target Milestone: SR2   
Hardware: PC   
OS: Mac OS X - Carbon (unsup.)   
Whiteboard:
Bug Depends on:    
Bug Blocks: 353321, 356305    
Attachments:
Description Flags
proposed patch
none
proposed patch
none
preference page none

Description Sven Efftinge CLA 2011-07-31 08:01:38 EDT
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.
Comment 1 Sven Efftinge CLA 2011-08-10 06:26:08 EDT
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.
Comment 2 Sebastian Zarnekow CLA 2011-08-10 07:34:42 EDT
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".
Comment 3 Sven Efftinge CLA 2011-08-22 10:17:25 EDT
I've pushed a new generic implementation of IBuilderParticipant. 
Now we need to change the initial OutputConfiguration using the preferences.
Comment 4 Sven Efftinge CLA 2011-08-23 15:44:22 EDT
*** Bug 352473 has been marked as a duplicate of this bug. ***
Comment 5 Michael Clay CLA 2011-09-13 09:11:40 EDT
Created attachment 203245 [details]
proposed patch
Comment 6 Michael Clay CLA 2011-09-13 09:25:09 EDT
Created attachment 203246 [details]
proposed patch
Comment 7 Sven Efftinge CLA 2011-09-19 04:41:32 EDT
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!
Comment 8 Michael Clay CLA 2011-09-19 15:59:35 EDT
pushed to master
Comment 9 Sven Efftinge CLA 2011-09-20 02:49:45 EDT
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.
Comment 10 Sven Efftinge CLA 2011-09-20 06:46:32 EDT
The name must not be displayed in the preferences, since it is a technical identifier.
Comment 11 Sven Efftinge CLA 2011-09-20 06:54:59 EDT
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.
Comment 12 Sven Efftinge CLA 2011-09-20 06:55:46 EDT
Created attachment 203667 [details]
preference page
Comment 13 Christian Dietrich CLA 2011-09-21 16:39:16 EDT
Hi,

shouldn't org.eclipse.xtext.generator.GeneratorComponent make use of the new possibilities too?
Comment 14 Sven Efftinge CLA 2011-09-22 02:48:18 EDT
(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.
Comment 15 Christian Dietrich CLA 2011-09-22 03:45:37 EDT
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.
Comment 16 Sven Efftinge CLA 2011-09-22 03:56:16 EDT
Ah, I see. Yes we should do that.
Comment 17 Sven Efftinge CLA 2011-09-26 05:28:18 EDT
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.
Comment 18 Michael Clay CLA 2011-10-19 12:11:22 EDT
pushed to master
Comment 19 Karsten Thoms CLA 2017-09-19 18:05:15 EDT
Closing all bugs that were set to RESOLVED before Neon.0
Comment 20 Karsten Thoms CLA 2017-09-19 18:15:11 EDT
Closing all bugs that were set to RESOLVED before Neon.0