Details

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

      Description

      Calcite's parent POM currently has a long dependency list, but that list should be short, or even empty.

      The parent POM should (and does) have a dependencyManagement section that specifies versions, but each module should have a dependencies section containing the dependencies that it actually uses.

        Activity

        Hide
        julianhyde Julian Hyde added a comment -

        Resolved in release 1.2.0-incubating (2015-04-16)

        Show
        julianhyde Julian Hyde added a comment - Resolved in release 1.2.0-incubating (2015-04-16)
        Hide
        julianhyde Julian Hyde added a comment -

        Re. 1. I don't remember, but it made something run more smoothly. For example, when you release 1.3 this is the first time ever that any 1.3 artifacts have been built and maven would complain that they don't exist in the local repo. I think using explicit numbers fixed that.

        Or there might have been some other issue when I moved dependencies on sub-modules to the dependencyManagement section in the root pom.xml.

        It works, the release plugin handles all of the version number changes, and I'm not too concerned about a few extra diffs.

        Re. 2. You're probably right. Feel free to change it.

        Re. 3. I'm trying to minimize Avatica's dependencies so it's scary to declare a "provided" dependency and not provide it. But if you think it would work, great, go ahead. I would love to have precondition annotations in Avatica.

        Show
        julianhyde Julian Hyde added a comment - Re. 1. I don't remember, but it made something run more smoothly. For example, when you release 1.3 this is the first time ever that any 1.3 artifacts have been built and maven would complain that they don't exist in the local repo. I think using explicit numbers fixed that. Or there might have been some other issue when I moved dependencies on sub-modules to the dependencyManagement section in the root pom.xml. It works, the release plugin handles all of the version number changes, and I'm not too concerned about a few extra diffs. Re. 2. You're probably right. Feel free to change it. Re. 3. I'm trying to minimize Avatica's dependencies so it's scary to declare a "provided" dependency and not provide it. But if you think it would work, great, go ahead. I would love to have precondition annotations in Avatica.
        Hide
        vladimirsitnikov Vladimir Sitnikov added a comment -

        Please clarify:
        1) Why did you expand project.version? I would prefer to keep variable there to minimize "update version diff"

        -        <version>${project.version}</version>
        +        <version>1.2.0-incubating-SNAPSHOT</version>
        

        2) Don't you think we'd better trim <version>1.2.0-incubating</version> from child modules, so the version is inherited from parent pom?

        3) We'd better move "annotations" to provided scope. The following change is not required.
        If annotation is missing on the runtime class path, then class/method works as usual. You just can't get the annotation value.

        I would vote for using @Nullable, etc annotations for easier code read and/or for static analyzers. It is free from the "additional dependencies" point of view. We just need to use provided for that

        @@ -20,7 +20,6 @@ import java.sql.ResultSetMetaData;
         import java.sql.SQLException;
         import java.util.Properties;
         import java.util.TimeZone;
        -import javax.annotation.Nullable;
         
         /**
          * Factory for JDBC objects.
        @@ -39,11 +38,11 @@ public interface AvaticaFactory {
               Properties info) throws SQLException;
         
           AvaticaStatement newStatement(AvaticaConnection connection,
        -      @Nullable Meta.StatementHandle h, int resultSetType,
        +      /*@Nullable*/ Meta.StatementHandle h, int resultSetType,
               int resultSetConcurrency, int resultSetHoldability) throws SQLException;
         
           AvaticaPreparedStatement newPreparedStatement(AvaticaConnection connection,
        -      @Nullable Meta.StatementHandle h, Meta.Signature signature,
        +      /*@Nullable*/ Meta.StatementHandle h, Meta.Signature signature,
               int resultSetType, int resultSetConcurrency, int resultSetHoldability)
               throws SQLException;
        Show
        vladimirsitnikov Vladimir Sitnikov added a comment - Please clarify: 1) Why did you expand project.version ? I would prefer to keep variable there to minimize "update version diff" - <version>${project.version}</version> + <version>1.2.0-incubating-SNAPSHOT</version> 2) Don't you think we'd better trim <version>1.2.0-incubating</version> from child modules, so the version is inherited from parent pom? 3) We'd better move "annotations" to provided scope. The following change is not required. If annotation is missing on the runtime class path, then class/method works as usual. You just can't get the annotation value. I would vote for using @Nullable , etc annotations for easier code read and/or for static analyzers. It is free from the "additional dependencies" point of view. We just need to use provided for that @@ -20,7 +20,6 @@ import java.sql.ResultSetMetaData; import java.sql.SQLException; import java.util.Properties; import java.util.TimeZone; -import javax.annotation.Nullable; /** * Factory for JDBC objects. @@ -39,11 +38,11 @@ public interface AvaticaFactory { Properties info) throws SQLException; AvaticaStatement newStatement(AvaticaConnection connection, - @Nullable Meta.StatementHandle h, int resultSetType, + /*@Nullable*/ Meta.StatementHandle h, int resultSetType, int resultSetConcurrency, int resultSetHoldability) throws SQLException; AvaticaPreparedStatement newPreparedStatement(AvaticaConnection connection, - @Nullable Meta.StatementHandle h, Meta.Signature signature, + /*@Nullable*/ Meta.StatementHandle h, Meta.Signature signature, int resultSetType, int resultSetConcurrency, int resultSetHoldability) throws SQLException;
        Show
        julianhyde Julian Hyde added a comment - Fixed in http://git-wip-us.apache.org/repos/asf/incubator-calcite/commit/119a3993 .

          People

          • Assignee:
            julianhyde Julian Hyde
            Reporter:
            julianhyde Julian Hyde
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development