[jwt-dev] Re: Components in JWT
So what about using the JWT CVS on the Open Wide Forge
https://forge.openwide.fr/projects/jwt/ to host temporarily things that
have no fixed place yet ? Here at Open Wide we're already using it this
way for JWT and BPMN samples.
Now what about this in the jwt eclipse repository :
jwt-compatibility / jwt-bpmn (may contain their own samples)
jwt-compatibility / jwt-xpdl (may contain their own samples)
jwt-compatibility / jwt-samples (a unified version of the previous
And why not :
jwt-wam / jwt-runtime-bonita-sca (bonita extension allowing to call sca
jwt-wam / jwt-registry-scorware (workflow editor plugin allowing to
browse the service semantic registry by the INT)
Arguably those last two could be put rather in the SCOrWare private
project SVN, but I'd rather have the JWT community have a look at it.
jwt4soa would have been an umbrella for soa, sca and scorware minded
extensions. For example, jwt-wam / jwt-runtime-bonita-sca makes sense,
but if we also develop jwt-we / jwt-we-sca i.e. an we plugin allowing to
drag and drop sca components from the Obeo sca editor on JWT actions in
order to link them together, it might be better to pack both at the same
place...I admit I'm not sure what is the right thing to do.
NB. The idea of "jwt-samples" was to have one set of
Florian Lautenbacher wrote:
sorry for the late response. The last days had been quite busy. The idea to
have some additional sub-projects/components where the other resources could
be committed is quite good, but I'm not sure whether we simply can add
components or whether we need to ask the PMC about that. Actually, we can
simply add components in Bugzilla ourselves (using MyFoundation) and of
course adding another directory in the CVS is not a problem either. Maybe we
should first start adding a directory for the components to CVS and at the
same time add the components to Bugzilla and in parallel to that we can ask
EMO about the normal progress about that.
So, which kind of "components" do we like to have:
- I would agree with something like JWT4SOA if that is necessary (what would
be the content of that?)
- There definitely needs to be something like JWT-transformations which
could include both jwt-bpmn as well as jwt-xpdl or jwt-bpel. In my opinion
those could easily be bundled in one component (however having different
source code of course).
- JWT-samples are surely necessary. However I'm not sure, whether this
should be an own component or whether we simply should have a part on our
web site called "documentation" where these example processes are given and
explained in detail.
- jwt-runtime-bonita seems to be part of the proposed WAM part of JWT, so I
don't see why we should have an own component for that. Better start filling
the WAM component (where jwt-runtime-bonita could again be a subcomponent).
The idea of using EAnnotations to support different runtime engines like
Bonita in JWT sounds good to me. However, since I missed the telco last
Friday, there is probably already an agreement on this!? Marc, Stéphane?
Von: Marc Dutoo [mailto:marc.dutoo@xxxxxxxxxxx]
Gesendet: Montag, 3. Dezember 2007 23:12
An: Java Workflow Toolbox; Florian Lautenbacher; Stéphane DRAPEAU;
Betreff: Re: AW: [jwt-dev] Re: Samples, BPMN-JWT transformation, new
I agree with you. We all promise to do it right in the future :)
Actually Loic could have committed the samples, but there is no JWT project
for JWT4SOA or JWT2BPMN or ...
What about these subprojects :
jwt-bpmn for jwt to bpmn and vice versa transformations and their
integration in jwt we, as well as a quick launch of STP BPMN ed
jwt-xpdl for jwt to xpdl (bonita version) transformation and their
integration in jwt we
maybe a jwt-samples, to gather a common basic version of our
interoperability & validation samples. Then these scripts could be copy
and pasted by any interoperability project ex. jwt-bpmn and fine-tuned
at will, but at the end the jwt-samples scripts would have to be updated
in a consistent manner. This would ensure that a new interoperability
feature won't break an existing one. Other ideas on samples and how to
ensure format consistence, anyone ?
jwt-runtime-bonita for bonita integration as a jwt runtime. NB. this
could also be put in the scorware private project, but I'd rather put it
here so the whole JWT community can help and give inputs.
As for how JWT workflow model will have to be extended to support the
bonita runtime there's nothing final yet, but why not add an EAnnotation
mechanism just like BPMN so as to not require to change the model each
time there is a new standard or engine supported ? Florian, Stéphane,
your take on this ?
By the way, did you read the PMC's comments on the two new committers on
The PMC's comments were: I'm a little concerned by the +1 votes that
"as requested" - individual committers are required to be making up their
own minds on whether to vote someone in, not just following a party line.
will assume that that is what you all have done. Please make sure that
voting comments in the future correctly reflect your opinions of the
I agree with him, that normally new committers should have developed some
code, answered some bugs or did anything else, but I also see the problem
when there is nobody to submit the code and you need to do all the things
Von: Marc Dutoo [mailto:marc.dutoo@xxxxxxxxxxx] Gesendet: Mittwoch,
14. November 2007 19:30
An: Stéphane DRAPEAU; Florian Lautenbacher
Cc: Etienne Juliot
Betreff: JWT to BPMN translation - first spec and samples
Here is my first take on JWT to BPMN translation detailed spec and
You'll find in this mail (content or attachments) :
* a first sample JWT process :
* its translated STP BPMN files :
transformation_sample_3_approval_frompp (without annotations yet
* my analysis of JWT to BPMN translation, whose goal is to be the
of a translation algo. What about putting this on the wiki ?
* Florian's answers to some questions of mine, that could be the
step towards a "How to build processes in JWT" FAQ. What about putting
on the wiki ?
Next steps :
* MDU : adding annotations to the STP BPMN process (though how they
obtained is already spec'd)
* MDU : completing my second sample, writing a third one
* everyone : sort out the last indecisions in translation behaviour
below first, and in attachments)
* SDR : work on the translation ^^
* FLA : look at all that, help out whenever it is useful (thanks for
cleaning my process)
PS indecisions to be closed out (see details in attached
* JWT eventHandler
* JWT Data mapping : this I left out for now. Its meaning and use
be made clearer.
* at a lower level, about JWT events
* I do not agree with the Augsburg proposed mapping for pool & lane,
rather "Pools represent participants, lane are for categorizing
* I do not agree with the Augsburg proposed mapping Application to
special BPMN DataObjects
jwt-dev mailing list