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.

[trademak]

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

[tombaeyens]

i can see the dependencies convenience we get from maven.  that is exactly why in the rc1 i tried to leverage that in the distro.  turns out that many of our users ran into trouble with that.  and the big problem was that if they ran into trouble, they didn't have a clue on how to fix it.  therefor I switched to including the libraries back into the distribution and build the mechanism based on the setup/files/dependencies/*.txt files that list the dependencies. 

there are pro's and con's in both approaches.  but I think it is important that we stick with 1 consistent approach for dealing with dependencies in the example projects and in the template project.

we already have a dependency on ant for out users.
we should only introduce an extra dependency on maven if that is necessary.  and i don't see that necessity yet.
on the contrary, i can see how all scripting work could be done in ant, but not in maven.
with ant:
- easier to leverage the ant deployment task.  how do integrate that in the maven deploy phase.  doable but more tricky imo.
- eclipse standard edition has an ant view in which you can drag and drop the project files and then double click on the targets.  with maven you need to install the maven plugin… and even then there is nothing like that afaict.

what is the benefit for using maven as the build in the example/template project?

[bernd_ruecker]

First an answer for Tijs (for your mail as well): I would be pretty happy with Maven and one additional Ant file. A template project for this is already present which is used in the "CreateDefaultMavenProject". Currently it is packed as zip, but creating an archetype from it (and adjust it correctly) is not a big deal.

Now for Ant vs. Maven: Actually I am tired of discussing that all over again all the time everywhere. In most real life project I now see Maven being used, and I would use that as the default for now. Then we could easily propose a default layout with Multi Module projects, one containing the classes, one the processes and forms for the bar, and maybe a war or whatever. Maven has the built in Archetypes, in Ant we have to do that all on our own.

How do you want to do the dependency management in the default project then? Please not with some stuff like "Eclipse classpath containers" or the like, I hate that in Drools or jBPM, because projects are not easy importable in a normal Eclipse or runnable without Eclipse.

Ant and Ivy would be a second option, a valid one! But I would go for it only in the second step. And then you have to explain the people Ivy or any other dependency mechanism as well.

I see the point that it shouldn't be necessary to explain the people Maven to INSTALL Activiti, but to create development projects, the people should now more. If they don't want to go with Maven, they still can create any Ant project they want…

But to summarize: My vote goes for Maven, and there we almost have the Archetype ready, so it is easy to do.

[bernd_ruecker]

Ah, and as a addition: In Cycle it is easy to support both, we just add another Plug-In creating an Ant project. It is just that somebody has to create that Ant Template and introduce it there. So it is just a matter of effort 😉

[tombaeyens]

Bernd, this is not a discussion about mvn vs ant.   This is about what experience we want to give our users.  Currently our users have a dependency on ant.  They need to download and install ant before they can start running the Activiti demo setup.  In order to maximize our reach to a bigger audience, I think, we should try to remove such dependencies instead of introducing an extra dependency to have maven installed. 

Working out an installer with e.g. IzPack would be great.  That installer could ask which components you want to have installed.  Ideally it would scan for existing JVM, ant, maven versions and indicate if those are appropriate.  And then offer to download and install any of those components.  Minimizing the need for installed components is making it the user a lot easier I think.

And that is my problem with the extra dependency on maven.  (and not the fact that developers don't want to work with maven)

[bernd_ruecker]

Hi Tom.

But these are different issues: First is about Installation of Activiti itself. I agree with you, that has to be as simple as possible. And even graphical steering of Ant or IzPack would be preferrable.

But the default project layout is about development projects done with Activiti. And if you do a development project with Java, you have to know Java, Ant and today Maven. There is no way around and no need to hide. We don't build a zero coding tool, so I don't have problems with that. So I would go for the solution making the most sense for the development projects. And that is Maven at the moment.

Cheers
Bernd

[trademak]

Hi Tom and Bernd,

I also see two things in the discussion. First the installation of Activiti and getting started with tools like the Modeler, KickStart, Explorer and Probe without any coding and minimizing the dependencies. If we can do this in a nice IzPack installation that would be great.

Second is the development cycle of developers working with Activiti in their projects. Most Java developers favor Maven for their project layout, dependencies and management over Ant. So we should support the developers with Maven based projects from Cycle and the Designer.

Best regards,

[tombaeyens]

I see the point.  And I agree with your both reasonings.  But there are still a couple open issues with that:

1) aren't we inconsistent if the example projects in the distro are done with ant and the default project build with maven?  so we create a diff between the example projects in the distro and the new project wizzards in designer and cycle.  i'm concerned that is a hurdle

2) with maven, how is the deployment to the database going to be handled?  calling ant from maven is a possibility. but what phase should we bind it too?  i can't find a logical answer to that.

3) ant-eclipse integration.  i think it's an easy win to leverage the eclipse-ant view for offering a deploy button.

so could this proposal meet both sides:  we use the maven pom as the basis for building the .bar archive.  and we offer an ant target for deploying to the activiti-DB.

* so we just take a different approach for the distro examples as for the template for real life projects.  I could consider those different use cases and therefor I could ignore that this might be inconsistent

* in the template for real life projects, we use the maven defaults for building, the business archive.  we don't do deployment in maven itself.

* we add an ant file that has a deploy target to deploy to an activiti DB.  that ant target calls out to maven to fetch the dependencies and then use the deploy-bar task.  this way we prevent confusion between 2 potential interpretations of 'deploy' in maven.  and can still leverage the eclipse-ant view.

WDYT?

[bernd_ruecker]

Hi Tom.

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. 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.

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.

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.

Cheers
Bernd