You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mario Ivankovits <ma...@ops.co.at> on 2005/11/12 19:50:29 UTC
Re: [vfs] jcommander [was: Browse the SMB network]
Hi!
> After having completed the JCommander 0.7.0 release and having a clear
> picture over all the VFS project, we thought of starting to contribute to it
> if you would be interested.
>
If you need any assistance and/or found a bug, please do not hesitate to
ask or file it here: http://issues.apache.org/bugzilla
I am really interested to see vfs working in such an environment.
Another project I started is JFileWatch:
http://l3x.net/imwiki/Wiki.jsp?page=JFileWatch
which should allow us to use e.g. inotify for linux to get filesystem
events.
Currently, I have only an implementation for linux - and I dont know if
it works with the latest inotify, but such a tool might be a great
addition for jcommander too. My motivation for further development might
rise :-)
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] jcommander [was: Browse the SMB network]
Posted by Robert Enyedi <re...@gmail.com>.
Hi Mario
> Some parts of this library could be standalone, but most of it should be
> > better in VFS:
> >
> ---snip---
>
> Sure, I see what you mean.
> I have to admit I am a little bit afraid about all this native stuff.
I myself am afraid of native code. The healthiest would be to have the
required native code included and maintained from inside the JDK but I
suppose that's not going to happen. That's why I see all native code going
into an optional VFS package.
I'd say, lets go to 1.1 - there are some bugs/todos before starting new
> ideas.
> e.g. one of it is a progress/cancellation api
> (I guess you might be happy to see as I have seen you tried hard to
> implement such stuff for jcommander)
Yes, we had a basic requirement for displaying operations progress and allow
interruptions (pause and cancellation). If you think we could donate the
code we already have to VFS as a starting point in the development of this
feature.
If the user base gets larger - and I hope the developer base too, we
> might hire someone to maintain at least the windows part too :-)
I think we can collaborate with JDIC project because they have native
development expertise on Windows and I think that on MacOS X too.
Regards,
Robert
Re: [vfs] jcommander [was: Browse the SMB network]
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Robert!
> Some parts of this library could be standalone, but most of it should be
> better in VFS:
>
---snip---
Sure, I see what you mean.
I have to admit I am a little bit afraid about all this native stuff.
I'd say, lets go to 1.1 - there are some bugs/todos before starting new
ideas.
e.g. one of it is a progress/cancellation api
(I guess you might be happy to see as I have seen you tried hard to
implement such stuff for jcommander)
If the user base gets larger - and I hope the developer base too, we
might hire someone to maintain at least the windows part too :-)
Anyway, I'll put it on the todo list.
Ciao,
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] jcommander [was: Browse the SMB network]
Posted by Robert Enyedi <re...@gmail.com>.
Hi Mario,
I know that it is quite an effort to keep track of the features developed on
multiple branches and versions. Maybe after the enhancement requests have
been discussed you could have a clearer look on what should go into 1.1 and
what should be delayed for 1.2. And maybe at that point you could think of a
1.2 branch with clearly defined targets especially if you would have
contributors for those features.
Regards,
Robert
On 11/14/05, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi!
> >Agree. Will let you guys know if I have anything useful and we can put
> >it in a branch first until it stabilizes..
> >
>
> >>And if so couldn't a separate
> >>(maybe 1.2) branch be created and start developing the identified
> >>features?
> >>A merge into the main branch could be done later once 1.1 is released.
> >>
>
> You know, every contribution is very welcome.
> But in our current constellation its too much hassle for us (me) to
> support multiple branches.
>
> Once I have a better feeling how it is to deal with releases and the
> development/vote/release cycle is more naturally I'll consider this again.
> You see how complicated it can be to get a release out ;-)
>
> Said that, any contribution will go into the development branch for now.
>
> I'll publish a list of requested enhancements on commons-dev so we can
> start a discussion on it.
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [vfs] jcommander [was: Browse the SMB network]
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
>Agree. Will let you guys know if I have anything useful and we can put
>it in a branch first until it stabilizes..
>
>>And if so couldn't a separate
>>(maybe 1.2) branch be created and start developing the identified
>>features?
>>A merge into the main branch could be done later once 1.1 is released.
>>
You know, every contribution is very welcome.
But in our current constellation its too much hassle for us (me) to
support multiple branches.
Once I have a better feeling how it is to deal with releases and the
development/vote/release cycle is more naturally I'll consider this again.
You see how complicated it can be to get a release out ;-)
Said that, any contribution will go into the development branch for now.
I'll publish a list of requested enhancements on commons-dev so we can
start a discussion on it.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] jcommander [was: Browse the SMB network]
Posted by fi...@cirquedigital.com.
hi,
Agree. Will let you guys know if I have anything useful and we can put
it in a branch first until it stabilizes..
Cheers,
- Filip
> Hi Filip,
>
> The file permissions and notifications I'm actually quite interested in
>> and may very well be forced to deal with in the near future... so
>> wouldn't
>> mind pitching in on these things...
>
>
> Given the large number of feature requests 1.1 already has I suppose that
> it
> will be decided for these two to go in 1.2. And if so couldn't a separate
> (maybe 1.2) branch be created and start developing the identified
> features?
> A merge into the main branch could be done later once 1.1 is released.
>
> Just my 2 cents...
>
> Regards,
> Robert
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] jcommander [was: Browse the SMB network]
Posted by Robert Enyedi <re...@gmail.com>.
Hi Filip,
The file permissions and notifications I'm actually quite interested in
> and may very well be forced to deal with in the near future... so wouldn't
> mind pitching in on these things...
Given the large number of feature requests 1.1 already has I suppose that it
will be decided for these two to go in 1.2. And if so couldn't a separate
(maybe 1.2) branch be created and start developing the identified features?
A merge into the main branch could be done later once 1.1 is released.
Just my 2 cents...
Regards,
Robert
Re: [vfs] jcommander [was: Browse the SMB network]
Posted by fi...@cirquedigital.com.
...
> Some parts of this library could be standalone, but most of it should be
> better in VFS:
> - file notifications - for instance on SMB too
> - partition information - you could get information for remote partitions
> too (SMB shares, FTP accounts)
> - trash/recycle bin handling - having an option to perform a deletion to
> the
> trash or make it a permanent one is useful even when calling VFS from Ant
> - file permissions - a generic mechanism on getting and setting file
> permissions regardless of the operating system is useful even in Ant
> scripts
Hi Mario,
The file permissions and notifications I'm actually quite interested in
and may very well be forced to deal with in the near future... so wouldn't
mind pitching in on these things...
Cheers,
- Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] jcommander [was: Browse the SMB network]
Posted by Robert Enyedi <re...@gmail.com>.
Mario,
> Do you think that in the future VFS could have a
> > native extension library which could be developed to support these?
> I am not sure now, as long as there is (at least) no windows and mac
> developer around, I'd say NO.
> I am able to do the windows native part myself, but I am absolutely not
> motivated to do it. :-\
Well, you could have a lot of VFS users on win32 for instance through
JCommander. The idea would be to create the ultimate platform independent
file management library for Java. Something that Sun was not able to do in
10 years.
> We could
> > interest people from the JDIC project (e.g.
> > https://jdic.dev.java.net/incubator/fileutil/index.html)<https://jdic.dev.java.net/incubator/fileutil/index.html%29>and maybe we could
> > set up a native C++ developers pool that could provide help in this
> process.
> >
> This looks interesting.
> If we manage to do so, VFS will support such a library for sure.
>
> Though, we have to see what the value of VFS can be here. I mean, such a
> library works pretty well standalone, we might just provide a way to get
> a FileObject out of a java.io.File, and this is already possible.
Some parts of this library could be standalone, but most of it should be
better in VFS:
- file notifications - for instance on SMB too
- partition information - you could get information for remote partitions
too (SMB shares, FTP accounts)
- trash/recycle bin handling - having an option to perform a deletion to the
trash or make it a permanent one is useful even when calling VFS from Ant
- file permissions - a generic mechanism on getting and setting file
permissions regardless of the operating system is useful even in Ant scripts
What do you think?
Regards,
Robert
Re: [vfs] jcommander [was: Browse the SMB network]
Posted by Mario Ivankovits <ma...@ops.co.at>.
Robert Enyedi wrote:
> Do you think that in the future VFS could have a
> native extension library which could be developed to support these?
I am not sure now, as long as there is (at least) no windows and mac
developer around, I'd say NO.
I am able to do the windows native part myself, but I am absolutely not
motivated to do it. :-\
> We could
> interest people from the JDIC project (e.g.
> https://jdic.dev.java.net/incubator/fileutil/index.html) and maybe we could
> set up a native C++ developers pool that could provide help in this process.
>
This looks interesting.
If we manage to do so, VFS will support such a library for sure.
Though, we have to see what the value of VFS can be here. I mean, such a
library works pretty well standalone, we might just provide a way to get
a FileObject out of a java.io.File, and this is already possible.
Ciao,
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] jcommander [was: Browse the SMB network]
Posted by Robert Enyedi <re...@gmail.com>.
Mario,
If you need any assistance and/or found a bug, please do not hesitate to
> ask or file it here: http://issues.apache.org/bugzilla
Thanks for the pointer. Be sure that we will provide as much feedback as
possible.
I am really interested to see vfs working in such an environment.
This is great! I have just uploaded a development version (for Windows and
Linux: https://sourceforge.net/project/shownotes.php?release_id=370450)
which runs on VFS. You might play with it and provide us some feedback too
(the JCommander forum is a good start:
http://sourceforge.net/forum/?group_id=35271).
Another project I started is JFileWatch:
> http://l3x.net/imwiki/Wiki.jsp?page=JFileWatch
> which should allow us to use e.g. inotify for linux to get filesystem
> events.
> Currently, I have only an implementation for linux - and I dont know if
> it works with the latest inotify, but such a tool might be a great
> addition for jcommander too. My motivation for further development might
> rise :-)
Great :-) This sounds interesting indeed. JFileWatch could be useful in
JCommander to monitor third-party activities in the current directory and
refresh when detecting these.
As an adjacent issue, we all know the limitations of the
java.io<http://java.io>API in dealing with files. The approach VFS
uses is a pure Java one, however
there are file system features that are completely unavailable in Java.
There are several examples : file notifications (in your case), partition
information, trash/recycle bin handling, file permissions. For all these
native code is required. Do you think that in the future VFS could have a
native extension library which could be developed to support these? We could
interest people from the JDIC project (e.g.
https://jdic.dev.java.net/incubator/fileutil/index.html) and maybe we could
set up a native C++ developers pool that could provide help in this process.
Regards,
Robert