accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-3402) Introduction of the mapreduce maven module breaks 1.6 compatibility
Date Fri, 12 Dec 2014 18:43:14 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14244588#comment-14244588
] 

Josh Elser commented on ACCUMULO-3402:
--------------------------------------

You're definitely right, [~kturner]. Let me see if I can summarize.

In <1.7.0-SNAPSHOT, we have MapReduce classes in core/. In 1.7.0-SNAPSHOT, those classes
were moved into a new mapreduce/ maven module which depends on the core/ module. Applications
who use our MapReduce classes, in the simplest form, will depend on {{o.a.a.core.client.mapred\[uce\].Accumulo\[Input|Output\]Format}}.
This creates a problem for applications because they need to depend on accumulo-core-1.6.x
sometimes and accumulo-mapreduce-1.7.x other times. Will this is possible to do, I don't consider
it remotely close to an ideal solution.

Like Mike said, when he made the changes originally, he only considered use of MapReduce by
using tool.sh which was incorrect as users can and do use launch mapreduce jobs in all ways/shapes/forms.
Use of tool.sh to launch mapreduce jobs would be transparent WRT runtime classpath; however,
the compilation dependency was still expanded.

#1 solution as implemented in the patch is a hacky way to get around the underlying issue
of classes being relocated to a different artifact by reintroducing the classes (but deprecated)
into the core/ module. I call this hacky because we now have copied classes in two locations.
This isn't a long-term solution.

#4 could probably work as well, but I also agree with you that I'm not sure what else that
buys us.

Looking back at ACCUMULO-1880, the main reason given to move the classes into a new module
was to have "a more minimal set of dependencies to compile against." I don't think the changes
actually do that, instead just introduce another layer of indirection since the mapreduce/
module still depends on the core module. That being said, I think #1 can be a short-term fix
that is less abrasive than reverting the changes outright; however, I find myself leaning
back to a revert being the better solution because it appears to cause problems without actually
solving a problem.

> Introduction of the mapreduce maven module breaks 1.6 compatibility
> -------------------------------------------------------------------
>
>                 Key: ACCUMULO-3402
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3402
>             Project: Accumulo
>          Issue Type: Bug
>          Components: client
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>            Priority: Blocker
>             Fix For: 1.7.0
>
>
> The introduction of mapreduce maven module breaks backwards compatibility with 1.6.
> Code that previously worked against 1.6 (that used our mapreduce classes) is now broken
without a deprecation cycle -- specifically trying to compile Hive against Accumulo 1.7 is
broken.
> While the classes themselves haven't technically changed, the required dependencies have.
In my eyes, this is an incompatible change that violates our current public API rules.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message