10 Replies Latest reply on Mar 29, 2006 3:11 AM by Tom Baeyens

    jbpm project structure

    Tom Baeyens Master

      i seem to have a problem with finding the right project structure. it's been revised a couple of times since 1.0. and lately i was experiencing some problems with the current structure as well.

      another point that i would like to introduce into the build is the use of a repository. so that you can configure how the dependencies should be resolved. jboss has a nice repository and i was looking into how we could replace the jbpm libs directory with using the repository.

      now, it turns out that i also use the wrong library naming convention. i thought it was good practice to add the version into the file name. seems i was the only one thinking that is a good idea. the manifest is indeed the best place for the version. probably this has been the drop that got me thinking to rework the whole project structure.

      my next proposal is based on the jboss project structure:

      jbpm
      + jbpm (gop + config framework + jpdl + jpdl services)
      + etc
      + examples
      + main
      + the main jbpm sources
      + resources
      + config.files
      + test
      + test

      + identity
      + main
      + test

      + database
      (a version of the jbpm.db project that doesn't include the driver libs)

      + console (user console + admin console)

      + server
      + all jboss integration stuff

      + userguide


      the biggest downside of such a restructuring is imo loosing the cvs history of the files. but i'm willing to take that in return for a better project structure.

      maybe the designer and bpel could be integrated into this as well. that would keep those projects better integrated in case of refactorings or updates of the jpdl schema...

      thoughts ?

      regards, tom.

        • 1. Re: jbpm project structure
          Tom Baeyens Master

          oops, i meant to put the new proposed structure in code format:

          jbpm
           + jbpm (gop + config framework + jpdl + jpdl services)
           + etc
           + examples
           + main
           + the main jbpm sources
           + resources
           + config.files
           + test
           + test
          
           + identity
           + main
           + test
          
           + database
           (a version of the jbpm.db project that doesn't include the driver libs)
          
           + console (user console + admin console)
          
           + server
           + all jboss integration stuff
          
           + userguide
          


          regards, tom.

          • 2. Re: jbpm project structure
            Jim Rigsbee Newbie

            Are we still going to use Maven? If so, the libraries would come from the Maven repository.

            Also, the directory structure should be based on the best practices for Maven for a multiproject.

            Regards, Jim

            • 3. Re: jbpm project structure
              Tom Baeyens Master

              agreed.

              i'm having a meeting with the QA team this afternoon. they manage the overall jboss build and think of switching to maven. there are a few issues to be resolved. since it seems that jboss is moving towards maven, i am going to check wether i can do it with maven, rather then with the jboss build system.

              the only thing i really care about is the dependency resolution mechanism. both the jboss build and maven have such a dependency mechanism. ideally, i should be able to use that and still keep the project buildable with plain ant.

              do you know if i can use the maven dependency resolution without a dependency on a maven installation... just ant ?

              regards, tom.

              • 4. Re: jbpm project structure
                Alejandro Guizar Master

                Putting the jbpm, gpd and bpel codebases together sounds like a good idea to me. How do you think they should be integrated? I believe something along these lines

                + jbpm
                 + jbpm
                 + identity
                 + database
                 + console
                 + server
                 + userguide
                 + gpd
                 [the gpd structure]
                 + bpel
                 + main
                 + examples
                 + resources
                 + test


                • 5. Re: jbpm project structure
                  Jim Rigsbee Newbie

                   

                  "tom.baeyens@jboss.com" wrote:


                  do you know if i can use the maven dependency resolution without a dependency on a maven installation... just ant ?


                  No you cannot..the dependency mechanism is supplied by the core maven plugins that have nothing to do with ant.

                  Once you and the JBoss team define a Maven standard structure that everyone can live with, it will be a simple matter to convert it to Maven. I have lots of starter files to get us up and running quickly. I've been working with Maven very intensely for the past six months.

                  The other question will be Maven 1.0.2 or 2.0. I'm using 1.0.2 right now.

                  Regards, Jim

                  • 6. Re: jbpm project structure
                    Jim Rigsbee Newbie

                    Typical version 1.0.2 Maven structure:

                    +main root directory
                     - project.xml <--------- this one drives the entire build
                     + component 1
                     - project.xml <---------- this one builds this sub-component only
                     + component N
                     - project.xml <------------ "" ""
                    


                    Within each of the component trees for a typical java component:

                    +component 1
                     - project.xml
                     - maven.xml
                     - project.properties
                     - build.properties (optional and typically in developer's home dir)
                     +src
                     +main
                     +java
                     +resources <---- any non-Java files that need to be copied to classpath
                     +webapp <----- root of web application
                     +test
                     +java <---- Junit classes
                     +resources <----- *.properties, *.xml, test files, etc. for testing only
                     +target <----- gets built by Maven runs and can always be destroyed
                    


                    Keep in mind it is best to have one product from each directory. You can also nest projects within projects within projects if it makes sense.

                    You can also have a project setup as a template and not have it build anything. Other projects can inherit from this...I do this with EJB and Xdoclet stuff all the time. They inherit the maven.xml, project.xml, and project.properties settings.

                    Regards, Jim

                    • 7. Re: jbpm project structure
                      Tom Baeyens Master

                      alex,

                      the internal structure of subprojects will depend on which build system is chosen by jboss in the next two weeks. for the jbpm sub project structure, i would like something like this:

                      + jbpm
                       + jbpm
                       + identity
                       + database
                       + console
                       + server
                       + userguide
                       + starters-kit
                       + designer
                       + bpel
                      


                      we also might need a separate build subproject. as we now have with the jbpm.build cvs module. although i'm not sure. i think that the usage of a repository will eliminate this need and that we can rework the build so that each part can be build and tagged independently.

                      we will have to identify the different products that need an independant versioning. probably only the designer and bpel will remain their own release cycles as they have now.

                      over time, (perhaps in jbpm 4.0) i want to split jbpm into a core (=GOP) and a jpdl project. that is the time when we can also think about DB-schema extensibility. meaning, how can we have a core set of tables that jpdl and bpel can extend...

                      regards, tom.

                      • 8. Re: jbpm project structure
                        Tom Baeyens Master

                        jim,

                        if we go for maven (and chances are quite high) then we will follow the maven guidelines as close as possible like one artifact per subproject, sub project structure, ...

                        regards, tom.

                        • 9. Re: jbpm project structure
                          Alejandro Guizar Master

                           

                          over time, (perhaps in jbpm 4.0) i want to split jbpm into a core (=GOP) and a jpdl project. that is the time when we can also think about DB-schema extensibility. meaning, how can we have a core set of tables that jpdl and bpel can extend...

                          +1, would be a nice design to have. Maybe the db-schema extensibility can be achieved by using different prefixes (GOP_, JPDL_, BPEL_).

                          A good feature of this separation is the gop module changing less frequently that the jpdl module, which would allow jpdl and bpel processes to coexist in the same database regardless the jpdl and bpel modules having different release cycles.

                          • 10. Re: jbpm project structure
                            Tom Baeyens Master

                            yes.

                            i think it is possible. mainly i think there is a solution for the specific node type attributes.
                            these could be resolved with metadata. the data of bean style XML in a persistable object model.

                            i will work that out for 4.0

                            regards, tom.