Apache Gora
  1. Apache Gora
  2. GORA-42

version declared in both build.xml and build-common.xml

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Later
    • Affects Version/s: 0.1-incubating, 0.1.1-incubating
    • Fix Version/s: 0.2
    • Component/s: build process
    • Labels:
      None

      Description

      the $

      {version}

      property is defined in both build.xml, and build-common.xml. This is confusing. We should decide on one place, and then just put it there and remove it from the other one.

      1. NUTCH-42.patch
        7 kB
        Lewis John McGibbney
      2. GORA-42.patch
        2 kB
        Lewis John McGibbney
      3. GORA-42-v2.patch
        2 kB
        Lewis John McGibbney

        Activity

        Hide
        Lewis John McGibbney added a comment -

        Bulk close of issues. Preparation for Gora 0.2 release candidate.

        Show
        Lewis John McGibbney added a comment - Bulk close of issues. Preparation for Gora 0.2 release candidate.
        Hide
        Lewis John McGibbney added a comment -

        If and when there is renewed interest to pick up the Ant/Ivy stuff, this can be reopened and completed. For the time being I would rather concentrate my efforts elsewhere.

        Show
        Lewis John McGibbney added a comment - If and when there is renewed interest to pick up the Ant/Ivy stuff, this can be reopened and completed. For the time being I would rather concentrate my efforts elsewhere.
        Hide
        Lewis John McGibbney added a comment -

        Ok so the problem here lies with the $

        {project.dir} property.

        In build-common.xml it exists as
        <property name="project.dir" value="${basedir}/.."/>
        


        In build.xml it exists as
         <property name="project.dir" value="${basedir}"/>
        


        and in each module's ivy/ivy.xml it is used in the following context.
        
        

        <include file="${project.dir}

        /ivy/ivy-configurations.xml"/>

        
        

        The subsequent effect is that Eclipse is extremely confused and states that no ivy file exists in each location due to the fact that it's misinterpreting $

        {project.dir}

        . We need to change one of the occurrences. There are several occurences of the variable in both build & build-common.xml

        Any preferences which one get changed?

        Show
        Lewis John McGibbney added a comment - Ok so the problem here lies with the $ {project.dir} property. In build-common.xml it exists as <property name= "project.dir" value= "${basedir}/.." /> In build.xml it exists as <property name= "project.dir" value= "${basedir}" /> and in each module's ivy/ivy.xml it is used in the following context. <include file="${project.dir} /ivy/ivy-configurations.xml"/> The subsequent effect is that Eclipse is extremely confused and states that no ivy file exists in each location due to the fact that it's misinterpreting $ {project.dir} . We need to change one of the occurrences. There are several occurences of the variable in both build & build-common.xml Any preferences which one get changed?
        Hide
        Lewis John McGibbney added a comment -

        There is more work to be done here. Please leave it with me.

        Show
        Lewis John McGibbney added a comment - There is more work to be done here. Please leave it with me.
        Hide
        Lewis John McGibbney added a comment -

        Been getting Gora sorted in Eclipse and your right Chris, this is a real pain indeed. If we can add anything to this default.properties great. Are there any other suggestions?

        Show
        Lewis John McGibbney added a comment - Been getting Gora sorted in Eclipse and your right Chris, this is a real pain indeed. If we can add anything to this default.properties great. Are there any other suggestions?
        Hide
        Chris A. Mattmann added a comment -

        Will do, Lewis! Hopefully in the next 2 days.

        Show
        Chris A. Mattmann added a comment - Will do, Lewis! Hopefully in the next 2 days.
        Hide
        Lewis John McGibbney added a comment -

        Hi Chris, when you get some time, can you please review and see whether the latest patch solves the initial problem this task was opened to address.

        Show
        Lewis John McGibbney added a comment - Hi Chris, when you get some time, can you please review and see whether the latest patch solves the initial problem this task was opened to address.
        Hide
        Lewis John McGibbney added a comment -

        New patch removes project.dir property from the default.properties files. This is because both build.xml and build-common.xml have different values for the same property. Would it help to rename the constant to something like main.project.dir in build.xml? This would disambiguate it from build-common.xml

        Show
        Lewis John McGibbney added a comment - New patch removes project.dir property from the default.properties files. This is because both build.xml and build-common.xml have different values for the same property. Would it help to rename the constant to something like main.project.dir in build.xml? This would disambiguate it from build-common.xml
        Hide
        Lewis John McGibbney added a comment -

        This rather trivial patch sorts out the issue of individually referenced property values for various constants. The patch does solve the underlying problem which initially resulted in this issue being opened, however I do not dispute there could be more done here with regards to adding more properties to the default.properties file. I tried to add more, however the configuration mapping becomes slightly more complex when the project module nature is taken into consideration. For the time being I am reasonably happy with the small number of properties included within the file as this permits Ant/Ivy testing and building at local level.

        Show
        Lewis John McGibbney added a comment - This rather trivial patch sorts out the issue of individually referenced property values for various constants. The patch does solve the underlying problem which initially resulted in this issue being opened, however I do not dispute there could be more done here with regards to adding more properties to the default.properties file. I tried to add more, however the configuration mapping becomes slightly more complex when the project module nature is taken into consideration. For the time being I am reasonably happy with the small number of properties included within the file as this permits Ant/Ivy testing and building at local level.
        Hide
        Lewis John McGibbney added a comment -

        For sake of loosing it, I attach a work in progress. There are inherent problems with the $

        {project.dir}

        variable, this breaks the build as the ivy 2.1.0.jar cannot be found!

        I'm away for a week or so but will try my best to get back to this ASAP.

        Show
        Lewis John McGibbney added a comment - For sake of loosing it, I attach a work in progress. There are inherent problems with the $ {project.dir} variable, this breaks the build as the ivy 2.1.0.jar cannot be found! I'm away for a week or so but will try my best to get back to this ASAP.
        Hide
        Lewis John McGibbney added a comment -

        OK, an interesting thread, which we have seen in different context's elsewhere... I thought it looked rather familiar

        Never-the-less, I'll begin work on suggestions I've made above and see where we get. Thanks

        Show
        Lewis John McGibbney added a comment - OK, an interesting thread, which we have seen in different context's elsewhere... I thought it looked rather familiar Never-the-less, I'll begin work on suggestions I've made above and see where we get. Thanks
        Hide
        Chris A. Mattmann added a comment -

        Hey Lewis, thanks. I think to satisfy this issue, a build.properties or default.properties file would be great. However, based on this discussion: http://www.mail-archive.com/gora-dev@incubator.apache.org/msg00224.html I'm leaning towards working on getting Maven going correctly and leveraging off that. But yeah if you were going to try and address this one, +1 to having a default.properties or build.properties.

        Show
        Chris A. Mattmann added a comment - Hey Lewis, thanks. I think to satisfy this issue, a build.properties or default.properties file would be great. However, based on this discussion: http://www.mail-archive.com/gora-dev@incubator.apache.org/msg00224.html I'm leaning towards working on getting Maven going correctly and leveraging off that. But yeah if you were going to try and address this one, +1 to having a default.properties or build.properties.
        Hide
        Lewis John McGibbney added a comment -

        Hi Chris, I'm looking in to this one with the intention of fixing ASAP. Before I start, I think it is essential to have a default.properties which is located in $GORA_HOME, however is it necessary to separate other properties into a build.properties file as well? There are quite a few overlaps between build.common and build.xml when specifying variables. As the build.xml is included in build.common.xml, would it not be easier to have a well structured easily readable default.properties file, and simply include reference to it in build.common.xml? Maybe I'm not getting it, but would that not work out easier?

        Show
        Lewis John McGibbney added a comment - Hi Chris, I'm looking in to this one with the intention of fixing ASAP. Before I start, I think it is essential to have a default.properties which is located in $GORA_HOME, however is it necessary to separate other properties into a build.properties file as well? There are quite a few overlaps between build.common and build.xml when specifying variables. As the build.xml is included in build.common.xml, would it not be easier to have a well structured easily readable default.properties file, and simply include reference to it in build.common.xml? Maybe I'm not getting it, but would that not work out easier?
        Hide
        Chris A. Mattmann added a comment -
        • schedule
        Show
        Chris A. Mattmann added a comment - schedule
        Hide
        Chris A. Mattmann added a comment -
        • push to 0.3
        Show
        Chris A. Mattmann added a comment - push to 0.3
        Hide
        Chris A. Mattmann added a comment -

        Specifically this is messing up my Eclipse environment while I am trying to get out the 0.1.1-incubating RC.

        Show
        Chris A. Mattmann added a comment - Specifically this is messing up my Eclipse environment while I am trying to get out the 0.1.1-incubating RC.

          People

          • Assignee:
            Lewis John McGibbney
            Reporter:
            Chris A. Mattmann
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development