June 2008 - jbpm-dev - Jboss List Archives

[Design of JBoss jBPM] - Re: jBPM3 switched to maven

by thomas.diesler＠jboss.com

Hi Alejandro, so far we have not setup a public jbmp maven site. I use the above to generate the site locally and then puch is manually to http://jbpm.dyndns.org/jbpm-site/ This is maily to give access to the API javadocs View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161401#4161401 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161401

15 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM3 switched to maven

by alex.guizar＠jboss.com

Note for starters: you need to add the snapshots repository or your fresh maven build will not work. <repositories> | <repository> | <id>jboss-snapshots</id> | <url>http://snapshots.jboss.org/maven2/</url> | </repository> | </repositories> Thomas: is this intentional? I saw the following snippet in the POM which doesn't look quite right... <distributionManagement> | <site> | <id>jbws.dyndns.org</id> | <url>file:///home/tdiesler/workspace/jbpm-site</url> | </site> | </distributionManagement> View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161265#4161265 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161265

15 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jPDL 4 early feedback

by alex.guizar＠jboss.com

I believe we should have a validating parser all the time. This would have two benefits: * the jPDL parser would be simpler because it would not have to concern itself with checking constraints that are already expressed in the schema document. * error reporting to users would be better, because we can capture the syntax error list from the XML parser and return it along the semantic errors detected by the jPDL parser. On the other hand I understand that users that always enter schema-valid documents (such as those produced by the designer) would want to save the overhead of validation. The configurable XML parser that you propose would be the solution there. A separate validation step is less useful in my view, because it adds more overhead compared to the validate-as-you-parse approach. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161253#4161253 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161253

15 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining a public API for jBPM

by tom.baeyens＠jboss.com

This is what I think we should provide: 1) drop in replacement for micro version upgrades like 3.2.3 to 3.2.4 2) DB migration support for db between minor version upgrades like 3.2.x to 3.3 3) DB coexistence support between major version numbers so a 3.x installation can run next to a 4.x installation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161209#4161209 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161209

15 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining a public API for jBPM

by tom.baeyens＠jboss.com

"alex.guizar(a)jboss.com" wrote : anonymous wrote : Database layout is considered implementation detail that might change between minor versions. | I see this one as a source of discontempt among folks (like me) who would expect each new minor version to be a drop-in replacement for the previous minor version, unless the changes are purely additive or we provide migration scripts (not fun). I believe major versions are the place for disruptive changes in the database schema. I think you are referring to micro releases. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161206#4161206 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161206

15 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining a public API for jBPM

by alex.guizar＠jboss.com

anonymous wrote : Database layout is considered implementation detail that might change between minor versions. I see this one as a source of discontempt among folks (like me) who would expect each new minor version to be a drop-in replacement for the previous minor version, unless the changes are purely additive or we provide migration scripts (not fun). I believe major versions are the place for disruptive changes in the database schema. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161198#4161198 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161198

15 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM3 switched to maven

by camunda

jbpm 3 moved to SVN? Since when? I still have the CVS access and thought only the PVM and jbpm 4 will move to SVN? By the way: Good news, that a lot of improvements are made. But at the moment it is maybe already too much? I can not work on jBPM full time and have other stuff to do. If everything changes in the development environment it is hard to keep track and commit small patches and stuff... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161196#4161196 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161196

15 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM3 should release lock-step with jPDL4

by tom.baeyens＠jboss.com

"thomas.diesler(a)jboss.com" wrote : I think we should have a consistent naming scheme (i.e. either we use the jBPM prefix or not) | good point. let's take "jPDL {version}" "thomas.diesler(a)jboss.com" wrote : Therefore I propose for jPDL4 a release cycle that aligns with jBPM3. Faster than eight weeks is very hard to manage anyway given the documentation and test coverage that is required. | the problem is that i need enough coverage in jPDL 4 to know that the basic public API starts off in the right direction. some of the advanced concepts will have their impact on the basic part of the api. i wanted to reflect with this release schedule that in my estimation, jPDL 4.0.alpha2 has enough coverage so that we can be confident that the basic parts of the api remain stable. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161185#4161185 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161185

15 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - jBPM3 should release lock-step with jPDL4

by thomas.diesler＠jboss.com

Folks, looking at the road map, I see jBPM jPDL 3.2.4 (01-Sep-2008) jPDL 4.0 alpha1 (01-Aug-2008) jPDL 4.0 alpha2 (11-Sep-2008) First, I think we should have a consistent naming scheme (i.e. either we use the jBPM prefix or not) Second, it is important that the releases go lock-step with respect to the API. Only if the functionality offered through the API actually has an implementation in both code bases we can be sure that it is the API that we want. Therefore I propose for jPDL4 a release cycle that aligns with jBPM3. Faster than eight weeks is very hard to manage anyway given the documentation and test coverage that is required. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161167#4161167 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161167

15 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM3 switched to maven

by tom.baeyens＠jboss.com

i didn't realize that our community missed it so much. great move, Thomas ! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161084#4161084 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161084

15 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jbpm-dev June 2008