accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dlmar...@comcast.net
Subject Re: On the future of our commons-vfs2 dynamic classloading implementation
Date Mon, 25 Apr 2016 18:18:54 GMT
My email from Dec 2015 was sent as a last ditch effort before we fork. I don't remember receiving
a response to it. I may have worn out my welcome in that community as I have been outspoken
on the lack of movement. It might be useful for someone else to try once more, and if not,
then we fork VFS, remove all of the things we don't need, and make it better. 


----- Original Message -----

From: "Josh Elser" <josh.elser@gmail.com> 
To: dev@accumulo.apache.org 
Sent: Monday, April 25, 2016 1:02:08 PM 
Subject: Re: On the future of our commons-vfs2 dynamic classloading implementation 

Thanks Dave. I know you've spent a bit of time trying to push them in 
the right direction. 

I don't have a lot of familiarity with how the commons-* actually work. 
I am more than happy to address any issues of pick-and-choose engagement 
by commons-* folks at the ASF level if you have more info to back this 
up. I trust Benson to raise the issue to the right group if there is 
something inherently wrong. 

Based on your emails, it seems like there have been discussions having a 
release for 2+ years, but no discernible progress (despite your offers 
to help with the process). 

Being the one who has been making the most effort on this front, what do 
you feel is the best course of action to unblock us? 

dlmarion@comcast.net wrote: 
> I feel your pain and am very frustrated by the lack of support from the Commons team.
I have brought up the subject multiple times[1,2,3] and have even volunteered to do the release.
FWIW, I am using the features of the new classloader in production with little issue (using
the 2.1 snapshot code). A few months ago I discussed this with Christopher and the topic of
forking did come up. Also note that Benson just went through the release process for Commons
IO and it was not pain free. Apparently they are willing to work with some people and not
others. 
> 
> [1] http://markmail.org/message/4iczynn2tqbtwdhd?q=VFS+2.1+release+list:org.apache.commons.dev/+from:%22dlmarion%40comcast.net%22&page=1

> [2] http://markmail.org/search/?q=VFS%202.1%20release%20list%3Aorg.apache.commons.dev%2F#query:VFS%202.1%20release%20list%3Aorg.apache.commons.dev%2F%20from%3A%22dlmarion%40comcast.net%22+page:1+mid:zkjkgvpsrh4blvtj+state:results

> [3] http://markmail.org/message/ojgizsfevkjjl6jv?q=VFS+2.1+release+list:org.apache.commons.dev/+from:%22dlmarion%40comcast.net%22&page=1

> 
> ----- Original Message ----- 
> 
> From: "Mike Drob"<mdrob@apache.org> 
> To: dev@accumulo.apache.org 
> Sent: Monday, April 25, 2016 11:37:25 AM 
> Subject: Re: On the future of our commons-vfs2 dynamic classloading implementation 
> 
> Have we asked them about making a release? 
> 
> On Mon, Apr 25, 2016 at 10:35 AM, Josh Elser<josh.elser@gmail.com> wrote: 
> 
>> I was trying to test out Dylan's patch this weekend and was met with a 
>> repeated failure of another VFS unit test due to the same race condition 
>> we've been fighting against for years. 
>> 
>> A cursory glance to vfs' website show still shows that they haven't made 
>> the 2.1 release which supposedly fixes this issue. In other words, they 
>> have no made a release since 2011. 
>> 
>> I'm now under the assumption that we cannot rely on them to make a 
>> release. As such, if the community wishes to continue to support this 
>> feature, something needs to happen before 1.8.0 -- fork vfs, use/build some 
>> other library for this functionality, or remove the dynamic-classloader 
>> functionality from Accumulo completely. 
>> 
>> I've tried to be very patient waiting for this to happen, but I'm rather 
>> frustrated having wasted significant time over the past years (not even 
>> exaggerating which is even crazier) working around known broken code that 
>> is unusable by users. 
>> 
>> Thoughts? 
>> 
>> - Josh 
>> 
> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message