If you want to make sub pages, make sure that they begin with JbpmPvm so that they don't interfere with the rest of the JBoss wiki namespace.

Persistence

See JbpmPvm_Persistence

Tempranillo meeting 25-26 september 2007

(tempranillo refers to the project name in svn of the PVM sources, not to the wine that we will drink after the meeting)

Variables (marc)

• Dynamic searching for variable mappings should be removed from the VariableMap.createVariable

• Instead a MappingFinder interface should be created.  And the mapping.finder should be fetched from the environment.  This mapping finder should be searched for in process definition (in case you run multiple process language in one instance) and application context.

Inclusion mechanism for configuration files

• xinclude will probably limited to urls only.  if we create our own include binding, we can have a url and resource attribute to reference other files to include into the current configuration file.

Orchestra project structure: Maven vs Ant+Ivy. Other PVM modules will be impacted, i.e: PVM, enterprise. Build module to be removed ?

• We'll switch to Ivy for the dependency management in all the projects

• Projects need to be buildable individually without the a dependency on the build project.  The common build targets will be duplicated in all the build files.

• The build project will still be used for overall targets like clean, publish and test.  The test will be the main continious integration target.

• Bull is going to set up a duplicate of the repository in http://repository.jboss.com/jbpm/ivy using anoncvs.  This repository will be the public backup repository

BPEL web services pluggability layer

• BPEL is going to have it's own SPI for plugging in different web service implementations

• Bull develops by default against the axis implementation of that SPI

Persistence pending issues

• Inventory of issues with JPA needs to be properly documented.  This way, we can focus on finding an acceptable alternative.

• Tom will check for which issues in jBPM currently user types are used

Inventory of persistence issues

• application cache (impacts jpa/hibernate big time)

• inheritence mappings / language pluggability in db schema  (impacts jpa/hibernate big time)

• equals with proxies (impacts jpa/hibernate)

• truncating/checking length of strings  (impacts jpa/hibernate)

• cascading  (impacts jpa/hibernate, but should be trivial)

• optimistic locking with versioning

• object references

• blobs and clobs

Application cache

• Guillaume will check usage of 2nd level cache for process definition caching.  A test case should show that 2 consequetive tx leverage caching of process definition objects.  Another test will show process deployment and process updates.

Equals with proxies

Class and database models.  how ?  first ?

1. Clear separation between definition, execution, historic and wiring data.  Each of these should be developed in separate iterations.  First some testing of the difficult parts, then modelling to overview, then implement a first complete iteration.

2. Cascading should be defined on a model

3. Inheritence mapping should be described on paper or in model

4. Implementation can only be started after 2) and 3)  Until then, all implementation work is experimenting and learning.

Test suite layout:

• Guillaume adds last pieces of the test configurability.

• Tom checks if Guillaume can get write access to the hudson integration test configurations

• We should both announce on the forums when we are starting build refactorings to prevent breaking each other's work

Background:

1) Sources should contain 4 test suites in package org.jbpm

• Standalone test suite

• Persistence test suite

• Stress test suite

• All test suite that combines all the above

2) IDE

• Only hibernate/hsqldb

• 1 classpath (the full classpath)

• Should work from the sources

3) Continious integration

• By hudson

• By running ant script

• Each test suite should be run in proper minimal classpath

• Properties in ${user.home} to configure different test runs

• Minimal: {java 5 | java6} X {standalone | persistenceConfiguration}

• --> where persistenceConfiguration = {jpa-impl} X

Do we still need the profile's in the build ?

no

PVM first release schedule

Storing execution state in the business object

Tasks:

• We should check following projects first for ideas or code that we can leverage:

• http://wiki.open-esb.java.net/Wiki.jsp?page=WLMSE .

• http://www.imixs.org .

• Separate component or inside of the pvm jar ?

• Relation to identity component

• How will we organize the relation between tasks and executions ?

• Will we verify BPEL4People compatibility ?

• Other project

Version naming scheme

For the library versioning, we'll use 3 version identifiers: major, minor and micro.  E.g. 0.0.1 or 3.1.0  We won't use status indicators like alpha, beta or ga.  The micro version is incremented each time when there is a new release which does not include db schema changes, xml schema changes nor forward incompatible API changes.  For releases that have changes to db schema, xml schema or non-compatible API update, the minor version number must be incremented.  Whenever we feel big functional changes justify it, we can increment the major version number.

For the product versioning, each of the companies is free to have their own schema.

For branch names created in svn, it is probably best to base them on the product versions.  As then it is easier to find the right branch across many subprojects.  This is in the assumption that we won't need many branches.