Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Java WorkFlow Tooling (JWT) » Wrap-up
Wrap-up [message #15239] Sat, 14 January 2006 21:38 Go to next message
Eclipse UserFriend
Originally posted by: fabrice.dewasmes.openwide.fr

Hi all,

I think it's time to wrap up on recent discussions on this newsgroup and
consider pending actions.

Here are several threads and decisions (if any) :

*** Code contributions
***********************

First of all, I would like to thank Roman Zulauf and ObjectEngineering
GmBH and Allen Young and others from Shanghai JiaoTong University for
their initial code contributions. Please see
https://forge.openwide.fr/frs/?group_id=61 and check them.

I have also posted a first code contribution to show how JaWE can fit
into Eclipse views using SWT AWT bridge (please see notes about this
topic below). I'm in the process of packaging our intial work on GEF
based XPDL graphical editor. I hope to be able to publish this at the
beginning of the week.

*** EMF/GMF use
****************

Well there have been lots of discussion around here to choose whether or
not to use EMF and eventually GMF.

* First my feelings about these are :

+ on EMF :
pros :
- EMF modeling is interesting.
- Using Omondo make things simple to create a EMF ecore diagram and
generate model.
- Code generation works fine and can end up with serialization in
desired format and especially XML. If model was created using an XML
schema, generated XML conforms to this XML Schema. Editors are created
automatically and help creating what EMF call Model instances meaning a
resource that conforms to the model definition (i.e for an XML schema
model this gives you an XML file valid against the XML schema)
cons
- Everything is cool when considering XPDL XML schema or BPEL
schema but this forces any new workflow/process grammar to be developped
this way which is not so easy for newcomers.
- Few people have sufficient EMF experience and none on this
newsgroup seems to have this kind of experience. Charlie is building a
frontend on EMF + GMF and is ready to share his experience on this but
it might be too late if JWT development have begun.

+ on GMF :
Well, I did everything I can with docs, tutorials and everything...
The tutorial was hard to get up and running (due to lack of GMF working
release) but when you finish the tutorial it's impressive. This is good
but I'm always scared of the demo effect (you know the kind of demo
where you push and button and just can say 'waow !'). So I've tried to
build a small XSD schema and see if I can build quickly a graphical
editor using GMF. This failed because the generated EMF model needed
some parametrization and I'm not an expert and when writing GMF map, you
just don't know what the different parameters are and it's like being
blind... So I tried from scratch and worked on the same model but
beginning directly with an EMF model (using Omondo EMF Class diagram
editor). Doing so means that even if you say that your model resource
type is XML you end up with XMI-like XML, meaning that you need to
completely handle the serialization your self if you want XML that is
valid against your schema. Moreover : this didn't help much in writing
the GMF map... :(
The conclusion for using GMF is that it is not mature enough. It has not
reached its first release yet and suffers from lack of documentation.
Adopting GMF would certainly cause us to jump into an ocean of
misunderstanding.

My feeling on using EMF/GMF is that there are chances that using these
frameworks may turn development into a nightmare of configuration tricks.

--> Seems that most of the people around here have expressed same kind
of feelings and for this reason I propose to stay on the only use of GEF.

*** Use of BPMN
****************

Use of BPMN is of interest for two important reasons :
- First, it allows to have a common graphical representation for two
different grammar in one shot : BPEL and XPDL.
- second, as Allen reported in reply to Guennadi, BPMN proposes to fold
up Pool and lane which would be helpful for addressing large workflows
which don't fit into one screen.

Roman and Guennadi have exposed the requirement to be able to plug in
other representations and especially simplfied representation for
business users. As a matter of fact BPMN is for technical users and
might be not understandable by a business analyst.

--> I propose to had this as a requirement in the proposal and put BPMN
as an exemplary graphical representation.

Roman is already working on how to abstract things to allow several
representations to be plugged in. Roman, it would be really nice if we
can integrate an early snapshot of your work in the proposal or creation
review slides.

*** Use of a Swing bridge
**************************

Recent discussions have raised the possibility of reusing some existing
graphical editors or pieces of work relying on Swing. The proposed way
of reusing this work is to use SWT AWT bridge. I'm not in favor of doing
this because this will certainly be a cause of refusal.

--> What is the opinion of others ?

*** WAM
*********

This topic has not been very much discussed. Michael Lipp has proposed
pointers to WfXML for workflow process deployment and OMG API for
accessing and controlling running workflow processes. We might consider
working on WAM in a second step, but I'd like to make people aware that
the STP project has been accepted and created those last days. STP
project is of great interest for JWT as JWT could be part of required
tools for the STP project and deployment and management facilities could
be done by implementing contracts defined by STP.

--> I will contact Carl from STP during the next days to see synergies
between projects.

*** Creation review
********************

As I've said in previous posts, I think we're ready to ask for creation
review. As you might know this is a very important step in the project
lifecycle as failing to creation review will prevent it to go any
further. We have to hardly work on creation review slides and update the
proposal.

--> If everyone is OK I'm going to ask next week for creation review to
Eclipse PMC.

*** Proposal
*************

Pending modifications on the proposal are :
- give pointers to the initial code contributions
- put Allen Young and people from Shanghai JiaoTong University in the
proposed committer list
- Add Guennadi to interested participants
- rectify typo in ObjectEngineering GmbH
- Add BPMN
- Add requirements to plug several representations especially for
business oriented users

--> Anyone willing to make modifications to the proposal is welcome.

Waiting for your comments/reactions

Best regards,

Fabrice Dewasmes
catching up the train [message #15311 is a reply to message #15239] Sat, 14 January 2006 23:12 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: vgv8.yahoo.com.br

Hi all,
How can I help? (I am interested only in designer and possibility to compact
workflow graphical representation, add definitions of workflow nodes to
sidebar, attach editable data structures to workflow nodes at run-time
through pop-up datagrid table and save it according to my XSD in one fused
XML definition of workflow)
I think I lag behind all others (I currently review JaWE docs, Swing-AWT
bridge, my own Swing designer, GMF, GEF, GMT, XSD, etc.)

I also would like to see designer both as plug-in and STAND-ALONE.
Thereafter the design somewhat defensive to Eclipse UI reuse.

Here is, ahead of us, BPEL Designer with dead discussion forum and somewhat
proprietory activity. Let me note that it is from that type of designers
where user do not have control of coordinates of workflow nodes (it is
managed by Layout Manager) and this is the sequence of BPEL, i.e its
context/objectives (orchestration of webservices, and this is very NARROW
and proprietory). And BPEL-Designer project treats already BPEL but I am
interested in non-webservices oriented workflow definitions with human
interactions on server-side and possibilities to control/redefine formats
and on client side.
I also posted that XPDL (there is always lost in trnslation from graphical
notation to XML representation) is the most flexible and complete and BPEL
is really not first priority.
Pluggability of various representation is.

The issue of Swing is not so much and not only of code reuse but also
interoperability. At least, IMHO the design should leave holes for this.

In another post, I mentioned that it is difficult to count with Omondo
EclipseUML Free Ed.
Then I could not understand how someone will fuse dynamically added data
associated eith workflow nodes into XML/XMI model as well as how to specidy
the model in XML (in text editor?). You go from XMI to EMF ECore in order to
produce Java representation model. Anyway, the problem is how to cotrol EMF
ECore model representation in custom XML

GEF with EMF is good for creation of a number of similar pure graphical
editors (m.b. for more than 6) but we are to create one. But EMF or GMF
doesn't give any PLUGGABILITY of various workflow models (other than
recompiling or upgrading the designer). It is conceptual issue and has
nothing to do with experience or stability of frameworks and tools.

Correct me,
Guennadi Vanine
Re: catching up the train [message #15410 is a reply to message #15311] Sun, 15 January 2006 07:13 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: fabrice.dewasmes.openwide.fr

"Guennadi Vanine" <vgv8@yahoo.com.br> wrote:
>Hi all,
>How can I help? (I am interested only in designer and possibility to compact
>workflow graphical representation, add definitions of workflow nodes to
>sidebar, attach editable data structures to workflow nodes at run-time
>through pop-up datagrid table and save it according to my XSD in one fused
>XML definition of workflow)
>I think I lag behind all others (I currently review JaWE docs, Swing-AWT
>bridge, my own Swing designer, GMF, GEF, GMT, XSD, etc.)
>
>I also would like to see designer both as plug-in and STAND-ALONE.
>Thereafter the design somewhat defensive to Eclipse UI reuse.

this would mean eventually being able to use the designer in Eclipse
RCP. In my opinion there is no other way to do it.
>
>Here is, ahead of us, BPEL Designer with dead discussion forum and somewhat
>proprietory activity. Let me note that it is from that type of designers
>where user do not have control of coordinates of workflow nodes (it is
>managed by Layout Manager) and this is the sequence of BPEL, i.e its
>context/objectives (orchestration of webservices, and this is very NARROW
>and proprietory). And BPEL-Designer project treats already BPEL but I am
>interested in non-webservices oriented workflow definitions with human
>interactions on server-side and possibilities to control/redefine formats
>and on client side.
>I also posted that XPDL (there is always lost in trnslation from graphical
>notation to XML representation) is the most flexible and complete and BPEL
>is really not first priority.
>Pluggability of various representation is.
>
>The issue of Swing is not so much and not only of code reuse but also
>interoperability. At least, IMHO the design should leave holes for this.

Right but where and how ?

>
>In another post, I mentioned that it is difficult to count with Omondo
>EclipseUML Free Ed.

I noticed your remark and knew about this issue. But I was not saying to
that we should use Omondo. I used it as a convenient way to build the
model.
>Then I could not understand how someone will fuse dynamically added data
>associated eith workflow nodes into XML/XMI model as well as how to specidy
>the model in XML (in text editor?). You go from XMI to EMF ECore in order to
>produce Java representation model. Anyway, the problem is how to cotrol EMF
>ECore model representation in custom XML

If you read the EMF redbook they point to how you can customize the XML
serialization and augment it with your own custom tags. If think the EMF
way of doing this is to use a JET template for the doSave command.>
>GEF with EMF is good for creation of a number of similar pure graphical
>editors (m.b. for more than 6) but we are to create one. But EMF or GMF
>doesn't give any PLUGGABILITY of various workflow models (other than
>recompiling or upgrading the designer). It is conceptual issue and has
>nothing to do with experience or stability of frameworks and tools.

This is both issues indeed. But maybe that I was not clear enough on
this part :
"- Everything is cool when considering XPDL XML schema or BPEL
schema but this forces any new workflow/process grammar to be developped
this way which is not so easy for newcomers."

This is the same exact thing you're telling. Meeting of the minds ;)

>
>Correct me,
>Guennadi Vanine
>
>

Fabrice


--
experience vs. common sense in EMF [message #15443 is a reply to message #15410] Sun, 15 January 2006 14:38 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: vgv8.yahoo.com.br

This is a multi-part message in MIME format.

------=_NextPart_000_002F_01C619E1.57950DC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

"Fabrice Dewasmes" wrote:..
> If you read the EMF redbook they point to how you can customize the =
XML
> serialization and augment it with your own custom tags. If think the =
EMF
> way of doing this is to use a JET template for the doSave command.>

This is where I really started to hate EMF.
It is very creative in producing time-consuming problems.

As I understood I should have produced initial XMI, Java =
representations,
block code generation and start manually hacking to attach run-time=20
(i.e. behavioral, i.e. those that u cannot add through static models)
artifacts, probably in Swing (somehow desactivating model generation and =
JET
templates)
Have you noticed that you cannot insert anything manually, it is=20
just replaced according to JET templates?=20

BTW, if you use EclipseUML, it cannot be swithed off:
http://www.forum-omondo.com/viewtopic.php?t=3D566&highli ght=3Dturn
"It is not and will never be possible to turn off the live code and =
model=20
synchro between the UML model and the Java code, inside the EclipseUML =
for=20
Java build and between UML model and XMI inside the EclipseUML for MDA=20
build. "

Now, when I tried to disable EclipseUML for Redbook sample,
I got error (*)
My purpose in EMF was not to get me more work with EMF but to the =
contrary.
Just common sense=20

I also have read the following answers from the autor of RedBook Anna =
Gaber=20
(at those times when authors still responded, try this now):
http://dev.eclipse.org/newslists/news.eclipse.tools.gef/msg0 6004.html
"There is no wizard to generate this code. You could use JET to generate =

some of the code from your model (as hinted in Chapter 5 of the book).=20
However, unless you are working with very large models, or intend to=20
generate a lot of very similar editors from different models, it is =
probably=20
less effort to write the code by hand than to set up the templates that =
such=20
an approach would require."

http://dev.eclipse.org/newslists/news.eclipse.tools.gef/msg0 6003.html
"> Also: is it recommended to use the methods generated by EMF.Edit in

II wouldn't use them. It takes less time to learn what you need to do =
and=20
do
it. For a graphical editpart, you are talking about a handful of =
methods.
They are:
mandatory
1) createFigure
2) refreshVisuals
3) activate(), extend to hook model
4) deactivate(), extend to unhook model
optional
5) getModel***(), depending on your part's structural features"

