- 浏览: 289792 次
- 性别:
- 来自: 唐山
最新评论
-
小灯笼:
JBPM5.4实战流程引擎开发网盘地址:https://pan ...
跟我学工作流——jBPM4视频教程(免费) -
Kai_Ge:
学会做人 写道临远大哥,谢谢你的贡献大名鼎鼎的临远!!膜拜中。 ...
Spring Security-3.0.1中文官方文档(翻译版) -
漂泊一剑客:
博主,你自己电脑上有下载,这些信息吗,能否分享一下给我
跟我学工作流——jBPM4视频教程(免费) -
Rookie_Li:
您好,您的教程很有用,请问例子的源码在哪下载?
spring security权限管理手册升级至spring security-3.1.3 -
nullFFF:
马教授 写道现在还用4有点过时了,最新的都已经是5.4了,目前 ...
跟我学工作流——jBPM4视频教程(免费)
jBPM4的发展遇到了瓶颈,官方已经有一个多月没有更新代码了,前段时间又传出了jBPM的主要成员tom和jorom离开red hat的消息,虽然jboss方面已经指定了alexjando作为新的project leader,但是这个家伙一个月来只更新了一次svn,而且还只是改改配置文件。
上周五,jboss突然发布了一个jbpm5的架构讨论帖,在jBPM4尚有好多好多bug没有搞定的情况下开始筹划jbpm5的新功能了。
https://community.jboss.org/wiki/jBPM5RequestforComments
虽然wiki上面架构图画的很完全,但是从功能来看,基本已经找不到jbpm的影子了,去jbpm-dev开发者邮件列表上看了一下,jboss官方的意思似乎是要用drools flow将jbpm取而代之。
看来前段时间传闻的jbpm和drools的争端已经有了结果,jbpm下一步就算不合并到drools中,也是要被鸠占鹊巢了。下一次发布的jbpm5就是打着jbpm招牌的drools flow了。毕竟drools flow已经完成了bpmn2(据说,咱们没亲眼见过,毕竟drools flow在国内没什么人用)。
下一步怎么办呢?目前已经有不少公司都在是用jbpm4了,使用jbpm3的人就更多,难道我们还要再等几个月甚至一年以上的时间,等drools flow把jbpm完全替代了之后再用工作流吗?还是说我们现在就必须迁移到drools flow上才行。
我的想法是将jbpm4的trunk代码拿出来,放到google code上做一个社区版分支,继续进行维护,这样至少可以保证目前已经使用了jbpm4的项目不会丧失持续的支持(当然对我们自己有好处啦,我们目前做的东西都是基于jbpm4,jbpm4如果死掉了我们岂不是要从头开始?)。
从开源协议上来说是没有问题的,LGPL要求如果修改了原代码,就要开放出来,只要社区版的jbpm4依然使用LGPL开源就可以了。问题是,red hat是否允许我们使用jbpm这个名字,或者说,我们是否可以在修补了bug之后,发布jbpm-4.3.1版,red hat目前拥有jbpm的版权,它是否会禁止其他地方使用jbpm的发布名称呢?也许我们必须改成其他名字,就像mysql被收购以后,作者立刻去搞了一个maria一样?
我也刚接触,如果能接受v4对v3的变化,基本也能接受v5对v4的改造了,因为变化实在太大了
那不是这样子的,V3的确设计比较糟糕,不能满足实际需求而摒弃掉是明智的。但是V4已基本能够满足项目需求了,投入了大量精力去消化这个东西并且在此基础上形成一些成果,如果摒弃掉就相当于之前做的工作很多都白费了,最重要是对JBPM没信心了,因为即使我们跟上了JBPM5,很可能在应用过程中又推出个JBPM6,那么就变成纯粹为技术而技术,无法应用到实际项目当中也就没什么价值可言了。
我也刚接触,如果能接受v4对v3的变化,基本也能接受v5对v4的改造了,因为变化实在太大了
不介意的话。我也可以。
上周五,jboss突然发布了一个jbpm5的架构讨论帖,在jBPM4尚有好多好多bug没有搞定的情况下开始筹划jbpm5的新功能了。
https://community.jboss.org/wiki/jBPM5RequestforComments
虽然wiki上面架构图画的很完全,但是从功能来看,基本已经找不到jbpm的影子了,去jbpm-dev开发者邮件列表上看了一下,jboss官方的意思似乎是要用drools flow将jbpm取而代之。
看来前段时间传闻的jbpm和drools的争端已经有了结果,jbpm下一步就算不合并到drools中,也是要被鸠占鹊巢了。下一次发布的jbpm5就是打着jbpm招牌的drools flow了。毕竟drools flow已经完成了bpmn2(据说,咱们没亲眼见过,毕竟drools flow在国内没什么人用)。
下一步怎么办呢?目前已经有不少公司都在是用jbpm4了,使用jbpm3的人就更多,难道我们还要再等几个月甚至一年以上的时间,等drools flow把jbpm完全替代了之后再用工作流吗?还是说我们现在就必须迁移到drools flow上才行。
我的想法是将jbpm4的trunk代码拿出来,放到google code上做一个社区版分支,继续进行维护,这样至少可以保证目前已经使用了jbpm4的项目不会丧失持续的支持(当然对我们自己有好处啦,我们目前做的东西都是基于jbpm4,jbpm4如果死掉了我们岂不是要从头开始?)。
从开源协议上来说是没有问题的,LGPL要求如果修改了原代码,就要开放出来,只要社区版的jbpm4依然使用LGPL开源就可以了。问题是,red hat是否允许我们使用jbpm这个名字,或者说,我们是否可以在修补了bug之后,发布jbpm-4.3.1版,red hat目前拥有jbpm的版权,它是否会禁止其他地方使用jbpm的发布名称呢?也许我们必须改成其他名字,就像mysql被收购以后,作者立刻去搞了一个maria一样?
评论
34 楼
Dawn.yang
2011-03-04
http://www.iteye.com/problems/60300
大家看看这个问题
大家看看这个问题
33 楼
Dawn.yang
2011-03-04
这个贴应该继续顶下去,不知道临远大哥最近对jbpm4.4有没有进一步的研究和改进?
32 楼
lyf_wx
2010-05-06
支持楼主!
31 楼
almar17
2010-05-05
我也支持楼主,如果可以,我也希望能出一分力
30 楼
xyz20003
2010-05-03
多谢神父支持,如果真要在国内搞开源项目,就不能叫jBPM了。而且LGPL对代码的约束太强,不如Apache 2好操作。
最近我尽量多的在jBPM官方论坛游荡,看是否可以寻找到其他机会。同时也在比较jPDL,BPMN和BPEL这些规范,为下一步做准备。
最近我尽量多的在jBPM官方论坛游荡,看是否可以寻找到其他机会。同时也在比较jPDL,BPMN和BPEL这些规范,为下一步做准备。
29 楼
comsci
2010-05-03
临远,我完全支持你们团队在国内搞一个项目,名叫JBPM中国化,把JBPM这个项目在国内搞下去,你们团队能够好好利用这个机会。。。
28 楼
comsci
2010-05-03
这个消息真的让人感到沮丧,这说明一个问题,核心技术和代码一定要掌握在自己的手中。。。依靠别人来生存,始终不是一件让人放心的事情。。。。
这个事件再次给国内的软件企业敲响一次警钟,要想真正生存和发展,自己的企业必须拥有自己的核心技术和产品。。。。。。
外国人是靠不住的,别人是靠不住的。。。。。
这个事件再次给国内的软件企业敲响一次警钟,要想真正生存和发展,自己的企业必须拥有自己的核心技术和产品。。。。。。
外国人是靠不住的,别人是靠不住的。。。。。
27 楼
ianatxm
2010-04-28
见楼主贴出的回信。
jBPM5会取代jBPM4和Drools Flow,毕竟jBPM是jboss官方项目,名气在外。但是jBPM5肯定又是一个全新的框架,就是说刚上到jBPM4.3的同学们还要继续努力。
最可怜的就是外围厂商,因为这意味着以前的产品又要重新开发,大家又回到同一起点线了。
既然版权所有者不同意单独发展一个分支版本,所以社区版在授权上讲,就不成立了。
jBPM5会取代jBPM4和Drools Flow,毕竟jBPM是jboss官方项目,名气在外。但是jBPM5肯定又是一个全新的框架,就是说刚上到jBPM4.3的同学们还要继续努力。
最可怜的就是外围厂商,因为这意味着以前的产品又要重新开发,大家又回到同一起点线了。
既然版权所有者不同意单独发展一个分支版本,所以社区版在授权上讲,就不成立了。
26 楼
taocong810
2010-04-23
支持楼主。
现在国内有很多用jpbm的公司,就稳定性和可扩展性来说,jpbm4应该是该领域的No.1。
我的建议倒是,楼主可以基于jpbm4.3, 做一个jpbm-side这样的分支,特点为:
1.修复jpbm4.3的bugfix
2.扩展一些功能,使得更加符合中国的国情
楼主加油 加油
现在国内有很多用jpbm的公司,就稳定性和可扩展性来说,jpbm4应该是该领域的No.1。
我的建议倒是,楼主可以基于jpbm4.3, 做一个jpbm-side这样的分支,特点为:
1.修复jpbm4.3的bugfix
2.扩展一些功能,使得更加符合中国的国情
楼主加油 加油
25 楼
supercwg
2010-04-20
chbest 写道
xyz20003 写道
jBPM 5 will supersede both jBPM 4 and Drools Flow. There is no need for
a jBPM 4 community branch since the whole thing is already a community
project. The sources are already open, and patches can still be posted
through Jira as usual. We might even make a new release now to publish
the updates and fixes made since the jBPM 4.3. However, it should be
clear that jBPM 5 is the focus of new development onwards.
-Alejandro
Xu Huisheng wrote:
> Hi Kris:
> I am glad to see there is still a plan for jBPM. But I can't find
> more details in this roadmap. It is just design a overall view for
> jBPM5, but there is still many problem in jBPM 4. If there is a plan
> to maintain the current version of jBPM 4.x, it will very helpful to us.
See my reply to Sebastian:
" This however does not necessarily mean that jBPM 4.x is "finished".
We know there are some issues that need to be dealt with (where some of
them have even been solved in the latest snapshot code already), and
we're also looking into that. Community involvement here is definitely
welcome, so please drop me a message if you want to help out."
> In the jBPM 5 archetecture figure, there is just a 'Core Process
> Engine' but no more details for the PVM and jPDL. Will we drop the
> support of jPDL and turn to the BPMN and drools?
We have been participating in the creation of the BPMN2 specification,
and we believe it is a big step forward. Therefore, we want to target
our future development to BPMN2. Having a standardized language instead
of a proprietary one is almost always a good thing (quality,
interoperability, etc.). And because BPMN2 also allows you to easily
extend the language if necessary, it still gives us the flexibility we
need as well.
So yes, we are looking at moving towards BPMN2 as the main process
execution language and moving away from proprietary languages as jPDL
and RuleFlow. Especially since we believe that BPMN2 will be able to
support the same (process language) features as jPDL, but we welcome
feedback on this. Not sure why you are saying "BPMN and drools" though?
Drools Flow is in exactly the same situation, as that also had a
proprietary language, but will also move to BPMN2.
> Because I just find 'jBPM (3.x) convert plan' here. So I think whether
> we could make a more clearly details for the PVM and jPDL4?
The reason is that jBPM 3.x is currently the officially supported
version. As part of this service, we will provide a migration path from
jBPM 3.x to jBPM5. This however does not there will be no migration
path for jBPM4. We hope and believe that, with some help from the
community, we can extend that to also support jBPM 4.x to jBPM5 migration.
Kris
从好的方面讲,jBPM5会继续开发,并提供BPMN2标准的流程支持,坏消息是对jBPM4的未来都是含糊其辞
a jBPM 4 community branch since the whole thing is already a community
project. The sources are already open, and patches can still be posted
through Jira as usual. We might even make a new release now to publish
the updates and fixes made since the jBPM 4.3. However, it should be
clear that jBPM 5 is the focus of new development onwards.
-Alejandro
Xu Huisheng wrote:
> Hi Kris:
> I am glad to see there is still a plan for jBPM. But I can't find
> more details in this roadmap. It is just design a overall view for
> jBPM5, but there is still many problem in jBPM 4. If there is a plan
> to maintain the current version of jBPM 4.x, it will very helpful to us.
See my reply to Sebastian:
" This however does not necessarily mean that jBPM 4.x is "finished".
We know there are some issues that need to be dealt with (where some of
them have even been solved in the latest snapshot code already), and
we're also looking into that. Community involvement here is definitely
welcome, so please drop me a message if you want to help out."
> In the jBPM 5 archetecture figure, there is just a 'Core Process
> Engine' but no more details for the PVM and jPDL. Will we drop the
> support of jPDL and turn to the BPMN and drools?
We have been participating in the creation of the BPMN2 specification,
and we believe it is a big step forward. Therefore, we want to target
our future development to BPMN2. Having a standardized language instead
of a proprietary one is almost always a good thing (quality,
interoperability, etc.). And because BPMN2 also allows you to easily
extend the language if necessary, it still gives us the flexibility we
need as well.
So yes, we are looking at moving towards BPMN2 as the main process
execution language and moving away from proprietary languages as jPDL
and RuleFlow. Especially since we believe that BPMN2 will be able to
support the same (process language) features as jPDL, but we welcome
feedback on this. Not sure why you are saying "BPMN and drools" though?
Drools Flow is in exactly the same situation, as that also had a
proprietary language, but will also move to BPMN2.
> Because I just find 'jBPM (3.x) convert plan' here. So I think whether
> we could make a more clearly details for the PVM and jPDL4?
The reason is that jBPM 3.x is currently the officially supported
version. As part of this service, we will provide a migration path from
jBPM 3.x to jBPM5. This however does not there will be no migration
path for jBPM4. We hope and believe that, with some help from the
community, we can extend that to also support jBPM 4.x to jBPM5 migration.
Kris
从好的方面讲,jBPM5会继续开发,并提供BPMN2标准的流程支持,坏消息是对jBPM4的未来都是含糊其辞
我也刚接触,如果能接受v4对v3的变化,基本也能接受v5对v4的改造了,因为变化实在太大了
那不是这样子的,V3的确设计比较糟糕,不能满足实际需求而摒弃掉是明智的。但是V4已基本能够满足项目需求了,投入了大量精力去消化这个东西并且在此基础上形成一些成果,如果摒弃掉就相当于之前做的工作很多都白费了,最重要是对JBPM没信心了,因为即使我们跟上了JBPM5,很可能在应用过程中又推出个JBPM6,那么就变成纯粹为技术而技术,无法应用到实际项目当中也就没什么价值可言了。
24 楼
chbest
2010-04-20
xyz20003 写道
jBPM 5 will supersede both jBPM 4 and Drools Flow. There is no need for
a jBPM 4 community branch since the whole thing is already a community
project. The sources are already open, and patches can still be posted
through Jira as usual. We might even make a new release now to publish
the updates and fixes made since the jBPM 4.3. However, it should be
clear that jBPM 5 is the focus of new development onwards.
-Alejandro
Xu Huisheng wrote:
> Hi Kris:
> I am glad to see there is still a plan for jBPM. But I can't find
> more details in this roadmap. It is just design a overall view for
> jBPM5, but there is still many problem in jBPM 4. If there is a plan
> to maintain the current version of jBPM 4.x, it will very helpful to us.
See my reply to Sebastian:
" This however does not necessarily mean that jBPM 4.x is "finished".
We know there are some issues that need to be dealt with (where some of
them have even been solved in the latest snapshot code already), and
we're also looking into that. Community involvement here is definitely
welcome, so please drop me a message if you want to help out."
> In the jBPM 5 archetecture figure, there is just a 'Core Process
> Engine' but no more details for the PVM and jPDL. Will we drop the
> support of jPDL and turn to the BPMN and drools?
We have been participating in the creation of the BPMN2 specification,
and we believe it is a big step forward. Therefore, we want to target
our future development to BPMN2. Having a standardized language instead
of a proprietary one is almost always a good thing (quality,
interoperability, etc.). And because BPMN2 also allows you to easily
extend the language if necessary, it still gives us the flexibility we
need as well.
So yes, we are looking at moving towards BPMN2 as the main process
execution language and moving away from proprietary languages as jPDL
and RuleFlow. Especially since we believe that BPMN2 will be able to
support the same (process language) features as jPDL, but we welcome
feedback on this. Not sure why you are saying "BPMN and drools" though?
Drools Flow is in exactly the same situation, as that also had a
proprietary language, but will also move to BPMN2.
> Because I just find 'jBPM (3.x) convert plan' here. So I think whether
> we could make a more clearly details for the PVM and jPDL4?
The reason is that jBPM 3.x is currently the officially supported
version. As part of this service, we will provide a migration path from
jBPM 3.x to jBPM5. This however does not there will be no migration
path for jBPM4. We hope and believe that, with some help from the
community, we can extend that to also support jBPM 4.x to jBPM5 migration.
Kris
从好的方面讲,jBPM5会继续开发,并提供BPMN2标准的流程支持,坏消息是对jBPM4的未来都是含糊其辞
a jBPM 4 community branch since the whole thing is already a community
project. The sources are already open, and patches can still be posted
through Jira as usual. We might even make a new release now to publish
the updates and fixes made since the jBPM 4.3. However, it should be
clear that jBPM 5 is the focus of new development onwards.
-Alejandro
Xu Huisheng wrote:
> Hi Kris:
> I am glad to see there is still a plan for jBPM. But I can't find
> more details in this roadmap. It is just design a overall view for
> jBPM5, but there is still many problem in jBPM 4. If there is a plan
> to maintain the current version of jBPM 4.x, it will very helpful to us.
See my reply to Sebastian:
" This however does not necessarily mean that jBPM 4.x is "finished".
We know there are some issues that need to be dealt with (where some of
them have even been solved in the latest snapshot code already), and
we're also looking into that. Community involvement here is definitely
welcome, so please drop me a message if you want to help out."
> In the jBPM 5 archetecture figure, there is just a 'Core Process
> Engine' but no more details for the PVM and jPDL. Will we drop the
> support of jPDL and turn to the BPMN and drools?
We have been participating in the creation of the BPMN2 specification,
and we believe it is a big step forward. Therefore, we want to target
our future development to BPMN2. Having a standardized language instead
of a proprietary one is almost always a good thing (quality,
interoperability, etc.). And because BPMN2 also allows you to easily
extend the language if necessary, it still gives us the flexibility we
need as well.
So yes, we are looking at moving towards BPMN2 as the main process
execution language and moving away from proprietary languages as jPDL
and RuleFlow. Especially since we believe that BPMN2 will be able to
support the same (process language) features as jPDL, but we welcome
feedback on this. Not sure why you are saying "BPMN and drools" though?
Drools Flow is in exactly the same situation, as that also had a
proprietary language, but will also move to BPMN2.
> Because I just find 'jBPM (3.x) convert plan' here. So I think whether
> we could make a more clearly details for the PVM and jPDL4?
The reason is that jBPM 3.x is currently the officially supported
version. As part of this service, we will provide a migration path from
jBPM 3.x to jBPM5. This however does not there will be no migration
path for jBPM4. We hope and believe that, with some help from the
community, we can extend that to also support jBPM 4.x to jBPM5 migration.
Kris
从好的方面讲,jBPM5会继续开发,并提供BPMN2标准的流程支持,坏消息是对jBPM4的未来都是含糊其辞
我也刚接触,如果能接受v4对v3的变化,基本也能接受v5对v4的改造了,因为变化实在太大了
23 楼
supercwg
2010-04-20
强烈支持!项目中好不容易将JBPM4弄进来了,现在又废弃掉实在可惜,支持创建社区版分支,虽然存在jbpm-side项目,但实际上没有什么东西,真的还不如spring-side这样形成一个可持续的向前发展的有中国流程特色的版本分支,当然可以申请“jbpm4-side”这样的项目名字,又好听又实在啊,呵呵!
22 楼
xyz20003
2010-04-20
jBPM 5 will supersede both jBPM 4 and Drools Flow. There is no need for
a jBPM 4 community branch since the whole thing is already a community
project. The sources are already open, and patches can still be posted
through Jira as usual. We might even make a new release now to publish
the updates and fixes made since the jBPM 4.3. However, it should be
clear that jBPM 5 is the focus of new development onwards.
-Alejandro
Xu Huisheng wrote:
> Hi Kris:
> I am glad to see there is still a plan for jBPM. But I can't find
> more details in this roadmap. It is just design a overall view for
> jBPM5, but there is still many problem in jBPM 4. If there is a plan
> to maintain the current version of jBPM 4.x, it will very helpful to us.
See my reply to Sebastian:
" This however does not necessarily mean that jBPM 4.x is "finished".
We know there are some issues that need to be dealt with (where some of
them have even been solved in the latest snapshot code already), and
we're also looking into that. Community involvement here is definitely
welcome, so please drop me a message if you want to help out."
> In the jBPM 5 archetecture figure, there is just a 'Core Process
> Engine' but no more details for the PVM and jPDL. Will we drop the
> support of jPDL and turn to the BPMN and drools?
We have been participating in the creation of the BPMN2 specification,
and we believe it is a big step forward. Therefore, we want to target
our future development to BPMN2. Having a standardized language instead
of a proprietary one is almost always a good thing (quality,
interoperability, etc.). And because BPMN2 also allows you to easily
extend the language if necessary, it still gives us the flexibility we
need as well.
So yes, we are looking at moving towards BPMN2 as the main process
execution language and moving away from proprietary languages as jPDL
and RuleFlow. Especially since we believe that BPMN2 will be able to
support the same (process language) features as jPDL, but we welcome
feedback on this. Not sure why you are saying "BPMN and drools" though?
Drools Flow is in exactly the same situation, as that also had a
proprietary language, but will also move to BPMN2.
> Because I just find 'jBPM (3.x) convert plan' here. So I think whether
> we could make a more clearly details for the PVM and jPDL4?
The reason is that jBPM 3.x is currently the officially supported
version. As part of this service, we will provide a migration path from
jBPM 3.x to jBPM5. This however does not there will be no migration
path for jBPM4. We hope and believe that, with some help from the
community, we can extend that to also support jBPM 4.x to jBPM5 migration.
Kris
从好的方面讲,jBPM5会继续开发,并提供BPMN2标准的流程支持,坏消息是对jBPM4的未来都是含糊其辞
a jBPM 4 community branch since the whole thing is already a community
project. The sources are already open, and patches can still be posted
through Jira as usual. We might even make a new release now to publish
the updates and fixes made since the jBPM 4.3. However, it should be
clear that jBPM 5 is the focus of new development onwards.
-Alejandro
Xu Huisheng wrote:
> Hi Kris:
> I am glad to see there is still a plan for jBPM. But I can't find
> more details in this roadmap. It is just design a overall view for
> jBPM5, but there is still many problem in jBPM 4. If there is a plan
> to maintain the current version of jBPM 4.x, it will very helpful to us.
See my reply to Sebastian:
" This however does not necessarily mean that jBPM 4.x is "finished".
We know there are some issues that need to be dealt with (where some of
them have even been solved in the latest snapshot code already), and
we're also looking into that. Community involvement here is definitely
welcome, so please drop me a message if you want to help out."
> In the jBPM 5 archetecture figure, there is just a 'Core Process
> Engine' but no more details for the PVM and jPDL. Will we drop the
> support of jPDL and turn to the BPMN and drools?
We have been participating in the creation of the BPMN2 specification,
and we believe it is a big step forward. Therefore, we want to target
our future development to BPMN2. Having a standardized language instead
of a proprietary one is almost always a good thing (quality,
interoperability, etc.). And because BPMN2 also allows you to easily
extend the language if necessary, it still gives us the flexibility we
need as well.
So yes, we are looking at moving towards BPMN2 as the main process
execution language and moving away from proprietary languages as jPDL
and RuleFlow. Especially since we believe that BPMN2 will be able to
support the same (process language) features as jPDL, but we welcome
feedback on this. Not sure why you are saying "BPMN and drools" though?
Drools Flow is in exactly the same situation, as that also had a
proprietary language, but will also move to BPMN2.
> Because I just find 'jBPM (3.x) convert plan' here. So I think whether
> we could make a more clearly details for the PVM and jPDL4?
The reason is that jBPM 3.x is currently the officially supported
version. As part of this service, we will provide a migration path from
jBPM 3.x to jBPM5. This however does not there will be no migration
path for jBPM4. We hope and believe that, with some help from the
community, we can extend that to also support jBPM 4.x to jBPM5 migration.
Kris
从好的方面讲,jBPM5会继续开发,并提供BPMN2标准的流程支持,坏消息是对jBPM4的未来都是含糊其辞
21 楼
五月天
2010-04-20
有回复吗?
20 楼
johnsonboby
2010-04-19
还好,偶们公司有自己的工作流平台。有的时候开源的东西不一定靠谱,呵呵
19 楼
卡拉阿风
2010-04-19
clsun88 写道
支持楼主的意见!如果可以的话,我愿意加入,贡献自己的一份力量
不介意的话。我也可以。
18 楼
木易有峰
2010-04-19
支持。JBPM我们现在一直在用3版本,4还没有来的及用,主要是由于seam对JBPM的支持原因。
17 楼
clsun88
2010-04-19
支持楼主的意见!如果可以的话,我愿意加入,贡献自己的一份力量
16 楼
saiyaren
2010-04-19
JBPM4.3我们也已经容入到项目里了,临远这个消息对我来说确实是个打击,但是确实4.3的问题还有许多,许多的东西还需要我们大家来去完善,有个交流平台最好,最近太忙了,前阵子本来想分享下成果呢!4的底层引擎确实不错,很便利了已经,但是我还很菜,只是初级应用上,到时候还需要慢慢看里面的东西,还是希望JBPM能继续下去
15 楼
chbest
2010-04-19
我现在在看jbpm相关的
发表评论
-
2010年11月27日周六去beijing open party讲讲jbpm4,有兴趣的话请过来一同聊聊。
2010-11-24 18:00 2691Hi All, 打算2010年11月27日下午13 ... -
轻量级工作流引擎jBPM 4.4正式发布
2010-07-20 19:31 5589jBPM-4.4于2010年7月19日正式发布。 jBP ... -
拖延一个多月后,jBPM-4.4发布CR1候选版
2010-07-15 22:06 2253Alejandro太谨慎了,发布jBPM-4.4之前还搞了一个 ... -
jBPM-4.3所需的最小依赖库列表
2010-06-18 17:06 4985这个问题被问到的次数太多了,无可奈何,只好花点儿时间整理一下。 ... -
jbpm4experiment——基于jbpm4的试验性项目
2010-05-31 14:15 5266官方的发布以稳重为主,所以也让人感觉步伐迟缓,自己建一个项目则 ... -
jBPM 4.4发布日期暂定于2010年6月4日
2010-05-24 09:51 2673jbpm官方终于传来好消息,jBPM 4.4可能在下月初发布。 ... -
jBPM 创始人发布BPMN原生引擎Activiti-5.0-alpha1
2010-05-20 09:21 5625Tom Baeyens也就是jBPM的原作者,离开了Red H ... -
寻求重现jbpm4.3中executionId映射错误的场景
2010-04-27 10:56 2552目前测试的结果是hibernate-3.2.1.ga以及之前 ... -
不选或许有千万种理由,但是选择hibernate只需要一个理由就足够了
2010-03-19 12:37 4442选择一门新技术,首先要看这门技术是否能够满足目前应用的需求,我 ... -
跟我学工作流——jBPM4视频教程(免费)
2010-03-06 15:40 29539新的一年,为了让工作流方面的初学者更快上手开发,我们录制了jB ... -
jBPM-4.x常见问题解决方案FAQ
2010-01-22 09:18 3015这段时间整理的jBPM-4.x常见问题以及解决方案,希望帮助对 ... -
轻量级工作流jBPM-4.3官方“开发指南”中文版
2009-12-30 13:41 4426jBPM-4.3这次升级的重头戏都放在开发指南里了,添加的最大 ... -
轻量级工作流jBPM-4.3官方“用户手册”中文版
2009-12-30 11:25 3479jBPM-4.3准时发布,这次用户手册修改不大,主要是换换xm ... -
谁应该用流程设计器
2009-11-23 12:44 1862谁应该用流程设计器 ... -
数据建模与业务建模
2009-11-20 09:43 2404数据建模与业务建模 无论是企业信息系统还是web网站,各种大 ...
相关推荐
jbpm创建数据库jbpm创建数据库jbpm创建数据库jbpm创建数据库jbpm创建数据库jbpm创建数据库jbpm创建数据库jbpm创建数据库jbpm创建数据库
jbpm4源码jbpm4源码jbpm4源码
jbpm应用开发指面(胡奇) jbpm4.3表结构和表字段说明 [jBPM开发指南].高杰.文字版 jBPM5_用户手册-中文版
5.1表JBPM4_DEPLOYMENT 7 5.2 表JBPM4_DEPLOYPROP 7 5.3 表JBPM4_EXECUTION 8 5.4 表JBPM4_HIST_ACTINST 9 5.5 表JBPM4_HIST_DETAIL 9 5.6 表JBPM4_HIST_PROCINST 10 5.7 表JBPM4_HIST_TASK 11 5.8 表JBPM4_HIST_VAR...
JBPM是一个扩展性很强的工作流系统,百分百用JAVA语言开发,持久层采用Hibernate实现,理论上说,只要Hibernate支持的数据库JBPM都支持。同时它还能被部署在任何一款JAVA应用服务器上 JBPM的工程文件,大家可以到...
jbpm介绍jbpm介绍jbpm介绍jbpm介绍jbpm介绍jbpm介绍jbpm介绍jbpm介绍jbpm介绍jbpm介绍jbpm介绍jbpm介绍
jbpm jbpm4.3.jar DDDDDDDD
自学Jbpm,根据教程自己写的web版本的Demo,欢迎下载测试。里边包含了业务流程的创建,发起,驳回,删除等。如果没有积分的同志请到我的博客里边去寻找联系我的QQ链接,发送QQ或者邮件来索取。
jboss jbpm4最新开发包 采用了pvm框架
JBPM4 SSH EXTJS JBPM SSH EXTJS JBPM4 SSH EXTJS JBPM SSH EXTJS JBPM4 SSH EXTJS JBPM SSH EXTJS JBPM4 SSH EXTJS JBPM SSH EXTJS 希望对大家有帮助。
jboss jbpm 5.0 最新版jboss jbpm 5.0 最新版jboss jbpm 5.0 最新版jboss jbpm 5.0 最新版jboss jbpm 5.0 最新版jboss jbpm 5.0 最新版jboss jbpm 5.0 最新版
jbpm4。4中表之间的关系,jbpm4 表关系
开发整理出了一个Web版本下的JBPM流程的创建,发起,审批,驳回等一系列操作的Demo,欢迎各位初学者下载查看。没有积分的网友可以去我的csdn博客找到“联系我”的模块,在左下角,通过QQ或者邮件的方式跟我索取
,jbpm4的源码,分支,会签等一些中国特色建立下载《jBPM4工作流应用开发指南.pdf》这本书
一个完整的jbpm4工程项目且带有源码,web工程。
JBPM5工作流引擎 S2SH+JBPM4.4开发工作流的一个完整的请假流程例子。带有文档教程和所有源码+JAR包。在网上找了半天jbpm6\jbpm7的资料,都很少。所以 环境:Myeclipse2015 JDK1.7 mysql 5.0 Struts2+Spring3.1 1...
java源代码分包详解JBPM4 java源代码分包详解JBPM4
\jbpm简介\jbpm简介\jbpm简介\jbpm简介\jbpm简介
JBPM数据库表创建\jbpm.jpdl.oracle.sqlJBPM数据库表创建\jbpm.jpdl.oracle.sqlJBPM数据库表创建\jbpm.jpdl.oracle.sqlJBPM数据库表创建\jbpm.jpdl.oracle.sqlJBPM数据库表创建\jbpm.jpdl.oracle.sql
每一个流程产生了多少个流程实例,有哪些流程实例结束了,哪些处于活动状态,哪些挂起了;同时对于每一个流程实例当前走到什么位置了(流程的进度状况)等等。通过查看JBPM的API我们发现API里并没有提供实现该功能...