Derby
  1. Derby
  2. DERBY-4548

would like an alternative location for ant.properties

    Details

      Description

      The current build.xml directs ant to look for a file ant.properties in user.home.
      This can get confusing when you have multiple versions on the same machine.
      I've worked around this in the past by pointing ant at other directories with -Duser.home=..., but it would be easier to have another place set up - I don't really like changing user.home.

      We could add another line to build.xml, e.g., for trunk's current build.xml:
      @@ -20,6 +20,7 @@

      <!-- Set Properties -->
      <!-- User settings -->
      + <property file="ant.properties"/>
      <property file="$

      {user.home}

      /ant.properties"/>
      <!-- Set property lib dir -->
      <property name="properties.dir" value="tools/ant/properties"/>

      This would make ant look first for ant.properties in the same directory as the top level build.xml, and secondly for the one in user.home.

      If the community agrees this would be ok, I'd like to make this change and backport it all the way to 10.0.
      By having an additional place we'd not cause incompatibilities to other build processes (except if someone has put an ant.properties file in the top of the checked out tree).

      If we do this, I think it's up to the developers to ensure that there's not 2 ant.properties files that are conflicting.

      1. DERBY-4548.diff
        0.4 kB
        Myrna van Lunteren
      2. DERBY-4548.diff_2
        0.5 kB
        Myrna van Lunteren

        Activity

        Hide
        Kristian Waagan added a comment -

        Just so I don't misunderstand, is this something you cannot do with the ant -propertyfile command line option?
        Or do you want to change this "once and for all" for a given checked out source tree?
        And if you need to do it per tree, does it work to simply edit the one line above in build.xml?

        Show
        Kristian Waagan added a comment - Just so I don't misunderstand, is this something you cannot do with the ant -propertyfile command line option? Or do you want to change this "once and for all" for a given checked out source tree? And if you need to do it per tree, does it work to simply edit the one line above in build.xml?
        Hide
        Myrna van Lunteren added a comment -

        For an example, I want to prevent that making changes for tinkering for a bug in trunk, affects my settings for building 10.5 - so that I can immediately build my 10.5 when I need...Or, for building 10.2, I need to use wctme5.7's libraries, but for 10.5 I want to use weme6.2 libraries.
        If I make a modification to the build.xml, and build like that, the version output from sysinfo gets the funky M attached, which I don't want. And I don't want to risk inadvertently checking in such a change.

        The main reason for not liking -Dpropertyfile is that I don't want to have to type something extra (or even have an alias).

        Another note re precedence for the case when there's multiple 'matching' property files - the properties don't seem to be incremental. For instance, when providing no proceed setting in user.home/ant.properties but proceed=true in the propertyfile passed in with -Dpropertyfile, the output from ant shows that Proceed=no.
        My testing shows that the file listed in build.xml gets precedence, and whichever file is listed first in build.xml gets precedence.

        Would it be acceptable to have the local ant.properties first?

        Show
        Myrna van Lunteren added a comment - For an example, I want to prevent that making changes for tinkering for a bug in trunk, affects my settings for building 10.5 - so that I can immediately build my 10.5 when I need...Or, for building 10.2, I need to use wctme5.7's libraries, but for 10.5 I want to use weme6.2 libraries. If I make a modification to the build.xml, and build like that, the version output from sysinfo gets the funky M attached, which I don't want. And I don't want to risk inadvertently checking in such a change. The main reason for not liking -Dpropertyfile is that I don't want to have to type something extra (or even have an alias). Another note re precedence for the case when there's multiple 'matching' property files - the properties don't seem to be incremental. For instance, when providing no proceed setting in user.home/ant.properties but proceed=true in the propertyfile passed in with -Dpropertyfile, the output from ant shows that Proceed=no. My testing shows that the file listed in build.xml gets precedence, and whichever file is listed first in build.xml gets precedence. Would it be acceptable to have the local ant.properties first?
        Hide
        Myrna van Lunteren added a comment -

        adding a patch - this makes the proposed additional propertyfile call to an ant.properties living at the top of the source tree being looked at after looking at user.home/ant.properties.

        Show
        Myrna van Lunteren added a comment - adding a patch - this makes the proposed additional propertyfile call to an ant.properties living at the top of the source tree being looked at after looking at user.home/ant.properties.
        Hide
        Myrna van Lunteren added a comment -

        I intend to commit this and backport tomorrow if there are no further comments/objections...

        Show
        Myrna van Lunteren added a comment - I intend to commit this and backport tomorrow if there are no further comments/objections...
        Hide
        Myrna van Lunteren added a comment -

        Committed the change to build.xml in trunk with revision 911231; also made a slight modification to BUILDING.html to say ant.properties can be in the top of the source tree.

        I'll wait a while to see if anyone has trouble with this or objects to backporting this after all.

        Show
        Myrna van Lunteren added a comment - Committed the change to build.xml in trunk with revision 911231; also made a slight modification to BUILDING.html to say ant.properties can be in the top of the source tree. I'll wait a while to see if anyone has trouble with this or objects to backporting this after all.
        Hide
        Kristian Waagan added a comment -

        Properties in ant have a certain behavior.
        Is it correct that properties defined in the local ant.properties file will not override properties already set based on the one in the home directory, and that "new" properties (i.e. those present in the local file but not in the home directory one) will be set?

        If this is indeed correct (I haven't checked), would it be better to swap the order of the property files?

        Show
        Kristian Waagan added a comment - Properties in ant have a certain behavior. Is it correct that properties defined in the local ant.properties file will not override properties already set based on the one in the home directory, and that "new" properties (i.e. those present in the local file but not in the home directory one) will be set? If this is indeed correct (I haven't checked), would it be better to swap the order of the property files?
        Hide
        Myrna van Lunteren added a comment -

        My empirical information (that is, I did various experiments) shows that that's how the properties work.
        (for instance, not specifying sane at all in user.home/ant.properties, but switching it to true vs. false in the local ant.properties showed it getting set from the local ant.properties; after setting it in user.home/ant.properties the setting in local ant.properties would get ignored).

        I thought about swapping the order of the property files, i.e. make the local one first, (that's what I put in the initial suggestion) but I thought it might be more likely to cause trouble if someone has - say for safe-keeping - put an ant.properties file in their local tree.

        Both ways have disadvantages/advantages.
        For instance, to ensure that old branches build correctly, regardless of what's in user.home/ant.properties, you'd want the local ant.properties file to take precedence (i.e. be first in build.xml).

        However, I can see setting some general properties in user.home/ant.properties and managing the sane/insane stuff in a local ant.properties file...

        In the end I decided less possible impact for unsuspecting developers if we kept the user.home/ant.properties as the 'primary' one.
        By not having any user.home/ant.properties file I can get my multiple ant.properties files to work...

        Thoughts/opinions?

        Show
        Myrna van Lunteren added a comment - My empirical information (that is, I did various experiments) shows that that's how the properties work. (for instance, not specifying sane at all in user.home/ant.properties, but switching it to true vs. false in the local ant.properties showed it getting set from the local ant.properties; after setting it in user.home/ant.properties the setting in local ant.properties would get ignored). I thought about swapping the order of the property files, i.e. make the local one first, (that's what I put in the initial suggestion) but I thought it might be more likely to cause trouble if someone has - say for safe-keeping - put an ant.properties file in their local tree. Both ways have disadvantages/advantages. For instance, to ensure that old branches build correctly, regardless of what's in user.home/ant.properties, you'd want the local ant.properties file to take precedence (i.e. be first in build.xml). However, I can see setting some general properties in user.home/ant.properties and managing the sane/insane stuff in a local ant.properties file... In the end I decided less possible impact for unsuspecting developers if we kept the user.home/ant.properties as the 'primary' one. By not having any user.home/ant.properties file I can get my multiple ant.properties files to work... Thoughts/opinions?
        Hide
        Kristian Waagan added a comment -

        No really any opinions, I obviously don't know enough about how ant is supposed to work.

        I did try some variations as well, and I have to say I only got confused. At one point I was convinced there is something wrong with our targets setting the sanity...
        Some of my scripts use -f propertyfile and that seems to change the behavior (I think you mentioned this). I only use different property files when building older releases, so my requirements are minimal (my single build script detects the Derby version and uses the appropriate property file).

        If you're confident enough of the current approach, and the change doesn't cause trouble for other people, I'd say it's fine.
        Putting something in place that fits perfectly for all use-cases might be hard

        +1

        Show
        Kristian Waagan added a comment - No really any opinions, I obviously don't know enough about how ant is supposed to work. I did try some variations as well, and I have to say I only got confused. At one point I was convinced there is something wrong with our targets setting the sanity... Some of my scripts use -f propertyfile and that seems to change the behavior (I think you mentioned this). I only use different property files when building older releases, so my requirements are minimal (my single build script detects the Derby version and uses the appropriate property file). If you're confident enough of the current approach, and the change doesn't cause trouble for other people, I'd say it's fine. Putting something in place that fits perfectly for all use-cases might be hard +1
        Hide
        Bryan Pendleton added a comment -

        Would it make things less confusing to use a different name for the new properties file?

        Perhaps, "branch.properties" or "codeline.properties"?

        Show
        Bryan Pendleton added a comment - Would it make things less confusing to use a different name for the new properties file? Perhaps, "branch.properties" or "codeline.properties"?
        Hide
        Knut Anders Hatlen added a comment -

        "local.properties"?

        My expectation would be that the local settings took precedence over the $HOME/ant.properties. If the only reason for not having this behaviour is to prevent backups of $HOME/ant.properties from being picked up, I think changing the name as Bryan suggested and changing the order would be a good idea.

        Show
        Knut Anders Hatlen added a comment - "local.properties"? My expectation would be that the local settings took precedence over the $HOME/ant.properties. If the only reason for not having this behaviour is to prevent backups of $HOME/ant.properties from being picked up, I think changing the name as Bryan suggested and changing the order would be a good idea.
        Hide
        Myrna van Lunteren added a comment -

        Changing the name as Bryan suggested to local.properties, and making it the first one in the file so any properties defined in local.properties will have precedence over any found in user.home/ant.properties.
        I'll commit this shortly.

        Show
        Myrna van Lunteren added a comment - Changing the name as Bryan suggested to local.properties, and making it the first one in the file so any properties defined in local.properties will have precedence over any found in user.home/ant.properties. I'll commit this shortly.
        Hide
        Myrna van Lunteren added a comment -

        committed diff2 patch as per suggestions by Bryan and Knut with revision 915129.

        Show
        Myrna van Lunteren added a comment - committed diff2 patch as per suggestions by Bryan and Knut with revision 915129.
        Hide
        Myrna van Lunteren added a comment -

        committed revision 923555 to 10.4; backport of 920530 from 10.5 with adjustments (modified BUILDING.txt instead of BUILDING.html.)

        Show
        Myrna van Lunteren added a comment - committed revision 923555 to 10.4; backport of 920530 from 10.5 with adjustments (modified BUILDING.txt instead of BUILDING.html.)
        Hide
        Myrna van Lunteren added a comment -

        Backported to 10.1 with revision 940710.
        That's enough for me; closing.

        Show
        Myrna van Lunteren added a comment - Backported to 10.1 with revision 940710. That's enough for me; closing.

          People

          • Assignee:
            Myrna van Lunteren
            Reporter:
            Myrna van Lunteren
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development