Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jwt-dev] Re: AW: Components in JWT

Hi Florian

Great, I like this new CVS layout !
I'm currently trying to gather my thoughts about how to ensure consistency across transformation specific extension / annotations / properties... stay tuned.


Florian Lautenbacher wrote:

Hi Marc, hi all,

concerning the components in JWT and in CVS: after having a longer
discussion with the webmaster of Eclipse he enabled my console to log into
CVS, so I have now been able to create the directories you proposed in your
last mail. So we can host most of our code on the Eclipse CVS which I would
prefer to using again an external server where nobody can see what we are
actually working on.

So there are now the following directories on



we/jwt-plugin-sample (a sample how to define plugins on top of WE)
we/jwt-view (a tool to define several views for WE)
we/jwt-we (the workflow editor itself)
we/jwt-we-deploy (the deployed plugins as JAR-file that anybody can simply
copy into his/her eclipse)
we/jwt-we-doc (a plugin on top of WE in order to generate an
html-documentation using a workflow model)
The useless directories (that had been there) have been removed, so now we
have a clearer structure on our CVS. If any further directories are
necessary or existing ones should be removed again, please don't hesitate to
contact me.

Concerning SCA: I would start in one place for the WAM-part (e.g. in
jwt-runtime-bonita-sca) and if there are extensions necessary on the WE
(they certainly will!) then we can add another directory to we/jwt-we-sca
(or something comparable).

Best regards,


-----Ursprüngliche Nachricht-----
Von: Marc Dutoo [mailto:marc.dutoo@xxxxxxxxxxx] Gesendet: Donnerstag, 13. Dezember 2007 16:42
An: Florian Lautenbacher
Cc: 'Java Workflow Toolbox'; 'Stéphane DRAPEAU'; loic.descotte@xxxxxxxxxxx
Betreff: Re: Components in JWT

Hi Florian

So what about using the JWT CVS on the Open Wide Forge 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
subproject samples)

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:

Hi all,

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
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,
Best regards,


-----Ursprüngliche Nachricht-----
Von: Marc Dutoo [mailto:marc.dutoo@xxxxxxxxxxx]
Gesendet: Montag, 3. Dezember 2007 23:12
An: Java Workflow Toolbox; Florian Lautenbacher; Stéphane DRAPEAU; loic.descotte@xxxxxxxxxxx Betreff: Re: AW: [jwt-dev] Re: Samples, BPMN-JWT transformation, new committers, etc.


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

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 candidate. Thanks.

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 yourself... ;-)

Best regards,


-----Ursprüngliche Nachricht-----
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

Hello all

Here is my first take on JWT to BPMN translation detailed spec and samples.
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 basis 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 this on the wiki ?

Next steps :
* MDU : adding annotations to the STP BPMN process (though how they are obtained is already spec'd)
 * MDU : completing my second sample, writing a third one
* everyone : sort out the last indecisions in translation behaviour (see 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
SCOrWareJwtBpmn) :
 * JWT eventHandler
* JWT Data mapping : this I left out for now. Its meaning and use should 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 activities". * I do not agree with the Augsburg proposed mapping Application to special BPMN DataObjects

jwt-dev mailing list

Back to the top