Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [Announce] New EMFT Subproject: Transaction
[Announce] New EMFT Subproject: Transaction [message #9839] Wed, 04 January 2006 14:25 Go to next message
Eclipse UserFriend
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 21:26 Go to previous messageGo to next message
Dave Carlson is currently offline Dave CarlsonFriend
Messages: 402
Registered: July 2009
Senior Member
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 14:27 Go to previous messageGo to next message
Eclipse UserFriend
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 15:24 Go to previous messageGo to next message
Dave Carlson is currently offline Dave CarlsonFriend
Messages: 402
Registered: July 2009
Senior Member
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 14:36 Go to previous message
Eclipse UserFriend
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 21:26 Go to previous message
Dave Carlson is currently offline Dave CarlsonFriend
Messages: 402
Registered: July 2009
Senior Member
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 14:27 Go to previous message
Eclipse UserFriend
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 15:24 Go to previous message
Dave Carlson is currently offline Dave CarlsonFriend
Messages: 402
Registered: July 2009
Senior Member
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 14:36 Go to previous message
Eclipse UserFriend
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>
Previous Topic:Newbie Question
Next Topic:Live validation and MSLActionAbandonedException
Goto Forum:
  


Current Time: Thu Sep 29 20:54:07 GMT 2022

Powered by FUDForum. Page generated in 0.02888 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top