http://www.forum-omondo.com/viewtopic.php?t=3D772&highli ght=3Dcvs
"Omondo EclipseUML Free Ed will never offer CVS support"

I also can give links to some outraged cries on EMF breaking other =
plug-ins

Guennadi Vanine
error (*):
"cvc-elt.1: Cannot find the declaration of element 'merge:options'.=20
emf-merge.xml WorkflowModel/templates line 6 27 de Novembro de 2005=20
14:38:31"
pointing to the last line of
\WorkflowModel\templates\emf-merge.xml=20


------=_NextPart_000_002F_01C619E1.57950DC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>"Fabrice Dewasmes" wrote:</FONT><FONT =
face=3DArial=20
size=3D2>..<BR>&gt; If you read the EMF redbook they point to how you =
can=20
customize the XML<BR>&gt; serialization and augment it with your own =
custom=20
tags. If think the EMF<BR>&gt; way of doing this is to use a JET =
template for=20
the doSave command.&gt;<BR><BR>This is where I really started to hate =
EMF.<BR>It=20
is very creative in producing time-consuming problems.<BR><BR>As I =
understood I=20
should have produced initial XMI, Java representations,<BR>block code =
generation=20
and start manually hacking to attach run-time </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>(i.e. behavioral, i.e. those that u =
cannot add=20
through static models)<BR>artifacts, probably in Swing (somehow =
desactivating=20
model generation and JET<BR>templates)<BR>Have you noticed that you =
cannot=20
insert anything manually, it is&nbsp;<BR>just replaced&nbsp;according=20
to&nbsp;JET templates? </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>BTW, if you use EclipseUML, it cannot =
be swithed=20
off:<BR></FONT><A=20
href=3D"http://www.forum-omondo.com/viewtopic.php?t=3D566&amp;highlight=3D=
turn"><FONT=20
face=3DArial=20
size=3D2>http://www.forum-omondo.com/viewtopic.php?t=3D566&amp;highlight=3D=
turn</FONT></A><BR><FONT=20
face=3DArial size=3D2>"It is not and will never be possible to turn off =
the live=20
code and model <BR>synchro between the UML model and the Java code, =
inside the=20
EclipseUML for <BR>Java build and between UML model and XMI inside the=20
EclipseUML for MDA <BR>build. "<BR><BR>Now, when I tried to disable =
EclipseUML=20
for Redbook sample,<BR>I got error (*)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>My purpose in EMF was not to&nbsp;get =
me&nbsp;more=20
work with EMF but to the contrary.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Just common sense&nbsp;</DIV>
<DIV><BR>I also have read the following answers from the autor of =
RedBook Anna=20
Gaber <BR>(at those times when&nbsp;authors still responded, try this=20
now):<BR></FONT><A=20
href=3D" http://dev.eclipse.org/newslists/news.eclipse.tools.gef/msg0 6004.=
html"><FONT=20
face=3DArial=20
size=3D2> http://dev.eclipse.org/newslists/news.eclipse.tools.gef/msg0 6004=
..html</FONT></A><BR><FONT=20
face=3DArial size=3D2>"There is no wizard to generate this code. You =
could use JET=20
to generate <BR>some of the code from your model (as hinted in Chapter 5 =
of the=20
book). <BR>However, unless you are working with very large models, or =
intend to=20
<BR>generate a lot of very similar editors from different models, it is =
probably=20
<BR>less effort to write the code by hand than to set up the templates =
that such=20
<BR>an approach would require."<BR><BR></FONT><A=20
href=3D" http://dev.eclipse.org/newslists/news.eclipse.tools.gef/msg0 6003.=
html"><FONT=20
face=3DArial=20
size=3D2> http://dev.eclipse.org/newslists/news.eclipse.tools.gef/msg0 6003=
..html</FONT></A><BR><FONT=20
face=3DArial size=3D2>"&gt; Also: is it recommended to use the methods =
generated by=20
EMF.Edit in<BR><BR>II wouldn't use them.&nbsp; It takes less time to =
learn what=20
you need to do and <BR>do<BR>it.&nbsp; For a graphical editpart, you are =
talking=20
about a handful of methods.<BR>They are:<BR>mandatory<BR>1) =
createFigure<BR>2)=20
refreshVisuals<BR>3) activate(), extend to hook model<BR>4) =
deactivate(), extend=20
to unhook model<BR>optional<BR>5) getModel***(), depending on your =
part's=20
structural features"<BR><BR></FONT><A=20
href=3D"http://www.forum-omondo.com/viewtopic.php?t=3D772&amp;highlight=3D=
cvs"><FONT=20
face=3DArial=20
size=3D2>http://www.forum-omondo.com/viewtopic.php?t=3D772&amp;highlight=3D=
cvs</FONT></A><BR><FONT=20
face=3DArial size=3D2>"Omondo EclipseUML Free Ed will never offer CVS=20
support"<BR><BR>I also can give links to&nbsp;some outraged cries on EMF =

