1 Reply Latest reply on Aug 22, 2013 8:23 AM by ocramot

    How to change console version for jbpm recompile

    ocramot

      I wanted to make some specific changes in the jbpm console, relative to a project I'm working on, so I followed the guide here:

      https://community.jboss.org/wiki/HowToBuildmodifyJbpm-consoleAndDeployItOnServer

      Anyway I downloaded the jbpm 5.4 version (last stable nowadays). This version uses the console version 2.3.8.Final by default, so I downloaded the 2.3.9-SNAPSHOT version, to avoid conflicts.

       

      Following the wiki, I compile the bpm-console code and then the jbpm code, taking care to follow the point 10 (search for "<version>2.3.8.Final</version>" and replace with "<version>2.3.9-SNAPSHOT</version>") in all the pom.xml files that I can find within the jbpm source directory. I find also some dependencies without the version specified; I suppose there is some "default version" defined somewhere, but I am unable to find it, so I add explicitly the version tag in those files.

       

      Still, when I try to compile, I get the following:

       

      [...]

      [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-resources-plugin:2.4.3:resources' with basic configurator -->

      [DEBUG]   (f) buildFilters = []

      [DEBUG]   (f) encoding = UTF-8

      [DEBUG]   (f) escapeWindowsPaths = true

      [DEBUG]   (s) includeEmptyDirs = false

      [DEBUG]   (s) outputDirectory = C:\Users\ocramot\repository\edit_console\jbpm\jbpm-flow\target\classes

      [DEBUG]   (s) overwrite = false

      [DEBUG]   (f) project = MavenProject: org.jbpm:jbpm-flow:5.4.1-SNAPSHOT @ C:\Users\ocramot\repository\edit_console\jbpm\jbpm-flow\pom.xml

      [DEBUG]   (s) resources = [Resource {targetPath: null, filtering: false, FileSet {directory: C:\Users\ocramot\repository\edit_console\jbpm\jbpm-flow\src\main\resources, PatternSet [includes: {}, excludes: {}]}}]

      [DEBUG]   (f) session = org.apache.maven.execution.MavenSession@10ebe2f8

      [DEBUG]   (f) useBuildFilters = true

      [DEBUG]   (s) useDefaultDelimiters = true

      [DEBUG] -- end configuration --

      [DEBUG] properties used { [ ... ],  bpm.console.version=2.3.8.Final, [ ... ]}

      [INFO] Using 'UTF-8' encoding to copy filtered resources.

      [DEBUG] resource with targetPath null

      [ ... ]

       

      and so on for every sub-project (jbpm-flow-builder, jbpm-persistence-jpa, etc.)

       

      and in fact, maven takes care to dowload and install in my local repository the 2.3.8.Final version, ignoring the 2.3.9.SNAPSHOT version already present there.

       

      How can I resolve this? What pom files do I have to modify? What could I have missed? Is there a default version defined somewhere?

        • 1. Re: How to change console version for jbpm recompile
          ocramot

          Ok, after another careful trial and error session, I found the solution.

           

          The jbpm/pom.xml file in the main project, requires as parent:

           

            <parent>

              <groupId>org.drools</groupId>

              <artifactId>droolsjbpm-parent</artifactId>

              <version>5.5.0.Final</version>

              <!-- relativePath causes out-of-date problems on hudson slaves -->

              <!--<relativePath>../droolsjbpm-build-bootstrap/pom.xml</relativePath>-->

            </parent>

           

          therefore I looked into .m2\repository\org\drools\droolsjbpm-parent\5.5.0.Final\droolsjbpm-parent-5.5.0.Final.pom, and here I found

           

          <bpm.console.version>2.3.8.Final</bpm.console.version>

           

          I changed this property, I compiled again, and everything worked fine.

           

          PS: since this is my case, I might add that the .zip version number must be the same jBPM.version number specified inside the $jbpm-install-directory/build.properties file.

          Also, you have to move the $source-directory/jbpm-form-builder/jbpm-form-builder-distribution/target/jbpm-5.4.3-SNAPSHOT-form-builder.war to the lib directory; the guide tells you to compile it at point 8, but the author must have forgotten to tell you to move the file. Once again, check that version numbers coincide, or the build file will automatically download another version and invalidate your changes.