Also, reading back through this chain, it was state as unclear as to
whether or not an inner class of a class in the public API is also,
itself, in the public API.
This should also be clarified in our definition of public API in the
README. Obviously, Don and Sean both agree that it should be. The
discussion of those on the vote didn't. Doesn't really matter to me
either way.
On 3/28/14, 9:50 AM, Josh Elser wrote:
Ah, I missed the recursiveness of the o.a.a.c.c.
But, like I mentioned in the other message, I don't think binary compat
was achieved, but the package name, constructors, and methods existing
in 1.5.0 were maintained AFAIK. Are we asserting binary compat here as
well?
I'm trying to understand if we actually didn't follow our own rules, or
if the expectations of the community are exceeding the rules we have for
ourselves. I think we're in the latter right now.
On 3/28/14, 9:41 AM, Sean Busbey wrote:
According to the definition of the public API in version 1.5.0,
RangeInputSplit is a part of the public API.
On Fri, Mar 28, 2014 at 11:26 AM, Josh Elser <[email protected]>
wrote:
Devil's advocate: RangeInputSplit isn't part of the public API
either, so
it comes with the same risks that TabletLocator would.
It sounds more like the definition of "public api" should be expanded to
prevent this in future cases. I need to look at what exactly broke
for Don.
On 3/28/14, 9:12 AM, Sean Busbey wrote:
Don,
If you can file a jira with some example code that covers what parts of
the
1.5.0 API you hit, I can see if I can a patch to get you working.
That would give you a patch you could apply on top of 1.5.1 now and
when
1.5.2 comes out it would correctly support the API.
-Sean
On Fri, Mar 28, 2014 at 8:49 AM, Donald Miner <[email protected]
wrote:
I'm starting to dig around for a workaround and figured someone
might be
able to help me right away.
In digging deeper, we were using RangeInputSplit because it gave us
the
splits AND the locations. We use the locations for some data locality
placing in our distributed application. listSplits only gives us
splits.
Is there an easy way to get both of these pieces of information
together?
On Thu, Mar 27, 2014 at 3:28 PM, Josh Elser <[email protected]>
wrote:
Ack, sorry about that, Don.
We probably should have been more strict about that. It's tough to
make
a
call about a public class that someone *might* be using.
On 3/27/14, 12:26 PM, Donald Miner wrote:
Sorry to necro this thread, just wanted to throw my 2 cents in.
We had some user code referencing this code directly and our
application
no
longer works in 1.5.1. Just found out today when installing on
1.5.1.
In
retrospect, we should have been using .listSplits from
TableOperatons,
but
instead we were using the RangeInputSplit method to get the splits
for a
table.
I guess since we probably shouldn't have been doing that, I don't
know
if
that's a case for this not being deleted without going to
deprecated...
but
we did have a nasty surprise and a deprecation warning would have
been
nice.
-d
On Tue, Feb 25, 2014 at 11:33 PM, Adam Fuchs <[email protected]>
wrote:
I'll buy that the RangeInputSplit is probably not referenced
directly
in
user code. In this case it's probably not a big enough change to
delay
the
release.
Adam
On Feb 25, 2014 6:19 PM, "Christopher" <[email protected]>
wrote:
I don't know that this inner class used for M/R should be
considered
public API... nor do I imagine it will cause compatibility
problems
if
users aren't referencing it in their code (which there's no
reason to
expect them to). I don't know if anybody is subclassing
RangeInputSplit, but I'd suspect that it's an acceptable risk.
Re-adding an inner class that subclasses the now external one
may be
a
good workaround. I don't think this would require recompilation
for
runtime compatibility, but if it does, I think that's probably
acceptable.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue, Feb 25, 2014 at 6:13 PM, Josh Elser <[email protected]>
wrote:
I haven't checked what would happen. If you subclassed the
RangeInputSplit,
it's rather likely that you'd need a recompilation.
On 2/25/14, 5:59 PM, John Vines wrote:
Will it? Clients don't interact with that code at all directly.
On Tue, Feb 25, 2014 at 5:57 PM, Adam Fuchs <[email protected]>
wrote:
Thanks for running that checker, Keith. Should we not be
worried
about
the
removal of InputFormatBase.RangeInputSplit? If I read correctly
this
will
break both binary (runtime) compatibility and code
(compile-time)
compatibility. Can somebody make an argument for why this is
not a
problem
in a minor release with no previous deprecation?
Is there a quick way to fix this, like by subclassing the
org.apache.accumulo.core.client.mapred.RangeInputSplit in a
o.a.a.c.c.mapred.InputFormatBase.RangeInputSplit that we
mark as
deprecated?
Adam
On Tue, Feb 25, 2014 at 5:17 PM, Keith Turner
<[email protected]>
wrote:
I ran a utility [1] to analyze API diffs [2] between 1.5.0
and
1.5.1-RC3.
The configs I used are the two xml files in the parent [3]
of the
report.
I think the diff looks ok. I used jars from 1.5.0 and
1.5.1-RC3
bin.tar.gz.
[1] :
http://ispras.linuxbase.org/index.php/Java_API_Compliance_
Checker
[2] :
http://people.apache.org/~kturner/1.5.0_to_1.5.1-RC3/
compat_report.html
[3] : http://people.apache.org/~kturner/1.5.0_to_1.5.1-RC3/
On Mon, Feb 24, 2014 at 8:01 PM, Josh Elser <
[email protected]
wrote:
All,
Please consider the following candidate as Apache Accumulo
1.5.1
--
now
with 100% more CHANGES changes.
Git artifacts: The staging repository was built from the tag
"1.5.1-rc3"
(3478f71a).
Maven Staging Repo:
https://repository.apache.org/content/repositories/
orgapacheaccumulo-1002
Source tarball:
http://repository.apache.org/content/repositories/
orgapacheaccumulo-1002/org/apache/accumulo/accumulo/1.5.
1/accumulo-1.5.1-src.tar.gz
Binary tarball:
http://repository.apache.org/content/repositories/
orgapacheaccumulo-1002/org/apache/accumulo/accumulo/1.5.
1/accumulo-1.5.1-bin.tar.gz
Changes since 1.5.1-RC2: ACCUMULO-2324, ACCUMULO-2361,
ACCUMULO-2369,
ACCUMULO-2378, ACCUMULO-2379, ACCUMULO-2380, ACCUMULO-2385,
ACCUMULO-2387,
ACCUMULO-2390
Keys: http://www.apache.org/dist/accumulo/KEYS
Final CHANGES:
https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=
blob_plain;f=CHANGES;hb=3478f71ae888f8d73aaa93837319a6
dbb4ba0c8a
Testing: Unit test and auto-tests passed successfully. Ran a
short
(~2hrs)
CI on 6 node installation. Ran a brief (~1hr) CI test on one
machine
with
the newly-released Hadoop-2.3.0. Built from src tarball, and
verified
functionality with bin tarball.
Since there are very minor changes compared to 1.5.1-RC2,
this
vote
will
be open for the next 72 hours (2/28/2014 0100 UTC).
Upon successful completion of this vote, a 1.5.1
gpg-signed Git
tag
will
be created from 3478f71a and the above staging repository
will
be
promoted.
- Josh
--
Donald Miner
Chief Technology Officer
ClearEdge IT Solutions, LLC
Cell: 443 799 7807
www.clearedgeit.com