breaking other plug-ins<BR><BR>Guennadi Vanine<BR>error =
(*):<BR>"cvc-elt.1:=20
Cannot find the declaration of element 'merge:options'. =
<BR>emf-merge.xml=20
WorkflowModel/templates line 6 27 de Novembro de 2005 =
<BR>14:38:31"<BR>pointing=20
to the last line of<BR>\WorkflowModel\templates\emf-merge.xml=20
<BR><BR></DIV></FONT></BODY></HTML>

------=_NextPart_000_002F_01C619E1.57950DC0--
Re: Wrap-up [message #15509 is a reply to message #15239] Mon, 16 January 2006 08:01 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: rzulauf.objeng.ch

Hi Farbrice

Fabrice Dewasmes wrote:
> My feeling on using EMF/GMF is that there are chances that using these
> frameworks may turn development into a nightmare of configuration tricks.
>
> --> Seems that most of the people around here have expressed same kind
> of feelings and for this reason I propose to stay on the only use of GEF.
I agree with you completely

>
> *** Use of BPMN
> ****************
>
> Use of BPMN is of interest for two important reasons :
> - First, it allows to have a common graphical representation for two
> different grammar in one shot : BPEL and XPDL.
> - second, as Allen reported in reply to Guennadi, BPMN proposes to fold
> up Pool and lane which would be helpful for addressing large workflows
> which don't fit into one screen.
>
> Roman and Guennadi have exposed the requirement to be able to plug in
> other representations and especially simplfied representation for
> business users. As a matter of fact BPMN is for technical users and
> might be not understandable by a business analyst.
>
> --> I propose to had this as a requirement in the proposal and put BPMN
> as an exemplary graphical representation.
Good idea.

>
> Roman is already working on how to abstract things to allow several
> representations to be plugged in. Roman, it would be really nice if we
> can integrate an early snapshot of your work in the proposal or creation
> review slides.
What exactly do you need at this point? While I have done some work I
would need to assemble my results to provide you with what you need. I
assume this is within the timeframe of the next few days?

>
> *** Use of a Swing bridge
> **************************
>
> Recent discussions have raised the possibility of reusing some existing
> graphical editors or pieces of work relying on Swing. The proposed way
> of reusing this work is to use SWT AWT bridge. I'm not in favor of doing
> this because this will certainly be a cause of refusal.
>
> --> What is the opinion of others ?
I feel that we should do it right from the start. While the SWT AWT
bridge has its correct place in the eclipse platform, I think it is the
wrong thing to base on for a project to become part of the eclipse
technology platform. I would rather favor rewriting the graphical editor
from scratch while reusing key concepts and design patterns used in
existing editors.

>
> *** WAM
> *********
>
> This topic has not been very much discussed. Michael Lipp has proposed
> pointers to WfXML for workflow process deployment and OMG API for
> accessing and controlling running workflow processes. We might consider
> working on WAM in a second step, but I'd like to make people aware that
> the STP project has been accepted and created those last days. STP
> project is of great interest for JWT as JWT could be part of required
> tools for the STP project and deployment and management facilities could
> be done by implementing contracts defined by STP.
WfXML and the OMG API are two possible APIs to use. But again I suggest
to provide a generic interface which can be implemented by a plugin. So
there could be a plugin for the WfXML (SOAP/ASAP) interface, a plugin
for the OMG API, a plugin for the jBPM API etc. etc.

I am definetely interested in the definition of these interfaces.
>
> --> I will contact Carl from STP during the next days to see synergies
> between projects.
>
> *** Creation review
> ********************
>
> As I've said in previous posts, I think we're ready to ask for creation
> review. As you might know this is a very important step in the project
> lifecycle as failing to creation review will prevent it to go any
> further. We have to hardly work on creation review slides and update the
> proposal.
>
> --> If everyone is OK I'm going to ask next week for creation review to
> Eclipse PMC.
>
> *** Proposal
> *************
>
> Pending modifications on the proposal are :
> - give pointers to the initial code contributions
> - put Allen Young and people from Shanghai JiaoTong University in the
> proposed committer list
> - Add Guennadi to interested participants
> - rectify typo in ObjectEngineering GmbH
> - Add BPMN
> - Add requirements to plug several representations especially for
> business oriented users
This seems ok to me.

>
> --> Anyone willing to make modifications to the proposal is welcome.
>
> Waiting for your comments/reactions
>
> Best regards,
>
> Fabrice Dewasmes
Hope my feedback helps. Thanks again for your hard work on this.

Regards
Roman
Re: Wrap-up [message #15603 is a reply to message #15509] Mon, 16 January 2006 09:42 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: fabrice.dewasmes.openwide.fr

Roman Zulauf wrote:
> Hi Farbrice
>
> Fabrice Dewasmes wrote:
>
>> My feeling on using EMF/GMF is that there are chances that using these
>> frameworks may turn development into a nightmare of configuration tricks.
>>
>> --> Seems that most of the people around here have expressed same kind
>> of feelings and for this reason I propose to stay on the only use of GEF.
>
> I agree with you completely
>
>>
>> *** Use of BPMN
>> ****************
>>
>> Use of BPMN is of interest for two important reasons :
>> - First, it allows to have a common graphical representation for two
>> different grammar in one shot : BPEL and XPDL.
>> - second, as Allen reported in reply to Guennadi, BPMN proposes to
>> fold up Pool and lane which would be helpful for addressing large
>> workflows which don't fit into one screen.
>>
>> Roman and Guennadi have exposed the requirement to be able to plug in
>> other representations and especially simplfied representation for
>> business users. As a matter of fact BPMN is for technical users and
>> might be not understandable by a business analyst.
>>
>> --> I propose to had this as a requirement in the proposal and put
>> BPMN as an exemplary graphical representation.
>
> Good idea.
>
>>
>> Roman is already working on how to abstract things to allow several
>> representations to be plugged in. Roman, it would be really nice if we
>> can integrate an early snapshot of your work in the proposal or
>> creation review slides.
>
> What exactly do you need at this point?

We don't need detailed conception yet but a general idea of how we plan
to do things. The correct input should be a simple diagram illsutrating
the different building blocks and how they collaborate.

While I have done some work I
> would need to assemble my results to provide you with what you need. I
> assume this is within the timeframe of the next few days?
>
>>
>> *** Use of a Swing bridge
>> **************************
>>
>> Recent discussions have raised the possibility of reusing some
>> existing graphical editors or pieces of work relying on Swing. The
>> proposed way of reusing this work is to use SWT AWT bridge. I'm not in
>> favor of doing this because this will certainly be a cause of refusal.
>>
>> --> What is the opinion of others ?
>
> I feel that we should do it right from the start. While the SWT AWT
> bridge has its correct place in the eclipse platform, I think it is the
> wrong thing to base on for a project to become part of the eclipse
> technology platform. I would rather favor rewriting the graphical editor
> from scratch while reusing key concepts and design patterns used in
> existing editors.

This is also my opinion.

>
>>
>> *** WAM
>> *********
>>
>> This topic has not been very much discussed. Michael Lipp has proposed
>> pointers to WfXML for workflow process deployment and OMG API for
>> accessing and controlling running workflow processes. We might
>> consider working on WAM in a second step, but I'd like to make people
>> aware that the STP project has been accepted and created those last
>> days. STP project is of great interest for JWT as JWT could be part of
>> required tools for the STP project and deployment and management
>> facilities could be done by implementing contracts defined by STP.
>
> WfXML and the OMG API are two possible APIs to use. But again I suggest
> to provide a generic interface which can be implemented by a plugin. So
> there could be a plugin for the WfXML (SOAP/ASAP) interface, a plugin
> for the OMG API, a plugin for the jBPM API etc. etc.
>
> I am definetely interested in the definition of these interfaces.

This is a good idea as we need to be able to provide extension points. I
propose to modify the proposal this way.

>
>>
>> --> I will contact Carl from STP during the next days to see synergies
>> between projects.
>>
>> *** Creation review
>> ********************
>>
>> As I've said in previous posts, I think we're ready to ask for
>> creation review. As you might know this is a very important step in
>> the project lifecycle as failing to creation review will prevent it to
>> go any further. We have to hardly work on creation review slides and
>> update the proposal.
>>
>> --> If everyone is OK I'm going to ask next week for creation review
>> to Eclipse PMC.
>>
>> *** Proposal
>> *************
>>
>> Pending modifications on the proposal are :
>> - give pointers to the initial code contributions
>> - put Allen Young and people from Shanghai JiaoTong University in the
>> proposed committer list
>> - Add Guennadi to interested participants
>> - rectify typo in ObjectEngineering GmbH
>> - Add BPMN
>> - Add requirements to plug several representations especially for
>> business oriented users
>
> This seems ok to me.
>
>>
>> --> Anyone willing to make modifications to the proposal is welcome.
>>
>> Waiting for your comments/reactions
>>
>> Best regards,
>>
>> Fabrice Dewasmes
>
> Hope my feedback helps. Thanks again for your hard work on this.
>
> Regards
> Roman

Fabrice
Re: experience vs. common sense in EMF [message #15635 is a reply to message #15443] Mon, 16 January 2006 09:50 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: fabrice.dewasmes.openwide.fr

Guennadi Vanine wrote:
> "Fabrice Dewasmes" wrote:..
> > If you read the EMF redbook they point to how you can customize the XML
> > serialization and augment it with your own custom tags. If think the EMF
> > way of doing this is to use a JET template for the doSave command.>
>
> This is where I really started to hate EMF.
> It is very creative in producing time-consuming problems.
>
> As I understood I should have produced initial XMI, Java representations,
> block code generation and start manually hacking to attach run-time
> (i.e. behavioral, i.e. those that u cannot add through static models)
> artifacts, probably in Swing (somehow desactivating model generation and JET
> templates)
> Have you noticed that you cannot insert anything manually, it is
> just replaced according to JET templates?

MMmh I understood that you can specifiy non overwritable sections using JET.

>
> BTW, if you use EclipseUML, it cannot be swithed off:
> http://www.forum-omondo.com/viewtopic.php?t=566&highligh t=turn
> < http://www.forum-omondo.com/viewtopic.php?t=566&highligh t=turn>
> "It is not and will never be possible to turn off the live code and model
> synchro between the UML model and the Java code, inside the EclipseUML for
> Java build and between UML model and XMI inside the EclipseUML for MDA
> build. "
>
> Now, when I tried to disable EclipseUML for Redbook sample,
> I got error (*)

I didn't know about this issue. Anyway this is one more point against
use of EMF.
> My purpose in EMF was not to get me more work with EMF but to the contrary.
> Just common sense
>
> I also have read the following answers from the autor of RedBook Anna Gaber
> (at those times when authors still responded, try this now):
> http://dev.eclipse.org/newslists/news.eclipse.tools.gef/msg0 6004.html
> "There is no wizard to generate this code. You could use JET to generate
> some of the code from your model (as hinted in Chapter 5 of the book).
> However, unless you are working with very large models, or intend to
> generate a lot of very similar editors from different models, it is
> probably
> less effort to write the code by hand than to set up the templates that
> such
> an approach would require."

Ah! This is interesting. I'll keep this information.

>
> http://dev.eclipse.org/newslists/news.eclipse.tools.gef/msg0 6003.html
> "> Also: is it recommended to use the methods generated by EMF.Edit in
>
> II wouldn't use them. It takes less time to learn what you need to do and
> do
> it. For a graphical editpart, you are talking about a handful of methods.
> They are:
> mandatory
> 1) createFigure
> 2) refreshVisuals
> 3) activate(), extend to hook model
> 4) deactivate(), extend to unhook model
> optional
> 5) getModel***(), depending on your part's structural features"
>
> http://www.forum-omondo.com/viewtopic.php?t=772&highligh t=cvs
> < http://www.forum-omondo.com/viewtopic.php?t=772&highligh t=cvs>
> "Omondo EclipseUML Free Ed will never offer CVS support"
>
> I also can give links to some outraged cries on EMF breaking other plug-ins

