sqoop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Voros (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SQOOP-3322) Version differences between ivy configurations
Date Mon, 07 May 2018 12:57:00 GMT

     [ https://issues.apache.org/jira/browse/SQOOP-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Daniel Voros updated SQOOP-3322:
--------------------------------
    Description: 
We have multiple ivy configurations defined in ivy.xml.
 - The {{redist}} configuration is used to select the artifacts that need to be distributed
with Sqoop in its tar.gz.
 - The {{common}} configuration is used to set the classpath during compilation (also refered
to as 'hadoop classpath')
 -  The {{test}} configuration is used to set the classpath during junit execution. It extends
the {{common}} config.

Some artifacts end up having different versions between these three configurations, which
means we're using different versions during compilation/testing/runtime.

Differences:
||Artifact||redist||common (compilation)||test||
|commons-pool|not in redist|1.5.4|*1.6*|
|commons-codec|1.4|1.9|*1.9*|
|commons-io|1.4|2.4|*2.4*|
|commons-logging|1.1.1|1.2|*1.2*|
|slf4j-api|1.6.1|1.7.7|*1.7.7*|

I'd suggest using the version *in bold* in all three configurations to use the latest versions.

To achieve this we should exclude these artifacts from the transitive dependencies and define
them explicitly.

  was:
We have multiple ivy configurations defined in ivy.xml.
 - The {{redist}} configuration is used to select the artifacts that need to be distributed
with Sqoop in its tar.gz.
 - The {{common}} configuration is used to set the classpath during compilation (also refered
to as 'hadoop classpath')
 -  The {{test}} configuration is used to set the classpath during junit execution. It extends
the {{common}} config.

Some artifacts end up having different versions between these three configurations, which
means we're using different versions during compilation/testing/runtime.

Differences:
||Artifact||redist||common (compilation)||test||
|commons-pool|not in redist|1.5.4|*1.6*|
|commons-codec|*1.4*|1.9|1.9|
|commons-io|*1.4*|2.4|2.4|
|commons-logging|*1.1.1*|1.2|1.2|
|slf4j-api|*1.6.1*|1.7.7|1.7.7|

I'd suggest using the version *in bold* in all three configurations, based on:
 - keep version from redist (where there is one), since that's the version we were shipping
with and used in production
 - keep the latest version in case of commons-pool that is not part of the redist config

To achieve this we should exclude these artifacts from the transitive dependencies and define
them explicitly.


Thanks for commenting [~vasas], I agree! I've updated the description.

> Version differences between ivy configurations
> ----------------------------------------------
>
>                 Key: SQOOP-3322
>                 URL: https://issues.apache.org/jira/browse/SQOOP-3322
>             Project: Sqoop
>          Issue Type: Bug
>          Components: build
>    Affects Versions: 1.4.7
>            Reporter: Daniel Voros
>            Assignee: Daniel Voros
>            Priority: Minor
>
> We have multiple ivy configurations defined in ivy.xml.
>  - The {{redist}} configuration is used to select the artifacts that need to be distributed
with Sqoop in its tar.gz.
>  - The {{common}} configuration is used to set the classpath during compilation (also
refered to as 'hadoop classpath')
>  -  The {{test}} configuration is used to set the classpath during junit execution. It
extends the {{common}} config.
> Some artifacts end up having different versions between these three configurations, which
means we're using different versions during compilation/testing/runtime.
> Differences:
> ||Artifact||redist||common (compilation)||test||
> |commons-pool|not in redist|1.5.4|*1.6*|
> |commons-codec|1.4|1.9|*1.9*|
> |commons-io|1.4|2.4|*2.4*|
> |commons-logging|1.1.1|1.2|*1.2*|
> |slf4j-api|1.6.1|1.7.7|*1.7.7*|
> I'd suggest using the version *in bold* in all three configurations to use the latest
versions.
> To achieve this we should exclude these artifacts from the transitive dependencies and
define them explicitly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message