Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [gmt-dev] The future of Fuut-je

Hi,

> The first question to answer is why we would like to maintain 
> and develop Fuut-je while there is also the EMF tool that is 
> available and supported with much more power than we ever can 
> afford for Fuut-je. 

This "WHY" question is for sure very reasonable! General opinion which I
guess most of us share is not to reinvent the wheel and reuse as much as
possible. So probably it would be good to find out common points of EMF and
FUUTje and how is it possible to EMF in those cases. Afterwords, answering
the "WHY" question would be easier.

Also some drawbacks of evolving FUUTje near EMF would be good to hear from
FUUTje authors!

To comment your point I have tried to rank them. 
Here is my ranking of importance(1 importand, 5 not important)
- 1 - "Ease of use". Very important. But in this case, I guess we should
have a roadmap how to keep this simplicity with evolution of the tool. Do
you have some ideas about?
- 1 - "Adaptability of the code generation templates". Can you be more
specific? EMF also has a support for JET templates. Why FUUTje one is
better?
- 3 - "Generate applications for any kind of environment". Important,
however I guess one day it will start to contradict with "easy of use" goal.
As an example, in roadmap you have mentioned the problem of each platforms
attributes in the FUUTje models.
- 3 - "Use it as a platform meta-level generation tool".  Yes, if it is
efficient
- 5 - "Extensibility of the tool itself by the users". Doesn't sound for me
like a benefit over EMF. 

> Proposal:
> Take the batch facilities of Fuut-je and put this into a 
> separate package, together with all modules that could run 
> with it. This is a part of Fuut-je that can run independently 
> of Swing, where you are still able to load/save models and to 
> generate code. This will result an a headless version of 
> Fuut-je. :-( (The head is the most beautiful part of a 
> "fuut", Dutch for "great crested grebe").

I like idea of making clear distinction between those versions. However I
would not create separate package for "headless" version? Those are just
different interfaces for user, ins't it? However doing different
distributions would be good.

Probably creating special Ant targets would also benefit?!
 
> Make the configuration files, batch scripts and template set 
> descriptors into XML based files and develop an EMF 
> application to handle these configurations and to start/stop 
> the headless version of Fuut-je.
> In the meantime we can start talking about the dead wood in 
> the tool model and refactor it without breaking the existing 
> templates. And do it.

Good idea.
 
> Develop a SWT GUI for Fuut-je.
> 
> Somewhere during this process, make the tool model into an 
> EMF model which will make it based on Ecore.

Those could be good reason and starting point for refactoring!

One more proposal from me: FUUT-je role in GMT should be made more clear!
And this by means of documentation and also by CVS structure. Restructuring
of GMT CVS I guess would be healthy in current situation.

Cheers,
Mark



Back to the top