cancel
Showing results for 
Search instead for 
Did you mean: 

Change the process of patching the modeler

bernd_ruecker
Champ in-the-making
Champ in-the-making
I am currently have a look on http://jira.codehaus.org/browse/ACT-309 (since I am at a customer extending the modeler as well).

One proposal as a preparation, which would ease the development on the Modeler a lot:
- Can we upload the "raw" Signavio modeler as an Maven WAR artifact to the Nexus/Mvn-Repo
- Create an own Maven war project including the patching of the activiti modeler and building a correct Maven Artifact of the Modeler for the current version (actually the war Plug-In can very easy patch the war file in a Maven standard way and we cna get rid of the Ant build for that).
- Upload the war as part of the release process to the Maven Repo.

by having the war available in the Maven Repo, it allows people to extend the Modeler with their own stencilset very easy. We could provide an easy example how to do this. And by this, I could add some mapping to Cycle in order to add all the Activiti Extensions to the BPMN 2.0 XML as well.

Anybody problems with it?
Could somebody upload the raw modeler to the Maven Repo? Since it currently doesn't really change in every version, that could be pretty stable (or not?).

Thanks
Bernd
4 REPLIES 4

falko_menge
Champ in-the-making
Champ in-the-making
Sounds promising. I like the idea of finally having Maven artifacts for the entire modeler.

The version numbers of the raw modeler could follow that of the Signavio Core Components JAR we are already building in fox. However, we may again need svn:externals in the Maven project that wraps the Ant build for the raw Activiti Modeler.

tombaeyens
Champ in-the-making
Champ in-the-making
As background, here's our strategy related to the Activiti Modeler: It start to become clear to us that we don't have the capacity to customize the modeler and maintain it so that 1) signavio modeler is limited to cover only the subset of BPMN that activiti supports and 2) add the activiti specific extensions

So in the future we want to move to a situation where there is a smaller Activiti download that includes a minimal set of tools that are well integrated into the engine.  And a set of optional add-ons that can be downloaded separately.

So now I come to your question about a module to build the customized version.

We already have a script (i think it's ant based) that can apply the differences to create an Activiti Modeler.  That script starts to work on a war file that is assumed to be build from the core-signavio-components project. 

We think it makes sense to enhance that scripts so that it can also fetch the sources from the project and launch a build of the core signavio components war before the differences are applied.  That  could be added to the ant script.    For us, adding this convenience is not really a priority.  If there are volunteers, then that would be good.

I don't yet see the need to have this as a maven module.  Nor do I see the need to use svn externals for that (experienced quite a bit of problems with that before).

bernd_ruecker
Champ in-the-making
Champ in-the-making
Hi Tom.

Actually Customizing the editor in the sense of an extended stencilset is not that complicated. But it is waaaay more easy to do that with Maven than with the Ant build. And it can be easily extended in custom projects, something much more complicated now. What is the problem with providing an Maven Artifact?

As an alternative I could do that as part of camunda fox in our code base and our Maven Repo, but I think that is unnecessary distribution of stuff.

For the svn:externals: That's a hazzle indeed. I still try to convince Signavio to create a Maven artifact in the first place 😉

Cheers
Bernd

tombaeyens
Champ in-the-making
Champ in-the-making
So in other words, you want to replace the existing ant script with a pom module because that is easier, right?  If you're convinced that this doesn't lead to big problems in our build and release process, then lets give it a try.

I think the module should go into trunk as this also needs to be uploaded.  There might be a potential problem when this very big module makes the other module deployments fail.