<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.6212" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>sounds good</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>wiki, do you mean the jboss.org jbpm wiki or other
url?</FONT></DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=salaboy@gmail.com href="mailto:salaboy@gmail.com">Mauricio
Salatino</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A
title=carlos.crosetti@mostar.com.ar
href="mailto:carlos.crosetti@mostar.com.ar">Carlos Crosetti</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=mrietvel@redhat.com
href="mailto:mrietvel@redhat.com">Marco Rietveld</A> ; <A
title=jbpm-dev@lists.jboss.org href="mailto:jbpm-dev@lists.jboss.org">jBPM Dev
List</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Friday, June 29, 2012 8:49 AM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [jbpm-dev] Human Task Module
API and DataStructures Proposedchanges</DIV>
<DIV><BR></DIV>Hi there,
<DIV>I will continue filling the wiki page, if someone wants to create a more
structured document about that, I'm OK with that.</DIV>
<DIV>Cheers<BR><BR>
<DIV class=gmail_quote>On Thu, Jun 28, 2012 at 10:07 PM, Carlos Crosetti <SPAN
dir=ltr><<A href="mailto:carlos.crosetti@mostar.com.ar"
target=_blank>carlos.crosetti@mostar.com.ar</A>></SPAN> wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><U></U>
<DIV bgcolor="#ffffff">
<DIV><FONT face=Arial>I like this content, however is a little difficult to
follow, would be a good idea writing Scrum-like user stories?</FONT></DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>
<DIV class=h5>
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV style="BACKGROUND: #e4e4e4; FONT: 10pt arial"><B>From:</B> <A
title=salaboy@gmail.com href="mailto:salaboy@gmail.com"
target=_blank>Mauricio Salatino</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=mrietvel@redhat.com
href="mailto:mrietvel@redhat.com" target=_blank>Marco Rietveld</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=jbpm-dev@lists.jboss.org
href="mailto:jbpm-dev@lists.jboss.org" target=_blank>jBPM Dev List</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Thursday, June 28, 2012 8:07
AM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [jbpm-dev] Human Task
Module API and DataStructures Proposedchanges</DIV>
<DIV><BR></DIV>Hi Marco,
<DIV>Thank you very much for your feedback, it really helps to move this
forward in the right direction.</DIV>
<DIV>Some comments inline:<BR><BR>
<DIV class=gmail_quote>On Thu, Jun 28, 2012 at 4:00 AM, Marco Rietveld
<SPAN dir=ltr><<A href="mailto:mrietvel@redhat.com"
target=_blank>mrietvel@redhat.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV bgcolor="#FFFFFF" text="#000000">
<DIV>Hi Mauricio, Maciej, <BR><BR>+1 on configuration. <BR><BR>+5 for "
facade for process interactions that hides some of the steps and expose
very simple API to interact with."<BR>In essence, we don't want the
process engine (or anything else) to trust the HT component at all --
and vice versa. <BR><BR></DIV></DIV></BLOCKQUOTE>
<DIV>The APIs exposed should be that. Like the current TaskService
interface, only operations. I would like to know that we are on the same
page about the interfaces. I'm interested to expose similar interfaces to
the one exposed by the specification, which are extremely similar to the
TaskService interface. On top of that I would like to promote some
decoupling which enable us to provide different implementations for
features which are required to integrate against a Content Repository, or
something similar. </DIV>
<DIV> </DIV>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV bgcolor="#FFFFFF" text="#000000">
<DIV>Maurcio, I like the API's that you defined in the second document
(HumanTaskAPIAndDataStructuresProposal), but I'm missing how they would
be used with the current architecture. Do you have idea's about that?
(Actually, see the 3rd para after this, for more ideas). <BR><BR>Also, I
think that the local human task service needs to be pulled away from the
current code base: at the moment, the local human task service is
essentially a facade that is based on an infrastructure that was not
designed for it's use that way. In fact, the local human task service
<I>was initially designed as a demo</I> -- but has grown far beyond
that. Luckily, it has an API which means we can change the underlying
implementation. <BR><BR></DIV></DIV></BLOCKQUOTE>
<DIV>The idea of the interfaces that I've created and described in the
document is that. Behind those interfaces we can implement a very straight
forward infrastructure like for example: Interface -> Implementation
-> Database. As mentioned in another email, the Task*Service Services
should be as stateless and as simple as possible.</DIV>
<DIV> </DIV>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV bgcolor="#FFFFFF" text="#000000">
<DIV>In short, I think the use case for the local task service is
sufficiently different from the rest of the use cases
(standalone/hornetq, etc.) that it should have it's own infrastructure
-- almost down to the task functional level. The main reason for this is
that persistence (especially tx's) are a big part of the use case for
the local task service -- but the tx logic and request handling in
human-task wasn't really written with that in mind. I would like to
consider rewriting the code so that persistence and request handling
could be even more pluggable than they are (depending on local or
standalone task service). <BR></DIV></DIV></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>On top of the very simple local implementation we can build the
transport layers or reuse an existing framework like camel/switchyard. If
we are in an EE environment we can instantiate the Local/Simple
configuration and plug the transports provided by the container. One of
the advantage of CDI is that it will make our life easier from the testing
perspective and also from the pluggeablity and configuration
perspective.</DIV>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV bgcolor="#FFFFFF" text="#000000">
<DIV><BR>Separating the pure human task code out from the other concerns
(request handling, persistence) will probably also help to create the
API's that you define. <BR></DIV></DIV></BLOCKQUOTE>
<DIV>The APIs that I've propose doesn't care about those topics, that's
one of the main points. In some way the structures that the API is
proposing affects how the persistence entities will look like, but I want
to have clear interfaces that exposes the semantic of the work that we
want to do with the module: Human Interactions. </DIV>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV bgcolor="#FFFFFF" text="#000000">
<DIV><BR>Lastly, +10 on the API's -- but I really do want them to be
Interfaces. Where possible, I'd really like to make sure that the
underlying classes are not accessible to the user and that there's a
real focus on creating an interface that satisfies a User's need --
instead of simply creating functionality for the user and exposing it.
<BR><BR></DIV></DIV></BLOCKQUOTE>
<DIV>They are all interfaces, we cannot force to the users to use one
implementation. I'm pushing CDI forward to guarantee standards ways
for the user to plug their own implementation if they want. </DIV>
<DIV><BR></DIV>
<DIV>I will be adding more details to the wiki page today to clarify some
of the points that were mentioned in this thread. </DIV>
<DIV>Unfortunately, I will be side tracked tomorrow with the form builder,
but as soon as I can get back with this topic I will try to upload a very
simple PoC to show how the interfaces will look like and
the responsibility of each service. </DIV>
<DIV><BR></DIV>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV bgcolor="#FFFFFF" text="#000000">
<DIV>Oh yeah, +1 on not forcing users to use the software a particular
way: they always end up surprising you and using it another way. The
more ways you can expose an API the better..
<BR><BR>Regards,<BR>Marco<BR></DIV></DIV></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>Cheers </DIV>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV bgcolor="#FFFFFF" text="#000000">
<DIV><BR>27-06-12 23:28, Maciej Swiderski:<BR></DIV>
<DIV>
<DIV>
<BLOCKQUOTE type="cite">Hi Mauricio,<BR><BR>Do we foresee any use
cases where task service will be used without process engine? If so, I
agree we could make it as generic as possible but priority number 1
should be integration with process engine to make it simple and
intuitive.<BR>In general I like this separation but I am not convinced
about task definition service as to me it looks bit over designed to
the use cases I am aware of. One issue I see with this is that we
introduce task definition management in human task module which I
don't think should be concerned about. It should be only runtime
component and not repository for task definition. If we think about
storing task definitions that are reusable across processes we should
store them in guvnor rather than in additional component (ht module).
Since both designer and form builder is integrated with it so no need
for yet another integration. This is more of tools responsibility and
not runtime component. Especially important in case of local task
service, since how we could store/deploy task definition into local
task service?<BR>Same applies for task delegation service, as this
kind of information could come from another place - repository and be
utilized by tooling.<BR><BR>Configuration is week point in human task
module currently so I believe that this is very important element to
be improved while refactoring (or even redesiging) task module. I
would see this as single configuration service that allows to
configure - in this new way - all services with defaulting to
convention over configuration so well documented convention of
configuration points is a must.<BR><BR>As it comes to integration
between process engine and human task it should be as simple as
possible. I agree that in some cases use of switch yard and camel
makes sence but we should not force users to include it every time.
Simple interactions should be available and in my opinion out of the
box. For instance, make use of jms provider that AS delivers instead
of putting additional frameworks in between.<BR><BR>If you want to
keep the services not aware of process interaction then we should
deliver facade for process interactions that hides some of the steps
and expose very simple API to interact with, like addTask,
completeTask, getTask, getAssignerTasks, etc (part of this is probably
in task instance service). That will make a smooth interaction from
the process side which as mentioned already is most important, in my
opinion.<BR><BR>For CDI, I am not expert here but what about
standalone adoptions, like swing, or other desktop frameworks, will
CDI fit into that?<BR><BR><BR>Let's encourage others here to speak up
as we need more votes on this refactor.<BR>Maciej <BR><BR><BR>On <A
href="tel:27.06.2012%2020" target=_blank
value="+12706201220">27.06.2012 20</A>:17, Mauricio Salatino wrote:
<BLOCKQUOTE type="cite">Thanks Maciej for the questions. I've
included comments between the bullets
<DIV><BR></DIV>
<DIV>
<P>"Mauricio, couple of questions at the very beginning to
understand correctly your proposal:</P>
<UL
style="BORDER-RIGHT: 0px; PADDING-RIGHT: 0px; BORDER-TOP: 0px; PADDING-LEFT: 2.25em; PADDING-BOTTOM: 0px; MARGIN: 0px; BORDER-LEFT: 0px; PADDING-TOP: 0px; BORDER-BOTTOM: 0px; BORDER-COLLAPSE: collapse; TEXT-ALIGN: left; border-spacing: 0px; outline: 0px">
<LI>Q: how does task def service applies to process interactions -
when task definition will be deployed?<BR>A: I was trying to not
think about the process engine for exposing a Human Task
Interactions APIs, but I understand your question. Right now
inside our HTWorkItems we are calling the taskClient.add method
which in fact is doing a deploy and an instantiation of a task
based on the WorkItem params map. This parameters map is created
based on the userTask defined in a process and its internal data
mappings. That's from one side. <BR>With the form builder,
what can be done right now is to "decorate" a userTask from a
business process and define a form based on it. So basically we do
something like: pick a process, get all the userTasks and for each
task we end up with a TaskForm.def this TaskForm.def can be
associated with a TaskDefinition, instead with a TaskInstance,
promoting reusability as much as we can.<BR>If we have this
TaskDefService, we can make both: the WorkItemHandlers and the
Form builder to consume the same information and reuse that as
much as we can. We can include the process designer in the loop
and make the Company Tasks Definitions available for the editor,
so the user when want to place a new UserTask inside their
process, can choose from a list of presets instead of filling all
the mappings, user assignments, presentation details,
notifications settings, etc.<BR><BR>
<LI><SPAN style="BACKGROUND-COLOR: transparent">Q: delegation
service - since that is on task def level - what about sharing
this information on concurrent task instances since based on the
same definition expressions can be evaluated to different
values<BR>A: Yes that's the idea. In the static information we can
have an expresion, in that case the expresion will be evaluated
with the TaskInstance context and the result will be placed
in the task instance context, the task def information will not be
changed, so it can be safely shared between instances. All the
taskDef related structures should contain "templating" information
which means something for the company. All the runtime status will
be kept in the task instances. Think about TaskDef,
DelegationsDef, NotificationDef, as shortcuts for the users to not
define everything each time that they want to instantiate a
task.<BR><BR></SPAN>
<LI
style="BORDER-RIGHT: 0px; PADDING-RIGHT: 0px; BORDER-TOP: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; BORDER-LEFT: 0px; PADDING-TOP: 0px; BORDER-BOTTOM: 0px; BORDER-COLLAPSE: collapse; BACKGROUND-COLOR: transparent; border-spacing: 0px; outline: 0px"><FONT
face="Lucida Sans, Lucida Sans Unicode, Lucida Grande, Verdana, Arial, Helvetica, sans-serif"
color=#555555><SPAN style="FONT-SIZE: 12px">Q:how is this going to
be configured - per service or will there be a configuration
service as well</SPAN></FONT><BR><FONT
face="Lucida Sans, Lucida Sans Unicode, Lucida Grande, Verdana, Arial, Helvetica, sans-serif"
color=#555555><SPAN style="FONT-SIZE: 12px">A: good question, we
can add this topic for our board session :) I'm not a CDI expert,
but based on what I've being reading, you can provide a default
set of services that will be
automatically instantiated and injected, and then you
can provide alternatives. If the user doesn't want the default
settings he can defined the alternatives via a vary basic
configuration file. Using CDI qualifiers we can, with a pair of
annotations, define which set implementations (1 configuration) do
we want for our whole set of services. </SPAN></FONT>
</LI></UL>
<P> </P>
<P>Would be really nice to see how this is going to be utilized from
following perspectives:</P>
<UL>
<LI
style="BORDER-RIGHT: 0px; PADDING-RIGHT: 0px; BORDER-TOP: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; BORDER-LEFT: 0px; PADDING-TOP: 0px; BORDER-BOTTOM: 0px; BORDER-COLLAPSE: collapse; BACKGROUND-COLOR: transparent; border-spacing: 0px; outline: 0px">Q:
process engine - how process engine will interact with human task
services<BR>A: This should not be a problem of this module, and I
think that this can be considered as an integration problem, so it
can be <BR>fixed with an specialized framework such as
switchyard and/or camel. I've being reading about the CDI support
for them.. and <BR>I think that we can go in that
way. <BR>The Callbacks/Listener Service is intended to store
information about the Task Owners and their interest to be
notified about a tasks events. We need to think about this a
little bit more, because the Process Engine is not the Task Owner
of a TaskInstance that has being created by a business process
instance. The business process instance is the owner of that task
in that case, so we will need to keep a reference from that
process instance inside this service. When I say, reference I mean
a business key, an ID, an endpoint or something to be able to
notify the interested ones.
<LI
style="BORDER-RIGHT: 0px; PADDING-RIGHT: 0px; BORDER-TOP: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; BORDER-LEFT: 0px; PADDING-TOP: 0px; BORDER-BOTTOM: 0px; BORDER-COLLAPSE: collapse; BACKGROUND-COLOR: transparent; border-spacing: 0px; outline: 0px">Q:
task client - how to access tasks and to perform operations on
them"<BR>A: via the TaskInstanceService, its the same as our
TaskClient right now. (but restricted for TaskInstances and
TaskInstancesQueries, not add, not Comments, not attachments, not
notifications) </LI></UL>
<DIV style="TEXT-ALIGN: left"><FONT
face="Lucida Sans, Lucida Sans Unicode, Lucida Grande, Verdana, Arial, Helvetica, sans-serif"
color=#555555><SPAN style="FONT-SIZE: 12px"><BR></SPAN></FONT></DIV>
<DIV style="TEXT-ALIGN: left"><BR></DIV>
<DIV style="TEXT-ALIGN: left"><FONT
face="Lucida Sans, Lucida Sans Unicode, Lucida Grande, Verdana, Arial, Helvetica, sans-serif"
color=#555555><SPAN
style="FONT-SIZE: 12px">Cheers</SPAN></FONT></DIV>
<DIV style="TEXT-ALIGN: left"><FONT
face="Lucida Sans, Lucida Sans Unicode, Lucida Grande, Verdana, Arial, Helvetica, sans-serif"
color=#555555><SPAN
style="FONT-SIZE: 12px"><BR></SPAN></FONT></DIV><BR>
<DIV class=gmail_quote>On Wed, Jun 27, 2012 at 1:02 PM, Mauricio
Salatino <SPAN dir=ltr><<A href="mailto:salaboy@gmail.com"
target=_blank>salaboy@gmail.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV>Hi guys,</DIV>
<DIV>I'm back with more wiki pages. I was thinking about how to
improve the Human Task Module and I came back with this wiki
page</DIV>
<DIV>that shows some proposals. </DIV>
<DIV>The main idea behind the proposal is to modularize as much as
we can the features provided by the human task module. I've also
included</DIV>
<DIV>into the proposal the concept of TaskDefinition which will
allow us to add a nice integration with the form builder (in
modeling and in runtime phases).</DIV>
<DIV><BR></DIV>
<DIV>I'm trying to move towards CDI to leverage all the mechanisms
provided by the framework and the fact that exposing CDI beans
across different platforms is extremely easy these
days. </DIV>
<DIV><BR></DIV><A
href="https://community.jboss.org/wiki/HumanTaskAPIAndDataStructuresProposal"
target=_blank>https://community.jboss.org/wiki/HumanTaskAPIAndDataStructuresProposal</A><BR
clear=all>
<DIV><BR></DIV>
<DIV>I understand that the changes proposed in the wiki looks
quite heavy, but I do believe that we can fit the current code
base into that structure without loosing functionality.</DIV>
<DIV> </DIV>
<DIV><BR></DIV>
<DIV>The document is showing APIs and Data Structures only. i
think that we can assume that all the services implementation will
represent simple stateless services which will </DIV>
<DIV>insert and read information from a database,
so architecturally speaking from that perspective the
service implementations should be straight forward. </DIV>
<DIV><BR></DIV>
<DIV>I will be filling the Data Structure Sections briefly, but I
would like to share the main concepts with you guys to gather
feedback, as always.</DIV>
<DIV><BR></DIV>
<DIV>Cheers</DIV><SPAN><FONT color=#888888>
<DIV><BR></DIV>-- <BR> - MyJourney @ <A
href="http://salaboy.wordpress.com"
target=_blank>http://salaboy.wordpress.com</A>
<DIV> - Co-Founder @ <A href="http://www.jugargentina.org"
target=_blank>http://www.jugargentina.org</A><BR> -
Co-Founder @ <A href="http://www.jbug.com.ar"
target=_blank>http://www.jbug.com.ar</A><BR> <BR> -
Salatino "Salaboy" Mauricio
-</DIV><BR></FONT></SPAN></BLOCKQUOTE></DIV><BR><BR clear=all>
<DIV><BR></DIV>-- <BR> - MyJourney @ <A
href="http://salaboy.wordpress.com"
target=_blank>http://salaboy.wordpress.com</A>
<DIV> - Co-Founder @ <A href="http://www.jugargentina.org"
target=_blank>http://www.jugargentina.org</A><BR> - Co-Founder
@ <A href="http://www.jbug.com.ar"
target=_blank>http://www.jbug.com.ar</A><BR> <BR> -
Salatino "Salaboy" Mauricio -</DIV><BR></DIV><BR>
<FIELDSET></FIELDSET> <BR><PRE>_______________________________________________
jbpm-dev mailing list
<A href="mailto:jbpm-dev@lists.jboss.org" target=_blank>jbpm-dev@lists.jboss.org</A>
<A href="https://lists.jboss.org/mailman/listinfo/jbpm-dev" target=_blank>https://lists.jboss.org/mailman/listinfo/jbpm-dev</A>
</PRE></BLOCKQUOTE><BR><BR>
<FIELDSET></FIELDSET> <BR><PRE>_______________________________________________
jbpm-dev mailing list
<A href="mailto:jbpm-dev@lists.jboss.org" target=_blank>jbpm-dev@lists.jboss.org</A>
<A href="https://lists.jboss.org/mailman/listinfo/jbpm-dev" target=_blank>https://lists.jboss.org/mailman/listinfo/jbpm-dev</A>
</PRE></BLOCKQUOTE><BR><BR></DIV></DIV><SPAN><FONT color=#888888><PRE cols="72">--
jBPM/Drools developer
Utrecht, the Netherlands</PRE></FONT></SPAN></DIV></BLOCKQUOTE></DIV><BR><BR
clear=all>
<DIV><BR></DIV>-- <BR> - MyJourney @ <A
href="http://salaboy.wordpress.com"
target=_blank>http://salaboy.wordpress.com</A>
<DIV> - Co-Founder @ <A href="http://www.jugargentina.org"
target=_blank>http://www.jugargentina.org</A><BR> - Co-Founder @ <A
href="http://www.jbug.com.ar"
target=_blank>http://www.jbug.com.ar</A><BR> <BR> - Salatino
"Salaboy" Mauricio -</DIV><BR></DIV></DIV></DIV>
<P></P>
<HR>
<DIV class=im>
<P></P>_______________________________________________<BR>jbpm-dev mailing
list<BR><A href="mailto:jbpm-dev@lists.jboss.org"
target=_blank>jbpm-dev@lists.jboss.org</A><BR><A
href="https://lists.jboss.org/mailman/listinfo/jbpm-dev"
target=_blank>https://lists.jboss.org/mailman/listinfo/jbpm-dev</A><BR></DIV>
<P></P></BLOCKQUOTE></DIV></BLOCKQUOTE></DIV><BR><BR clear=all>
<DIV><BR></DIV>-- <BR> - MyJourney @ <A
href="http://salaboy.wordpress.com"
target=_blank>http://salaboy.wordpress.com</A>
<DIV> - Co-Founder @ <A href="http://www.jugargentina.org"
target=_blank>http://www.jugargentina.org</A><BR> - Co-Founder @ <A
href="http://www.jbug.com.ar"
target=_blank>http://www.jbug.com.ar</A><BR> <BR> - Salatino
"Salaboy" Mauricio -</DIV><BR></DIV></BLOCKQUOTE></BODY></HTML>