Adding an IO File system abstraction about silenceengine HOT 14 CLOSED

Good idea. I am looking forward to this addition and seeing how it will be implemented.

from silenceengine.

The functions are very basic, but it works. Had to write more methods, like the mkdirs, copyTo, moveTo etc., and change the other classes to accept from FilePath instances. This feature is not complete yet, so I will not close this issue until it is completely done.

from silenceengine.

Nice work. May I add this to XShot to use for file management, etc? I will keep your author tag and attribute your work as necessary. Also, XShot is under the MIT license just like your code.

from silenceengine.

Yeah, that's okay as long as you keep my author tag. I'll submit a PR to your repository once this is usable, as I did not test this thoroughly. Could you wait until it is complete? I don't want my incomplete code in other's projects

from silenceengine.

Sounds good. I'll just let you make a PR when it's done. Whenever you're done add it to the file package and I'll implement the resource manage specific to XShot that I was talking about. Thanks. :)

from silenceengine.

Added a new property size for the files. This works for both resources and external files, but in the case of the resources, it is not accurate. For directories, the size is always reported as 4096b, i.e., 4 KB. And I have implemented copyTo method. The next in the list is listChildren method for directories.

from silenceengine.

Implemented the listFiles() method for both resources and external files. Also added mkdirs() and createFile() and moveTo() methods for external files. Fixed the size calculation, now it shows the correct size for directories on both resources and external files. Testing and documentation is now in balance.

from silenceengine.

I have verified that these FilePaths are now working as they should, from the IDE (I use IDEA), from the command line (java command from the build directory) and also from a runnable JAR. I moved the detection code from the constructor to the getters, as those properties are not commonly used.

However, this will only work (list files and file size) if the library is extracted into the runnable JAR. So if there is only one single JAR, this works well. I still have to test from other IDEs, so some help in testing with other IDEs will be helpful.

from silenceengine.

I'll test it in eclipse some time tomorrow also a possible way to "fix" you problem with one jar is to give it the ability to set its own base path from a file object as it could then use that to redirect itself properly when given an abstract path (could give it a list to store them in and it looks for the file in all base paths) or you could just have it give the absolute path but that would probably defeat what your going for.

from silenceengine.

There seems to be a bug in the isDirectory method, it keeps throwing FileSystemNotFoundException for resources that are directly in the root of the class path, but it is working for resources that are in a folder which is in a sub-directory in the classpath. This, however only occurs when running from the IDE, it is mistaking the IDE for a ZipFileSystem when the file is in the root. Will investigate this soon as the JAR file exported is working fine. Right now, I'm swallowing the FileSystemNotFoundException, I know it is a bad approach, and it'll be fixed very soon.

from silenceengine.

It seems to work fine for me however you should always copy files only to places you know exists. For example I don't have a D drive (Its named E on my computer) so the test fails when it runs because of that however directory seems to run properly though i didn't look that hard

from silenceengine.

Yeah, I dunno how I missed that. Will do that today.

from silenceengine.

The bug I said yesterday (regarding FileSystemNotFoundException thrown for files in another jar/zip file in the classpath) is already reported in the Oracle bug tracker, and can be seen here: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7181278

So I tried for a work-around, that is now working. Now if we detect that the URI starts with jar:/ or zip:/, then we create a new FileSystem object instead of relying on the ZipFileSystemProvider class. For now, everything works as intended. I think the only thing that is pending in this issue is some refactorings and documentation.

from silenceengine.

The FilePath class is now completely documented and tested. I'm now closing this issue as it has been implemented, but if you want to say anything you can still comment here.

from silenceengine.