[
https://issues.apache.org/jira/browse/HADOOP-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15554878#comment-15554878
]
Steve Loughran commented on HADOOP-13687:
-----------------------------------------
(this is actually a comment on patch-1; didn't hit submit in time, so some of
the comments are probably obsolete)
# I like the idea, as for, say, SPARK-7481 it'd simplify tracking an expanding
list of object stores.
# I'd prefer the name {{hadoop-cloud-storage}}. Why? (a) it's what it is, and
(b) avoids us having to reject patches related to adding clients of external
filesystems, *ones not tested in ASF releases*.
# I see the appeal of AW's suggest of a new source tree. Maybe we could start
with {{hadoop-cloud-storage/hadoop-cloud-storage}} for this, move the trunk
only hadoop-adl work in there, and move the others (azure, openstack, aws) at
our leisure.
# I think you could be more aggressive about the dependencies of the openstack
stuff; I suspect there is stuff there which could/should be tagged as
scope=provided, so tuning down the transitiveness more.
# [~aw] there's no chance of Yetus doing a mvn dependencies >
target/dependencies.txt operation on any patch which does poms? Or perhaps we
add the policy: all patches which update dependencies must attached the changed
dependency graph
> Provide a unified dependency artifact that transitively includes the
> Hadoop-compatible file systems shipped with Hadoop.
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-13687
> URL: https://issues.apache.org/jira/browse/HADOOP-13687
> Project: Hadoop Common
> Issue Type: Improvement
> Components: build
> Reporter: Chris Nauroth
> Assignee: Chris Nauroth
> Attachments: HADOOP-13687-branch-2.001.patch,
> HADOOP-13687-branch-2.002.patch, HADOOP-13687-trunk.001.patch,
> HADOOP-13687-trunk.002.patch
>
>
> Currently, downstream projects that want to integrate with different
> Hadoop-compatible file systems like WASB and S3A need to list dependencies on
> each one. This creates an ongoing maintenance burden for those projects,
> because they need to update their build whenever a new Hadoop-compatible file
> system is introduced. This issue proposes adding a new artifact that
> transitively includes all Hadoop-compatible file systems. Similar to
> hadoop-client, this new artifact will consist of just a pom.xml listing the
> individual dependencies. Downstream users can depend on this artifact to
> sweep in everything, and picking up a new file system in a future version
> will be just a matter of updating the Hadoop dependency version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
