Home » Modeling » EMF » "Should I stay or should I go!"
| "Should I stay or should I go!" [message #513392] |
Tue, 09 February 2010 23:27  |
 Hasan Ceylan
Messages: 198
Registered: July 2009 |
Senior Member |
|
|
Hello,
I remembered that I haven't listened to the classical song I like lately [1]
[2].
As some of you are well aware, I have been investing in some time to a
generalized IDE-like build, validation, and code generation for EMF models
so far.
I felt the need to write this post up as I have come to a point where I am
paralyzed.
I have sent the original mail to the newsgroup on February the 1st. On one
hand, I have been receiving very encouraging comments and directions from a
number of parties, on the other hand after 10 days and 150 hours of work and
one release [3] with great motivation, I also get comments like "this
already exists."
I am at total loss and awaiting for advises from Eclipse Officials and
fellow EMF Committers.
What I have been seeing from valuable responses to the original thread so
far is that, a number of frameworks already felt the need and addressed it.
However implementations seemed to be confined into the projects implementing
them.
I would like to re-iterate what I aim at: "EMF Builder's intention is to
centralize the validation, consolidation and code generation right on top
EMF Core [4]." It is not my intent to implement a new validation framework,
code generation framework nor anything similar. Rather the intent is to push
such facilities down to EMF core so that
i) it is reusable to the maximum possible extend by downstream projects
ii) Address a need (At least the need I felt - which is the whole
motivation for the last two weeks) for IDE-like features for EMF Core by
extending and gluing pieces that are already existent.
iii) providing extension point for downstream projects to tap in with
their own implementation of code build integration, validation and
generation at last...
The 0.1.0-beta release includes
i) A "Dependency Manager" that tracks *all* EMF resource dependencies
exist in the workspace.
ii) A Custom Builder that kicks in the actual validation, generation
providers
iii) Three extension points to extend and throw in content types to add to
dependency tracking, validation provision and code generation provision
iv) EMF Core validation and Generation bridges to the extesion point #2 &
#3 in (iii)
v) A Sample implementation of to bridge GMF code generation in to EBM
As so far ideas on where to place EBM and reuse what exists so far is
flying, I decided wait until an official "go for it!" and well defined goals
to continue.
It may be the case that, EBM could be a crappy idea altogether, that's an
answer as well, which I desperately need now.
[1] http://en.wikipedia.org/wiki/Should_I_Stay_or_Should_I_Go
[2] http://www.youtube.com/watch?v=0Ag8J2NMYmc
[3] http://ebm.batoo.org
[4] http://ebm.batoo.org/index.php/Proposal
Regards,
--
Hasan Ceylan
|
|
|
| Re: "Should I stay or should I go!" [message #513412 is a reply to message #513392] |
Wed, 10 February 2010 05:48  |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Hasan,
I don't really know the functionality of the other projects in this area but I like the idea to have this 'auto-build'
available on EMF core. I am also interested to make use of/extend it in the projects I am doing.
From my point of view I would say: stay or for sure continue and give your solution some more time to get traction.
I will surely try out your solution and give feedback if I have any.
gr. Martin
Hasan Ceylan wrote:
> Hello,
>
> I remembered that I haven't listened to the classical song I like lately [1]
> [2].
>
> As some of you are well aware, I have been investing in some time to a
> generalized IDE-like build, validation, and code generation for EMF models
> so far.
>
> I felt the need to write this post up as I have come to a point where I am
> paralyzed.
>
> I have sent the original mail to the newsgroup on February the 1st. On one
> hand, I have been receiving very encouraging comments and directions from a
> number of parties, on the other hand after 10 days and 150 hours of work and
> one release [3] with great motivation, I also get comments like "this
> already exists."
>
> I am at total loss and awaiting for advises from Eclipse Officials and
> fellow EMF Committers.
>
> What I have been seeing from valuable responses to the original thread so
> far is that, a number of frameworks already felt the need and addressed it.
> However implementations seemed to be confined into the projects implementing
> them.
>
> I would like to re-iterate what I aim at: "EMF Builder's intention is to
> centralize the validation, consolidation and code generation right on top
> EMF Core [4]." It is not my intent to implement a new validation framework,
> code generation framework nor anything similar. Rather the intent is to push
> such facilities down to EMF core so that
> i) it is reusable to the maximum possible extend by downstream projects
> ii) Address a need (At least the need I felt - which is the whole
> motivation for the last two weeks) for IDE-like features for EMF Core by
> extending and gluing pieces that are already existent.
> iii) providing extension point for downstream projects to tap in with
> their own implementation of code build integration, validation and
> generation at last...
>
> The 0.1.0-beta release includes
> i) A "Dependency Manager" that tracks *all* EMF resource dependencies
> exist in the workspace.
> ii) A Custom Builder that kicks in the actual validation, generation
> providers
> iii) Three extension points to extend and throw in content types to add to
> dependency tracking, validation provision and code generation provision
> iv) EMF Core validation and Generation bridges to the extesion point #2 &
> #3 in (iii)
> v) A Sample implementation of to bridge GMF code generation in to EBM
>
> As so far ideas on where to place EBM and reuse what exists so far is
> flying, I decided wait until an official "go for it!" and well defined goals
> to continue.
>
>
> It may be the case that, EBM could be a crappy idea altogether, that's an
> answer as well, which I desperately need now.
>
> [1] http://en.wikipedia.org/wiki/Should_I_Stay_or_Should_I_Go
> [2] http://www.youtube.com/watch?v=0Ag8J2NMYmc
> [3] http://ebm.batoo.org
> [4] http://ebm.batoo.org/index.php/Proposal
>
> Regards,
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: "Should I stay or should I go!" [message #513432 is a reply to message #513392] |
Wed, 10 February 2010 08:25 |
|
Hi Hasan,
Please stay! I think it's the PMC's task to coordinate projects and
provide guidance to the community as to which projects do what and the
like. Like Martin, I can not judge where there is overlap with existing
projects, but I could not find any usable tool in this area that I can
install from the release train repository. The goal should be to have
such a tool consumable from there. If there is currently none, why
shouldn't you be the first one to provide it from there? Of course it
should also be in your own interest to see overlap, or better synergy
potential, with other projects. And do expect a lot of overhead work to
be necessary to be part of the release train. Lots of nasty and
unthankful effort! But being on the train is awfully helpful in becoming
a successful project ;-)
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 10.02.2010 00:27, schrieb Hasan Ceylan:
> Hello,
>
> I remembered that I haven't listened to the classical song I like lately [1]
> [2].
>
> As some of you are well aware, I have been investing in some time to a
> generalized IDE-like build, validation, and code generation for EMF models
> so far.
>
> I felt the need to write this post up as I have come to a point where I am
> paralyzed.
>
> I have sent the original mail to the newsgroup on February the 1st. On one
> hand, I have been receiving very encouraging comments and directions from a
> number of parties, on the other hand after 10 days and 150 hours of work and
> one release [3] with great motivation, I also get comments like "this
> already exists."
>
> I am at total loss and awaiting for advises from Eclipse Officials and
> fellow EMF Committers.
>
> What I have been seeing from valuable responses to the original thread so
> far is that, a number of frameworks already felt the need and addressed it.
> However implementations seemed to be confined into the projects implementing
> them.
>
> I would like to re-iterate what I aim at: "EMF Builder's intention is to
> centralize the validation, consolidation and code generation right on top
> EMF Core [4]." It is not my intent to implement a new validation framework,
> code generation framework nor anything similar. Rather the intent is to push
> such facilities down to EMF core so that
> i) it is reusable to the maximum possible extend by downstream projects
> ii) Address a need (At least the need I felt - which is the whole
> motivation for the last two weeks) for IDE-like features for EMF Core by
> extending and gluing pieces that are already existent.
> iii) providing extension point for downstream projects to tap in with
> their own implementation of code build integration, validation and
> generation at last...
>
> The 0.1.0-beta release includes
> i) A "Dependency Manager" that tracks *all* EMF resource dependencies
> exist in the workspace.
> ii) A Custom Builder that kicks in the actual validation, generation
> providers
> iii) Three extension points to extend and throw in content types to add to
> dependency tracking, validation provision and code generation provision
> iv) EMF Core validation and Generation bridges to the extesion point #2&
> #3 in (iii)
> v) A Sample implementation of to bridge GMF code generation in to EBM
>
> As so far ideas on where to place EBM and reuse what exists so far is
> flying, I decided wait until an official "go for it!" and well defined goals
> to continue.
>
>
> It may be the case that, EBM could be a crappy idea altogether, that's an
> answer as well, which I desperately need now.
>
> [1] http://en.wikipedia.org/wiki/Should_I_Stay_or_Should_I_Go
> [2] http://www.youtube.com/watch?v=0Ag8J2NMYmc
> [3] http://ebm.batoo.org
> [4] http://ebm.batoo.org/index.php/Proposal
>
> Regards,
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | | | | |
| Re: "Should I stay or should I go!" [message #513493 is a reply to message #513392] |
Wed, 10 February 2010 07:04 |
Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
Hasan,
Comments below.
Hasan Ceylan wrote:
> Hello,
>
> I remembered that I haven't listened to the classical song I like lately [1]
> [2].
>
> As some of you are well aware, I have been investing in some time to a
> generalized IDE-like build, validation, and code generation for EMF models
> so far.
>
> I felt the need to write this post up as I have come to a point where I am
> paralyzed.
>
> I have sent the original mail to the newsgroup on February the 1st. On one
> hand, I have been receiving very encouraging comments and directions from a
> number of parties, on the other hand after 10 days and 150 hours of work and
> one release [3] with great motivation, I also get comments like "this
> already exists."
>
There's a lot of overlap in the modeling projects, e.g., three template
engines, two of which (JET and XPand) come in two versions. Overlap is
not ideal, but nothing prevents it.
> I am at total loss and awaiting for advises from Eclipse Officials and
> fellow EMF Committers.
>
You've seen the advice. We like participants.
> What I have been seeing from valuable responses to the original thread so
> far is that, a number of frameworks already felt the need and addressed it.
> However implementations seemed to be confined into the projects implementing
> them.
>
Yes, and that's not ideal. None of the projects currently containing it
really have a well defined scope being a builder project. Even the
index project, which should fundamentally be reusable like EMF core
should perhaps just be an underpinning for the dependency analysis part
of a builder project rather than becoming a builder project.
> I would like to re-iterate what I aim at: "EMF Builder's intention is to
> centralize the validation, consolidation and code generation right on top
> EMF Core [4]."
It's certainly a more well define scope than some of the more sweeping
project proposals that come, not to mention projects with creeping
feature scope...
> It is not my intent to implement a new validation framework,
> code generation framework nor anything similar. Rather the intent is to push
> such facilities down to EMF core so that
> i) it is reusable to the maximum possible extend by downstream projects
>
Yes, to me this is the most fundamental goal.
> ii) Address a need (At least the need I felt - which is the whole
> motivation for the last two weeks) for IDE-like features for EMF Core by
> extending and gluing pieces that are already existent.
>
Proper integration of existing pieces and a new layer of important
capability...
> iii) providing extension point for downstream projects to tap in with
> their own implementation of code build integration, validation and
> generation at last...
>
It sounds like you pretty much have the scope well define for a project
proposal.
> The 0.1.0-beta release includes
> i) A "Dependency Manager" that tracks *all* EMF resource dependencies
> exist in the workspace.
>
We should have discussions about how this ought to leverage the index
project. I believe that both Query and Xtext embed their own versions
of Index within their projects when what we really need is a separate
reusable version. If other projects have builder framework type stuff,
stuff that's generally reusable, then it to ought to be moved to a more
generally reusable place.
> ii) A Custom Builder that kicks in the actual validation, generation
> providers
> iii) Three extension points to extend and throw in content types to add to
> dependency tracking, validation provision and code generation provision
> iv) EMF Core validation and Generation bridges to the extesion point #2 &
> #3 in (iii)
> v) A Sample implementation of to bridge GMF code generation in to EBM
>
> As so far ideas on where to place EBM and reuse what exists so far is
> flying, I decided wait until an official "go for it!" and well defined goals
> to continue.
>
Personally I think a separate project would be good; something that will
reuse the index project. I expect other folks with existing overlapping
technology would want to join and be involved in that new builder
project. Does anyone have opinions to the contrary?
>
> It may be the case that, EBM could be a crappy idea altogether, that's an
> answer as well, which I desperately need now.
>
You've had an existential crisis. Get over it. :-P
> [1] http://en.wikipedia.org/wiki/Should_I_Stay_or_Should_I_Go
> [2] http://www.youtube.com/watch?v=0Ag8J2NMYmc
> [3] http://ebm.batoo.org
> [4] http://ebm.batoo.org/index.php/Proposal
>
> Regards,
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: "Should I stay or should I go!" [message #513495 is a reply to message #513392] |
Wed, 10 February 2010 07:04 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Hasan Ceylan wrote:
>
> I remembered that I haven't listened to the classical song I like lately [1]
> [2].
>
> As some of you are well aware, I have been investing in some time to a
> generalized IDE-like build, validation, and code generation for EMF models
> so far.
>
> I felt the need to write this post up as I have come to a point where I am
> paralyzed.
I understand the feeling, as I've several time discovered other,
relevant work and had to decide between 1) going for my own idea and
implementation, 2) integrating with an existing (and newly discovered)
implementation, or 3) throwing my own work away and going for the other.
Whatever the decision, the good thing is that by having tried on your
own and being able to analyze others' work, you should have enough
knowledge to 1) gather the relevant set of requirements and 2) identify
alternative solutions. Although your own initial code may end up being
less useful, the knowledge you gained from the process is very valuable!
I suggest two moves at this point:
- gather requirements, based on your own work and what the others' have
implemented
- get an overview of the various solutions that exist for fulfilling
these requirements
Then you should be able to prepare a new release, possibly as a mix of
your and others' code.
Hallvard
|
|
| |
| Re: "Should I stay or should I go!" [message #513551 is a reply to message #513514] |
Wed, 10 February 2010 14:40 |
Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
Vlad,
I really would prefer that your spend all of your free time with a
Google phone, or anything else that will eliminate your need to share
your poisonous nonconstructive ramblings in our newsgroups.
Vlad Varnica wrote:
> Quote:
>> Dear Vlad,
>>
>> First of all, I didn't break down and cried. I am sure that the the main
>> subject of this thread is well taken by a vast majority of the followers
>> that - being a newcomer into Eclipse Kitchen - I needed directions.
>> This is to make sure I continue with the idea in the most effective
>> manner and also to make sure not to make what's already available in
>> a number of places obsolete altogether - as I value the time invested
>> in other stuff. Second of all, I do not see any aspect in my posting
>> that relates to financial matters, but I do appreciate you sharing
>> you experiences. Not but not the least, rather then waiting for a
>> year, I expect to be on the 3.6 release train which is due in a
>> couple of months and prepared to put in what it takes to get there.
>
>
> It seems to me that you have great personal potential. You should
> therefore carefully select a new technology which has high potential.
> I think that EMF with 10 years is now a very mature project and before
> any new development you fisrt need to invest in understanding the
> existing plugins. In my experience you need at least 12 months of full
> practice to become an EMF plugin architect/developer. Once you have
> reached this level then you can develop your own plugin. Developing
> your own plugin before reaching this stage is a waste of time.
>
> For myself I am more and more disapointed by Eclipse modeling and
> prefer on my free time look at google phone than EMF. My personal
> recommendation is to move to mobile, green or cloud technologies
> because I am afraid to say that modeling is slowly dying....
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
| Re: "Should I stay or should I go!" [message #513764 is a reply to message #513637] |
Thu, 11 February 2010 08:05 |
Sven Efftinge
Messages: 1823
Registered: July 2009 |
Senior Member |
|
|
Hi Hasan,
thanks for not giving up. I think it's important to have some discussion
to find out where, if and how a new idea should be implemented in EMP.
Don't take it personally, we're all working hard, have good ideas and
are proud of it :-)
Note, that we decided to leave the builder we eventually want to put
into EMF Index within Xtext for Helios.
So please look at the code in Xtext, the interesting bundle is
org.eclipse.xtext.builder and the corresponding test bundle
(org.eclipse.xtext.builder).
Also note that in Xtext we have slightly different requirements to how a
dependency analysis is done, because with textual languages you
typically link via name and not via qualified URI. So we need to know
about the names of the elements within the different resources.
The dependency analysis is based on that, however each resource service
provider can have it's own notion of how dependencies are calculated.
Also we have things like "open model element" or "find references"
implemented based on that data. The builder bundle currently has
dependencies to Xtext which we want to remove, so that it can be used
without it. Another nice thing is that there's a dirty state layer on
top of the index. So if you do e.g. "open model element" you'll have any
unsaved state reflected.
I have looked at your code, and I think that the builder infrastructure
of Xtext does what you need. Should be straight forward to register the
EMF and GMF generation as an IBuilderParticipant.
I don't think that the actual EMF (or GMF) specific implementation
(triggering the generator) should be part of EMF Index. So maybe it
might be a good idea to focus on those aspects in the scope of your
project proposal.
Cheers,
Sven
Hasan Ceylan schrieb:
> Hello,
>
> I thank everyone who sent very constructive replies.
>
> I think the outcome is I should get closer with Sven's team to make use of
> what's existing in EMF Index and compliment EMF Index for what's missing for
> EBM.
>
> I'll study EMF Index for some time, then consolidate EBM Dependency Manager
> into EMF Index.
>
> PS: For the record, I'm far from being a lad :( (36 years old)
>
> Regards,
> Hasan
>
> Hasan Ceylan wrote:
>
>> Hello,
>>
> [...]
>> I am at total loss and awaiting for advises from Eclipse Officials and
>> fellow EMF Committers.
>>
> [...]
>> Hasan
--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
|
|
|
Goto Forum:
Current Time: Wed Sep 25 17:15:10 GMT 2024
Powered by FUDForum. Page generated in 0.05501 seconds |
] 
Search
Help
Register
Login
Home