OK this might interesting if we have justify the choice of not using EMF.

Thanks for this work.

Fabrice
>
> Guennadi Vanine
> error (*):
> "cvc-elt.1: Cannot find the declaration of element 'merge:options'.
> emf-merge.xml WorkflowModel/templates line 6 27 de Novembro de 2005
> 14:38:31"
> pointing to the last line of
> \WorkflowModel\templates\emf-merge.xml
>
Re: Wrap-up [message #15667 is a reply to message #15603] Mon, 16 January 2006 11:22 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: rzulauf.objeng.ch

Fabrice Dewasmes wrote:
>>> Roman is already working on how to abstract things to allow several
>>> representations to be plugged in. Roman, it would be really nice if
>>> we can integrate an early snapshot of your work in the proposal or
>>> creation review slides.
>>
>>
>> What exactly do you need at this point?
>
>
> We don't need detailed conception yet but a general idea of how we plan
> to do things. The correct input should be a simple diagram illsutrating
> the different building blocks and how they collaborate.
OK, I will try to get this to you within the next few (2-3) days.

>>> *** WAM
>>> *********
>>>
>>> This topic has not been very much discussed. Michael Lipp has
>>> proposed pointers to WfXML for workflow process deployment and OMG
>>> API for accessing and controlling running workflow processes. We
>>> might consider working on WAM in a second step, but I'd like to make
>>> people aware that the STP project has been accepted and created those
>>> last days. STP project is of great interest for JWT as JWT could be
>>> part of required tools for the STP project and deployment and
>>> management facilities could be done by implementing contracts defined
>>> by STP.
>>
>>
>> WfXML and the OMG API are two possible APIs to use. But again I
>> suggest to provide a generic interface which can be implemented by a
>> plugin. So there could be a plugin for the WfXML (SOAP/ASAP)
>> interface, a plugin for the OMG API, a plugin for the jBPM API etc. etc.
>>
>> I am definetely interested in the definition of these interfaces.
>
>
> This is a good idea as we need to be able to provide extension points. I
> propose to modify the proposal this way.
Excellent.

Best regards,
Roman
If not Swing then what? [message #17589 is a reply to message #15509] Tue, 17 January 2006 05:29 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: vgv8.yahoo.com.br

"Roman Zulauf" wrote in message
> I feel that we should do it right from the start. While the SWT AWT bridge
> has its correct place in the eclipse platform, I think it is the wrong
> thing to base on for a project to become part of the eclipse technology
> platform. I would rather favor rewriting the graphical editor from scratch
> while reusing key concepts and design patterns used in existing editors.

Should it be understood that SWT/JFace is right and Swing/AWT is wrong?
and I am really very-very eager to understand why

Have you seen this bug report
https://bugs.eclipse.org/bugs/show_bug.cgi?id=104570

If SWT AWT bridge is wrong then only because Eclipse as underlying platform
is not good.

The most curious is that I have seen dozens of articles describing as ready
(with code snippets) something that should appear only in 1-3 years and in
quite stealthy way

Or click on this trick
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/plat form-ui-home/databinding-proposal/databinding.html



hmm, redirected. You will never find this Eclipse.org project under
eclipse.org site.

Cunny



I also have looked for all posts on databinding in EEclipse - they are never
answered



All these MVCs with GEF, EMF, GMF, SWT/JFace doesn't come out from
manipulation of purely graphic data (as model) aka shapes.


Guennai Vanine
Swing vs. SWT - no way to bypass this problem [message #17645 is a reply to message #17589] Tue, 17 January 2006 15:33 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: vgv8.yahoo.com.br

Hi, all,
I badly need opinion of the others on SWT AWT bridge problem.
IMHO it is "go/no go" decision.

I feel that:
- SWT is not mature (in comparison with Swing where there are plethora of
widgets, libraries, books, samples, etc. and that is around for decade), I
even do not know how to reproduce in SWT features of my existing Wf Dwsigner
in Swing that I should substitute;
- I feel bad about compatibility with Java world outside of Eclipse
including my own project (I have Wf Designer in Swing)
- if to decide on clean eclipse vision, do we have resources (programmers,
qualifications and TIME to wait for completing other eclipse projects on
which such decision depends on? In my project - no!)
- the architecture, coding in SWT is horrible, it resembles me MFC that MS
is desperately abandoning last years
- Yes, JFace/SWT seems cleaner it is because it doesn't permit to
differentiate between UI elements (models) and data models.
"One interesting idea in jface.databinding is that UI elements and data
models are treated the same"
http://michaelscharf.blogspot.com/2006/01/new-jfacedatabindi ng-needs-users.html
It hardly started and it is already of no use to me


Here are some links (between others) that I read tonight:
http://www.eclipsezone.com/eclipse/forums/m91978575.html
Anybody venturing into the world of the SWT-AWT bridge needs to be aware:
1. The linux version is buggy, and
2. The Mac version does not work at all.
To be sure, people are working on these things, but it is slow going.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=47716
https://bugs.eclipse.org/bugs/show_bug.cgi?id=67384


https://bugs.eclipse.org/bugs/show_bug.cgi?id=104570

Data binding framework for SWT and RCP needed


http://swingwt.sourceforge.net/

(Swing/AWT API on top of SWT, org.eclipse.swt.awt.SWT_AWT class)

http://chrriis.brainlex.com/projects/swtswing/

(SWT API on top of Swing)

Guennadi Vanine

"Guennadi Vanine" <vgv8@yahoo.com.br> wrote in message
news:dqhvcj$odo$1@utils.eclipse.org...
> "Roman Zulauf" wrote in message
>> I feel that we should do it right from the start. While the SWT AWT
>> bridge has its correct place in the eclipse platform, I think it is the
>> wrong thing to base on for a project to become part of the eclipse
>> technology platform. I would rather favor rewriting the graphical editor
>> from scratch while reusing key concepts and design patterns used in
>> existing editors.
>
> Should it be understood that SWT/JFace is right and Swing/AWT is wrong?
> and I am really very-very eager to understand why
>
> Have you seen this bug report
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=104570
>
> If SWT AWT bridge is wrong then only because Eclipse as underlying
> platform is not good.
>
> The most curious is that I have seen dozens of articles describing as
> ready (with code snippets) something that should appear only in 1-3 years
> and in quite stealthy way
>
> Or click on this trick
> http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/plat form-ui-home/databinding-proposal/databinding.html
>
>
>
> hmm, redirected. You will never find this Eclipse.org project under
> eclipse.org site.
>
> Cunny
>
>
>
> I also have looked for all posts on databinding in EEclipse - they are
> never answered
>
>
>
> All these MVCs with GEF, EMF, GMF, SWT/JFace doesn't come out from
> manipulation of purely graphic data (as model) aka shapes.
>
>
> Guennai Vanine
>
Vista/WinFX support? [message #19661 is a reply to message #15509] Thu, 26 January 2006 14:41 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: vgv8.yahoo.com.br

"Roman Zulauf" wrote:
>> *** Use of a Swing bridge
> I feel that we should do it right from the start. While the SWT AWT bridge
> has its correct place in the eclipse platform, I think it is the wrong
> thing to base on for a project to become part of the eclipse technology
> platform. I would rather favor rewriting the graphical editor from scratch
> while reusing key concepts and design patterns used in existing editors.

But what is right?
GEF is not based specifically on any model at all!

SWT is based on Win32 API/MFC that is discontinued for coming MS Windows,
starting from Vista/Avalon that are shifted to WinFX/XAML/XAML/.NET, etc.

BTW there both SWT_AWT anf AWT_SWT bridge

It is just dangerous approach to be hooked to native implementations. It
defeats "Write once, debug everywhere"

And the share of MS Windows PCs is significant. A lot of companies have MSDN
subcription licences and move upgrading somewhat automatically

What do u think?

Guennadi Vanine
Re: Vista/WinFX support? [message #19706 is a reply to message #19661] Fri, 27 January 2006 08:53 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: rzulauf.objeng.ch

Guennadi Vanine wrote:
> "Roman Zulauf" wrote:
>
>>>*** Use of a Swing bridge
>>
>>I feel that we should do it right from the start. While the SWT AWT bridge
>>has its correct place in the eclipse platform, I think it is the wrong
>>thing to base on for a project to become part of the eclipse technology
>>platform. I would rather favor rewriting the graphical editor from scratch
>>while reusing key concepts and design patterns used in existing editors.
>
>
> But what is right?
> GEF is not based specifically on any model at all!
That is correct, it just leverages the MVC pattern and leaves the
definition of the concrete model up to you.
I'm not saying other, existing graphical editors are wrong, all I am
saying is that we are trying to build an *eclipse* workflow editor and
in the context of the eclipse platform the right thing to do is use SWT.

>
> SWT is based on Win32 API/MFC that is discontinued for coming MS Windows,
> starting from Vista/Avalon that are shifted to WinFX/XAML/XAML/.NET, etc.
Personally I am not interested in political discussions about which GUI
Toolkit or API is the best. And if SWT uses Win32 or WinFX or something
else behind the scenes is of little importance to us. That's what an
Interface or a Wrapper is for, to hide the implementation details.

All we need to ask ourselves is, can we get the job done with GEF and
SWT? The answer is yes, so that is the obvious choice considering we are
building an editor for the eclipse platform.

>
> BTW there both SWT_AWT anf AWT_SWT bridge
Correct.

>
> It is just dangerous approach to be hooked to native implementations. It
> defeats "Write once, debug everywhere"
Realize that SWT has many stakeholders. The entire eclipse platform
depends on SWT, so as long as eclipse has industry backup, SWT will be
supported and maintained. I do not see any risk here.


Regards Roman
will we cope with that? [message #19778 is a reply to message #19706] Fri, 27 January 2006 16:44 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: vgv8.yahoo.com.br

Hi, Roman,
recently I have been discussing with Allen on messenger (he is currently out
up to 05Febr, 2006 to vacation due to Chinese New Year)

And our worry was that it would be laborious to reproduce in SWT and GEF all
functionalities offered by EMF or GMF frameworks.
This depends on our resources (programmers and time available)

Anyway, our progress rate (and resources) seem to be much less than that of
GMF project and the latter exhibits great improvements. While we made
wrap-up in the past based on the situation in the past while it could have
been more correct to synchronize our start in the future with GMF state in
the future.

Then, the logic is that if Eclipse is targeted as platform then it is
logical to base on its frameworks. And GEF with SWT doesn't add much to
non-Eclipse Swing/AWT. Don't we target non-Eclipse arquitectures, solutions
by targeting GEF/SWT only?

Allen thought that we should have from the very start all-embracing
meta-model.
I expressed my concern that we should wrap up current practical necessities
to designer functionalities from interested parties and do not target for
immediate realization all possible (in the future) usage scenarios.

That is, to device extensibility, interoperability in the future.

For ex., BPMN, as graphical notation, with close to it XPDL, as its textual
representation, is more then all-embracing for me (I even do not need XPDL's
participants and processes, in my case it is configured at server-side).
BPEL, BPML, etrc. may be seen as truncated versions, subset of XPDL.
We could have one unique graphical notation BPMN and closely corresponding
to it XPDL representation and give possibility to translate to BPEL, BPML,
etc. (really I am interested in non-standard format) angle of view reflected
graphically again by the same (subset of) BPMN.

Though I still have difficulties to grasp how to customize GMF, EMF.

I am just worried whether it was correct to target too ambitious/noble
plans. If we do not reuse legacy code themn we should rely more on
high-level framework reutilization and should adapt it to our capabilites
(resources).

Guennadi Vanine
"Roman Zulauf" <rzulauf@objeng.ch> wrote in message
news:drcn3m$q7i$1@utils.eclipse.org...
> Guennadi Vanine wrote:
>> "Roman Zulauf" wrote:
>>
>>>>*** Use of a Swing bridge
>>>
>>>I feel that we should do it right from the start. While the SWT AWT
>>>bridge has its correct place in the eclipse platform, I think it is the
>>>wrong thing to base on for a project to become part of the eclipse
>>>technology platform. I would rather favor rewriting the graphical editor
>>>from scratch while reusing key concepts and design patterns used in
>>>existing editors.
>>
>>
>> But what is right?
>> GEF is not based specifically on any model at all!
> That is correct, it just leverages the MVC pattern and leaves the
> definition of the concrete model up to you.
> I'm not saying other, existing graphical editors are wrong, all I am
> saying is that we are trying to build an *eclipse* workflow editor and in
> the context of the eclipse platform the right thing to do is use SWT.
>
>>
>> SWT is based on Win32 API/MFC that is discontinued for coming MS
>> Windows,
>> starting from Vista/Avalon that are shifted to WinFX/XAML/XAML/.NET, etc.
> Personally I am not interested in political discussions about which GUI
> Toolkit or API is the best. And if SWT uses Win32 or WinFX or something
> else behind the scenes is of little importance to us. That's what an
> Interface or a Wrapper is for, to hide the implementation details.
>
> All we need to ask ourselves is, can we get the job done with GEF and SWT?
> The answer is yes, so that is the obvious choice considering we are
> building an editor for the eclipse platform.
>
>>
>> BTW there both SWT_AWT anf AWT_SWT bridge
> Correct.
>
>>
>> It is just dangerous approach to be hooked to native implementations. It
>> defeats "Write once, debug everywhere"
> Realize that SWT has many stakeholders. The entire eclipse platform
> depends on SWT, so as long as eclipse has industry backup, SWT will be
> supported and maintained. I do not see any risk here.
>
>
> Regards Roman
Re: will we cope with that? [message #19819 is a reply to message #19778] Mon, 30 January 2006 13:17 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: fabrice.dewasmes.openwide.fr

Guennadi Vanine wrote:

>
> And our worry was that it would be laborious to reproduce in SWT and GEF all
> functionalities offered by EMF or GMF frameworks.
> This depends on our resources (programmers and time available)

Yes. I'll post something about this today or tomorrow.
>
> Anyway, our progress rate (and resources) seem to be much less than that of
> GMF project and the latter exhibits great improvements. While we made
> wrap-up in the past based on the situation in the past while it could have
> been more correct to synchronize our start in the future with GMF state in
> the future.
>
> Then, the logic is that if Eclipse is targeted as platform then it is
> logical to base on its frameworks.

Glad you're OK with this now ;)

And GEF with SWT doesn't add much to
> non-Eclipse Swing/AWT. Don't we target non-Eclipse arquitectures, solutions
> by targeting GEF/SWT only?

Non-eclipse platforms are not targeted and of course using GEF/SWT will
stick us to Eclipse platforms or at least SWT platform.

>
> Allen thought that we should have from the very start all-embracing
> meta-model.

Yes This is a discussion we also had. The point is how to simply write
the meta model without any high level tools such as EclipseUML ?

> I expressed my concern that we should wrap up current practical necessities
> to designer functionalities from interested parties and do not target for
> immediate realization all possible (in the future) usage scenarios.
>
> That is, to device extensibility, interoperability in the future.
>
> For ex., BPMN, as graphical notation, with close to it XPDL, as its textual
> representation, is more then all-embracing for me (I even do not need XPDL's
> participants and processes, in my case it is configured at server-side).
> BPEL, BPML, etrc. may be seen as truncated versions, subset of XPDL.
> We could have one unique graphical notation BPMN and closely corresponding
> to it XPDL representation and give possibility to translate to BPEL, BPML,
> etc. (really I am interested in non-standard format) angle of view reflected
> graphically again by the same (subset of) BPMN.

Of course. We definitely need to have an iterative roadmap. I'm going to
work on it for creation review. Your point is grist to my mill and will
include this in the roadmap

>
> Though I still have difficulties to grasp how to customize GMF, EMF.
>
> I am just worried whether it was correct to target too ambitious/noble
> plans. If we do not reuse legacy code themn we should rely more on
> high-level framework reutilization and should adapt it to our capabilites
> (resources).

Yes this is also a concern to me. Experience says that doing too generic
things end up with a bloatware. As expressed earlier we should stick
with concrete 'simple' implementations at first and keep in mind targets.
vote our issues! [message #19863 is a reply to message #15509] Tue, 31 January 2006 16:24 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: vgv8.yahoo.com.br

I bumped into many problems with EMF.
Then I encountered their description in bugzilla.
They are even not considered as bugs but as duplication of
https://bugs.eclipse.org/bugs/show_bug.cgi?id=75933

And what is the last bug? Absence of the concept of well-defineIt is EMF
architecture to be decided in the future while other framework should base
their own architectures on it.

This is fundamental issue without which u should not even start framework
instead this bug has the lowest priority "enhancement" (it is lower than
"trivial") And any usability problems are marked as duplication of it

Another but dependent on firs is GMF "bug":
https://bugs.eclipse.org/bugs/show_bug.cgi?id=114233
[req] Provide alternative persistence mechanism

It is even not targeted by GMF1.0 Release!
and again is has just an "enhancement" priority
(am I crazy? first to make framework and then design/architecture it)

IMHO the main problem in development using Eclipse frameworks is that u r
forced not only to do yr application but also hack the tool, IDE, and
frameworks for this.

These issues are quite critical for their use or plans to use. In JWT also
Everybody, go to vote for this bugs!
Salvation of all is the matter of everybody!

Guennadi Vanine
no concept of well defined ECore model [message #19893 is a reply to message #19863] Tue, 31 January 2006 16:57 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: vgv8.yahoo.com.br

I made a typo.
I shoulf have written:
Abscence of concept of well-defined ECore model, i.e. of EMF models as such
"Guennadi Vanine" <vgv8@yahoo.com.br> wrote in message
news:dro2vp$5qf$1@utils.eclipse.org...
>I bumped into many problems with EMF.
> Then I encountered their description in bugzilla.
> They are even not considered as bugs but as duplication of
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=75933
>
> And what is the last bug? Absence of the concept of well-defineIt is EMF
> architecture to be decided in the future while other framework should base
> their own architectures on it.
>
> This is fundamental issue without which u should not even start framework
> instead this bug has the lowest priority "enhancement" (it is lower than
> "trivial") And any usability problems are marked as duplication of it
>
> Another but dependent on firs is GMF "bug":
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=114233
> [req] Provide alternative persistence mechanism
>
> It is even not targeted by GMF1.0 Release!
> and again is has just an "enhancement" priority
> (am I crazy? first to make framework and then design/architecture it)
>
> IMHO the main problem in development using Eclipse frameworks is that u r
> forced not only to do yr application but also hack the tool, IDE, and
> frameworks for this.
>
> These issues are quite critical for their use or plans to use. In JWT also
> Everybody, go to vote for this bugs!
> Salvation of all is the matter of everybody!
>
> Guennadi Vanine
>
no errors/warning in code generation [message #19960 is a reply to message #19863] Tue, 31 January 2006 17:11 Go to previous message
Eclipse UserFriend
Originally posted by: vgv8.yahoo.com.br

And vote for this one!
https://bugs.eclipse.org/bugs/show_bug.cgi?id=104727
[Plan Item] Improve code generation error reporting and handling

Guennadi Vanine
"Guennadi Vanine" <vgv8@yahoo.com.br> wrote in message
news:dro2vp$5qf$1@utils.eclipse.org...
>I bumped into many problems with EMF.
> Then I encountered their description in bugzilla.
> They are even not considered as bugs but as duplication of
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=75933
>
> And what is the last bug? Absence of the concept of well-defineIt is EMF
> architecture to be decided in the future while other framework should base
> their own architectures on it.
>
> This is fundamental issue without which u should not even start framework
> instead this bug has the lowest priority "enhancement" (it is lower than
> "trivial") And any usability problems are marked as duplication of it
>
> Another but dependent on firs is GMF "bug":
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=114233
> [req] Provide alternative persistence mechanism
>
> It is even not targeted by GMF1.0 Release!
> and again is has just an "enhancement" priority
> (am I crazy? first to make framework and then design/architecture it)
>
> IMHO the main problem in development using Eclipse frameworks is that u r
> forced not only to do yr application but also hack the tool, IDE, and
> frameworks for this.
>
> These issues are quite critical for their use or plans to use. In JWT also
> Everybody, go to vote for this bugs!
> Salvation of all is the matter of everybody!
>
> Guennadi Vanine
>
Previous Topic:How to run Elune
Next Topic:move to STP
Goto Forum:
  


Current Time: Tue Mar 19 03:24:56 GMT 2024

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

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

Back to the top