8 Replies Latest reply on Jun 14, 2007 5:20 PM by jason.greene

    jbpm4jsf java 5 dependency

    tom.baeyens

      there is a source="1.5" in the jbpm4jsf build file.

      the current console must be runnable on jbpm 1.4. david, could you make sure that the install target puts a version in the repository that runs on jbpm 1.4 ?

        • 1. Re: jbpm4jsf java 5 dependency
          dmlloyd

          The console outputs three versions: a JBossAS 4.2.x version, a JBossAS 4.0.x version, and a JBossAS 4.0.x/JDK 1.4 version. There is no need for a JDK 1.4 version for JBAS 4.2.x because the AS requires JDK5 to run.

          jBPM4JSF, Gravel, and the JSF RI all require JDK 5. So the console target for JDK 1.4 runs JBossRetro across all of these libraries.

          In order to put more than one version into the repository, we have two options:

          1) update the directory structure so that there's a directory for each console WAR.
          2) switch to distributing the exploded WAR zip archive instead, in which case we can name each one differently, since they all unzip to a directory called jbpm-console.war

          I think we should do #2 personally, because this gives users easy access to all the configuration files, and makes it equally easy to install any version. I do not want to only put out the JDK 1.4 version by default, because if we have to choose between making life easiest for users of AS 4.2.x versus 4.0.x, I choose the former. In any case, rumor has it that Sun will be desupporting JDK 1.4 by the end of the year anyway...

          • 2. Re: jbpm4jsf java 5 dependency
            tom.baeyens

            only one console package needs to be build by the console subproject. that one needs to run on 1.4.2

            to get the java 5 console, people will have to build from source.

            i only want to support version of the console. since we want 1.4.2 support, it must be that version. that one will run on java 5 runtimes.

            so the question is: what version does the install target put in the local repository ? a java 1.4.2 compatible one ?

            • 3. Re: jbpm4jsf java 5 dependency
              dmlloyd

               

              "tom.baeyens@jboss.com" wrote:
              only one console package needs to be build by the console subproject.


              I don't see why, but OK...

              "tom.baeyens@jboss.com" wrote:
              that one needs to run on 1.4.2


              I don't get that either, but OK

              "tom.baeyens@jboss.com" wrote:
              to get the java 5 console, people will have to build from source.


              Sounds like unnecessary work for the user, but OK

              "tom.baeyens@jboss.com" wrote:
              i only want to support version of the console.


              Well, you don't have a choice. If you want people to be able to run on 4.2.x, you have to at least support two versions. I think it would be a bad idea to restrict people to 4.0.x.

              "tom.baeyens@jboss.com" wrote:
              since we want 1.4.2 support, it must be that version. that one will run on java 5 runtimes.


              ...but not in 4.2.x.

              "tom.baeyens@jboss.com" wrote:
              so the question is: what version does the install target put in the local repository ? a java 1.4.2 compatible one ?


              Your wish is my command - the 4.0.x, JDK 1.4 version is now the default.

              • 4. Re: jbpm4jsf java 5 dependency
                jeffdelong

                I don't think we should target JDK 1.4.2..

                Furthermore, I think we should have multiple builds in the deploy idirectory fo the installed product, each in its own sub-directory. Let''s make it easy on the user to deploy the correct version for their environment.

                • 5. Re: jbpm4jsf java 5 dependency
                  kukeltje

                  With regard to making it easy for the user to deploy correct versions. I'd like to propose the ability to configure what database dialect should be used when building the webapps/ear. So it is really build and run...

                  • 6. Re: jbpm4jsf java 5 dependency
                    tom.baeyens

                    I'm pretty sure that there are people and customers that are still running on 1.4.2. maybe not much. but those will be screwed if they simply want to upgrade from jPDL 3.2.GA to 3.2.1. This would backfire if we upgrade JDK requirements or JBoss version between micro releases.

                    For 3.3, it's a whole other discussion. that is where I'm very open to discuss this.

                    Similar for jboss versions. Currently we build with 4.0.4.GA. I don't mind switching to 4.0.5. But i would mind switching to 4.2.0.

                    I'm talking about the suite distribution here. What we can do is add more packages in the deploy directory. There we can put packages that you can deploy in other environments then the one we selected for the out-of-the-box experience.

                    Also I think it's good if the project can handle many versions. But we already had a hard time setting up the simple integration test build. I think it would be a lot of effort to upgrade that integration test build for the matrix of jdk's and jbosses. Our current team would not be able to handle the extra load resulting from that. We need to focus on 1 set of dependencies. If we can handle variations, the better. But I don't want the team to be too much distracted from the resulting complexity of such a matrix.

                    We better focus first on getting the integration tests running on multiple databases.

                    • 7. Re: jbpm4jsf java 5 dependency
                      jeffdelong

                      Tom said

                      What we can do is add more packages in the deploy directory


                      Yes, please put the other war packagaes in the deploy directory, so we can deploy wars and ears containing these wars to jdk5 / JBossAS4.2 environments.

                      I think it is great that David has tested these other combinations, and can build wars that work in each. In the past we had to deploy them in the field only to find out there were various jar incompatibilities with newer versions of the app server. We almost always start of a new project with the latest release version of the AS, so this always bit us in the past. I don't mind having to repackage an ear (be nice if there were scripts to do it with a build.properties file to describe which app server and jdk and pick the correct war version you wanted). But I don't want to have to go to CVS and build from source.



                      • 8. Re: jbpm4jsf java 5 dependency
                        jason.greene

                        I just happened to notice this thread and thought I would chime in. At some point all projects are supposed to align with the platform release of AS (4.2) since that is the officially supported release. So providing any easy to use deployment for this would be a good chance to pilot support for it. Also keep in mind that JDK4 has already started the EOL transition, so Sun is only honoring existing contracts and only until next year. So in general I think its a good idea to encourage anyone who is using JDK4 still to get off of it ASAP.

                        -Jason