- 浏览: 296097 次
- 性别:
- 来自: 唐山
-
最新评论
-
小灯笼:
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 2785Hi All, 打算2010年11月27日下午13 ... -
轻量级工作流引擎jBPM 4.4正式发布
2010-07-20 19:31 5710jBPM-4.4于2010年7月19日正式发布。 jBP ... -
拖延一个多月后,jBPM-4.4发布CR1候选版
2010-07-15 22:06 2341Alejandro太谨慎了,发布jBPM-4.4之前还搞了一个 ... -
jBPM-4.3所需的最小依赖库列表
2010-06-18 17:06 5107这个问题被问到的次数太多了,无可奈何,只好花点儿时间整理一下。 ... -
jbpm4experiment——基于jbpm4的试验性项目
2010-05-31 14:15 5392官方的发布以稳重为主,所以也让人感觉步伐迟缓,自己建一个项目则 ... -
jBPM 4.4发布日期暂定于2010年6月4日
2010-05-24 09:51 2815jbpm官方终于传来好消息,jBPM 4.4可能在下月初发布。 ... -
jBPM 创始人发布BPMN原生引擎Activiti-5.0-alpha1
2010-05-20 09:21 5769Tom Baeyens也就是jBPM的原作者,离开了Red H ... -
寻求重现jbpm4.3中executionId映射错误的场景
2010-04-27 10:56 2649目前测试的结果是hibernate-3.2.1.ga以及之前 ... -
不选或许有千万种理由,但是选择hibernate只需要一个理由就足够了
2010-03-19 12:37 4650选择一门新技术,首先要看这门技术是否能够满足目前应用的需求,我 ... -
跟我学工作流——jBPM4视频教程(免费)
2010-03-06 15:40 29768新的一年,为了让工作流方面的初学者更快上手开发,我们录制了jB ... -
jBPM-4.x常见问题解决方案FAQ
2010-01-22 09:18 3102这段时间整理的jBPM-4.x常见问题以及解决方案,希望帮助对 ... -
轻量级工作流jBPM-4.3官方“开发指南”中文版
2009-12-30 13:41 4588jBPM-4.3这次升级的重头戏都放在开发指南里了,添加的最大 ... -
轻量级工作流jBPM-4.3官方“用户手册”中文版
2009-12-30 11:25 3594jBPM-4.3准时发布,这次用户手册修改不大,主要是换换xm ... -
谁应该用流程设计器
2009-11-23 12:44 1985谁应该用流程设计器 ... -
数据建模与业务建模
2009-11-20 09:43 2520数据建模与业务建模 无论是企业信息系统还是web网站,各种大 ...
相关推荐
内容概要:本文详细介绍了基于MATLAB GUI界面和卷积神经网络(CNN)的模糊车牌识别系统。该系统旨在解决现实中车牌因模糊不清导致识别困难的问题。文中阐述了整个流程的关键步骤,包括图像的模糊还原、灰度化、阈值化、边缘检测、孔洞填充、形态学操作、滤波操作、车牌定位、字符分割以及最终的字符识别。通过使用维纳滤波或最小二乘法约束滤波进行模糊还原,再利用CNN的强大特征提取能力完成字符分类。此外,还特别强调了MATLAB GUI界面的设计,使得用户能直观便捷地操作整个系统。 适合人群:对图像处理和深度学习感兴趣的科研人员、高校学生及从事相关领域的工程师。 使用场景及目标:适用于交通管理、智能停车场等领域,用于提升车牌识别的准确性和效率,特别是在面对模糊车牌时的表现。 其他说明:文中提供了部分关键代码片段作为参考,并对实验结果进行了详细的分析,展示了系统在不同环境下的表现情况及其潜在的应用前景。
嵌入式八股文面试题库资料知识宝典-计算机专业试题.zip
嵌入式八股文面试题库资料知识宝典-C and C++ normal interview_3.zip
内容概要:本文深入探讨了一款额定功率为4kW的开关磁阻电机,详细介绍了其性能参数如额定功率、转速、效率、输出转矩和脉动率等。同时,文章还展示了利用RMxprt、Maxwell 2D和3D模型对该电机进行仿真的方法和技术,通过外电路分析进一步研究其电气性能和动态响应特性。最后,文章提供了基于RMxprt模型的MATLAB仿真代码示例,帮助读者理解电机的工作原理及其性能特点。 适合人群:从事电机设计、工业自动化领域的工程师和技术人员,尤其是对开关磁阻电机感兴趣的科研工作者。 使用场景及目标:适用于希望深入了解开关磁阻电机特性和建模技术的研究人员,在新产品开发或现有产品改进时作为参考资料。 其他说明:文中提供的代码示例仅用于演示目的,实际操作时需根据所用软件的具体情况进行适当修改。
少儿编程scratch项目源代码文件案例素材-剑客冲刺.zip
少儿编程scratch项目源代码文件案例素材-几何冲刺 转瞬即逝.zip
内容概要:本文详细介绍了基于PID控制器的四象限直流电机速度驱动控制系统仿真模型及其永磁直流电机(PMDC)转速控制模型。首先阐述了PID控制器的工作原理,即通过对系统误差的比例、积分和微分运算来调整电机的驱动信号,从而实现转速的精确控制。接着讨论了如何利用PID控制器使有刷PMDC电机在四个象限中精确跟踪参考速度,并展示了仿真模型在应对快速负载扰动时的有效性和稳定性。最后,提供了Simulink仿真模型和详细的Word模型说明文档,帮助读者理解和调整PID控制器参数,以达到最佳控制效果。 适合人群:从事电力电子与电机控制领域的研究人员和技术人员,尤其是对四象限直流电机速度驱动控制系统感兴趣的读者。 使用场景及目标:适用于需要深入了解和掌握四象限直流电机速度驱动控制系统设计与实现的研究人员和技术人员。目标是在实际项目中能够运用PID控制器实现电机转速的精确控制,并提高系统的稳定性和抗干扰能力。 其他说明:文中引用了多篇相关领域的权威文献,确保了理论依据的可靠性和实用性。此外,提供的Simulink模型和Word文档有助于读者更好地理解和实践所介绍的内容。
嵌入式八股文面试题库资料知识宝典-2013年海康威视校园招聘嵌入式开发笔试题.zip
少儿编程scratch项目源代码文件案例素材-驾驶通关.zip
小区开放对周边道路通行能力影响的研究.pdf
内容概要:本文探讨了冷链物流车辆路径优化问题,特别是如何通过NSGA-2遗传算法和软硬时间窗策略来实现高效、环保和高客户满意度的路径规划。文中介绍了冷链物流的特点及其重要性,提出了软时间窗概念,允许一定的配送时间弹性,同时考虑碳排放成本,以达到绿色物流的目的。此外,还讨论了如何将客户满意度作为路径优化的重要评价标准之一。最后,通过一段简化的Python代码展示了遗传算法的应用。 适合人群:从事物流管理、冷链物流运营的专业人士,以及对遗传算法和路径优化感兴趣的科研人员和技术开发者。 使用场景及目标:适用于冷链物流企业,旨在优化配送路线,降低运营成本,减少碳排放,提升客户满意度。目标是帮助企业实现绿色、高效的物流配送系统。 其他说明:文中提供的代码仅为示意,实际应用需根据具体情况调整参数设置和模型构建。
少儿编程scratch项目源代码文件案例素材-恐怖矿井.zip
内容概要:本文详细介绍了基于STM32F030的无刷电机控制方案,重点在于高压FOC(磁场定向控制)技术和滑膜无感FOC的应用。该方案实现了过载、过欠压、堵转等多种保护机制,并提供了完整的源码、原理图和PCB设计。文中展示了关键代码片段,如滑膜观测器和电流环处理,以及保护机制的具体实现方法。此外,还提到了方案的移植要点和实际测试效果,确保系统的稳定性和高效性。 适合人群:嵌入式系统开发者、电机控制系统工程师、硬件工程师。 使用场景及目标:适用于需要高性能无刷电机控制的应用场景,如工业自动化设备、无人机、电动工具等。目标是提供一种成熟的、经过验证的无刷电机控制方案,帮助开发者快速实现并优化电机控制性能。 其他说明:提供的资料包括详细的原理图、PCB设计文件、源码及测试视频,方便开发者进行学习和应用。
基于有限体积法Godunov格式的管道泄漏检测模型研究.pdf
嵌入式八股文面试题库资料知识宝典-CC++笔试题-深圳有为(2019.2.28)1.zip
少儿编程scratch项目源代码文件案例素材-几何冲刺 V1.5.zip
Android系统开发_Linux内核配置_USB-HID设备模拟_通过root权限将Android设备转换为全功能USB键盘的项目实现_该项目需要内核支持configFS文件系统
C# WPF - LiveCharts Project
少儿编程scratch项目源代码文件案例素材-恐怖叉子 动画.zip
嵌入式八股文面试题库资料知识宝典-嵌⼊式⼯程师⾯试⾼频问题.zip