8 Replies Latest reply on Jan 29, 2007 3:20 AM by tom.baeyens

    committing content from our

    camunda

      Hi everybody.

      First of all I am very sorry I haven't done anything on that issue for the last 4 months, even if I have planned to do that! But I was very busy with other projects :-(

      My plan is now to

      1.) contribute some jbpm commands (because we had written some additional logic like updating a process version in special cricumstances) to get rid of our own service-classes.

      2.) Get the Swing AdminClient (Screenshots on http://www.camunda.com/toolkit_for_jbpm/tk-jbpm-screenshots.html) work with the default Command mechanism in jBPM

      3.) Extract the generic code we used for a Swing-Tasklist and opening tasks in Swing panels to form a generic framework for Swing applications working with jBPM

      So I will start with the first issue the next time.

      One problem is maybe, that we have some very pragmatic commands in our toolkit (e.g. updating the process version of a running instance in the case, that there is a note with the same name in the new version), which we also want to contribute. Would that be OK for you?

      Maybe I can make a package

      org.jbpm.command.experimental
      for that?

      A second thing is, that I need for Swing-applications some GetProcess/Task/.../Command's, because I need to preload some parts of the objects graph before give the result to the client. But the advantage is, we can get rid of any DataTransferObject's we currently use in the AdminClient. I will just add them to the core, ok?

      Also I will not have a JUnit test for every command, even if they are working in some real life applications... But I will work on that issue as soon there is time!

      What do you mean on that plan?

      Sorry for the long thread!

      Bernd.

        • 1. Re: committing content from our
          camunda

          Sorry, seems the forum has cut of my nice subject :-(

          And a second question: In JIRA the release for jbpm 3.2 is scheduled for the 02/Feb/07. Is that realy realistic and your plan right now?

          Because for me it would be nice to integrate some of the stuff in the version 3.2 to develop the AdminClient and Swing-Client framework against that version...

          • 2. Re: committing content from our
            kukeltje

            since there seem to very few issues reported against 3.2, the february timeline seems resonable. I myself have some contributions pending (commands via webservices) that I did not keep up to date because of the either changing commands or build procedures. The latter are in their last fase now, so if you have some contributions as well as I, maybe the 3.3 release (which currently only has drools integration scheduled is a more realistinc timeline for both our cuntributuions

            • 3. Re: committing content from our
              tom.baeyens

               

              "camunda" wrote:
              1.) contribute some jbpm commands (because we had written some additional logic like updating a process version in special cricumstances) to get rid of our own service-classes.


              great. put them in org.jbpm.command package. the good thing is that commands are isolated. so you can't break any existing stuff.

              "camunda" wrote:
              3.) Extract the generic code we used for a Swing-Tasklist and opening tasks in Swing panels to form a generic framework for Swing applications working with jBPM


              a minimal working swing client would be nice. even better would be a client based on eclipse rcp. ever thought of doing that ?

              "camunda" wrote:
              One problem is maybe, that we have some very pragmatic commands in our toolkit (e.g. updating the process version of a running instance in the case, that there is a note with the same name in the new version), which we also want to contribute. Would that be OK for you?


              process migration is a good command. providing that functionality is on my todo list as well. i want to do this as follows: input is a processInstance, a new processDefinition and a map of old node names to new node names. any help in that is appreciated. even if your code doesn't yet have the node map integrated.

              "camunda" wrote:
              Maybe I can make a package
              org.jbpm.command.experimental
              for that?


              no need for that. put it in the org.jbpm.package. if you can, such info should be in the documentation. i guess the most practical place to start documenting commands is in the javadocs.

              "camunda" wrote:
              A second thing is, that I need for Swing-applications some GetProcess/Task/.../Command's, because I need to preload some parts of the objects graph before give the result to the client. But the advantage is, we can get rid of any DataTransferObject's we currently use in the AdminClient. I will just add them to the core, ok?


              yes, please add them.

              "camunda" wrote:
              Also I will not have a JUnit test for every command, even if they are working in some real life applications... But I will work on that issue as soon there is time!


              as long as the average test coverage is ok, this is good. but beware that writing a test also guards your code of being evicted if you can't maintain it any more. if untested code starts producing problems and you're not around to fix it in a reasonable time, we might decide to evict that code... With unit test we can fix it ourselves, even if you're not around.

              great plan. thanks. sorry for late reply

              • 4. Re: committing content from our
                camunda

                Hi tom,

                sorry for late reply

                no problem...

                even better would be a client based on eclipse rcp. ever thought of doing that ?

                Sorry, I have no experience with RCP clients, and I think they are much different from Swing ones. Also I have only be in projects working with Swing, not RCP (I experienced in bigger companies the Webstart argument is very strong, so they do not go with RCP, but I will not start this discussion here :-))


                process migration is a good command. providing that functionality is on my todo list as well. i want to do this as follows: input is a processInstance, a new processDefinition and a map of old node names to new node names. any help in that is appreciated. even if your code doesn't yet have the node map integrated.


                Our code currently updates one processInstance if the node exists with the same name in the new definition. changing that to a node-name-map should not be a big deal....

                How do you organize commits, can I add everything to the HEAD in cvs and commit then when I am ready?

                • 5. Re: committing content from our
                  tom.baeyens

                  yes. you can just commit when you're ready. keep an eye on these forums. as before and after a release, i might instruct here to keep your updates on HEAD for a short period (a few days).

                  • 6. Re: committing content from our
                    camunda

                    Okay, I have started to transfer our code to Commands. The first thing to say is, that we will need a lot of commands (because for working with a fat client we need a command for every communication with the engine), but I think that is not a problem (and I do not know a good way around that).

                    I have some questions on code conventions in the jbpm project, I haven't figured it our myself and the JBoss-Website seems to be down today :-(

                    1) What Exception to use if I get invalid data in a command? The JbpmException?

                    2.) Where to put Hibernate-Queries? We had to build some additional ones for some circumstances. I have seen you put them into a xml-file. This is good for seperating of concerns but I don't like it to much because you get typos in Classes or package names faster there. But anyway, if I have additional queries, can I add them there? Or write them into the commands (not a good idea I think), or just move the HibernateQuery-class we have to the jBPM code base?

                    3) Which JDK to use? Can I use generics (so loose JDK 1.4 compability)?

                    Another question: Shouldn't be every attribute in the commands private? Because in the existing commands all attributes are package local...

                    And the last question: Where to put concrete questions on the already existing commands. In the sourcecode? Here in the forum? Wiki?

                    Thanks in advance for the answers and a nice weekend
                    Bernd

                    • 7. Re: committing content from our
                      kukeltje

                      I've no idea about 1 and 2, but the answer to 3 is that jdk 1.4 compatibility is still required for the 3.2 core. Don't know if 3.3 or 4 will target 1.5/5 but 3.2 definately not. Sorry.

                      The questions if it is not a summary should be discussed here. The outcom could be summarized in the wiki

                      • 8. Re: committing content from our
                        tom.baeyens


                        Java version:
                        runtime engine of 3.x.x must run on JDK 1.4.2
                        the next version of the console 3.3+ probably will require java 5

                        Commands
                        Having a lot of commands is not a problem. That is in fact the reason why we use the command pattern over the typical session facade.

                        But you could do similar things like with database connections: provide a base API with which you can send queries and retrieve results. There is one catch however: lazy loading. Together with the query, you should send some instructions on which relations of the retrieved objects should be eager loaded.

                        When the result is serialized and deserialized on the client, lazy loading will not work.

                        Another approach to adding eager loading indications is to create commands to navigate the relations: e.g. 1 command to get all the swimlaneInstances for this taskInstance.

                        If you want more info on these various approaches and their tradeoffs, you can give me a skype.

                        Exceptions
                        Use JbpmException or create a specific command exception if you think it is applicable. as long as it inherits from JbpmException and as long as you keep the total number of exception types low.

                        More important, try to document very carefully the return values of the commands and the exceptions they throw

                        Where to put the queries
                        Is this the file you're looking for ?

                        jpdl/jar/src/main/java/org/jbpm/db/hibernate.queries.hbm.xml