Re: Re[2]: Assign myself to work ACCUMULO-2907

[Mike Drob]

Done. You should be able to assign yourself now.

On Mon, Sep 18, 2017 at 3:34 PM, J. Mark Owens  wrote:

> jmark99
>
>
>
> -- Original Message --
> From: "Mike Drob" 
> To: "Accumulo Dev List" 
> Sent: 9/18/2017 4:33:10 PM
> Subject: Re: Assign myself to work ACCUMULO-2907
>
> What is your apache jira id?
>>
>> On Mon, Sep 18, 2017 at 3:29 PM, J. Mark Owens 
>> wrote:
>>
>> Hi Mike,
>>>
>>> I have an Apache Jira account.  But the Accumulo issues page is not
>>> displaying the 'Assign to me" option underneath the 'Unassigned'  area on
>>> the right.  Whereas on the Apache NiFi project page that option appeared
>>> after someone granted me access to the project.
>>> thanks,
>>> mark
>>>
>>>
>>> On Mon, Sep 18, 2017 at 4:23 PM, Mike Walch  wrote:
>>>
>>> > Have created a Apache Jira account yet?  Below is the url where you can
>>> > setup an account.
>>> >
>>> > https://issues.apache.org/jira/login.jsp
>>> >
>>> > The Accumulo Jira is a project under Apache Jira.  Anyone can create an
>>> > account on Apache Jira.  After you create an account, you should be
>>> able
>>> to
>>> > assign yourself to an Accumulo issue.  If not, email the list again
>>> someone
>>> > can enable access.
>>> >
>>> > On Mon, Sep 18, 2017 at 4:14 PM J. Mark Owens 
>>> wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > I'd like to assign myself to work on ACCUMULO-2907
>>> > > .
>>> > >
>>> > > Could I be granted access to Accumulo Jira in order to assign the
>>> ticket
>>> > > to myself?
>>> > >
>>> > > Thanks,
>>> > > Mark Owens
>>> >
>>>
>>>
>

Re[2]: Assign myself to work ACCUMULO-2907

[J. Mark Owens]

jmark99


-- Original Message --
From: "Mike Drob" 
To: "Accumulo Dev List" 
Sent: 9/18/2017 4:33:10 PM
Subject: Re: Assign myself to work ACCUMULO-2907


What is your apache jira id?

On Mon, Sep 18, 2017 at 3:29 PM, J. Mark Owens  
wrote:



Hi Mike,

I have an Apache Jira account.  But the Accumulo issues page is not
displaying the 'Assign to me" option underneath the 'Unassigned'  area 
on
the right.  Whereas on the Apache NiFi project page that option 
appeared

after someone granted me access to the project.
thanks,
mark


On Mon, Sep 18, 2017 at 4:23 PM, Mike Walch  wrote:

> Have created a Apache Jira account yet?  Below is the url where you 
can

> setup an account.
>
> https://issues.apache.org/jira/login.jsp
>
> The Accumulo Jira is a project under Apache Jira.  Anyone can create 
an
> account on Apache Jira.  After you create an account, you should be 
able

to
> assign yourself to an Accumulo issue.  If not, email the list again
someone
> can enable access.
>
> On Mon, Sep 18, 2017 at 4:14 PM J. Mark Owens 
wrote:
>
> > Hi,
> >
> > I'd like to assign myself to work on ACCUMULO-2907
> > .
> >
> > Could I be granted access to Accumulo Jira in order to assign the
ticket
> > to myself?
> >
> > Thanks,
> > Mark Owens
>

Re: Assign myself to work ACCUMULO-2907

[Mike Drob]

What is your apache jira id?

On Mon, Sep 18, 2017 at 3:29 PM, J. Mark Owens  wrote:

> Hi Mike,
>
> I have an Apache Jira account.  But the Accumulo issues page is not
> displaying the 'Assign to me" option underneath the 'Unassigned'  area on
> the right.  Whereas on the Apache NiFi project page that option appeared
> after someone granted me access to the project.
> thanks,
> mark
>
>
> On Mon, Sep 18, 2017 at 4:23 PM, Mike Walch  wrote:
>
> > Have created a Apache Jira account yet?  Below is the url where you can
> > setup an account.
> >
> > https://issues.apache.org/jira/login.jsp
> >
> > The Accumulo Jira is a project under Apache Jira.  Anyone can create an
> > account on Apache Jira.  After you create an account, you should be able
> to
> > assign yourself to an Accumulo issue.  If not, email the list again
> someone
> > can enable access.
> >
> > On Mon, Sep 18, 2017 at 4:14 PM J. Mark Owens 
> wrote:
> >
> > > Hi,
> > >
> > > I'd like to assign myself to work on ACCUMULO-2907
> > > .
> > >
> > > Could I be granted access to Accumulo Jira in order to assign the
> ticket
> > > to myself?
> > >
> > > Thanks,
> > > Mark Owens
> >
>

