Project layout for business archives

[tombaeyens]

In the past, I always saw executable processes always inside the project where developers created their own business application.  I think it becomes a lot easier to guide developers when we use the convention and advice that developers should use a single project for every business archive that they build.  Then still all the Java integrations remain as valid as before.  But the ant and maven integrations will be simpler to provide and understand.  Also it will be easier to embed such a project layout in various (multiple!) scenarios/styles of collaboration around process authoring.

Here are some ideas.  Not all very structured or exhaustive, but I hope they are a good start for the discussion.

Proposed project layout:

+ src/main/java –> contains delegation classes that will be deployed in the business archive (future feature)
+ src/main/resources –> .bpmn20.xml process files and other resources like forms and rules
+ build.xml
|   + target 'bar' creates the business archive
|   + target 'deploy' should deploy the business archive to the configured deployment location
+ pom.xml –> alternative for the build.xml file for developers prefering maven.  
     + 'mvn clean install' builds the business archives and deploys it to the local repo
     + 'mvn clean deploy' should deploy it to the configured deployment location‍‍‍‍‍‍‍‍

Deployment locations could be
* Activiti Engine
* Some versioned file based repository manged by Activiti Cycle from which sys admins can pick it up
* Maven repository in the case of maven

In case of ant based building, the Activiti Engine lib dependencies still need to be fetched from somewhere.  Setup contains the capability to copy the libs in libs folders as it's done with the examples projects.  It's based on the .txt files containing all the dependencies.   That could be inspiration for the ant based approach.

For example (just thinking/dreaming out loud):
Activiti Designer could have a new BPMN 2.0 business archive project.  First choice is ant or maven.  Suppose we select ant. Then a new screen presents the optional features for which library dependencies have to be included like groovy, jpa, cxf etc.  By default all checkboxes should be checked to minimize troubles for beginners.  Only more advanced developers may want to minimize the lib dependencies.    For the Designer to be able to generate the project and fetch the dependencies, it would also need a configuration property that points to an Activiti installation from which the dependencies .txt files and the library jars are used.

This would imply that we also have to offer the same wizard in e.g. Activiti KickStart as we also have to let people choose the build tool and where they want to create their new project.

[tombaeyens]

What you describe is exactly what is currently done in the default project layout (maybe you have a look at it?). we have a Maven project but an additional Ant file for the deployment, using the Maven-Ant-Tasks to call Maven.

ok, that looks good.

What is not yet there is, that it should be a Multi-Module-Maven Project with Modules for the bar and Modules for the jars.

there are 2 flavours of class deployment that we want to support:
1) classes in a jar in the webapp's classpath.  that is the only option we support today.
2) asap (one of the next months?) we'll also support classloading from the business archive.

we should take into account that we'll want to support both of those approaches.  so they should preferrably be consistent with each other.

from what i can see now, it makes the most sense to focus on just a single business archive module that serves the business archive purpose. 

for the delegation classes that should be deployed to the webapp, people should use the existing jar packaging.  basically there is nothing we can offer there.  maybe an ant script that copies the resulting jar file to the webserver.  but that is probably not necessary.  as the jar file will typically be included into a user war as a dependency.

i think we can also leave the combination these and other modules into a multimodule project to the user.

For the moment I would be happy with that solution. In the long run a Maven Plug-In could make sense as well, but from my side we can skip this for now.

agreed with skipping that for now.  I don't see the need for that as well.  We should be able to do it by using plain pom configurations and a plugin here and there.

For the example projects: Best would be to migrate them to the Maven structure as well as soon as we have it. That indeed should better be the same IMHO.

See my earlier post: we had that before and users ran into problems with that approach.  And most problematic was that if there's problems, the examples build was a piece of magic and they got stuck completely.  That was the original reasoning why we switched back to including the jars in the distro and why i brought up this thread in this context. 

So i think we're looking at a tradeoff here.  Or we have the distro example project consistent with the template-real-life project, in which case the template-real-life project it has to be ant based.  Or we accept this difference between distro example project (ant based) and the template-real-life project (maven based)

[bernd_ruecker]

Okay, actually I don't care too much about the examples personally, so I don't have problems to treat them differently.

But you now raise a third subject, which is indeed interesting. What kind of architectures and deployment options should be supported.

You described:
1.) Including libs in the Activiti rest webapp (actually: The current Ant file copies the jar already there for you. Please take a look at the current template).
2.) Adding Activiti jars to your own app together with the delegation classes and start an own engine within your app (would work with war, ear, …)

