5 Replies Latest reply on May 29, 2008 3:56 PM by Tom Baeyens

    package restructuring

    Tom Baeyens Master

      here's the package renaming that i would like to introduce

      current name ......................... destination package name
      
      org.jbpm ............................. org.jbpm.pvm
      org.jbpm.cal ......................... org.jbpm.pvm.internal.cal
      org.jbpm.client ...................... org.jbpm.pvm.internal.svc
      org.jbpm.deploy.Deployment ........... org.jbpm.pvm
      org.jbpm.deploy ...................... org.jbpm.pvm.internal.deploy
      org.jbpm.enterprise .................. org.jbpm.pvm.internal.ejb
      org.jbpm.env ......................... org.jbpm.pvm.env
      org.jbpm.env.context ................. org.jbpm.pvm.internal.env
      org.jbpm.env.impl .................... org.jbpm.pvm.internal.env
      org.jbpm.env.session ................. org.jbpm.pvm.session
      org.jbpm.env.tx.Transaction .......... org.jbpm.pvm.env
      org.jbpm.env.tx ...................... org.jbpm.pvm.internal.tx
      org.jbpm.env.xml.EnvironmentParser ... org.jbpm.pvm.env
      org.jbpm.env.xml ..................... org.jbpm.pvm.internal.env.xml
      org.jbpm.hibernate ................... org.jbpm.pvm.internal.hibernate
      org.jbpm.jms ......................... org.jbpm.pvm.internal.jms
      org.jbpm.jobexecutor ................. org.jbpm.pvm.internal.jobexecutor
      org.jbpm.lob ......................... org.jbpm.pvm.internal.lob
      org.jbpm.log ......................... org.jbpm.pvm.internal.log
      org.jbpm.pvm.impl .................... org.jbpm.pvm.internal.impl
      org.jbpm.pvm.impl.op ................. org.jbpm.pvm.internal.impl.op
      org.jbpm.pvm.job ..................... org.jbpm.pvm.internal.job (implementations)
      org.jbpm.pvm.job ..................... org.jbpm.pvm.job (extract interfaces)
      org.jbpm.pvm.log ..................... org.jbpm.pvm.internal.processlog
      org.jbpm.pvm.type .................... org.jbpm.pvm.internal.type
      org.jbpm.stream ...................... org.jbpm.pvm.internal.stream
      org.jbpm.util.Listener ............... org.jbpm.pvm.util
      org.jbpm.util.Observable ............. org.jbpm.pvm.util
      org.jbpm.util ........................ org.jbpm.pvm.internal.util
      org.jbpm.wire ........................ org.jbpm.pvm.internal.wire
      org.jbpm.xml.Parser .................. org.jbpm.pvm.util
      org.jbpm.xml.Parse ................... org.jbpm.pvm.util
      org.jbpm.xml ......................... org.jbpm.pvm.internal.xml
      


      This excercise revealed that the distinction between API and implementation was way more blurry then I thought it was.

      The main goal of this separation is improving the user experience. Users should be able to use all of the straightforward functionality by only using the public API. Only for tricky things, users might revert to the internal packages that serve as a kind of back door.

      By indicating very clearly the API and minimizing it, we create much more maintainable situation between pvm and its users.

      In the next couple of weeks I'll be refactoring towards this restructuring and describing the intended usage in different environments.

      So for the next weeks till this refactoring is done, always sync up front with me in this forum before you want to apply changes.

        • 1. Re: package restructuring
          mvaldes Novice

          Hi Tom,

          This is my proposal (Bull side) regarding this refactoring:

          - We will continue our stabilization/test/quality process on XPDL and BPEL extensions using the PVM 1.0alpha2 version. This process will conclude next week with the release of RC2

          - After this period we should be in synch to work together on PVM stabilization (for that time I guess you will finish the package renaming and refactoring).

          What I would like to do on this part is to focus on how to get the PVM robust and stable enough to release the PVM 1.0.

          I would like to dedicate the same effort that the one we are doing on extensions.

          At that time I should also require to migrate our extensions to the PVM 1.0.

          On the meantime, Guillaume will post on some issues/bugs he has already found on the activities instance.

          best regards,
          Miguel Valdes

          • 2. Re: package restructuring
            Tom Baeyens Master

             

            "mvaldes" wrote:
            - After this period we should be in synch to work together on PVM stabilization (for that time I guess you will finish the package renaming and refactoring).


            the rough structure should be in place by then.

            "mvaldes" wrote:
            What I would like to do on this part is to focus on how to get the PVM robust and stable enough to release the PVM 1.0.

            I would like to dedicate the same effort that the one we are doing on extensions.


            great. the first thing that you guys can validate is where the extensions have to go outside of the api. for each use case of internal classes we have to examine why and if we can avoid it.

            "mvaldes" wrote:
            At that time I should also require to migrate our extensions to the PVM 1.0.


            after the restructuring, i would like to release a first beta. that would be a good candidate to update the dependencies.

            "mvaldes" wrote:
            On the meantime, Guillaume will post on some issues/bugs he has already found on the activities instance.


            make sure it's synchronized with me as i'm in the middle of the package restructuring now

            • 3. Re: package restructuring
              Tom Baeyens Master

              first big chunk is done. the javadocs now generate only the docs for the api. feedback is welcome

              • 4. Re: package restructuring
                Edward Staub Expert

                Applause for the renaming! The lack of interfaces and clear lines in JBPM3 is a big problem for us - I'm going to have to develop our own wrapper API.

                -Ed Staub

                • 5. Re: package restructuring
                  Tom Baeyens Master

                  thanks for your support.

                  in 3, I envisioned that people wrote their own wrapper api's

                  we have hopes that now we can cover a big enough part of what people need with our new approach.

                  starting pvm, i thought i was doing this already. but introducing the package naming structure made it clear that there was still a lot of overlap between api and impl. doing this excercise turned (already) out to be a big advancement