4 Replies Latest reply on Oct 2, 2007 10:39 AM by Tom Baeyens

    environment properties in pvm ant build ?

    Tom Baeyens Master

      who added

      <property environment="env"/>


      in the pvm build ? and why ?

        • 1. Re: environment properties in pvm ant build ?
          Charles Souillard Newbie

          I added this line.
          This allows some flexibility for build projects users. In my case it was necessary to specify a different directory for the jbpm repo in build.properties file.
          Basically you decided to set it to user.home/jbpm/repo but as I have a double boot computer sharing the same workspace, I wanted to set my jbpm repo in a common partition. This directory was found in both sides in an environment variable.
          So I think it is not a bad idea to allow some flexibility... Maybe not used by everyone but used in some cases...
          In that case, only the build.properties file must be updated (which is the best approach for ant builds)

          Charles

          • 2. Re: environment properties in pvm ant build ?
            Tom Baeyens Master

            flexibility is good. but i would like to minimize the number of customization points of the build.

            for build customizations, i would like us only to use:

            * files located in ${user.home} e.g. ${user.home}/pvm/build.properties

            * System properties to be fetched with System.getProperty(String) Since such parameters can be specified easily in the continuous integration test scripts

            Could you refactor your use of environment variable to any of the above two mechanisms ?

            • 3. Re: environment properties in pvm ant build ?
              Charles Souillard Newbie

              I am not using env variables anymore but I think this could be a good idea to be flexible...
              I can not see any drawback for that point ???

              • 4. Re: environment properties in pvm ant build ?
                Tom Baeyens Master

                the drawback is that you could end up with 10 different configuration mechanisms.

                so to get the build to work you would need to set 1 environment variable. set a file somewhere in some location. customize a properties file in the source code base and set a few JVM properties to get the build to work in your case.

                that's why i want to limit that. just 2 ways of configuring the build will be much easier to explain, document and maintain.

                the proposed 2 configuration mechanisms give you the same kind of flexibility as environment variables.