What is missing IMHO is a third variant
3.) Having an single Engine deployed and but deploying several applications containing delegation classes

But that gets interesting. I see different approaches to make that happen:
a) Deploying the Delegates together with the bar file
   –> I think that is a poor solution. Classes in the database a bad idea. And you not only need delegation classes, but client-jars, third party libs, …
b) Hooking into the Deployment Architecture of the server. This is what we did with jBPM 3 already (see http://www.bpm-guide.de/2008/10/16/jbpm-deployer-for-jbpm-in-enterprise-environments/ and http://www.bpm-guide.de/2008/11/14/jbpm-deployer-status-and-sourcecode/).
   –> Advantage: Really Enterprise ready
   –> Disadvantage: Service specific solution

It would be pretty interesting for us to tackle the third case, since this are the real Enterprise installations, but then I don't see a Tomcat but a JBoss solution…
And as stated: Having the classes in the database is not worth the effort IMHO.

[bernd_ruecker]

Hey guys.

Somehow we should draw a conclusion on this and take the next actions on this topic. The deployment options are still interesting, if we clarified this I think we can build a starting default project layout using Maven and Ant as sketched above. Therefor the main action would be to translate the current ZIP-Template into a proper Maven Archetype…

Cheers
Bernd

[mproch]

What is missing IMHO is a third variant
3.) Having an single Engine deployed and but deploying several applications containing delegation classes

With activiti-osgi module it is currently possible to deploy jars/business archives as OSGi bundles. The only point that is missing is classloading stuff.
We find this to be the best solution for processes that are more focused on service integration - this way they can be deployed e.g. in Servicemix ESB.

I guess it's not suitable for all uses - but I think it's quite important option.

[tombaeyens]

agreed, we need to come to conclusion.  let's discuss it as well on the phone in our meeting next week.

i think putting classes in the bar (and hence in the db) could be a good default as that solution works in all situations without the user having to be very concerned.   i agree that we might have to provide multiple ways to deploy classes, but let's limit the number of ways as that might get challenging for a new user on what he has to do.

then if you want performance optimizations, then you could do other stuff.  but speaking of performance, there is a difference between jbpm 4 and what we have now.  now we can properly cache the deployment classloaders if we want.  that way they will only be read once and the class files will end up in perm gen space just like any other class that is loaded in the vm.  just a thought.

another option that we could investigate is temporary directories.  in that case we deploy classes and dependent jars on a temporary directory on the server.  then we can create a new plain classloader based on that temp/working directory.  then the DB is still the reference and we get the performance of file based classloading.  and this solution would also work in clustering mode.  and an advantage is that the user always can use the same model for deployment.  that might be another path we need to explore.  can anyone see problems with this approach?

[bernd_ruecker]

I like the directory approach much more than the db one. Not because of performance, but just serializing classes in a database is wrong. No customer with some serious app ever did it in jBPM, it was always "just" to play around. Having it file based could be a compromise. But then versioning and isolation will be interesting (again, it is not only the delegate, but their dependencies) and I am a bit afraid that we rebuild a whole classloader hierarchy already there in Java EE app servers. Then it would make more sense to introduce a clean JBoss Deployer/Classloading integration in my eyes.

For OSGI I cannot say too much, since I am not an expert in that area. The most projects we are currently in use Java EE (JBoss AS), but some now use a Tomcat/Spring architecture as well. We start to see OSGI related projects as well, but I still have to understand that more to comment on it 😉

[nico1]

I agree we should have a convention for one project per business archive.
The proposed project layout also looks fine with me.
I don't know if I agree with a choice between an Ant and a Maven based project. To get the necessary project dependencies Maven, to my opinion, is a better approach because it's pretty much the default standard in Java space and also very convenient for Cycle and Designer to use. So I'm thinking about the following approach for the project layout:

1. To start with, we have a Maven based project structure with an additional Ant build file just for deploying and creating the BAR file.
2. When the Maven plugins are in place, we can optionally remove the Ant build file, because deployment and BAR creation are then possible via Maven.

Best regards,

Tijs

Do you have an example of 2. Tijs?

In my case, I have a maven project that creates a jar (delegates) and a .zip (bar) using a Maven assembly. So, I have my jar and .zip release which I then add as a dependency in e.g. explorer. Where it becomes a real pain is deploying the zip. I've been looking for an example of a Maven pom that deploys a .bar and cannot find one anywhere, please share if anyone has an example.