[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[jwt-dev] How to watch all bugs
|
About how to watch all bugs :
In the Bugzilla Preferences page
https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email , add the
following emails in the "User watching" list at the bottom :
jwt.we-inbox@xxxxxxxxxxx
jwt.wam-inbox@xxxxxxxxxxx
jwt.desktop-inbox@xxxxxxxxxxx
I'm putting this in the FAQ at
http://wiki.eclipse.org/JWT_DeveloperFAQ#Working_with_Bugzilla .
Regards,
Marc
Pierre Vigneras a écrit :
Le Monday 08 December 2008 14:06:20 Florian Lautenbacher, vous avez écrit :
Hi all,
I agree that currently the restrictions of ForkNode and JoinNode
(DecisionNode and MergeNode respectively) (having only a single incoming or
outgoing edge) are only contained in the workflow editor and that this is
not a good thing. However, I would prefer to leave them in the metamodel,
but additionally adding some OCL constraints which actually say that a
DecisionNode is not allowed to have more than one incoming node (others
similar).
There are plenty of algorithms (e.g. for validation) that require that a
process model has And-Split and And-Join (as well as XOR-Split and
XOR-Join) and that would fail if we would remove these nodes from the
metamodel.
Ok, I understand that.
More specifically, I currently got a group of students who are creating a
first version of a JWT validation plugin and that require the DecisionNode,
MergeNode, ForkNode and JoinNode. If we would now remove these nodes from
the metamodel, their work cannot be finished or is not valid or usable in
the end anymore. Their validation approach builds on an idea of IBM called
Fast Heuristics and makes some simple checks concerning deadlocks and lack
of synchronization. I will soon create a bug describing their work.
Good. But, it seems to me that the following, rather simple algorithm, will
tell you if a given node is actually a Fork or a Join (adapting that to
Decision/Merge is staightforward):
public static boolean isFork(AndControlNode node) {
return (node.getIn().size() == 1) && (node.getOut().size() >= 1);
}
public static boolean isJoin(AndControlNode node) {
return (node.getIn().size() >= 1) && (node.getOut().size() == 1);
}
Again, since the model does not enforce anything, your student are working on
instances of the model that only comes from the default JWT editor.
Basically, the work done by your students will not work with other instances
based on other JWT-based editors. Removing those leaf nodes will guarantee
that those algorithms will actually pay attention to constraints. My claim,
is that since informations about number of edges is already in any model
instance (getIn() and getOut() methods on any node) and since the constraints
are expressed elsewhere (either an OCL as you suggest, or in the graphical
layers), I don't see the point of keeping those leaf nodes. They just don't
serve any purposes as far as I see, other than making compatibility between
JWT-based editors an issue.
I am aware of the impact on the current code base of such a removal. This
modification is *not required* currently. But, we are sufficiently concerned
on that issue to discuss it right now, and to come to a formal conclusion
that will be implemented in one way or another at some stage (rather vague,
huh?)
Of course, since I am quite fresh to JWT technology, it is quite possible that
I haven't seen problems related to the removal of those leaf nodes.
[snip: we are all concerned about compatibility]
Basically, in the model we may have only two elements : Node and Edges.
Yes, I agree with that and refer to a comment made already before: when the
aspect mechanism is perfectly working we might think about outsourcing all
elements of the current metamodel to several profiles/conf-files. Then we
could have a plugin with a metamodel ActivityNode / ActivityEdge, another
one which introduces the concepts of Actions and some ControlNodes. A third
one that has all ControlNodes, StructuredActivityNode and ActivityLinkNode
and a forth one containing the extensions concerning Data, Application
and/or Roles.
I am not sure that this will not lead to some compatibility issues actually.
What will happen if one tool use one profile, and another tool, another
profile? At least, with the current model (apart from those leaf nodes
IMHO ;-)), any tools written for JWT can deal with model instances designed
with any JWT-based editors. Maybe, I misunderstood something.
But for the moment I would rather stay with working things
than removing them and having something that doesn't work anymore.
Again, for us, the removal of leaf nodes from the model, is not urgent. But,
discussing it now, will hopefully lead us to a conclusion.
Regards.
PS: Problem with bug tracker is that everyone is not reading to it! And we
still don't know how to subscribe to all bugs in JWT in order to follow any
JWT topic. Anyone, a solution?
PPS: Should I copy/paste this inside the related bug?