Re: Assign myself to work ACCUMULO-2907

[J. Mark Owens]

Hi Mike,

I have an Apache Jira account.  But the Accumulo issues page is not
displaying the 'Assign to me" option underneath the 'Unassigned'  area on
the right.  Whereas on the Apache NiFi project page that option appeared
after someone granted me access to the project.
thanks,
mark


On Mon, Sep 18, 2017 at 4:23 PM, Mike Walch  wrote:

> Have created a Apache Jira account yet?  Below is the url where you can
> setup an account.
>
> https://issues.apache.org/jira/login.jsp
>
> The Accumulo Jira is a project under Apache Jira.  Anyone can create an
> account on Apache Jira.  After you create an account, you should be able to
> assign yourself to an Accumulo issue.  If not, email the list again someone
> can enable access.
>
> On Mon, Sep 18, 2017 at 4:14 PM J. Mark Owens  wrote:
>
> > Hi,
> >
> > I'd like to assign myself to work on ACCUMULO-2907
> > .
> >
> > Could I be granted access to Accumulo Jira in order to assign the ticket
> > to myself?
> >
> > Thanks,
> > Mark Owens
>

Re: Assign myself to work ACCUMULO-2907

[Mike Walch]

Have created a Apache Jira account yet?  Below is the url where you can
setup an account.

https://issues.apache.org/jira/login.jsp

The Accumulo Jira is a project under Apache Jira.  Anyone can create an
account on Apache Jira.  After you create an account, you should be able to
assign yourself to an Accumulo issue.  If not, email the list again someone
can enable access.

On Mon, Sep 18, 2017 at 4:14 PM J. Mark Owens  wrote:

> Hi,
>
> I'd like to assign myself to work on ACCUMULO-2907
> .
>
> Could I be granted access to Accumulo Jira in order to assign the ticket
> to myself?
>
> Thanks,
> Mark Owens

Assign myself to work ACCUMULO-2907

[J. Mark Owens]

Hi,

I'd like to assign myself to work on ACCUMULO-2907 
.


Could I be granted access to Accumulo Jira in order to assign the ticket 
to myself?


Thanks,
Mark Owens

Re: [DISCUSS] Guava Dependencies

[Josh Elser]

On 9/18/17 2:12 PM, Mike Miller wrote:

Recently tickets have been opened dealing with Guava in Accumulo (see
ACCUMULO-4701 through 4704), in particular the use of Beta classes and
methods.  Use of Guava comes with a few warnings...

 From the Guava README:

*1. APIs marked with the @Beta annotation at the class or method level are
subject to change. They can be modified in any way, or even removed, at any
time. If your code is a library itself (i.e. it is used on the CLASSPATH of
users outside your own control), you should not use beta APIs, unless you
repackage them (e.g. using ProGuard).2.Deprecated non-beta APIs will be
removed two years after the release in which they are first deprecated. You
must fix your references before this time. If you don't, any manner of
breakage could result (you are not guaranteed a compilation error).*

I think it is worth a discussion on how to handle Guava dependencies going
forward across the different versions of Accumulo.  The goal would be to
allow use of a newer version version of Guava in client applications with
the current supported versions of Accumulo.

Ideally, we could just eliminate any use of Beta Guava code.  But there are
Beta classes that are very useful and some which we already have integrated
into released Accumulo versions.

There seem to be 3 ways to handle Guava dependencies:
1 - jar shading


