Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.7.0
    • Component/s: None
    • Labels:
      None

      Description

      • all repository entries should go to parent pom
      • define versions in the parent pom; as possible
      • define plugins in the parent pom; as possible
      • define lifecycles in the parent pom; as possible
      • fix java versions (1.5, 1.6. 1.7 to 1.8)

        Activity

        Hide
        julianhyde Julian Hyde added a comment -

        I believe we already define as much as we can in the parent pom. We use pluginManagement and dependencyManagement, for example.

        I don't know what you mean by "fix java versions".

        Show
        julianhyde Julian Hyde added a comment - I believe we already define as much as we can in the parent pom. We use pluginManagement and dependencyManagement, for example. I don't know what you mean by "fix java versions".
        Hide
        sreevaddi Sree Vaddi added a comment -

        multiple jdk versions

        Show
        sreevaddi Sree Vaddi added a comment - multiple jdk versions
        Hide
        sreevaddi Sree Vaddi added a comment -

        Julian Hyde
        Please see the attached screenshot.
        Notice the jdk 1.5, 1.6, 1.7 for various projects.
        Please look into the respective pom.xmls where the jdk source and target versions are defined.
        This is the reason behind 'fix java versions'.

        Show
        sreevaddi Sree Vaddi added a comment - Julian Hyde Please see the attached screenshot. Notice the jdk 1.5, 1.6, 1.7 for various projects. Please look into the respective pom.xmls where the jdk source and target versions are defined. This is the reason behind 'fix java versions'.
        Hide
        julianhyde Julian Hyde added a comment -

        They are nothing more than source/target language levels. Eclipse is choosing to escalates those language levels to JDK versions, but in fact they can all be handled by JDK 1.7 or 1.8.

        I did some cleanup already on the https://github.com/julianhyde/calcite/tree/816-sub-query branch. Please see whether that is sufficient.

        I believe that ubenchmark MUST remain at source and target 1.6; Vladimir Sitnikov correct me if I am wrong.

        Show
        julianhyde Julian Hyde added a comment - They are nothing more than source/target language levels. Eclipse is choosing to escalates those language levels to JDK versions, but in fact they can all be handled by JDK 1.7 or 1.8. I did some cleanup already on the https://github.com/julianhyde/calcite/tree/816-sub-query branch. Please see whether that is sufficient. I believe that ubenchmark MUST remain at source and target 1.6; Vladimir Sitnikov correct me if I am wrong.
        Hide
        vladimirsitnikov Vladimir Sitnikov added a comment - - edited

        I believe that ubenchmark MUST remain at source and target 1.6;

        That's not a requirement.
        Well, it would be nice to be able to build via different JDK versions (e.g. to compare performance of Calcite under different JDKs).
        However, I would not mind much if using just 1.8 (i.e. JDK-latest) source and target

        Julian Hyde,
        It makes sense to update maven-source-plugin to disable default attach-sources goal.
        Current configuration (in 816 branch) is bad: https://github.com/julianhyde/calcite/blob/816-sub-query/pom.xml#L327-L337

        I believe it causes "double-execution of mvn generate-source" target during a release.
        Here's detailed explanation: http://blog.peterlynch.ca/2010/05/maven-how-to-prevent-generate-sources.html
        It boils down to "add invalid <phase> for default attach-sources execution id" and "add your own attach-sources-nofork".

        Show
        vladimirsitnikov Vladimir Sitnikov added a comment - - edited I believe that ubenchmark MUST remain at source and target 1.6; That's not a requirement. Well, it would be nice to be able to build via different JDK versions (e.g. to compare performance of Calcite under different JDKs). However, I would not mind much if using just 1.8 (i.e. JDK-latest) source and target Julian Hyde , It makes sense to update maven-source-plugin to disable default attach-sources goal. Current configuration (in 816 branch) is bad: https://github.com/julianhyde/calcite/blob/816-sub-query/pom.xml#L327-L337 I believe it causes "double-execution of mvn generate-source" target during a release. Here's detailed explanation: http://blog.peterlynch.ca/2010/05/maven-how-to-prevent-generate-sources.html It boils down to "add invalid <phase> for default attach-sources execution id" and "add your own attach-sources-nofork".
        Hide
        julianhyde Julian Hyde added a comment -
        Show
        julianhyde Julian Hyde added a comment - Fixed some of the points raised in http://git-wip-us.apache.org/repos/asf/calcite/commit/4ae02986 .
        Show
        julianhyde Julian Hyde added a comment - Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/4d58768d .
        Hide
        julianhyde Julian Hyde added a comment -

        Resolved in release 1.7.0 (2016-03-22).

        Show
        julianhyde Julian Hyde added a comment - Resolved in release 1.7.0 (2016-03-22).
        Hide
        julianhyde Julian Hyde added a comment -

        Further cleanup in http://git-wip-us.apache.org/repos/asf/calcite/commit/578fb2cd, which will be in calcite-1.8.

        Show
        julianhyde Julian Hyde added a comment - Further cleanup in http://git-wip-us.apache.org/repos/asf/calcite/commit/578fb2cd , which will be in calcite-1.8.

          People

          • Assignee:
            julianhyde Julian Hyde
            Reporter:
            sreevaddi Sree Vaddi
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development