Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [Announce] New EMFT Subproject: Transaction 
| [Announce] New EMFT Subproject: Transaction [message #9839] | 
Wed, 04 January 2006 09:25   | 
 
Eclipse User  | 
 | 
 | 
   | 
 
Originally posted by: cdamus.ca.ibm.com 
 
A new sub-project of EMFT is created and the initial code base committed, 
named Transaction (a.k.a. EMF-TX).  It consists of two layered APIs:  a 
base layer providing a transactional editing domain (TXEditingDomain) and a 
workbench integration layer that bridges the TXEditingDomain with the 
operation history API in Eclipse runtime and, to a lesser extent, the 
workspace API. 
 
For more details, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=113708. 
 
Note that builds are not yet available, but should be coming soon.  For now, 
the code can be checked out from CVS in the org.eclipse.emft/transaction 
module of the technology repository.
 |  
 |  
  |  
| Re: [Announce] New EMFT Subproject: Transaction [message #9884 is a reply to message #9839] | 
Thu, 05 January 2006 16:26    | 
 
Eclipse User  | 
 | 
 | 
   | 
 
When you say "operation history API in Eclipse runtime", do you mean this is  
migrating to the shared Eclipse command stack APIs, and moving away from the  
EMF command stack and GMF CommandManager?  I've been trying to sort out the  
GMF command history stacks for undo/redo support this past week, and found  
it very confusing with the variety of command APIs used by these different  
components. 
 
Thanks, 
  Dave Carlson 
 
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message  
news:dpgltu$t9s$1@utils.eclipse.org... 
> 
> A new sub-project of EMFT is created and the initial code base committed, 
> named Transaction (a.k.a. EMF-TX).  It consists of two layered APIs:  a 
> base layer providing a transactional editing domain (TXEditingDomain) and  
> a 
> workbench integration layer that bridges the TXEditingDomain with the 
> operation history API in Eclipse runtime and, to a lesser extent, the 
> workspace API. 
> 
> For more details, see  
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=113708. 
> 
> Note that builds are not yet available, but should be coming soon.  For  
> now, 
> the code can be checked out from CVS in the org.eclipse.emft/transaction 
> module of the technology repository. 
>
 |  
 |  
  |  
| Re: [Announce] New EMFT Subproject: Transaction [message #9974 is a reply to message #9884] | 
Fri, 06 January 2006 09:27    | 
 
Eclipse User  | 
 | 
 | 
   | 
 
Originally posted by: cdamus.ca.ibm.com 
 
Hi, Dave, 
 
Work is beginning on refactoring the GMF runtime onto this new EMF 
transaction API, to replace of the MEditingDomain and related APIs.  
Concomitant to this is the replacement of the GMF CommandManager with the 
OperationHistory.  Thus, GMF will end up using only one "stack" for 
"commands" (though I'm not sure about GEF plans for adopting the operation 
history). 
 
The EMFT Transaction project's basic editing domain implementation continues 
to use an EMF CommandStack to support applications that deploy in 
non-Eclipse environments (where there is no OperationHistory).  We also 
provide an editing domain whose command stack delegates to the operation 
history.  Or, you can use the OperationHistory directly as your command 
stack, bypassing the editing domain's stack.  Basically, we can't provide 
an editing domain without a command stack but we can provide one that works 
without it. 
 
Cheers, 
 
Christian 
 
 
Dave Carlson wrote: 
 
> When you say "operation history API in Eclipse runtime", do you mean this 
> is migrating to the shared Eclipse command stack APIs, and moving away 
> from the 
> EMF command stack and GMF CommandManager?  I've been trying to sort out 
> the GMF command history stacks for undo/redo support this past week, and 
> found it very confusing with the variety of command APIs used by these 
> different components. 
>  
> Thanks, 
>   Dave Carlson 
>  
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message 
> news:dpgltu$t9s$1@utils.eclipse.org... 
>> 
 
<snip>
 |  
 |  
  |  
| Re: [Announce] New EMFT Subproject: Transaction [message #9996 is a reply to message #9974] | 
Fri, 06 January 2006 10:24    | 
 
Eclipse User  | 
 | 
 | 
   | 
 
Hi Christian, 
 
Thanks much for your explanation.  I've not yet studied the eclipse  
operation history implementation (used only the EMF commands this past  
year).  But I will review the EMFT transactions and eclipse history. 
 
Do you expect this refactoring and adoption of  EMF-TX and OperationHistory  
to be complete by GMF 1.0 in June? 
 
Thanks, 
  Dave 
 
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message  
news:dpluqb$i8d$1@utils.eclipse.org... 
> 
> Hi, Dave, 
> 
> Work is beginning on refactoring the GMF runtime onto this new EMF 
> transaction API, to replace of the MEditingDomain and related APIs. 
> Concomitant to this is the replacement of the GMF CommandManager with the 
> OperationHistory.  Thus, GMF will end up using only one "stack" for 
> "commands" (though I'm not sure about GEF plans for adopting the operation 
> history). 
> 
> The EMFT Transaction project's basic editing domain implementation  
> continues 
> to use an EMF CommandStack to support applications that deploy in 
> non-Eclipse environments (where there is no OperationHistory).  We also 
> provide an editing domain whose command stack delegates to the operation 
> history.  Or, you can use the OperationHistory directly as your command 
> stack, bypassing the editing domain's stack.  Basically, we can't provide 
> an editing domain without a command stack but we can provide one that  
> works 
> without it. 
> 
> Cheers, 
> 
> Christian 
> 
> 
> Dave Carlson wrote: 
> 
>> When you say "operation history API in Eclipse runtime", do you mean this 
>> is migrating to the shared Eclipse command stack APIs, and moving away 
>> from the 
>> EMF command stack and GMF CommandManager?  I've been trying to sort out 
>> the GMF command history stacks for undo/redo support this past week, and 
>> found it very confusing with the variety of command APIs used by these 
>> different components. 
>> 
>> Thanks, 
>>   Dave Carlson 
>> 
>> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message 
>> news:dpgltu$t9s$1@utils.eclipse.org... 
>>> 
> 
> <snip>
 |  
 |  
  |  
| Re: [Announce] New EMFT Subproject: Transaction [message #10020 is a reply to message #9996] | 
Mon, 09 January 2006 09:36   | 
 
Eclipse User  | 
 | 
 | 
   | 
 
Originally posted by: cdamus.ca.ibm.com 
 
Hi, Dave, 
 
Bug 112826 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=112826) is 
tracking the GMF adoption of the operation history API, and is currently 
forecast for M5. 
 
Cheers, 
 
Christian 
 
 
Dave Carlson wrote: 
 
> Hi Christian, 
>  
> Thanks much for your explanation.  I've not yet studied the eclipse 
> operation history implementation (used only the EMF commands this past 
> year).  But I will review the EMFT transactions and eclipse history. 
>  
> Do you expect this refactoring and adoption of  EMF-TX and 
> OperationHistory to be complete by GMF 1.0 in June? 
>  
> Thanks, 
>   Dave 
>  
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message 
> news:dpluqb$i8d$1@utils.eclipse.org... 
 
<snip>
 |  
 |  
  |  
| Re: [Announce] New EMFT Subproject: Transaction [message #562474 is a reply to message #9839] | 
Thu, 05 January 2006 16:26   | 
 
Eclipse User  | 
 | 
 | 
   | 
 
When you say "operation history API in Eclipse runtime", do you mean this is  
migrating to the shared Eclipse command stack APIs, and moving away from the  
EMF command stack and GMF CommandManager?  I've been trying to sort out the  
GMF command history stacks for undo/redo support this past week, and found  
it very confusing with the variety of command APIs used by these different  
components. 
 
Thanks, 
  Dave Carlson 
 
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message  
news:dpgltu$t9s$1@utils.eclipse.org... 
> 
> A new sub-project of EMFT is created and the initial code base committed, 
> named Transaction (a.k.a. EMF-TX).  It consists of two layered APIs:  a 
> base layer providing a transactional editing domain (TXEditingDomain) and  
> a 
> workbench integration layer that bridges the TXEditingDomain with the 
> operation history API in Eclipse runtime and, to a lesser extent, the 
> workspace API. 
> 
> For more details, see  
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=113708 
> 
> Note that builds are not yet available, but should be coming soon.  For  
> now, 
> the code can be checked out from CVS in the org.eclipse.emft/transaction 
> module of the technology repository. 
>
 |  
 |  
  |  
| Re: [Announce] New EMFT Subproject: Transaction [message #562575 is a reply to message #9884] | 
Fri, 06 January 2006 09:27   | 
 
Eclipse User  | 
 | 
 | 
   | 
 
Originally posted by: cdamus.ca.ibm.com 
 
Hi, Dave, 
 
Work is beginning on refactoring the GMF runtime onto this new EMF 
transaction API, to replace of the MEditingDomain and related APIs.  
Concomitant to this is the replacement of the GMF CommandManager with the 
OperationHistory.  Thus, GMF will end up using only one "stack" for 
"commands" (though I'm not sure about GEF plans for adopting the operation 
history). 
 
The EMFT Transaction project's basic editing domain implementation continues 
to use an EMF CommandStack to support applications that deploy in 
non-Eclipse environments (where there is no OperationHistory).  We also 
provide an editing domain whose command stack delegates to the operation 
history.  Or, you can use the OperationHistory directly as your command 
stack, bypassing the editing domain's stack.  Basically, we can't provide 
an editing domain without a command stack but we can provide one that works 
without it. 
 
Cheers, 
 
Christian 
 
 
Dave Carlson wrote: 
 
> When you say "operation history API in Eclipse runtime", do you mean this 
> is migrating to the shared Eclipse command stack APIs, and moving away 
> from the 
> EMF command stack and GMF CommandManager?  I've been trying to sort out 
> the GMF command history stacks for undo/redo support this past week, and 
> found it very confusing with the variety of command APIs used by these 
> different components. 
>  
> Thanks, 
>   Dave Carlson 
>  
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message 
> news:dpgltu$t9s$1@utils.eclipse.org... 
>> 
 
<snip>
 |  
 |  
  |  
| Re: [Announce] New EMFT Subproject: Transaction [message #562596 is a reply to message #9974] | 
Fri, 06 January 2006 10:24   | 
 
Eclipse User  | 
 | 
 | 
   | 
 
Hi Christian, 
 
Thanks much for your explanation.  I've not yet studied the eclipse  
operation history implementation (used only the EMF commands this past  
year).  But I will review the EMFT transactions and eclipse history. 
 
Do you expect this refactoring and adoption of  EMF-TX and OperationHistory  
to be complete by GMF 1.0 in June? 
 
Thanks, 
  Dave 
 
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message  
news:dpluqb$i8d$1@utils.eclipse.org... 
> 
> Hi, Dave, 
> 
> Work is beginning on refactoring the GMF runtime onto this new EMF 
> transaction API, to replace of the MEditingDomain and related APIs. 
> Concomitant to this is the replacement of the GMF CommandManager with the 
> OperationHistory.  Thus, GMF will end up using only one "stack" for 
> "commands" (though I'm not sure about GEF plans for adopting the operation 
> history). 
> 
> The EMFT Transaction project's basic editing domain implementation  
> continues 
> to use an EMF CommandStack to support applications that deploy in 
> non-Eclipse environments (where there is no OperationHistory).  We also 
> provide an editing domain whose command stack delegates to the operation 
> history.  Or, you can use the OperationHistory directly as your command 
> stack, bypassing the editing domain's stack.  Basically, we can't provide 
> an editing domain without a command stack but we can provide one that  
> works 
> without it. 
> 
> Cheers, 
> 
> Christian 
> 
> 
> Dave Carlson wrote: 
> 
>> When you say "operation history API in Eclipse runtime", do you mean this 
>> is migrating to the shared Eclipse command stack APIs, and moving away 
>> from the 
>> EMF command stack and GMF CommandManager?  I've been trying to sort out 
>> the GMF command history stacks for undo/redo support this past week, and 
>> found it very confusing with the variety of command APIs used by these 
>> different components. 
>> 
>> Thanks, 
>>   Dave Carlson 
>> 
>> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message 
>> news:dpgltu$t9s$1@utils.eclipse.org... 
>>> 
> 
> <snip>
 |  
 |  
  |  
| Re: [Announce] New EMFT Subproject: Transaction [message #562618 is a reply to message #9996] | 
Mon, 09 January 2006 09:36   | 
 
Eclipse User  | 
 | 
 | 
   | 
 
Originally posted by: cdamus.ca.ibm.com 
 
Hi, Dave, 
 
Bug 112826 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=112826) is 
tracking the GMF adoption of the operation history API, and is currently 
forecast for M5. 
 
Cheers, 
 
Christian 
 
 
Dave Carlson wrote: 
 
> Hi Christian, 
>  
> Thanks much for your explanation.  I've not yet studied the eclipse 
> operation history implementation (used only the EMF commands this past 
> year).  But I will review the EMFT transactions and eclipse history. 
>  
> Do you expect this refactoring and adoption of  EMF-TX and 
> OperationHistory to be complete by GMF 1.0 in June? 
>  
> Thanks, 
>   Dave 
>  
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message 
> news:dpluqb$i8d$1@utils.eclipse.org... 
 
<snip>
 |  
 |  
  |   
Goto Forum:
 
 Current Time: Mon Nov 03 22:06:33 EST 2025 
 Powered by  FUDForum. Page generated in 0.05861 seconds  
 |