[kukeltje]

I don't think Tom disagrees with you (and he might not have reread the whole thread, otherwise I think he would have made a different statement).

The thing is, is that the target of the *current* release of jBPM 4 was 'normal users' and not to support multiple models. That is intended for 4.1/4.2 so the 'not programming against interfaces' currently is not a real problem. For you it is, and your remarks are valid (I think Tom agrees on that). The only thing I disagree with is your remark about it being released to soon. Nobody expected that someone would pick this part up that quickly. :-)

The easiest thing you can do is make patches, attach them to a jira issue and they will get fixed some time it the future. The best you can after that is flooding this list with requests about reviewing your patches and in the meantime fill in the contributors agreement. If both 'succeed' you can make the patches yourself and discuss on this list the directions of your other repository solution.

[jorgemoralespou_2]

Thanks,
Is jBPM targeted to be extendible by developers from outside JBoss.org? If so, I think that one really lacking feature is design documentation, as I have to dive into the internal API, where there is no much javadoc, nor documentation.
I'll try to post my questions in here as they arise in the hope of letting me fulfill my requirements, and I'll try to flood the list with requests and questions, so In Memory Process Execution can become a reality.

[kukeltje]

Is jBPM targeted to be extendible by developers from outside JBoss.org?

Yes it is, but for now that is limited to make custom nodes, eventhandlers etc.. and to some extend custom services (like IDM).

As mentioned earlier by Tom (second post)

that is a target. but we'll be only able to bring this to the surface in the mid term

and the fourth post:

the direction we're thinking in for that use case is to use the ProcessBuilder to create process definitions. Probably we can leverage the JpdlParser for that as wel. That will immediately give most of jPDL features instead of having to start from an empty PVM. Maybe some dependencies on the environment configuration sneeked in here or there.

Our current idea is to use methods on the objects themselves for the memory execution mode, and skip the services api's

It would be great if you could try that direction and see where you run into problems.

So yes it is, but you are 'early' and doing groundbraking work :-).

If so, I think that one really lacking feature is design documentation, as I have to dive into the internal API, where there is no much javadoc, nor documentation.

And yes, that is one of the reasons docs in this area are not there.

I'll try to post my questions in here as they arise in the hope of letting me fulfill my requirements, and I'll try to flood the list with requests and questions, so In Memory Process Execution can become a reality.

What you do is of interest, and with detailed questions in separate topics I'm sure the core devs are willing to help/comment.

[tom.baeyens]

"jorgemoralespou_2" wrote:
I started by trying to create a new RepositoryService, that hold Deployments in memory (probably a JBossCache in the future). For that I have my MemoryRepositoryService (with its binding in jbpm.user.wire.bindings.xml). I could reuse most of the commands in RepositoryService, but createDeployment has to create a new DeploymentImpl, since the one in the core depends on hibernate (LOB). And from there I have to replicate tons of classes that could have done it if it would have referenced NewDeployment instead of DeploymentImpl.

usually i use protected as the default, so you could consider inheriting the existing services and just overwrite one method with your custom command.

if there is a simple way on how we can make a small change to make your customizations easier, post them very concrete and we'll always consider them.