Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Matt Sicker]

They package ByteBuf and family in a package called netty-buffer which only
depends on netty-common. We could add those as dependencies, or we could
shade them. Do note that netty-common already shades jctools, so this would
be a double-shading which is rather amusing.

On 17 March 2017 at 12:35, Matt Sicker  wrote:

> Oh wait, I looked into it more. That might be usable actually. Plus it
> could be useful for diving directly into the network code of networked file
> systems to implement them more efficiently. I'm not sure how well isolated
> those classes are, so we might need to just take them and do some renaming.
>
> On 17 March 2017 at 12:34, Matt Sicker  wrote:
>
>> I'm actually learning a little bit about ByteBuf from Netty this
>> afternoon. I don't know enough about the implementation to say. The thing
>> is, the Channel APIs all use ByteBuffer. I'm not sure how ByteBufs are
>> converted into ByteBuffers yet.
>>
>> On 17 March 2017 at 12:19, Gary Gregory  wrote:
>>
>>> I'll be happy to help with PMC related tasks.
>>>
>>> Gary
>>>
>>> On Thu, Mar 16, 2017 at 4:31 PM, Matt Sicker  wrote:
>>>
>>> > Commons VFS is still in Subversion. We're going to need a new Git repo
>>> > regardless. I can do an import for that repo like I did for Pool, but I
>>> > need PMC help to complete the transition.
>>> >
>>> > Also, I was thinking about which Java version to support. Java 7 is
>>> > obviously the minimum due to the API being added there, and it doesn't
>>> look
>>> > like there was anything new added in Java 8 for NIO (other than an
>>> improved
>>> > SelectorProvider implementation on Solaris, but that's not a public
>>> API). I
>>> > don't see any additions in Java 9, either. Now I prefer using Java 8
>>> for
>>> > development, but as there appears to be no specific reason to use Java
>>> 8
>>> > for this version, we could really go either way. Using Java 7 makes
>>> more
>>> > sense for creating FileSystemProvider implementations, though
>>> depending on
>>> > any additional APIs added, I don't know if it'll turn out that
>>> supporting
>>> > Java 8 APIs will be all that useful.
>>> >
>>> > On 16 March 2017 at 02:39, Benedikt Ritter  wrote:
>>> >
>>> > > Why not a new branch in the existing repo?
>>> > >
>>> > > Benedikt
>>> > >
>>> > > Ralph Goers  schrieb am Do. 16. März
>>> 2017 um
>>> > > 06:54:
>>> > >
>>> > > > Yes, and here we are with Java 9 at our doorstep.  Time flies.
>>> > > >
>>> > > > I would recommend that you create a commons-vfs3 git repo for this
>>> as
>>> > you
>>> > > > will only be able to borrow some code. A lot will be different.
>>> > > >
>>> > > > Ralph
>>> > > >
>>> > > > > On Mar 15, 2017, at 8:12 PM, Matt Sicker 
>>> wrote:
>>> > > > >
>>> > > > > Ralph has mentioned in the past an idea about rewriting
>>> commons-vfs
>>> > > using
>>> > > > > java.nio.file from Java 7. I was playing with this API today
>>> > attempting
>>> > > > to
>>> > > > > abstract some S3 file operations using <
>>> > > > > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and
>>> found
>>> > > that
>>> > > > > the API is pretty nice. OpenJDK already contains implementations
>>> for
>>> > > the
>>> > > > > normal file system and zip files if I recall correctly (so
>>> probably
>>> > > also
>>> > > > > jar files).
>>> > > > >
>>> > > > > Anyways, if we were to go forward with starting work on this,
>>> should
>>> > we
>>> > > > > just make a commons-vfs3 branch in the vfs repo? Or does this
>>> belong
>>> > in
>>> > > > the
>>> > > > > sandbox?
>>> > > > >
>>> > > > > --
>>> > > > > Matt Sicker 
>>> > > >
>>> > > >
>>> > > >
>>> > > > 
>>> -
>>> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> > > > For additional commands, e-mail: dev-h...@commons.apache.org
>>> > > >
>>> > > >
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> > Matt Sicker 
>>> >
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> >> e=UTF8=1789=9325=1617290459
>>> ode=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>
>>> >> am2=1=1617290459>
>>> JUnit in Action, Second Edition
>>> >> e=UTF8=1789=9325=1935182021
>>> ode=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>
>>> >> am2=1=1935182021>
>>> Spring Batch in Action
>>> >> e=UTF8=1789=9325=1935182951
>>> ode=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%7Blin
>>> k_id%7D%7D%22%3ESpring+Batch+in+Action>
>>> 

Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Matt Sicker]

