Derby
  1. Derby
  2. DERBY-1526

build should be able to locate the Java runtime libraries from properties not sourced from ${user.home}, but inside the current subversion checkout.

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.2.1.6
    • Fix Version/s: 10.3.1.4
    • Component/s: Build tools
    • Labels:
      None

      Description

      I think it is problemmatic that the Derby build process makes use of, for example, $

      {user.home}

      /ant.properties.

      I would actually like to be able to build multiple versions of Derby. I also cannot see what is gained by relying on the user's home directory in this manner. All of this information could be put into a configuration that can be kept in the project directory. That would work just fine.

      By the way, I am looking at the top-of-tree code. How do I refer to that in the "Affects Version" box above? This version is 422938.

      thanx - ray

        Activity

        Hide
        Andrew McIntyre added a comment -

        This issue has been resolved for over a year with no further movement. Closing.

        Show
        Andrew McIntyre added a comment - This issue has been resolved for over a year with no further movement. Closing.
        Hide
        Andrew McIntyre added a comment -

        Committed patch to trunk recommending using the Ant -propertyfile option to the trunk with revision 433931.

        Show
        Andrew McIntyre added a comment - Committed patch to trunk recommending using the Ant -propertyfile option to the trunk with revision 433931.
        Hide
        Andrew McIntyre added a comment -

        Attaching a patch which adds a note to BUILDING.txt describing the use of the propertyfile option.

        Show
        Andrew McIntyre added a comment - Attaching a patch which adds a note to BUILDING.txt describing the use of the propertyfile option.
        Hide
        Andrew McIntyre added a comment -

        Rick: right, we certainly shouldn't stop sourcing the properties from user.home, but maybe we should also also source an ant.properties from the basedir as well? although, there is a workaround...

        Dan: Thanks, I had forgotten about that nifty Ant option, since I don't ever use it. I think we should add a note to BUILDING.txt with that suggestion.

        And yes, I probably should have left out the "(and should)". the bit in i.e. in my original comment clarifies what I intended to say.

        Show
        Andrew McIntyre added a comment - Rick: right, we certainly shouldn't stop sourcing the properties from user.home, but maybe we should also also source an ant.properties from the basedir as well? although, there is a workaround... Dan: Thanks, I had forgotten about that nifty Ant option, since I don't ever use it. I think we should add a note to BUILDING.txt with that suggestion. And yes, I probably should have left out the "(and should)". the bit in i.e. in my original comment clarifies what I intended to say.
        Hide
        Daniel John Debrunner added a comment -

        Andrew wrote:

        • These runtime [Java] classes can (and should) be static across Derby versions.

        That's not true, at least the "and should" piece. I may choose to build different Derby codelines with different JDK setups. I do this today either using IBM's SDK's or SUn's JDKs.

        Show
        Daniel John Debrunner added a comment - Andrew wrote: These runtime [Java] classes can (and should) be static across Derby versions. That's not true, at least the "and should" piece. I may choose to build different Derby codelines with different JDK setups. I do this today either using IBM's SDK's or SUn's JDKs.
        Hide
        Daniel John Debrunner added a comment -

        I build multiple versions of derby by not having an ant.properties file in user.home, but instead at the top of each svn tree.
        I then have a script to build that uses the -propertyfile argument of ant to point to the correct ant.properties file.

        Show
        Daniel John Debrunner added a comment - I build multiple versions of derby by not having an ant.properties file in user.home, but instead at the top of each svn tree. I then have a script to build that uses the -propertyfile argument of ant to point to the correct ant.properties file.
        Hide
        Rick Hillegas added a comment -

        $

        {user.home}

        /ant.properties also holds configuration variables needed to run the ant-based compatibility tests. I don't have strong religion about where we should keep user-specific environment variables. However, I'd like to keep these variables in one place and not have to clone them. Here's what I like about the current arrangement: all ant-based scripts look for environment variables in a canonical place. As long as we preserve that behavior, I'm happy.

        Show
        Rick Hillegas added a comment - $ {user.home} /ant.properties also holds configuration variables needed to run the ant-based compatibility tests. I don't have strong religion about where we should keep user-specific environment variables. However, I'd like to keep these variables in one place and not have to clone them. Here's what I like about the current arrangement: all ant-based scripts look for environment variables in a canonical place. As long as we preserve that behavior, I'm happy.
        Hide
        Andrew McIntyre added a comment -

        Marking this as an improvement, since the current setup works in most situations. I've edited the summary to more accurately indicate the improvement that could be made.

        Show
        Andrew McIntyre added a comment - Marking this as an improvement, since the current setup works in most situations. I've edited the summary to more accurately indicate the improvement that could be made.
        Hide
        Andrew McIntyre added a comment -

        The only information expected to be in $

        {user.home}/ant.properties for the Derby build is the location of the runtime java libraries that are accessible to the current user. These runtime classes can (and should) be static across Derby versions. i.e. the versions of Java that you use to build any particular version of Derby should consistently build multiple versions of Derby. There shouldn't be any information in ${user.home}

        /ant.properties that is specific to a specific version of Derby.

        With the current setup, I can specify the locations of the multiple versions of the runtime classes needed to build Derby once for each machine/user where I am building in the user's ant.properties. Then, I can build 10.0, 10.1, and 10.2 without needing to change anything but the directory where I've checked out the source. The requirements on Mac OS X for the content in ant.properties is somewhat different, as noted in BUILDING.txt, but once set up, I can build Derby 10.0, 10.1, and the trunk without needing to set up a separate properties file for each individual checkout of the source. I find this very handy.

        That said, I can understand the desire not to introduce a dependency on a user-space file. I think there is room for improvement here if we also sourced a file from $

        {basedir}

        in addition to the user.home, in case a user wants to have these base properties sourced from a file that is specific to a particular checkout of Derby.

        As far as the affects version, there currently is not a way to track specific Subversion revisions in JIRA. Since it looks like you are working with the trunk, we are tracking the current trunk version as 10.2.0.0 in JIRA. For the other versions, the latest released 10.1 version is 10.1.3.1 and the latest released 10.0 version is 10.0.2.1.

        Show
        Andrew McIntyre added a comment - The only information expected to be in $ {user.home}/ant.properties for the Derby build is the location of the runtime java libraries that are accessible to the current user. These runtime classes can (and should) be static across Derby versions. i.e. the versions of Java that you use to build any particular version of Derby should consistently build multiple versions of Derby. There shouldn't be any information in ${user.home} /ant.properties that is specific to a specific version of Derby. With the current setup, I can specify the locations of the multiple versions of the runtime classes needed to build Derby once for each machine/user where I am building in the user's ant.properties. Then, I can build 10.0, 10.1, and 10.2 without needing to change anything but the directory where I've checked out the source. The requirements on Mac OS X for the content in ant.properties is somewhat different, as noted in BUILDING.txt, but once set up, I can build Derby 10.0, 10.1, and the trunk without needing to set up a separate properties file for each individual checkout of the source. I find this very handy. That said, I can understand the desire not to introduce a dependency on a user-space file. I think there is room for improvement here if we also sourced a file from $ {basedir} in addition to the user.home, in case a user wants to have these base properties sourced from a file that is specific to a particular checkout of Derby. As far as the affects version, there currently is not a way to track specific Subversion revisions in JIRA. Since it looks like you are working with the trunk, we are tracking the current trunk version as 10.2.0.0 in JIRA. For the other versions, the latest released 10.1 version is 10.1.3.1 and the latest released 10.0 version is 10.0.2.1.

          People

          • Assignee:
            Unassigned
            Reporter:
            Ray Kiddy
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development