invalid enterprise-ear dependency on gwt-console
by Thomas Diesler
Heiko,
if you remove the gwt console from your local repo a
mvn clean package
will always fail because of this dependency
<dependency>
<groupId>org.jbpm.jbpm3</groupId>
<artifactId>gwt-console-war</artifactId>
<version>${version}</version>
<type>war</type>
</dependency>
in
<name>JBoss jBPM3 - Enterprise (EAR)</name>
<groupId>org.jbpm.jbpm3</groupId>
<artifactId>jbpm-enterprise-bundle</artifactId>
<packaging>ear</packaging>
This condition would occur for everybody trying to get started with
jbpm3. Is it really necessary to package the gwt console inside the
enterprise ear?
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
BPM Product Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years, 5 months
[Design of JBoss jBPM] - Re: meeting context
by kukeltje
[O/T]First beer, now nuts and meat... lol... The only thing missing are music (Tom, show us your drumming skills) and women.... Besides that we've had 'in Koen we trust' and now Mozes makes an appearance....people should not get a wrong impression of this meeting. [/O/T]
anonymous wrote : OK, but that means the fact that JBPM4 does leverage the PVM should be transparent to the API, right?
Transparant meaning you do not see anything in e.g. the client-api that points to the PVM? Yep, that is my impression to
anonymous wrote : I mean it's an implementation detail then, or is it not?
Yep, albeit marketing wise an important one ;-)
anonymous wrote : As I said earlier, I think there's actually several API's with different scope.
Was my impression to, and it was also my impression that this was Tom's idea as well, but he seems to disagree now:
anonymous wrote : I think it is possible to have 1 API for all PDLs. Which would be a real achievement, given the diversity of languages that we try to cover. Let's discuss the tradeoffs in the meeting.
Well, maybe we should ask him to elaborate upfront ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181449#4181449
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181449
17 years, 5 months
[Design of JBoss jBPM] - Re: meeting context
by koen.aers＠jboss.com
"alejandro" wrote : Even if it provides a visual notation and semantics it does not (and should not) define an execution model. Hence BPMN should be an influence and not an objective.
Chapter 10 of the BPMN 2.0 draft specifies in about 15 pages the runtime semantics of BPMN. So the committee is clearly not agreeing with your point of view. ;-)
That being said, the specified semantics are described in natural language and thus very unclear and confusing. The execution semantics of an activity are *very* complicated. It is specified by a state diagram that contains no less than 20 nodes. It remains to be seen if such a complicated model will get a lot of supporters/implementers.
"ronald" wrote : Afaik, but could not find it directly, BPMN is based on structured graphs
This is not completely true. BPMN allows for unstructured or 'free' graphs, multiple branches of sequence flow ending in random end events, etc. However, the earlier mentioned runtime semantics specify that some of these constructions are invalid (but of course this would only appear at runtime) as you can see in the following exerpt:
anonymous wrote : The Inclusive Gateway is activated if at least one incoming sequence flow has at least one Token and for each empty incoming sequence flow, there is no corresponding Token in the graph anywhere upstream of this sequence flow, i.e. there is no path from a Token to this sequence flow unless the path visits a dominator or postdominator of a non-empty incoming sequence flow of the gateway
Aside from all this, I believe indeed that it would be good to discuss the different concepts as much as possible and see where we can 'borrow' from the spec. I saw that the new Choreography part is entirely optional and that the compliance part is still to be defined (if at all possible). So I am not sure how this is going to look when the spec goes final but I am hopeful that we will be able to comply somehow.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181322#4181322
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181322
17 years, 5 months