Oh wait, I looked into it more. That might be usable actually. Plus it
could be useful for diving directly into the network code of networked file
systems to implement them more efficiently. I'm not sure how well isolated
those classes are, so we might need to just take them and do some renaming.

On 17 March 2017 at 12:34, Matt Sicker  wrote:

> I'm actually learning a little bit about ByteBuf from Netty this
> afternoon. I don't know enough about the implementation to say. The thing
> is, the Channel APIs all use ByteBuffer. I'm not sure how ByteBufs are
> converted into ByteBuffers yet.
>
> On 17 March 2017 at 12:19, Gary Gregory  wrote:
>
>> I'll be happy to help with PMC related tasks.
>>
>> Gary
>>
>> On Thu, Mar 16, 2017 at 4:31 PM, Matt Sicker  wrote:
>>
>> > Commons VFS is still in Subversion. We're going to need a new Git repo
>> > regardless. I can do an import for that repo like I did for Pool, but I
>> > need PMC help to complete the transition.
>> >
>> > Also, I was thinking about which Java version to support. Java 7 is
>> > obviously the minimum due to the API being added there, and it doesn't
>> look
>> > like there was anything new added in Java 8 for NIO (other than an
>> improved
>> > SelectorProvider implementation on Solaris, but that's not a public
>> API). I
>> > don't see any additions in Java 9, either. Now I prefer using Java 8 for
>> > development, but as there appears to be no specific reason to use Java 8
>> > for this version, we could really go either way. Using Java 7 makes more
>> > sense for creating FileSystemProvider implementations, though depending
>> on
>> > any additional APIs added, I don't know if it'll turn out that
>> supporting
>> > Java 8 APIs will be all that useful.
>> >
>> > On 16 March 2017 at 02:39, Benedikt Ritter  wrote:
>> >
>> > > Why not a new branch in the existing repo?
>> > >
>> > > Benedikt
>> > >
>> > > Ralph Goers  schrieb am Do. 16. März
>> 2017 um
>> > > 06:54:
>> > >
>> > > > Yes, and here we are with Java 9 at our doorstep.  Time flies.
>> > > >
>> > > > I would recommend that you create a commons-vfs3 git repo for this
>> as
>> > you
>> > > > will only be able to borrow some code. A lot will be different.
>> > > >
>> > > > Ralph
>> > > >
>> > > > > On Mar 15, 2017, at 8:12 PM, Matt Sicker 
>> wrote:
>> > > > >
>> > > > > Ralph has mentioned in the past an idea about rewriting
>> commons-vfs
>> > > using
>> > > > > java.nio.file from Java 7. I was playing with this API today
>> > attempting
>> > > > to
>> > > > > abstract some S3 file operations using <
>> > > > > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and
>> found
>> > > that
>> > > > > the API is pretty nice. OpenJDK already contains implementations
>> for
>> > > the
>> > > > > normal file system and zip files if I recall correctly (so
>> probably
>> > > also
>> > > > > jar files).
>> > > > >
>> > > > > Anyways, if we were to go forward with starting work on this,
>> should
>> > we
>> > > > > just make a commons-vfs3 branch in the vfs repo? Or does this
>> belong
>> > in
>> > > > the
>> > > > > sandbox?
>> > > > >
>> > > > > --
>> > > > > Matt Sicker 
>> > > >
>> > > >
>> > > >
>> > > > 
>> -
>> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > > > For additional commands, e-mail: dev-h...@commons.apache.org
>> > > >
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Matt Sicker 
>> >
>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> > ie=UTF8=1789=9325=1617290459
>> Code=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8>
>>
>> > am2=1=1617290459>
>> JUnit in Action, Second Edition
>> > ie=UTF8=1789=9325=1935182021
>> Code=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>
>> > am2=1=1935182021>
>> Spring Batch in Action
>> > ie=UTF8=1789=9325=1935182951
>> Code=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%7Bli
>> nk_id%7D%7D%22%3ESpring+Batch+in+Action>
>> > am2=1=1935182951>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> Matt Sicker 
>



-- 
Matt Sicker 

Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Matt Sicker]

I'm actually learning a little bit about ByteBuf from Netty this afternoon.
I don't know enough about the implementation to say. The thing is, the
Channel APIs all use ByteBuffer. I'm not sure how ByteBufs are converted
into ByteBuffers yet.

