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é  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 
Date: 16/03/2017  08:42  (GMT+05:30)
To: Commons Developers List 
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 







--
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] NIO Version Questions

[Schalk Cronjé]

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 / Ello / Toeter : @ysb33r

Re: [VFS] NIO Version Questions

[Schalk Cronjé]

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 think one can take two routes:

[1] Provide separate providers i.e. fts, sftp etc. which are simply 
loaded separately. This has the advantage that each provider can be 
developed independently whilst having some core code that is shared. The 
core code could include stuff such as caching, which already has some 
good solutions in VFS2


[2] Provide a single front-end scheme, which then also loads the 
subsequent protocol i.e. vfs:ftp://. This could potentially then just 
load up a VFS system underneath and re-use most of the code as-is. I 
think there will be quite some technical problems to solve, as I am not 
sure whether the current VFS2 architecture will play along being a NIO2 
provider (maybe it will, but I don't know).


Unfortunately I have not seen any way to handle multi-scheme such as 
zip:http:// in NIO2. It might be possible to do something like that in 
route #2.


My gut feeling, is to just start following #1 for now and roll out 
separate providers for each protocol. This will allow for some usage 
patterns to develop in the community.



On 02/06/2016 00:28, Benson Margulies wrote:

Which direction do you have in mind here? I'd be up for helping to
build a device that makes commons-vfs act as an NIO2 file system
provider, but you might be aiming in the opposite direction.


On Wed, Jun 1, 2016 at 7:02 PM, Peter Ansell  wrote:

On 2 June 2016 at 01:48, Mark Fortner  wrote:

There was some discussion during the last release about a NIO-compatible
version of VFS.  This raised a few questions in my mind.

1. Is there a branch where this work should start?
2. Are there any specific API proposals, if so where are they (or will
they) be documented?  Would there be branches with specific proposal code,
or a wiki?
3. Does anyone have an "out of the gate" proposal? A proposed file
system implementation that they're willing to contribute/collaborate on?
Preferably something that's easy to test without additional server setup.
Perhaps a db-based file system that could use java db?
4. How would the code be organized? Would each implementation have to
have its own repo? If so, this might slow down initial API development.
And you always run into the danger that any API changes you make break
implementing code.
5. Has anyone considered support for virtual roots in file system URLs?
Like "home://", "documents://", "music://", etc.

Virtual roots are very simple in NIO2. They are implemented using
FileSystemProvider with a
META-INF/services/java.nio.file.spi.FileSystemProvider file for
autodiscovery by java.util.ServiceLoader.

https://docs.oracle.com/javase/7/docs/technotes/guides/io/fsp/filesystemprovider.html

Cheers,

Peter

-
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




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

Re: [VFS] Final steps for 2.1

[Schalk Cronjé]

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, nexus 
repo was released, reporter.a.o was updated, and the svn tag was 
renamed. I did remove the checksums on the signatures before promoting 
the Nexus repository (thanks for pointing that out Bernd and Sebb). 
Just pushed all of the fixVersion=2.1 issues out as well.


Copying from Ralph's 2.0 announcement:


The Apache Commons team is pleased to announce the release of Apache 
Commons VFS 2.1


Details of the changes and bug fixes in this release can be found in
the release notes:
http://www.apache.org/dist/commons/vfs/RELEASE_NOTES.txt

For information on Commons VFS please visit the VFS website:
http://commons.apache.org/vfs/

Commons VFS can be downloaded from the following page:
http://commons.apache.org/vfs/download_vfs.cgi

- The Apache Commons community


We'll need to do the following after the artifacts filter out to the 
mirrors:


* Update the website [1]
* Send out the ANNOUNCE (text above)

Anything else I missed?

- Josh

[1]http://commons.apache.org/site-publish.html

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




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

Re: [vfs] On to Java 7

[Schalk Cronjé]

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.




On 19/05/2016 12:44, Ralph Goers wrote:

If Java 7 is going to be the minimum version then VFS should become an 
extension of java.nio.file.  Not doing that doesn’t make any sense to me and 
you should just keep the Java version at 6 since you aren’t taking advantage of 
the new Java APIs.

Ralph


On May 19, 2016, at 3:21 AM, Gary Gregory  wrote:

Now that we have finally gotten 2.1 out the door, I think it is time to
move [vfs] on to Java 7.

Tracking here: https://issues.apache.org/jira/browse/VFS-612

Gary

--
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



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




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

Re: [math] Name of the new TLP

[Schalk Cronjé]

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:46 +0100, Emmanuel Bourg wrote:

Le 25/01/2016 13:21, Gilles a écrit :


 * AJaMa
?

The last one is short while fully descriptive:
  AJaMa
   is
the Apache JAva MAthematics library


This one will probably sound too similar with Jama, another math 
library:


http://math.nist.gov/javanumerics/jama/


I made the proposal knowing about this.

A few years ago, the JAMA project had been declared dead (although I 
do not

find the announcement page).
Anyways, it has not been updated since November 2012.
To be sure we could ask them.

A similar sounding name could be taken as a tribute... ;-)


