[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [gmf-dev] Tiger GMF Transformation
|
Hi GMF Team,
many thanks, Artem, for your deeper look into our GMF model changes for
the GMFtrans extension.
We discussed this in the group and you are absolutely right that this
could be done much easier.
Anyhow we are expecting major modifications in the GMFtrans model
extensions due to major model changes between GMF2.0M3 and the current
GMF version.
The solution to provide gmfmap->gmfgen transformation extensions sounds
interesting. A general way to extend GMF capabilities is really needed
for the community. Could you provide further information (or even better
a tutorial or wiki page for the community) how to develop such
extensions? Moreover, we have changes in the Tooling model (for rule
entries in the editor palette) and extensions in the GMF dashboard.
Integrating most of the GMFtrans model changes into our .emt model (EMF
Transformer Model) would mean that we have to come up with a specific
version of EMT for GMF. Is this your intension? This would imply that we
have to contribute the specific EMT version directly in the GMF "SDK+".
Best wishes,
Karsten
Artem Tikhomirov schrieb:
> Hi,
>
> Let me share few thoughts regarding what I've grasped from the document. My main focus were changes to the GMF models, as these are essential, and UI aspects are quite easy to accommodate to specific needs.
>
> 1. The idea behind gmftool::TransRuleApplicationTool is not clear to me. If I'm not mistaken, it's the only tool that might be specified for the gmfmap::TransRuleMapping, hence, these two are mostly serving needs of each other, rather than represent some concept.
>
> 2. gmfmap::TransRuleMapping is merely a way to reference transformation rule. GMFMap was intended to link various aspects of domain model with tooling and graphical elements, while TransRuleMapping doesn't really maps anything but the rule with a tool (which I belive is restricted to specific variety, TransRuleApplicationTool only, see #1 above). Besides, it's not clear where TransRuleMapping resides, i.e. if it is canvas mapping or node mapping or smth else that is its owner.
>
> 3. gmfgen::TransRuleToolEntry seems to hold attributes that might be sufficiently covered with gmfgen::ToolEntry, though, without complete understaning of its use it's pure guess.
>
> To me, this combination of extra elements looks like bit overcomplicated. I wonder if all the information from TransRuleApplicationTool and TransRuleMapping can be kept in the .emt model itself? This model would reference particular elements of the gmfmap, if needed (not sure there's such a need, though), and would get transformed into either TransRuleToolEntry or regular ToolEntry (if found sufficient) as an extra step during gmfmap->gmfgen transformation. Such solution would be simpler to grasp and also quite "confined", so that would be easily pluggable from the "SDK+" as we agreed earlier. With that, it would be quite an examplary tool to show ways to extend gmf capabilities.
>
> Best wishes,
> Artem Tikhomirov
>
>
>
>> -----Original Message-----
>> From: gmf-dev-bounces@xxxxxxxxxxx
>> [mailto:gmf-dev-bounces@xxxxxxxxxxx] On Behalf Of Karsten Ehrig
>> Sent: Thursday, September 20, 2007 4:37 PM
>> To: GMF Project developer discussions.
>> Subject: Re: [gmf-dev] Tiger GMF Transformation
>>
>> Hi GMF Team,
>>
>> I've attached a PDF file with an overview of model and wizard
>> changes (mainly screen shots) of the GMFtrans extension, as
>> discussed in the last developer call.
>>
>> Please let me know if this is helpful and what further
>> description do you need.
>>
>> Best wishes,
>> Karsten
>>
>> Richard Gronback wrote:
>>
>>> Hi Karsten,
>>>
>>> Thanks for the additional info. I've added this to our GMF
>>>
>> Dev call
>>
>>> agenda for tomorrow's call: http://wiki.eclipse.org/GMF_Dev_Calls
>>>
>>> It would be helpful if you could join and discuss in more detail.
>>>
>>> Thanks,
>>> Rich
>>>
>>>
>>> On 9/10/07 8:36 AM, "Karsten Ehrig"
>>>
>> <karstene@xxxxxxxxxxxxxxx> wrote:
>>
>>>> Hi Richard,
>>>>
>>>> I've attached a PDF file describing an overview of the changes.
>>>>
>>>> Here are answers to your questions below:
>>>> 1. No API changes required
>>>> 2. GMFtrans uses JET (as in GMF2.0M3) while GMF2.0 uses XPand.
>>>> There are only some changes in a few number of GMF templates.
>>>> JET is also used by the Tiger EMF Transformer.
>>>> 3. no 3rd part libraries involved (we would only consider
>>>>
>> the Tiger
>>
>>>> EMF Compiler for contribution).
>>>>
>>>> Best wishes,
>>>> Karsten
>>>>
>>>> Richard Gronback wrote:
>>>>
>>>>> Hi Karsten,
>>>>>
>>>>> Perhaps an overview of what was changed could be
>>>>>
>> provided? Based on
>>
>>>>> the PSF file you provide on the website, it seems both
>>>>>
>> the tooling
>>
>>>>> and runtime components of GMF have been altered. It's tough to
>>>>> consider any contribution without a clear understanding of the
>>>>> impact it represents to the current code base. Pulling
>>>>>
>> modified GMF
>>
>>>>> sources from your repository doesn't make it easy to determine.
>>>>> Patches are the typical "Eclipse way" of providing
>>>>>
>> contributions of this nature.
>>
>>>>> Some important questions we'd need answered are:
>>>>>
>>>>> 1. Are there API changes required for this contribution
>>>>>
>> to be accepted?
>>
>>>>> 2. Could the addition of Tiger functionality be
>>>>>
>> accomplished using
>>
>>>>> the current extensibility options (model
>>>>>
>> extension/decoration, Xpand
>>
>>>>> template overrides/aspects, etc.)? What changes could we make to
>>>>> allow for Tiger to be added in this manner?
>>>>> 3. Finally, just to be explicitly clear about 3rd party libraries
>>>>> used, nothing outside the EMF Transformer code also being
>>>>>
>> considered
>>
>>>>> for contribution is utilized?
>>>>>
>>>>> Thanks again,
>>>>> Rich
>>>>>
>>>>>
>>>>> On 9/4/07 4:11 PM, "Karsten Ehrig"
>>>>>
>> <karstene@xxxxxxxxxxxxxxx> wrote:
>>
>>>>>> Hi Richard,
>>>>>>
>>>>>> up to now, we support Eclipse3.3M2 and GMF2.0M3.
>>>>>>
>> Adapting the code
>>
>>>>>> to the released 2.0 stream requires lots of changes
>>>>>>
>> which we like
>>
>>>>>> to do only if you definitely consider a contribution. In
>>>>>>
>> this case
>>
>>>>>> we would be also glad to discuss a contribution of the related
>>>>>> Tiger EMF Transformer code to EMF or EMFT.
>>>>>>
>>>>>> Best wishes,
>>>>>> Karsten
>>>>>>
>>>>>>
>>>>>> Richard Gronback wrote:
>>>>>>
>>>>>>> Hi Karsten,
>>>>>>>
>>>>>>> And what is the progress on becoming part of GMT? We'd
>>>>>>>
>> not likely
>>
>>>>>>> introduce a dependency from GMF to a component in GMT; that is,
>>>>>>> outside of something we'd include in our "experimental" SDK.
>>>>>>>
>>>>>>> I'd be helpful to assess the impact of the changes
>>>>>>>
>> you've made if
>>
>>>>>>> a patch were attached to a bugzilla using the released
>>>>>>>
>> 2.0 stream code base.
>>
>>>>>>> Thanks,
>>>>>>> Rich
>>>>>>>
>>>>>>>
>>>>>>> On 8/31/07 4:37 PM, "Karsten Ehrig"
>>>>>>>
>> <karstene@xxxxxxxxxxxxxxx> wrote:
>>
>>>>>>>> Hi Richard,
>>>>>>>>
>>>>>>>> in fact we already got an invitation from Jean Bezivin to join
>>>>>>>> GMT with the Tiger EMF Transformation Project (short EMT).
>>>>>>>>
>>>>>>>> Maybe EMT could be also used in the GMF generator:
>>>>>>>>
>>>>>>>> "Like in EMF, the GMF Generator model can be automatically
>>>>>>>> created from high-level models. Unlike in EMF, GMF
>>>>>>>>
>> significantly
>>
>>>>>>>> reorganizes the diagram description while creating Generator
>>>>>>>> model. The transformation from high-level GMF models
>>>>>>>>
>> to Generator
>>
>>>>>>>> model is not one-to-one transformation like in EMF, so more
>>>>>>>> powerful techniques are used here. Currently this
>>>>>>>>
>> transformation
>>
>>>>>>>> is hand coded in Java classes, while some model-to-model
>>>>>>>> transformation techniques could be used there in the future."
>>>>>>>>
>>>>>>>>
>> (http://www.eclipsecon.org/summiteurope2006/presentations/ESE2006
>>
>>>>>>>> -EclipseM
>>>>>>>> od
>>>>>>>> el
>>>>>>>> ingSymposium15_GMF.pdf)
>>>>>>>>
>>>>>>>> Best wishes,
>>>>>>>> Karsten
>>>>>>>>
>>>>>>>> Richard Gronback wrote:
>>>>>>>>
>>>>>>>>> Hi Karsten,
>>>>>>>>>
>>>>>>>>> I'm just starting to take a look at this, and
>>>>>>>>>
>> wondered if there
>>
>>>>>>>>> were plans to contribute the dependent EMF Transformation
>>>>>>>>> Project code to EMF (or EMFT)? I see it's all released under
>>>>>>>>> EPL, or are there additional libraries that have another
>>>>>>>>> license?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Rich
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 8/20/07 10:50 AM, "Karsten Ehrig"
>>>>>>>>>
>> <karstene@xxxxxxxxxxxxxxx> wrote:
>>
>>>>>>>>>> Hi Richard,
>>>>>>>>>>
>>>>>>>>>> great, that we are still involved.
>>>>>>>>>>
>>>>>>>>>> A user and developer documentation for our extension is now
>>>>>>>>>> available
>>>>>>>>>> at:
>>>>>>>>>> http://tfs.cs.tu-berlin.de/emftrans/gmftrans/userdoc.pdf
>>>>>>>>>>
>>>>>>>>>> Moreover a ZIP bundle containing all projects and a
>>>>>>>>>>
>> project set
>>
>>>>>>>>>> file for source code installation from the CVS
>>>>>>>>>>
>> repositories is available at:
>>
>>>>>>>>>> http://tfs.cs.tu-berlin.de/emftrans/gmftrans/
>>>>>>>>>>
>>>>>>>>>> Up to now, we do require Eclipse3.3M2 and GMF2.0M3. This is
>>>>>>>>>> because the extension is mostly implemented as
>>>>>>>>>>
>> patch/extension
>>
>>>>>>>>>> for the described versions.
>>>>>>>>>>
>>>>>>>>>> Please let us know your opinion about the current
>>>>>>>>>>
>> version. Is
>>
>>>>>>>>>> there a chance to integrate the Tiger GMF
>>>>>>>>>>
>> Transformation in GMF 3.0?
>>
>>>>>>>>>> If you consider a contribution we are happy to help with
>>>>>>>>>> adapting the code to the current GMF version.
>>>>>>>>>>
>>>>>>>>>> Best wishes,
>>>>>>>>>> Karsten (on behalf of the Tiger developer team)
>>>>>>>>>>
>>>>>>>>>> Richard Gronback wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Karsten,
>>>>>>>>>>>
>>>>>>>>>>> Sure, we remember! I'll give the latest a try.
>>>>>>>>>>>
>> The last time
>>
>>>>>>>>>>> I tried, it was a rather involved configuration.
>>>>>>>>>>>
>>>>>>>>>>> Any chance some of the documents on the website are
>>>>>>>>>>>
>> translated
>>
>>>>>>>>>>> to English?
>>>>>>>>>>> ;)
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Rich
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 7/19/07 1:46 AM, "Karsten Ehrig"
>>>>>>>>>>>
>> <karstene@xxxxxxxxxxxxxxx> wrote:
>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Dear Team,
>>>>>>>>>>>>
>>>>>>>>>>>> hopefully you remember our group from the kick-off meeting
>>>>>>>>>>>> where we promised to implement complex editor
>>>>>>>>>>>>
>> operation support in GMF.
>>
>>>>>>>>>>>> Andre Crema and Rene Schmutzler completed this
>>>>>>>>>>>>
>> work in their
>>
>>>>>>>>>>>> diploma thesis for GMF 2.0M3:
>>>>>>>>>>>> http://tfs.cs.tu-berlin.de/emftrans/gmftrans/
>>>>>>>>>>>> http://tfs.cs.tu-berlin.de/emftrans/gmftrans/downloads/
>>>>>>>>>>>>
>>>>>>>>>>>> Please let us know whether there is still a need
>>>>>>>>>>>>
>> or a chance
>>
>>>>>>>>>>>> to integrate this extension in GMF.
>>>>>>>>>>>>
>>>>>>>>>>>> Best wishes,
>>>>>>>>>>>> Karsten
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> gmf-dev mailing list
>>>>>>>>>>>> gmf-dev@xxxxxxxxxxx
>>>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/gmf-dev
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> gmf-dev mailing list
>>>>>>>>>> gmf-dev@xxxxxxxxxxx
>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/gmf-dev
>>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> gmf-dev mailing list
>>>>>>>> gmf-dev@xxxxxxxxxxx
>>>>>>>> https://dev.eclipse.org/mailman/listinfo/gmf-dev
>>>>>>>>
>>>>>> _______________________________________________
>>>>>> gmf-dev mailing list
>>>>>> gmf-dev@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/gmf-dev
>>>>>>
>>>> _______________________________________________
>>>> gmf-dev mailing list
>>>> gmf-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/gmf-dev
>>>>
> _______________________________________________
> gmf-dev mailing list
> gmf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/gmf-dev
>