On 17 March 2017 at 12:19, Gary Gregory  wrote:

> I'll be happy to help with PMC related tasks.
>
> Gary
>
> On Thu, Mar 16, 2017 at 4:31 PM, Matt Sicker  wrote:
>
> > Commons VFS is still in Subversion. We're going to need a new Git repo
> > regardless. I can do an import for that repo like I did for Pool, but I
> > need PMC help to complete the transition.
> >
> > Also, I was thinking about which Java version to support. Java 7 is
> > obviously the minimum due to the API being added there, and it doesn't
> look
> > like there was anything new added in Java 8 for NIO (other than an
> improved
> > SelectorProvider implementation on Solaris, but that's not a public
> API). I
> > don't see any additions in Java 9, either. Now I prefer using Java 8 for
> > development, but as there appears to be no specific reason to use Java 8
> > for this version, we could really go either way. Using Java 7 makes more
> > sense for creating FileSystemProvider implementations, though depending
> on
> > any additional APIs added, I don't know if it'll turn out that supporting
> > Java 8 APIs will be all that useful.
> >
> > On 16 March 2017 at 02:39, Benedikt Ritter  wrote:
> >
> > > Why not a new branch in the existing repo?
> > >
> > > Benedikt
> > >
> > > Ralph Goers  schrieb am Do. 16. März 2017
> um
> > > 06:54:
> > >
> > > > Yes, and here we are with Java 9 at our doorstep.  Time flies.
> > > >
> > > > I would recommend that you create a commons-vfs3 git repo for this as
> > you
> > > > will only be able to borrow some code. A lot will be different.
> > > >
> > > > Ralph
> > > >
> > > > > On Mar 15, 2017, at 8:12 PM, Matt Sicker  wrote:
> > > > >
> > > > > Ralph has mentioned in the past an idea about rewriting commons-vfs
> > > using
> > > > > java.nio.file from Java 7. I was playing with this API today
> > attempting
> > > > to
> > > > > abstract some S3 file operations using <
> > > > > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and
> found
> > > that
> > > > > the API is pretty nice. OpenJDK already contains implementations
> for
> > > the
> > > > > normal file system and zip files if I recall correctly (so probably
> > > also
> > > > > jar files).
> > > > >
> > > > > Anyways, if we were to go forward with starting work on this,
> should
> > we
> > > > > just make a commons-vfs3 branch in the vfs repo? Or does this
> belong
> > in
> > > > the
> > > > > sandbox?
> > > > >
> > > > > --
> > > > > Matt Sicker 
> > > >
> > > >
> > > >
> > > > 
> -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Matt Sicker 
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
>  tl?ie=UTF8=1789=9325=1617290459&
> linkCode=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8>
>
>  1617290459>
> JUnit in Action, Second Edition
>  tl?ie=UTF8=1789=9325=1935182021&
> linkCode=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
>
>  1935182021>
> Spring Batch in Action
>  tl?ie=UTF8=1789=9325=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>  1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
Matt Sicker 

Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Gary Gregory]

I'll be happy to help with PMC related tasks.

Gary

On Thu, Mar 16, 2017 at 4:31 PM, Matt Sicker  wrote:

> Commons VFS is still in Subversion. We're going to need a new Git repo
> regardless. I can do an import for that repo like I did for Pool, but I
> need PMC help to complete the transition.
>
> Also, I was thinking about which Java version to support. Java 7 is
> obviously the minimum due to the API being added there, and it doesn't look
> like there was anything new added in Java 8 for NIO (other than an improved
> SelectorProvider implementation on Solaris, but that's not a public API). I
> don't see any additions in Java 9, either. Now I prefer using Java 8 for
> development, but as there appears to be no specific reason to use Java 8
> for this version, we could really go either way. Using Java 7 makes more
> sense for creating FileSystemProvider implementations, though depending on
> any additional APIs added, I don't know if it'll turn out that supporting
> Java 8 APIs will be all that useful.
>
> On 16 March 2017 at 02:39, Benedikt Ritter  wrote:
>
> > Why not a new branch in the existing repo?
> >
> > Benedikt
> >
> > Ralph Goers  schrieb am Do. 16. März 2017 um
> > 06:54:
> >
> > > Yes, and here we are with Java 9 at our doorstep.  Time flies.
> > >
> > > I would recommend that you create a commons-vfs3 git repo for this as
> you
> > > will only be able to borrow some code. A lot will be different.
> > >
> > > Ralph
> > >
> > > > On Mar 15, 2017, at 8:12 PM, Matt Sicker  wrote:
> > > >
> > > > Ralph has mentioned in the past an idea about rewriting commons-vfs
> > using
> > > > java.nio.file from Java 7. I was playing with this API today
> attempting
> > > to
> > > > abstract some S3 file operations using <
> > > > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found
> > that
> > > > the API is pretty nice. OpenJDK already contains implementations for
> > the
> > > > normal file system and zip files if I recall correctly (so probably
> > also
> > > > jar files).
> > > >
> > > > Anyways, if we were to go forward with starting work on this, should
> we
> > > > just make a commons-vfs3 branch in the vfs repo? Or does this belong
> in
> > > the
> > > > sandbox?
> > > >
> > > > --
> > > > Matt Sicker 
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
>
>
>
> --
> Matt Sicker 
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Gary Gregory]

