[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [modeling-pmc] Re: [emft-dev] Proposal for Texo Component
|
Christian,
One could, and if they wanted to argue that and to host it there, they
could ask. The proposal was announced on one of their mailing lists and
they didn't ask. I'm not sure there's much spring focus in WTP... And
keep in mind that even things like XSD are in modeling, so I doubt their
concerned about their scope being infringed. It's clear that the primary
focus here is on modeling...
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 313)
Christian
Damus/Ottawa/IBM@
IBMCA To
Sent by: EMFT Developer Mailing List
emft-dev-bounces@ <emft-dev@xxxxxxxxxxx>
eclipse.org cc
PMC members mailing list
<modeling-pmc@xxxxxxxxxxx>
04/16/2008 09:18 Subject
AM Re: [modeling-pmc] Re: [emft-dev]
Proposal for Texo Component
Please respond to
EMFT Developer
Mailing List
<emft-dev@eclipse
.org>
Hi,
Can one also make an argument for locating this component in the Web Tools
Platform project? It seems to me that Texo is more of a model-driven web
application development tool (and WTP is all about developing web apps)
than it is a framework for building modeling tools or even a big-M modeling
app.
Cheers,
Christian
Christian W. Damus
Component Lead, Eclipse OCL and EMF MQ/MT/VF
IBM Rational Software
From: Ed Merks/Toronto/IBM@IBMCA
To: PMC members mailing list <modeling-pmc@xxxxxxxxxxx>
Cc: modeling-pmc-bounces@xxxxxxxxxxx, EMFT Developer Mailing List
<emft-dev@xxxxxxxxxxx>, PMC members mailing list
<modeling-pmc@xxxxxxxxxxx>
Date: 04/16/2008 09:04 AM
Subject: Re: [modeling-pmc] Re: [emft-dev] Proposal for Texo Component
Sven,
Once-only code generators really do suck, so you have to wonder at their
preponderance given how relatively trivial it was to build Java merge
support. The original design and implementation of JMerge took roughly a
week of effort, as a I recall. EMP is definitely a great basis for
building DSLs with the added benefit that they all have a common underlying
meta model to ensure that we don't end up with just a Tower of Babel. In
addition, we aren't suffering from the misguided belief that XML syntax is
the be-all-and-end-all of human readable notations.
In our quest toward a grand vision, I think it's best to start small and to
build the little pieces bottom rather than carve out a grand high level
space top down. We also have to consider our project's charter and be
sensitive to the concerns that the scope of the modeling project could just
creep out to consume all other projects. Many DSLs would most logically
live in other projects and we'd be best off to ensure that things evolve in
that direction when it makes the most sense. So for the time being, I'd
rather avoid creating more direct child projects under the modeling
project. Having a small number of projects to group the large number of
components seems appropriate...
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 313)
Sven Efftinge
<sven@xxxxxxxxxxx
> To
Sent by: EMFT Developer Mailing List
modeling-pmc-boun <emft-dev@xxxxxxxxxxx>, PMC members
ces@xxxxxxxxxxx mailing list
<modeling-pmc@xxxxxxxxxxx>
cc
04/16/2008 07:12
AM Subject
[modeling-pmc] Re: [emft-dev]
Proposal for Texo Component
Please respond to
PMC members
mailing list
<modeling-pmc@ecl
ipse.org>
Hi all,
this sounds very cool. We all know that there are many general
frameworks (web, RCP, SOA, etc,) out there which would profit from
generators.
Some of them (Ruby on Rails, Grails, SEAM just to name a few) already
use code generation a lot.
Unfortunately they use wizard-style passive code generation, where you
generate once and further change the generated code manually.
So most of the time generators are just used to get users up and
running as fast as possible.
Also they come up with concise languages to descibe domain models
(internal DSLs).
Those languages are not statically typed, have to fit into the host's
syntax and have no tool support at all (EMP can do better).
IMHO there should be some more projects like Texo, which show how EMP
can be used.
As EMFT is for EMF technology I find that those projects don't fit
well there. We should create a new Project for such domain-specific
applications of EMP.
What do you think?
atb,
Sven
btw: +1
On Apr 16, 2008, at 12:34 , Ed Merks wrote:
>
> Extended EMF Community,
>
> Martin Taal, the lead for the Teneo component, recently announced his
> intent to work on the Texo component which will focus on exploiting
> modeling technology for building web applications.
>
> http://wiki.eclipse.org/Texo
>
> I request the community's approval to create this new component as
> part of
> the EMFT subproject with Martin Taal as the component lead. Please
> reply
> with +1 or -1 on this thread. Obviously I recommend you give a +1,
> given
> Martin's outstanding track record with Teneo and his exemplary
> support for
> it. All EMF and EMFT committers are eligible to vote, so please
> take a
> moment to do so.
>
>
> Ed Merks/Toronto/IBM@IBMCA
> mailto: merks@xxxxxxxxxx
> 905-413-3265 (t/l 313)
>
>
> _______________________________________________
> emft-dev mailing list
> emft-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/emft-dev
--
Sven Efftinge
Phone: +49 431 5606335
Fax : +49 431 5606339
Mobile: +49 175 5274726
web: http://www.itemis.de
blog: http://effi-blog.blogspot.com
team-blog: http://apps.itemis.de/roller/itemislabkiel
mail: sven.efftinge@xxxxxxxxx
xing: https://www.xing.com/profile/Sven_Efftinge
itemis AG
Schauenburgerstraße 116
24118 Kiel
Germany
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek
Aufsichtsrat: Dr. Burkhard Igel(Vors.), Stephan Grollmann, Michael
Neuhaus
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
_______________________________________________
emft-dev mailing list
emft-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emft-dev
_______________________________________________
emft-dev mailing list
emft-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emft-dev