topic Re: Project layout for business archives in Alfresco Archive

Project layout for business archives

tombaeyens — Thu, 23 Dec 2010 15:09:21 GMT

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 the

Re: Project layout for business archives

trademak — Mon, 27 Dec 2010 21:00:20 GMT

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

Re: Project layout for business archives

tombaeyens — Tue, 28 Dec 2010 08:20:20 GMT

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?

Re: Project layout for business archives

bernd_ruecker — Tue, 28 Dec 2010 08:33:11 GMT

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.

Re: Project layout for business archives

bernd_ruecker — Tue, 28 Dec 2010 08:38:04 GMT

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 😉

Re: Project layout for business archives

tombaeyens — Mon, 03 Jan 2011 12:05:04 GMT

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)

Re: Project layout for business archives

bernd_ruecker — Mon, 03 Jan 2011 14:38:04 GMT

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

Re: Project layout for business archives

trademak — Mon, 03 Jan 2011 14:57:49 GMT

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,

Re: Project layout for business archives

tombaeyens — Tue, 04 Jan 2011 09:55:21 GMT

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?

Re: Project layout for business archives

bernd_ruecker — Tue, 04 Jan 2011 10:02:49 GMT

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

Re: Project layout for business archives

tombaeyens — Tue, 04 Jan 2011 12:41:01 GMT

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)

Re: Project layout for business archives

bernd_ruecker — Tue, 04 Jan 2011 13:36:40 GMT

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.

Re: Project layout for business archives

bernd_ruecker — Mon, 10 Jan 2011 08:18:22 GMT

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

Re: Project layout for business archives

mproch — Mon, 10 Jan 2011 09:42:35 GMT

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.

Re: Project layout for business archives

tombaeyens — Tue, 11 Jan 2011 11:15:57 GMT

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?

Re: Project layout for business archives

bernd_ruecker — Thu, 13 Jan 2011 13:31:32 GMT

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 😉

Re: Project layout for business archives

nico1 — Sat, 10 Mar 2012 11:14:14 GMT

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.