I seems reasonable to go with Java 7 but I would not hesitate to switch to
Java 8 if it makes the job easier.

Gary

On Thu, Mar 16, 2017 at 4:31 PM, Matt Sicker  wrote:

> Commons VFS is still in Subversion. We're going to need a new Git repo
> regardless. I can do an import for that repo like I did for Pool, but I
> need PMC help to complete the transition.
>
> Also, I was thinking about which Java version to support. Java 7 is
> obviously the minimum due to the API being added there, and it doesn't look
> like there was anything new added in Java 8 for NIO (other than an improved
> SelectorProvider implementation on Solaris, but that's not a public API). I
> don't see any additions in Java 9, either. Now I prefer using Java 8 for
> development, but as there appears to be no specific reason to use Java 8
> for this version, we could really go either way. Using Java 7 makes more
> sense for creating FileSystemProvider implementations, though depending on
> any additional APIs added, I don't know if it'll turn out that supporting
> Java 8 APIs will be all that useful.
>
> On 16 March 2017 at 02:39, Benedikt Ritter  wrote:
>
> > Why not a new branch in the existing repo?
> >
> > Benedikt
> >
> > Ralph Goers  schrieb am Do. 16. März 2017 um
> > 06:54:
> >
> > > Yes, and here we are with Java 9 at our doorstep.  Time flies.
> > >
> > > I would recommend that you create a commons-vfs3 git repo for this as
> you
> > > will only be able to borrow some code. A lot will be different.
> > >
> > > Ralph
> > >
> > > > On Mar 15, 2017, at 8:12 PM, Matt Sicker  wrote:
> > > >
> > > > Ralph has mentioned in the past an idea about rewriting commons-vfs
> > using
> > > > java.nio.file from Java 7. I was playing with this API today
> attempting
> > > to
> > > > abstract some S3 file operations using <
> > > > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found
> > that
> > > > the API is pretty nice. OpenJDK already contains implementations for
> > the
> > > > normal file system and zip files if I recall correctly (so probably
> > also
> > > > jar files).
> > > >
> > > > Anyways, if we were to go forward with starting work on this, should
> we
> > > > just make a commons-vfs3 branch in the vfs repo? Or does this belong
> in
> > > the
> > > > sandbox?
> > > >
> > > > --
> > > > Matt Sicker 
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
>
>
>
> --
> Matt Sicker 
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Gary Gregory]

Can we just pick up Netty's buffers and put them in Commons IO and use that
from Commons VFS?

Gary

On Thu, Mar 16, 2017 at 8:06 PM, Matt Sicker  wrote:

