Community
Participate
Working Groups
QVTi files are expensive to create and so can be created ahead of time; just need a builder. But which QVTi files? A launch configuration could indicate what was needed so the builder just scans all launch files. Useful, but surely not the only solution? Maybe the MWE2/ANT/... launch component/task lazily creates the QVTi first time and registers it for subsequent auto-building. Looks like there needs to be an auto-build registry for QVTi compilation, and no doubt a UI to maintain it for deletions (or manual additions). ----- Many transformations are unidirectional so why is it necessary to register the only possibility? Few transformations are more than unidirectional, so does it cost unduly to compile all directions?
I see two use cases. Launch configuration/dialog. Variously used by newbies and quick experiments. May sometimes be given a fixed parameterization for a regular task. Workflow. The user invokes a transformation within a script (MWE/ANT/...) or tool configuration (? a Papyrus add-on). A builder should ensure that the edited artefact is automatically converted to the executable artefact. For Java/Xtend/... building is 'easy', there are just Java files to produce, no user options. For QVTo/... building is easy. It doesn't happen. Building occurs at run-time. For QVTc/QVTr we have user options; direction/enforcement-mode/CG-or-interpreted. How are these configured? For my transformation, the editor could offer an extra dialog. But when re-using your transformation, I don't use the editor. What I want may be different to what you want. [We might eliminate some of the options if we re-combined all directions in a jumbo executable, and maybe CG can be deduced from available genmodels. But can we eliminate all options?] If we have options, where are they stored? 1) The source file. No: May be read-only. 2) A launch config: klunky; user will forget to store in the workspace. 3) The .project file builder parameters: No; will grow unpleasantly large. 4) .settings file/files: No; one file could grow large, multiple files lack hierarchy. 5) The 'output' file(s). *.qvtbuild files can be placed anywhere, but typically where auto-generated Java / QVTi files are to be produced. A *.qvtbuild model is a list of zero or more sets of filenames and build options. How do we stop these *.qvtbuild files being a confusing pain? How do we avoid writing lots of UI code? Can something like the Java Build path property pages provide a default behavior? Maybe .launch files aren't so bad. We will duplicate ergonomics unnecessarily if we don't use them. We can ensure that the store locally is configured as part of the creation. QVTd builder traverses .launches.