+1 (favoring #3 too, when not intrusive). We stop "advertising" that we 
include Guava on the classpath and it's no longer our problem. As the 
other part of the thread alludes, if Hadoop brings in a version, fine. 
Accumulo specifically should stop trying to rely on something specific 
coming down from its dependencies and "control its own destiny".


FWIW, HBase has been actively moving to this model and, IMO, it's been 
working well.



2 - copy Guava code into Accumulo
3 - replace Guava code with standard Java

We may have to handle it differently with each version of Accumulo.  For
example, 1.8 has more widespread use of Beta annotated code than 1.7.

Re: [DISCUSS] Guava Dependencies

[Mike Miller]

Right.  We are tied down to Guava 14 because of Hadoop.  This is the work
around since we can't just update Guava.  Previously, we had just avoided
using 14 code that wasn't around anymore.  Which was OK until code was
deprecated after version 14 and then removed, like in the case with
ACCUMULO-4701.  https://issues.apache.org/jira/browse/ACCUMULO-4701

I guess another option would be to do nothing since I believe I have fixed
the problem that was reported in ACCUMULO-4701.

On Mon, Sep 18, 2017 at 2:34 PM, Dave Marion  wrote:

> We still have to use a Hadoop-compatible version of Guava on the
> server-side though, right? I believe the DFSClient has Guava dependencies.
>
>
> >
> > On September 18, 2017 at 2:12 PM Mike Miller 
> wrote:
> >
> > Recently tickets have been opened dealing with Guava in Accumulo (see
> > ACCUMULO-4701 through 4704), in particular the use of Beta classes
> and
> > methods. Use of Guava comes with a few warnings...
> >
> > From the Guava README:
> >
> > *1. APIs marked with the @Beta annotation at the class or method
> level are
> > subject to change. They can be modified in any way, or even removed,
> at any
> > time. If your code is a library itself (i.e. it is used on the
> CLASSPATH of
> > users outside your own control), you should not use beta APIs,
> unless you
> > repackage them (e.g. using ProGuard).2.Deprecated non-beta APIs will
> be
> > removed two years after the release in which they are first
> deprecated. You
> > must fix your references before this time. If you don't, any manner
> of
> > breakage could result (you are not guaranteed a compilation error).*
> >
> > I think it is worth a discussion on how to handle Guava dependencies
> going
> > forward across the different versions of Accumulo. The goal would be
> to
> > allow use of a newer version version of Guava in client applications
> with
> > the current supported versions of Accumulo.
> >
> > Ideally, we could just eliminate any use of Beta Guava code. But
> there are
> > Beta classes that are very useful and some which we already have
> integrated
> > into released Accumulo versions.
> >
> > There seem to be 3 ways to handle Guava dependencies:
> > 1 - jar shading
> > 2 - copy Guava code into Accumulo
> > 3 - replace Guava code with standard Java
> >
> > We may have to handle it differently with each version of Accumulo.
> For
> > example, 1.8 has more widespread use of Beta annotated code than 1.7.
> >
>

Re: [DISCUSS] Guava Dependencies

[Dave Marion]

We still have to use a Hadoop-compatible version of Guava on the server-side 
though, right? I believe the DFSClient has Guava dependencies.


> 
> On September 18, 2017 at 2:12 PM Mike Miller  wrote:
> 
> Recently tickets have been opened dealing with Guava in Accumulo (see
> ACCUMULO-4701 through 4704), in particular the use of Beta classes and
> methods. Use of Guava comes with a few warnings...
> 
> From the Guava README:
> 
> *1. APIs marked with the @Beta annotation at the class or method level are
> subject to change. They can be modified in any way, or even removed, at 
> any
> time. If your code is a library itself (i.e. it is used on the CLASSPATH 
> of
> users outside your own control), you should not use beta APIs, unless you
> repackage them (e.g. using ProGuard).2.Deprecated non-beta APIs will be
> removed two years after the release in which they are first deprecated. 
> You
> must fix your references before this time. If you don't, any manner of
> breakage could result (you are not guaranteed a compilation error).*
> 
> I think it is worth a discussion on how to handle Guava dependencies going
> forward across the different versions of Accumulo. The goal would be to
> allow use of a newer version version of Guava in client applications with
> the current supported versions of Accumulo.
> 
> Ideally, we could just eliminate any use of Beta Guava code. But there are
> Beta classes that are very useful and some which we already have 
> integrated
> into released Accumulo versions.
> 
> There seem to be 3 ways to handle Guava dependencies:
> 1 - jar shading
> 2 - copy Guava code into Accumulo
> 3 - replace Guava code with standard Java
> 
> We may have to handle it differently with each version of Accumulo. For
> example, 1.8 has more widespread use of Beta annotated code than 1.7.
> 

[DISCUSS] Guava Dependencies

[Mike Miller]

Recently tickets have been opened dealing with Guava in Accumulo (see
ACCUMULO-4701 through 4704), in particular the use of Beta classes and
methods.  Use of Guava comes with a few warnings...

>From the Guava README:

*1. APIs marked with the @Beta annotation at the class or method level are
subject to change. They can be modified in any way, or even removed, at any
time. If your code is a library itself (i.e. it is used on the CLASSPATH of
users outside your own control), you should not use beta APIs, unless you
repackage them (e.g. using ProGuard).2.Deprecated non-beta APIs will be
removed two years after the release in which they are first deprecated. You
must fix your references before this time. If you don't, any manner of
breakage could result (you are not guaranteed a compilation error).*

I think it is worth a discussion on how to handle Guava dependencies going
forward across the different versions of Accumulo.  The goal would be to
allow use of a newer version version of Guava in client applications with
the current supported versions of Accumulo.

Ideally, we could just eliminate any use of Beta Guava code.  But there are
Beta classes that are very useful and some which we already have integrated
into released Accumulo versions.

There seem to be 3 ways to handle Guava dependencies:
1 - jar shading
2 - copy Guava code into Accumulo
3 - replace Guava code with standard Java

We may have to handle it differently with each version of Accumulo.  For
example, 1.8 has more widespread use of Beta annotated code than 1.7.