> Based on experience with ByteBuffers in the past, I have a feeling VFS3 may
> want to provide some sort of abstraction over it like how Netty does.
> Otherwise, managing ByteBuffers can become painful.
>
> On 16 March 2017 at 10:31, Matt Sicker  wrote:
>
> > Commons VFS is still in Subversion. We're going to need a new Git repo
> > regardless. I can do an import for that repo like I did for Pool, but I
> > need PMC help to complete the transition.
> >
> > Also, I was thinking about which Java version to support. Java 7 is
> > obviously the minimum due to the API being added there, and it doesn't
> look
> > like there was anything new added in Java 8 for NIO (other than an
> improved
> > SelectorProvider implementation on Solaris, but that's not a public
> API). I
> > don't see any additions in Java 9, either. Now I prefer using Java 8 for
> > development, but as there appears to be no specific reason to use Java 8
> > for this version, we could really go either way. Using Java 7 makes more
> > sense for creating FileSystemProvider implementations, though depending
> on
> > any additional APIs added, I don't know if it'll turn out that supporting
> > Java 8 APIs will be all that useful.
> >
> > On 16 March 2017 at 02:39, Benedikt Ritter  wrote:
> >
> >> Why not a new branch in the existing repo?
> >>
> >> Benedikt
> >>
> >> Ralph Goers  schrieb am Do. 16. März 2017
> um
> >> 06:54:
> >>
> >> > Yes, and here we are with Java 9 at our doorstep.  Time flies.
> >> >
> >> > I would recommend that you create a commons-vfs3 git repo for this as
> >> you
> >> > will only be able to borrow some code. A lot will be different.
> >> >
> >> > Ralph
> >> >
> >> > > On Mar 15, 2017, at 8:12 PM, Matt Sicker  wrote:
> >> > >
> >> > > Ralph has mentioned in the past an idea about rewriting commons-vfs
> >> using
> >> > > java.nio.file from Java 7. I was playing with this API today
> >> attempting
> >> > to
> >> > > abstract some S3 file operations using <
> >> > > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found
> >> that
> >> > > the API is pretty nice. OpenJDK already contains implementations for
> >> the
> >> > > normal file system and zip files if I recall correctly (so probably
> >> also
> >> > > jar files).
> >> > >
> >> > > Anyways, if we were to go forward with starting work on this, should
> >> we
> >> > > just make a commons-vfs3 branch in the vfs repo? Or does this belong
> >> in
> >> > the
> >> > > sandbox?
> >> > >
> >> > > --
> >> > > Matt Sicker 
> >> >
> >> >
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> > For additional commands, e-mail: dev-h...@commons.apache.org
> >> >
> >> >
> >>
> >
> >
> >
> > --
> > Matt Sicker 
> >
>
>
>
> --
> Matt Sicker 
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Matt Sicker]

Based on experience with ByteBuffers in the past, I have a feeling VFS3 may
want to provide some sort of abstraction over it like how Netty does.
Otherwise, managing ByteBuffers can become painful.

On 16 March 2017 at 10:31, Matt Sicker  wrote:

> Commons VFS is still in Subversion. We're going to need a new Git repo
> regardless. I can do an import for that repo like I did for Pool, but I
> need PMC help to complete the transition.
>
> Also, I was thinking about which Java version to support. Java 7 is
> obviously the minimum due to the API being added there, and it doesn't look
> like there was anything new added in Java 8 for NIO (other than an improved
> SelectorProvider implementation on Solaris, but that's not a public API). I
> don't see any additions in Java 9, either. Now I prefer using Java 8 for
> development, but as there appears to be no specific reason to use Java 8
> for this version, we could really go either way. Using Java 7 makes more
> sense for creating FileSystemProvider implementations, though depending on
> any additional APIs added, I don't know if it'll turn out that supporting
> Java 8 APIs will be all that useful.
>
> On 16 March 2017 at 02:39, Benedikt Ritter  wrote:
>
>> Why not a new branch in the existing repo?
>>
>> Benedikt
>>
>> Ralph Goers  schrieb am Do. 16. März 2017 um
>> 06:54:
>>
>> > Yes, and here we are with Java 9 at our doorstep.  Time flies.
>> >
>> > I would recommend that you create a commons-vfs3 git repo for this as
>> you
>> > will only be able to borrow some code. A lot will be different.
>> >
>> > Ralph
>> >
>> > > On Mar 15, 2017, at 8:12 PM, Matt Sicker  wrote:
>> > >
>> > > Ralph has mentioned in the past an idea about rewriting commons-vfs
>> using
>> > > java.nio.file from Java 7. I was playing with this API today
>> attempting
>> > to
>> > > abstract some S3 file operations using <
>> > > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found
>> that
>> > > the API is pretty nice. OpenJDK already contains implementations for
>> the
>> > > normal file system and zip files if I recall correctly (so probably
>> also
>> > > jar files).
>> > >
>> > > Anyways, if we were to go forward with starting work on this, should
>> we
>> > > just make a commons-vfs3 branch in the vfs repo? Or does this belong
>> in
>> > the
>> > > sandbox?
>> > >
>> > > --
>> > > Matt Sicker 
>> >
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>> >
>>
>
>
>
> --
> Matt Sicker 
>



-- 
Matt Sicker 

Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Matt Sicker]

Commons VFS is still in Subversion. We're going to need a new Git repo
regardless. I can do an import for that repo like I did for Pool, but I
need PMC help to complete the transition.

