package restructuring

[tom.baeyens]

here's the package renaming that i would like to introduce

current name ......................... destination package name

org.jbpm ............................. org.jbpm.pvm
org.jbpm.cal ......................... org.jbpm.pvm.internal.cal
org.jbpm.client ...................... org.jbpm.pvm.internal.svc
org.jbpm.deploy.Deployment ........... org.jbpm.pvm
org.jbpm.deploy ...................... org.jbpm.pvm.internal.deploy
org.jbpm.enterprise .................. org.jbpm.pvm.internal.ejb
org.jbpm.env ......................... org.jbpm.pvm.env
org.jbpm.env.context ................. org.jbpm.pvm.internal.env
org.jbpm.env.impl .................... org.jbpm.pvm.internal.env
org.jbpm.env.session ................. org.jbpm.pvm.session
org.jbpm.env.tx.Transaction .......... org.jbpm.pvm.env
org.jbpm.env.tx ...................... org.jbpm.pvm.internal.tx
org.jbpm.env.xml.EnvironmentParser ... org.jbpm.pvm.env
org.jbpm.env.xml ..................... org.jbpm.pvm.internal.env.xml
org.jbpm.hibernate ................... org.jbpm.pvm.internal.hibernate
org.jbpm.jms ......................... org.jbpm.pvm.internal.jms
org.jbpm.jobexecutor ................. org.jbpm.pvm.internal.jobexecutor
org.jbpm.lob ......................... org.jbpm.pvm.internal.lob
org.jbpm.log ......................... org.jbpm.pvm.internal.log
org.jbpm.pvm.impl .................... org.jbpm.pvm.internal.impl
org.jbpm.pvm.impl.op ................. org.jbpm.pvm.internal.impl.op
org.jbpm.pvm.job ..................... org.jbpm.pvm.internal.job (implementations)
org.jbpm.pvm.job ..................... org.jbpm.pvm.job (extract interfaces)
org.jbpm.pvm.log ..................... org.jbpm.pvm.internal.processlog
org.jbpm.pvm.type .................... org.jbpm.pvm.internal.type
org.jbpm.stream ...................... org.jbpm.pvm.internal.stream
org.jbpm.util.Listener ............... org.jbpm.pvm.util
org.jbpm.util.Observable ............. org.jbpm.pvm.util
org.jbpm.util ........................ org.jbpm.pvm.internal.util
org.jbpm.wire ........................ org.jbpm.pvm.internal.wire
org.jbpm.xml.Parser .................. org.jbpm.pvm.util
org.jbpm.xml.Parse ................... org.jbpm.pvm.util
org.jbpm.xml ......................... org.jbpm.pvm.internal.xml

This excercise revealed that the distinction between API and implementation was way more blurry then I thought it was.

The main goal of this separation is improving the user experience. Users should be able to use all of the straightforward functionality by only using the public API. Only for tricky things, users might revert to the internal packages that serve as a kind of back door.

By indicating very clearly the API and minimizing it, we create much more maintainable situation between pvm and its users.

In the next couple of weeks I'll be refactoring towards this restructuring and describing the intended usage in different environments.

So for the next weeks till this refactoring is done, always sync up front with me in this forum before you want to apply changes.

[mvaldes]

Hi Tom,

This is my proposal (Bull side) regarding this refactoring:

- We will continue our stabilization/test/quality process on XPDL and BPEL extensions using the PVM 1.0alpha2 version. This process will conclude next week with the release of RC2

- After this period we should be in synch to work together on PVM stabilization (for that time I guess you will finish the package renaming and refactoring).

What I would like to do on this part is to focus on how to get the PVM robust and stable enough to release the PVM 1.0.

I would like to dedicate the same effort that the one we are doing on extensions.

At that time I should also require to migrate our extensions to the PVM 1.0.

On the meantime, Guillaume will post on some issues/bugs he has already found on the activities instance.

best regards,
Miguel Valdes

[tom.baeyens]

"mvaldes" wrote:
- After this period we should be in synch to work together on PVM stabilization (for that time I guess you will finish the package renaming and refactoring).

the rough structure should be in place by then.

"mvaldes" wrote:
What I would like to do on this part is to focus on how to get the PVM robust and stable enough to release the PVM 1.0.

I would like to dedicate the same effort that the one we are doing on extensions.

great. the first thing that you guys can validate is where the extensions have to go outside of the api. for each use case of internal classes we have to examine why and if we can avoid it.

"mvaldes" wrote:
At that time I should also require to migrate our extensions to the PVM 1.0.

after the restructuring, i would like to release a first beta. that would be a good candidate to update the dependencies.

"mvaldes" wrote:
On the meantime, Guillaume will post on some issues/bugs he has already found on the activities instance.

make sure it's synchronized with me as i'm in the middle of the package restructuring now

[tom.baeyens]

first big chunk is done. the javadocs now generate only the docs for the api. feedback is welcome

[estaub]

Applause for the renaming! The lack of interfaces and clear lines in JBPM3 is a big problem for us - I'm going to have to develop our own wrapper API.

-Ed Staub

[tom.baeyens]

thanks for your support.

in 3, I envisioned that people wrote their own wrapper api's

we have hopes that now we can cover a big enough part of what people need with our new approach.

starting pvm, i thought i was doing this already. but introducing the package naming structure made it clear that there was still a lot of overlap between api and impl. doing this excercise turned (already) out to be a big advancement