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 th
On 02/06/2016 08:45, Stian Soiland-Reyes wrote:
As each filesystem provider in nio2 only does one URI scheme we would
probably need nested URIs or multiple providers.
I would like to see how that one will get solved. It is definitely one
of the joys of VFS.
--
Schalk W. Cronjé
Twitter / E
I have looked at this for some time and played with some ideas. Firstly,
I want to say that atm NIO2 sucks. It sucks because there are no decent
provider implementations. So using the knowledge from VFS2 today, I
think a great contribution can be made to "re-use" the VFS2 projects for
NIO2.
I
If the next main release is going to be JDK7 & NIO focused, should there
not be a 3.0-SNAPSHOT branch as well?
On 19/05/2016 03:14, Josh Elser wrote:
Hi all,
Worked through the remaining steps for this release. dist.a.o (dev and
release) were both updated, trunk was bumped to 2.2-SNAPSHOT, ne
With VFS 2.1 getting out, I can clean up Groovy VFS 1.0 as well and get
it out of beta state \o/
I'm all for that NIO thing :-}
Just yesterday I wrote a provider for Files.probeFileContent(Path) which
utilises Apache Tika. It's on Github atm -
https://github.com/ysb33r/nio2-filedetector-tika.
By matter of assocation (and some expressive freedom).
Ajama -> Adama -> Battlestar Galactica -> Galactica -> Mathelactica.
And thus: Mathelactica the Apache Mathematics library
I think that name can fly (pun intented).
Regards
On 25/01/2016 13:24, Gilles wrote:
On Mon, 25 Jan 2016 13:41
compile scope of vfs core [1]
Benedikt
[1]
https://github.com/apache/commons-vfs/blob/422c4f5d6822a77679a2c70166d72adb7d426c98/core/pom.xml#L83
Gruss
Bernd
--
http://bernd.eckenfels.net
-Original Message-
From: "Schalk Cronjé"
To: Commons Developers List
Sent: Do., 29 Okt.
]
Benedikt
[1]
https://github.com/apache/commons-vfs/blob/422c4f5d6822a77679a2c70166d72adb7d426c98/core/pom.xml#L83
Gruss
Bernd
--
http://bernd.eckenfels.net
-Original Message-
From: "Schalk Cronjé"
To: Commons Developers List
Sent: Do., 29 Okt. 2015 1:30 AM
Subject: [VFS]
Bernd,
Is it possible to bump the Jackrabbit version to 2.11.1 for the VFS 2.1
release?
The current 1.6.5 is quite old and later versions of jackrabbit-webdav
cannot be used with the existing 2.0.
I did a quick check and there seems to be only one test failure when the
version is bumped:
On 03/09/2015 08:13, Arsen Babakhanyan wrote:
Thanks a lot for help. I have started some research on projects.
Choosing right project to begin with is important i think !
VFS can do with some help...
--
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r
--
extending to fit better with VFS, but it seems
wrong to put the CPIO code in VFS which already depends on Compress.
On 1 July 2015 at 21:25, Schalk Cronjé wrote:
Would anyone fancy backporting this cpio-provider
(https://github.com/ysb33r/groovy-vfs/tree/development/cpio-provider) into
Java and
Would anyone fancy backporting this cpio-provider
(https://github.com/ysb33r/groovy-vfs/tree/development/cpio-provider)
into Java and adding it to VFS?
I pretty much wrote it based upon the Tar provider.
--
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r
-
12 matches
Mail list logo