Also, I was thinking about which Java version to support. Java 7 is
obviously the minimum due to the API being added there, and it doesn't look
like there was anything new added in Java 8 for NIO (other than an improved
SelectorProvider implementation on Solaris, but that's not a public API). I
don't see any additions in Java 9, either. Now I prefer using Java 8 for
development, but as there appears to be no specific reason to use Java 8
for this version, we could really go either way. Using Java 7 makes more
sense for creating FileSystemProvider implementations, though depending on
any additional APIs added, I don't know if it'll turn out that supporting
Java 8 APIs will be all that useful.

On 16 March 2017 at 02:39, Benedikt Ritter  wrote:

> Why not a new branch in the existing repo?
>
> Benedikt
>
> Ralph Goers  schrieb am Do. 16. März 2017 um
> 06:54:
>
> > Yes, and here we are with Java 9 at our doorstep.  Time flies.
> >
> > I would recommend that you create a commons-vfs3 git repo for this as you
> > will only be able to borrow some code. A lot will be different.
> >
> > Ralph
> >
> > > On Mar 15, 2017, at 8:12 PM, Matt Sicker  wrote:
> > >
> > > Ralph has mentioned in the past an idea about rewriting commons-vfs
> using
> > > java.nio.file from Java 7. I was playing with this API today attempting
> > to
> > > abstract some S3 file operations using <
> > > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found
> that
> > > the API is pretty nice. OpenJDK already contains implementations for
> the
> > > normal file system and zip files if I recall correctly (so probably
> also
> > > jar files).
> > >
> > > Anyways, if we were to go forward with starting work on this, should we
> > > just make a commons-vfs3 branch in the vfs repo? Or does this belong in
> > the
> > > sandbox?
> > >
> > > --
> > > Matt Sicker 
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>



-- 
Matt Sicker 

Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Benedikt Ritter]

Why not a new branch in the existing repo?

Benedikt

Ralph Goers  schrieb am Do. 16. März 2017 um
06:54:

> Yes, and here we are with Java 9 at our doorstep.  Time flies.
>
> I would recommend that you create a commons-vfs3 git repo for this as you
> will only be able to borrow some code. A lot will be different.
>
> Ralph
>
> > On Mar 15, 2017, at 8:12 PM, Matt Sicker  wrote:
> >
> > Ralph has mentioned in the past an idea about rewriting commons-vfs using
> > java.nio.file from Java 7. I was playing with this API today attempting
> to
> > abstract some S3 file operations using <
> > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found that
> > the API is pretty nice. OpenJDK already contains implementations for the
> > normal file system and zip files if I recall correctly (so probably also
> > jar files).
> >
> > Anyways, if we were to go forward with starting work on this, should we
> > just make a commons-vfs3 branch in the vfs repo? Or does this belong in
> the
> > sandbox?
> >
> > --
> > Matt Sicker 
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Gary Gregory]

Great idea Matt. This is a long time coming. A porting guide will be key. I
have a lot of code depending on vfs2.

Gary

On Mar 16, 2017 6:54 AM, "Ralph Goers"  wrote:

> Yes, and here we are with Java 9 at our doorstep.  Time flies.
>
> I would recommend that you create a commons-vfs3 git repo for this as you
> will only be able to borrow some code. A lot will be different.
>
> Ralph
>
> > On Mar 15, 2017, at 8:12 PM, Matt Sicker  wrote:
> >
> > Ralph has mentioned in the past an idea about rewriting commons-vfs using
> > java.nio.file from Java 7. I was playing with this API today attempting
> to
> > abstract some S3 file operations using <
> > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found that
> > the API is pretty nice. OpenJDK already contains implementations for the
> > normal file system and zip files if I recall correctly (so probably also
> > jar files).
> >
> > Anyways, if we were to go forward with starting work on this, should we
> > just make a commons-vfs3 branch in the vfs repo? Or does this belong in
> the
> > sandbox?
> >
> > --
> > Matt Sicker 
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Ralph Goers]

Yes, and here we are with Java 9 at our doorstep.  Time flies.

I would recommend that you create a commons-vfs3 git repo for this as you will 
only be able to borrow some code. A lot will be different.

Ralph

> On Mar 15, 2017, at 8:12 PM, Matt Sicker  wrote:
> 
> Ralph has mentioned in the past an idea about rewriting commons-vfs using
> java.nio.file from Java 7. I was playing with this API today attempting to
> abstract some S3 file operations using <
> https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found that
> the API is pretty nice. OpenJDK already contains implementations for the
> normal file system and zip files if I recall correctly (so probably also
> jar files).
> 
> Anyways, if we were to go forward with starting work on this, should we
> just make a commons-vfs3 branch in the vfs repo? Or does this belong in the
> sandbox?
> 
> -- 
> Matt Sicker 



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Peter Ansell]