Will the new TLP focus on Java libraries exclusively or will it be open
to implementations in other languages?


This is also a fundamental question.

Given that we could not even agree to evolve with the JDK (last 
release of

CM had to be Java *5* source-compatible!), it would be a (bad) joke (or a
revolution!) to throw other languages into the discussion.

Gilles



Emmanuel Bourg



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




--
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] Jackrabbit

[Schalk Cronjé]

What I have noticed whilst playing around with JackRabbit is that the 
jackrabbit-standalone.jar used as part of testing is not available under 
the later 2.x releases. I think the VFS 2.1 release should probably 
stick to the 1.6.5 release. I would rather see VFS 2.1 get released, 
than waste time now trying to get a later Jackrabbit to work. This can 
always be looked at for a future release.





On 29/10/2015 07:37, Benedikt Ritter wrote:

Hi,

2015-10-29 2:17 GMT+01:00 :


Hello,

Unfortunatelly the whole webdav filesystem tests depend on that specific
version as it wraps the server as an endpoint. The setUp fails so the whole
test suite will get skipped. I havent been able to quickly fix when I tried
to bump the dependency (but it is not impossible, as you can also test
against other servers). But isnt this only a test dependency?


No, looks like it is an optional dependency in 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. 2015 1:30 AM
Subject: [VFS] Jackrabbit

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:

 junit.framework.AssertionFailedError: Folder does not exist:
 webdav://admin@localhost:61279/repository/default/read-tests
  at junit.framework.Assert.fail(Assert.java:57)
  at junit.framework.Assert.assertTrue(Assert.java:22)
  at

org.apache.commons.vfs2.test.AbstractTestSuite.setUp(AbstractTestSuite.java:190)
  at

org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1.setUp(WebdavProviderTestCase.java:284)
  at

org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:148)
  at junit.framework.TestResult.runProtected(TestResult.java:142)
  at

org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:154)
  at

org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
  at

org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
  at

org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
  at

org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
  at

org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
  at

org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
  at

org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
  at

org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)


--
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





--
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] Jackrabbit

[Schalk Cronjé]

Hi again,

The issue was discovered during some work I was doing for Groovy-VFS. In 
that situtation the webdav provider is consumed and it will fail to work 
if anything JackRabbit 2.0+ is used as a depedency. The webdav provider 
released with VFS 2.0 is depending on a static field (BUILDER_FACTORY) 
in JackRabbit that no longer exists in the 2.0+ releases.


HTH

On 29/10/2015 07:37, Benedikt Ritter wrote:

Hi,

2015-10-29 2:17 GMT+01:00 :


Hello,

Unfortunatelly the whole webdav filesystem tests depend on that specific
version as it wraps the server as an endpoint. The setUp fails so the whole
test suite will get skipped. I havent been able to quickly fix when I tried
to bump the dependency (but it is not impossible, as you can also test
against other servers). But isnt this only a test dependency?


No, looks like it is an optional dependency in 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. 2015 1:30 AM
Subject: [VFS] Jackrabbit

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:

 junit.framework.AssertionFailedError: Folder does not exist:
 webdav://admin@localhost:61279/repository/default/read-tests
  at junit.framework.Assert.fail(Assert.java:57)
  at junit.framework.Assert.assertTrue(Assert.java:22)
  at

org.apache.commons.vfs2.test.AbstractTestSuite.setUp(AbstractTestSuite.java:190)
  at

org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1.setUp(WebdavProviderTestCase.java:284)
  at

org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:148)
  at junit.framework.TestResult.runProtected(TestResult.java:142)
  at

org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:154)
  at

org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
  at

org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
  at

org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
  at

org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
  at

org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
  at

org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
  at

org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
  at

org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)


--
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





--
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

[VFS] Jackrabbit

[Schalk Cronjé]

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:


   junit.framework.AssertionFailedError: Folder does not exist:
   webdav://admin@localhost:61279/repository/default/read-tests
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.assertTrue(Assert.java:22)
at
   
org.apache.commons.vfs2.test.AbstractTestSuite.setUp(AbstractTestSuite.java:190)
at
   
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1.setUp(WebdavProviderTestCase.java:284)
at
   
org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:148)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at
   
org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:154)
at
   org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
at
   
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at
   
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at
   
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
   
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at
   
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at
   
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at
   org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)


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

Re: need some help

[Schalk Cronjé]

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


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

Re: [VFS] cpio

[Schalk Cronjé]

VFS correctly depends on Compress as it uses the Tar etc. libraries from 
there.


What I was referring to is backporting the provider code to VFS. The 
provider relies on the CPIO code from Compress,


On 01/07/2015 22:01, sebb wrote:

Commons Compress already supports CPIO.

Perhaps that needs 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 adding it to VFS?

I pretty much wrote it based upon the Tar provider.


--
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




--
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

[VFS] cpio

[Schalk Cronjé]

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


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