Feel free to merge your changes into Tika to update the barebones
implementation I contributed there:

https://github.com/apache/tika/blob/master/tika-java7/src/main/java/org/apache/tika/filetypedetector/TikaFileTypeDetector.java

Cheers,

Peter

On 16 March 2017 at 14:46, Schalk Cronjé <ysb...@gmail.com> wrote:
> I have already implemented FileTypeDetector using Tika ->
> https://github.com/ysb33r/nio2-filedetector-tika.
>
>
> On 16/03/2017 09:14, Matt Sicker wrote:
>>
>> There's also a ton of in-depth features like file attributes, ACLs, other
>> permissions, etc. Then there's a bit of overlap with security concerns
>> that
>> come with that. It certainly provides a rather broad matrix of features
>> that are possible to expose. There's also FileTypeDetector which has
>> functional overlap with Tika. Also, the dependencies in vfs2 are pretty
>> out
>> of date at this point.
>>
>> On 15 March 2017 at 22:27, Schalk W. Cronjé <ysb...@gmail.com> wrote:
>>
>>>
>>> The ZIP implementation is very basic. I've started exoerimenting with
>>> this
>>> quite a while ago writing a RAM filesystem as to experiment w.ith the
>>> complexities.
>>> I would definitely be interested in working with you on this even if it
>>> is
>>> only for shared learning. As one dives deeper into it there's a lot of
>>> 'devil in details' and two minds are better than one to bounce ideas
>>> around.
>>>
>>>
>>> Sent from my Samsung device
>>>
>>> ---- Original message 
>>> From: Matt Sicker <boa...@gmail.com>
>>> Date: 16/03/2017  08:42  (GMT+05:30)
>>> To: Commons Developers List <dev@commons.apache.org>
>>> Subject: [VFS] Interest in starting a Java 7 FileSystem-based version?
>>>
>>> Ralph has mentioned in the past an idea about rewriting commons-vfs using
>>> java.nio.file from Java 7. I was playing with this API today attempting
>>> to
>>> abstract some S3 file operations using <
>>> https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found that
>>> the API is pretty nice. OpenJDK already contains implementations for the
>>> normal file system and zip files if I recall correctly (so probably also
>>> jar files).
>>>
>>> Anyways, if we were to go forward with starting work on this, should we
>>> just make a commons-vfs3 branch in the vfs repo? Or does this belong in
>>> the
>>> sandbox?
>>>
>>> --
>>> Matt Sicker <boa...@gmail.com>
>>>
>>
>>
>
>
> --
> Schalk W. Cronjé
> Twitter / Ello / Toeter : @ysb33r
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Schalk Cronjé]

I have already implemented FileTypeDetector using Tika -> 
https://github.com/ysb33r/nio2-filedetector-tika.


On 16/03/2017 09:14, Matt Sicker wrote:

There's also a ton of in-depth features like file attributes, ACLs, other
permissions, etc. Then there's a bit of overlap with security concerns that
come with that. It certainly provides a rather broad matrix of features
that are possible to expose. There's also FileTypeDetector which has
functional overlap with Tika. Also, the dependencies in vfs2 are pretty out
of date at this point.

On 15 March 2017 at 22:27, Schalk W. Cronjé <ysb...@gmail.com> wrote:



The ZIP implementation is very basic. I've started exoerimenting with this
quite a while ago writing a RAM filesystem as to experiment w.ith the
complexities.
I would definitely be interested in working with you on this even if it is
only for shared learning. As one dives deeper into it there's a lot of
'devil in details' and two minds are better than one to bounce ideas around.


Sent from my Samsung device

 Original message 
From: Matt Sicker <boa...@gmail.com>
Date: 16/03/2017  08:42  (GMT+05:30)
To: Commons Developers List <dev@commons.apache.org>
Subject: [VFS] Interest in starting a Java 7 FileSystem-based version?

Ralph has mentioned in the past an idea about rewriting commons-vfs using
java.nio.file from Java 7. I was playing with this API today attempting to
abstract some S3 file operations using <
https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found that
the API is pretty nice. OpenJDK already contains implementations for the
normal file system and zip files if I recall correctly (so probably also
jar files).

Anyways, if we were to go forward with starting work on this, should we
just make a commons-vfs3 branch in the vfs repo? Or does this belong in the
sandbox?

--
Matt Sicker <boa...@gmail.com>







--
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Matt Sicker]

There's also a ton of in-depth features like file attributes, ACLs, other
permissions, etc. Then there's a bit of overlap with security concerns that
come with that. It certainly provides a rather broad matrix of features
that are possible to expose. There's also FileTypeDetector which has
functional overlap with Tika. Also, the dependencies in vfs2 are pretty out
of date at this point.

On 15 March 2017 at 22:27, Schalk W. Cronjé <ysb...@gmail.com> wrote:

>
>
> The ZIP implementation is very basic. I've started exoerimenting with this
> quite a while ago writing a RAM filesystem as to experiment w.ith the
> complexities.
> I would definitely be interested in working with you on this even if it is
> only for shared learning. As one dives deeper into it there's a lot of
> 'devil in details' and two minds are better than one to bounce ideas around.
>
>
> Sent from my Samsung device
>
>  Original message 
> From: Matt Sicker <boa...@gmail.com>
> Date: 16/03/2017  08:42  (GMT+05:30)
> To: Commons Developers List <dev@commons.apache.org>
> Subject: [VFS] Interest in starting a Java 7 FileSystem-based version?
>
> Ralph has mentioned in the past an idea about rewriting commons-vfs using
> java.nio.file from Java 7. I was playing with this API today attempting to
> abstract some S3 file operations using <
> https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found that
> the API is pretty nice. OpenJDK already contains implementations for the
> normal file system and zip files if I recall correctly (so probably also
> jar files).
>
> Anyways, if we were to go forward with starting work on this, should we
> just make a commons-vfs3 branch in the vfs repo? Or does this belong in the
> sandbox?
>
> --
> Matt Sicker <boa...@gmail.com>
>



-- 
Matt Sicker <boa...@gmail.com>

Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Peter Ansell]

An example from Google of a custom Java-7 file system provider (Apache
licensed) which may also be useful is at:

https://github.com/google/jimfs

Cheers,

Peter

On 16 March 2017 at 14:12, Matt Sicker  wrote:
> Ralph has mentioned in the past an idea about rewriting commons-vfs using
> java.nio.file from Java 7. I was playing with this API today attempting to
> abstract some S3 file operations using <
> https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found that
> the API is pretty nice. OpenJDK already contains implementations for the
> normal file system and zip files if I recall correctly (so probably also
> jar files).
>
> Anyways, if we were to go forward with starting work on this, should we
> just make a commons-vfs3 branch in the vfs repo? Or does this belong in the
> sandbox?
>
> --
> Matt Sicker 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VFS] Interest in starting a Java 7 FileSystem-based version?

[Schalk W . Cronjé]

The ZIP implementation is very basic. I've started exoerimenting with this 
quite a while ago writing a RAM filesystem as to experiment w.ith the 
complexities.
I would definitely be interested in working with you on this even if it is only 
for shared learning. As one dives deeper into it there's a lot of 'devil in 
details' and two minds are better than one to bounce ideas around.


Sent from my Samsung device

 Original message 
From: Matt Sicker <boa...@gmail.com> 
Date: 16/03/2017  08:42  (GMT+05:30) 
To: Commons Developers List <dev@commons.apache.org> 
Subject: [VFS] Interest in starting a Java 7 FileSystem-based version? 

Ralph has mentioned in the past an idea about rewriting commons-vfs using
java.nio.file from Java 7. I was playing with this API today attempting to
abstract some S3 file operations using <
https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found that
the API is pretty nice. OpenJDK already contains implementations for the
normal file system and zip files if I recall correctly (so probably also
jar files).

Anyways, if we were to go forward with starting work on this, should we
just make a commons-vfs3 branch in the vfs repo? Or does this belong in the
sandbox?

-- 
Matt Sicker <boa...@gmail.com>

[VFS] Interest in starting a Java 7 FileSystem-based version?

[Matt Sicker]

Ralph has mentioned in the past an idea about rewriting commons-vfs using
java.nio.file from Java 7. I was playing with this API today attempting to
abstract some S3 file operations using <
https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found that
the API is pretty nice. OpenJDK already contains implementations for the
normal file system and zip files if I recall correctly (so probably also
jar files).

Anyways, if we were to go forward with starting work on this, should we
just make a commons-vfs3 branch in the vfs repo? Or does this belong in the
sandbox?

-- 
Matt Sicker