Re: [VFS] Support for File System Roots?

2012-12-28 Thread Mark Fortner
Hi Gary,
This would be per operating system.  So, if I call
*RootFactory.getRoot(RootNames.HOME)
*from a Linux box, that would resolve to */home/*, on a Windows
box that might be */Users/*.  It would be driven by the *
System.getProperty("user.home")* variable.  The other roots, are OS
dependent and are subdirectories of the home directory.  You might also
have another method like *getRoot(RootNames.HOME, OS.LINUX)* that would let
you get the value for Linux, even if you aren't on a Linux box.

The URIs might look like "/Documents" which would resolve to
"file:///home//Documents".

This came up because I'm reworking a Swing file manager using JavaFX and I
wanted to clean up the API some and minimize any VFS specific workarounds I
was doing.

Cheers,

Mark



On Fri, Dec 28, 2012 at 11:42 AM, Gary Gregory wrote:

> Would this only be for Windows? What do URIs look like?
>
> Gary
>
> On Dec 28, 2012, at 14:18, Mark Fortner  wrote:
>
> > I was wondering if there were any plans (or currently any way) to support
> > File System Roots.  In addition to the standard sorts of roots, there are
> > roots like your home directory, the Documents, Photos, Music, Downloads,
> > etc.
> >
> > At a minimum it would be useful to have an Enum of the different
> directory
> > names, with some way of resolving them.  Something like:
> >
> > FileObject root = RootFactory.getRoot(RootNames.HOME);
> >
> > and
> >
> > Map rootMap = RootFactory.getRoots();
> >
> >
> > Cheers,
> >
> > Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


Re: [VFS] Support for File System Roots?

2012-12-28 Thread Mark Fortner
Hi Gary,
Good question.  There would need to be some OS version checking to
determine which directory to return.  I seem to recall that older versions
of Windows had a C:\Documents and Settings folder or something like that.
 Currently, I use Spring to config these directories (rather than hard
coding them).  What would be the appropriate Commons VFS way of dealing
with this?  An abstract factory method perhaps with hard coded factories
per OS + version?

Cheers,

Mark



On Fri, Dec 28, 2012 at 11:57 AM, Gary Gregory wrote:

> Hi,
>
> Ok, patches welcome! :)
>
> What happens if there is a c:\Documents folder?
>
> Gary
>
> On Dec 28, 2012, at 14:54, Mark Fortner  wrote:
>
> > Hi Gary,
> > This would be per operating system.  So, if I call
> > *RootFactory.getRoot(RootNames.HOME)
> > *from a Linux box, that would resolve to */home/*, on a Windows
> > box that might be */Users/*.  It would be driven by the *
> > System.getProperty("user.home")* variable.  The other roots, are OS
> > dependent and are subdirectories of the home directory.  You might also
> > have another method like *getRoot(RootNames.HOME, OS.LINUX)* that would
> let
> > you get the value for Linux, even if you aren't on a Linux box.
> >
> > The URIs might look like "/Documents" which would resolve to
> > "file:///home//Documents".
> >
> > This came up because I'm reworking a Swing file manager using JavaFX and
> I
> > wanted to clean up the API some and minimize any VFS specific
> workarounds I
> > was doing.
> >
> > Cheers,
> >
> > Mark
> >
> >
> >
> > On Fri, Dec 28, 2012 at 11:42 AM, Gary Gregory  >wrote:
> >
> >> Would this only be for Windows? What do URIs look like?
> >>
> >> Gary
> >>
> >> On Dec 28, 2012, at 14:18, Mark Fortner  wrote:
> >>
> >>> I was wondering if there were any plans (or currently any way) to
> support
> >>> File System Roots.  In addition to the standard sorts of roots, there
> are
> >>> roots like your home directory, the Documents, Photos, Music,
> Downloads,
> >>> etc.
> >>>
> >>> At a minimum it would be useful to have an Enum of the different
> >> directory
> >>> names, with some way of resolving them.  Something like:
> >>>
> >>> FileObject root = RootFactory.getRoot(RootNames.HOME);
> >>>
> >>> and
> >>>
> >>> Map rootMap = RootFactory.getRoots();
> >>>
> >>>
> >>> Cheers,
> >>>
> >>> Mark
> >>
> >> -
> >> 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] Support for File System Roots?

2013-01-06 Thread Mark Fortner
Gary,
The File#getRoots() method that you mentioned gets the file system roots
and not user-specific directories like Documents, Downloads, Photos, Music,
etc.

I ended up creating a solution with maps of directories for each operating
system (or relevant OS version in the case of Windows).  I also implemented
a solution for resolving "~" as the home directory in URLs.  I can check
these into my project and send you the URLs for the files if you're
interested.

Cheers,

Mark



On Sun, Jan 6, 2013 at 3:18 PM, Roger L. Whitcomb  wrote:

> I'm actually working on a similar project to make a new version of the
> Apache Pivot File Browser to use VFS.  So, I'd also be interested to see
> what suggestions the developers here have.
>
> ~Roger Whitcomb
>
> -Original Message-
> From: Mark Fortner [mailto:phidia...@gmail.com]
> Sent: Friday, December 28, 2012 11:54 AM
> To: Commons Developers List
> Subject: Re: [VFS] Support for File System Roots?
>
> Hi Gary,
> This would be per operating system.  So, if I call
> *RootFactory.getRoot(RootNames.HOME)
> *from a Linux box, that would resolve to */home/*, on a
> Windows box that might be */Users/*.  It would be driven by
> the *
> System.getProperty("user.home")* variable.  The other roots, are OS
> dependent and are subdirectories of the home directory.  You might also
> have another method like *getRoot(RootNames.HOME, OS.LINUX)* that would
> let you get the value for Linux, even if you aren't on a Linux box.
>
> The URIs might look like "/Documents" which would resolve to
> "file:///home//Documents".
>
> This came up because I'm reworking a Swing file manager using JavaFX and
> I wanted to clean up the API some and minimize any VFS specific
> workarounds I was doing.
>
> Cheers,
>
> Mark
>
>
>
> On Fri, Dec 28, 2012 at 11:42 AM, Gary Gregory
> wrote:
>
> > Would this only be for Windows? What do URIs look like?
> >
> > Gary
> >
> > On Dec 28, 2012, at 14:18, Mark Fortner  wrote:
> >
> > > I was wondering if there were any plans (or currently any way) to
> > > support File System Roots.  In addition to the standard sorts of
> > > roots, there are roots like your home directory, the Documents,
> > > Photos, Music, Downloads, etc.
> > >
> > > At a minimum it would be useful to have an Enum of the different
> > directory
> > > names, with some way of resolving them.  Something like:
> > >
> > > FileObject root = RootFactory.getRoot(RootNames.HOME);
> > >
> > > and
> > >
> > > Map rootMap = RootFactory.getRoots();
> > >
> > >
> > > Cheers,
> > >
> > > Mark
> >
> > -
> > 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] Support for File System Roots?

2013-01-06 Thread Mark Fortner
Sorry, that should have read *FileSystem.listRoots()*.

Cheers,

Mark



On Sun, Jan 6, 2013 at 4:50 PM, Mark Fortner  wrote:

> Gary,
> The File#getRoots() method that you mentioned gets the file system roots
> and not user-specific directories like Documents, Downloads, Photos, Music,
> etc.
>
> I ended up creating a solution with maps of directories for each operating
> system (or relevant OS version in the case of Windows).  I also implemented
> a solution for resolving "~" as the home directory in URLs.  I can check
> these into my project and send you the URLs for the files if you're
> interested.
>
> Cheers,
>
> Mark
>
>
>
> On Sun, Jan 6, 2013 at 3:18 PM, Roger L. Whitcomb <
> roger.whitc...@actian.com> wrote:
>
>> I'm actually working on a similar project to make a new version of the
>> Apache Pivot File Browser to use VFS.  So, I'd also be interested to see
>> what suggestions the developers here have.
>>
>> ~Roger Whitcomb
>>
>> -Original Message-
>> From: Mark Fortner [mailto:phidia...@gmail.com]
>> Sent: Friday, December 28, 2012 11:54 AM
>> To: Commons Developers List
>> Subject: Re: [VFS] Support for File System Roots?
>>
>> Hi Gary,
>> This would be per operating system.  So, if I call
>> *RootFactory.getRoot(RootNames.HOME)
>> *from a Linux box, that would resolve to */home/*, on a
>> Windows box that might be */Users/*.  It would be driven by
>> the *
>> System.getProperty("user.home")* variable.  The other roots, are OS
>> dependent and are subdirectories of the home directory.  You might also
>> have another method like *getRoot(RootNames.HOME, OS.LINUX)* that would
>> let you get the value for Linux, even if you aren't on a Linux box.
>>
>> The URIs might look like "/Documents" which would resolve to
>> "file:///home//Documents".
>>
>> This came up because I'm reworking a Swing file manager using JavaFX and
>> I wanted to clean up the API some and minimize any VFS specific
>> workarounds I was doing.
>>
>> Cheers,
>>
>> Mark
>>
>>
>>
>> On Fri, Dec 28, 2012 at 11:42 AM, Gary Gregory
>> wrote:
>>
>> > Would this only be for Windows? What do URIs look like?
>> >
>> > Gary
>> >
>> > On Dec 28, 2012, at 14:18, Mark Fortner  wrote:
>> >
>> > > I was wondering if there were any plans (or currently any way) to
>> > > support File System Roots.  In addition to the standard sorts of
>> > > roots, there are roots like your home directory, the Documents,
>> > > Photos, Music, Downloads, etc.
>> > >
>> > > At a minimum it would be useful to have an Enum of the different
>> > directory
>> > > names, with some way of resolving them.  Something like:
>> > >
>> > > FileObject root = RootFactory.getRoot(RootNames.HOME);
>> > >
>> > > and
>> > >
>> > > Map rootMap = RootFactory.getRoots();
>> > >
>> > >
>> > > Cheers,
>> > >
>> > > Mark
>> >
>> > -
>> > 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] New feature request: configurable socket timeout for HTTP and WebDAV in VFS

2013-02-05 Thread Mark Fortner
Just out of curiousity, is there a reason that socket timeouts shouldn't
also apply to all file systems in general?

Cheers,

Mark



On Tue, Feb 5, 2013 at 8:58 AM, Gary Gregory  wrote:

> Sure, make sure you base you patch on the latest from trunk.
>
> Gary
>
>
> On Tue, Feb 5, 2013 at 11:50 AM, Jean-Marc Borer 
> wrote:
>
> > Hello list members,
> >
> > We need to be able to specify socket timeouts in VFS for HTTP and
> > WebDAV in our project so that request will no hang for ever in certain
> > conditions.
> >
> >  I have modified the sources of HttpFileSystemConfigBuilder and
> > HttpClientFactory to be able to configure this in HttpClient.
> >
> > Do you want me to propose a patch for that?
> >
> > Cheers,
> >
> > Jean-marc
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>


Re: [vfs] New feature request: configurable socket timeout for HTTP and WebDAV in VFS

2013-02-05 Thread Mark Fortner
Perhaps not for local file systems, but I would imagine that any kind of
distributed file system would have need of a socket timeout.

Cheers,

Mark



On Tue, Feb 5, 2013 at 1:59 PM, Gary Gregory  wrote:

> On Tue, Feb 5, 2013 at 4:54 PM, Mark Fortner  wrote:
>
> > Just out of curiousity, is there a reason that socket timeouts shouldn't
> > also apply to all file systems in general?
> >
>
> How does a socket timeout make sense for a local file system, ZIP, and so
> on?
>
> Gary
>
>
> >
> > Cheers,
> >
> > Mark
> >
> >
> >
> > On Tue, Feb 5, 2013 at 8:58 AM, Gary Gregory 
> > wrote:
> >
> > > Sure, make sure you base you patch on the latest from trunk.
> > >
> > > Gary
> > >
> > >
> > > On Tue, Feb 5, 2013 at 11:50 AM, Jean-Marc Borer 
> > > wrote:
> > >
> > > > Hello list members,
> > > >
> > > > We need to be able to specify socket timeouts in VFS for HTTP and
> > > > WebDAV in our project so that request will no hang for ever in
> certain
> > > > conditions.
> > > >
> > > >  I have modified the sources of HttpFileSystemConfigBuilder and
> > > > HttpClientFactory to be able to configure this in HttpClient.
> > > >
> > > > Do you want me to propose a patch for that?
> > > >
> > > > Cheers,
> > > >
> > > > Jean-marc
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> > > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> > >
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>


Re: [VFS] Support for File System Roots?

2013-02-08 Thread Mark Fortner
Gary,
I'm not aware of the tilde being used for any other purpose in any other
file system. If a user had specified a directory like "~/mu~noz" as a home
directory it should resolve to the appropriate directory i.e. "/mu~noz".

As for it being optional on a per file system basis, I suppose that's
possible. Is there a way of storing/registering file system configurations
(ala Spring Context)?

I hadn't really thought about it's use for other file systems.  Merely for
use with the local file system.  How would you use this in a distributed
file system?  What would happen if the remote file system did not have a
home directory (or equivalent) for the current user?

Mark

Cheers,

Mark



On Sun, Jan 6, 2013 at 10:24 PM, Gary Gregory wrote:

> Ok, that sounds interesting. Can you give us some examples? I sounds like
> it makes sense for file:// only. Did you have it in mind for other file
> systems?
>
> Should the treatment of '~' be optional? Is there a chance of it being
> confused with any kind of legal file reference on any OS?
>
> Gary
>
>
> On Sun, Jan 6, 2013 at 7:50 PM, Mark Fortner  wrote:
>
> > Gary,
> > The File#getRoots() method that you mentioned gets the file system roots
> > and not user-specific directories like Documents, Downloads, Photos,
> Music,
> > etc.
> >
> > I ended up creating a solution with maps of directories for each
> operating
> > system (or relevant OS version in the case of Windows).  I also
> implemented
> > a solution for resolving "~" as the home directory in URLs.  I can check
> > these into my project and send you the URLs for the files if you're
> > interested.
> >
> > Cheers,
> >
> > Mark
> >
> >
> >
> > On Sun, Jan 6, 2013 at 3:18 PM, Roger L. Whitcomb <
> > roger.whitc...@actian.com
> > > wrote:
> >
> > > I'm actually working on a similar project to make a new version of the
> > > Apache Pivot File Browser to use VFS.  So, I'd also be interested to
> see
> > > what suggestions the developers here have.
> > >
> > > ~Roger Whitcomb
> > >
> > > -Original Message-
> > > From: Mark Fortner [mailto:phidia...@gmail.com]
> > > Sent: Friday, December 28, 2012 11:54 AM
> > > To: Commons Developers List
> > > Subject: Re: [VFS] Support for File System Roots?
> > >
> > > Hi Gary,
> > > This would be per operating system.  So, if I call
> > > *RootFactory.getRoot(RootNames.HOME)
> > > *from a Linux box, that would resolve to */home/*, on a
> > > Windows box that might be */Users/*.  It would be driven by
> > > the *
> > > System.getProperty("user.home")* variable.  The other roots, are OS
> > > dependent and are subdirectories of the home directory.  You might also
> > > have another method like *getRoot(RootNames.HOME, OS.LINUX)* that would
> > > let you get the value for Linux, even if you aren't on a Linux box.
> > >
> > > The URIs might look like "/Documents" which would resolve to
> > > "file:///home//Documents".
> > >
> > > This came up because I'm reworking a Swing file manager using JavaFX
> and
> > > I wanted to clean up the API some and minimize any VFS specific
> > > workarounds I was doing.
> > >
> > > Cheers,
> > >
> > > Mark
> > >
> > >
> > >
> > > On Fri, Dec 28, 2012 at 11:42 AM, Gary Gregory
> > > wrote:
> > >
> > > > Would this only be for Windows? What do URIs look like?
> > > >
> > > > Gary
> > > >
> > > > On Dec 28, 2012, at 14:18, Mark Fortner  wrote:
> > > >
> > > > > I was wondering if there were any plans (or currently any way) to
> > > > > support File System Roots.  In addition to the standard sorts of
> > > > > roots, there are roots like your home directory, the Documents,
> > > > > Photos, Music, Downloads, etc.
> > > > >
> > > > > At a minimum it would be useful to have an Enum of the different
> > > > directory
> > > > > names, with some way of resolving them.  Something like:
> > > > >
> > > > > FileObject root = RootFactory.getRoot(RootNames.HOME);
> > > > >
> > > > > and
> > > > >
> > > > > Map rootMap = RootFactory.getRoots();
> > > > >
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Mark
> > > >
> > > > -
> > > > 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
> > >
> > >
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>


VFS Questions

2023-09-13 Thread Mark Fortner
I was looking at the VFS code recently and had a few questions:

   - There's a *plugins.xml* file that each of the plugins needs to
   register themselves with. I was wondering if there was a reason that the
   *ServiceLoader* wasn't used for this? It would seem like a natural fit.
   - Are there any plans to create adaptors for the NIO FS package? I'm
   envisioning something where we write adapters that adapt the interfaces of
   one to the interfaces of the other. This might cut down on the amount of
   work, since every implementation would not have to write their own NIO FS
   adapter.
   - Is there a TCK for VFS? This would make it easy for implementers to
   verify that they're conforming with the intent of the interfaces. This came
   up while I was looking over the S3 implementation and realised that the
   UserAuthenticator doesn't seem to be implemented. And that credentials are
   basically part of the URL. Ideally, the TCK would allow the user to specify
   a ROOT URL, and user credentials, and then run the suite of tests and
   verify that all operations work properly.
   - What is the long-term plan for VFS? Do you want to have all of the
   implementations be NIO FS implementations, and the original APIs for VFS
   would be deprecated? The reason I ask is that we have an application that
   currently uses VFS with a handful of plugins and want to know if we should
   plan on refactoring that at some point to NIO FS?


Cheers,

Mark


Re: [ALL] Too much traffic on the "dev" ML

2015-01-17 Thread Mark Fortner
Bulk JIRA changes prior to a release tend to swamp the list. Perhaps it
would be better to close the issue as the work is done.

Mark
On Jan 17, 2015 8:11 AM, "Gilles"  wrote:

> On Sat, 17 Jan 2015 16:36:55 +0100, Gilles wrote:
>
>> On Sat, 17 Jan 2015 15:00:34 +, sebb wrote:
>>
>>> On 17 January 2015 at 14:23, Gilles 
>>> wrote:
>>>
 On Fri, 16 Jan 2015 16:00:45 -0600, Ole Ersoy wrote:

>
> I agree - we're hung up on a clown from the 90s.  It's so much
> simpler click watch on github and get notifications.  Also
> stackoverflow has a much broader Java community and having traffic go
> through it could benefit this community.
>


 I'm afraid that the main problem is not the tool.

 Step 1: an issue is felt as a problem by some people (from the
 community or might-be contributors)
 Step 2: people (from the community) who don't feel the problem
 try to demonstrate that there isn't a problem, thus
 dismissing the (argumented) feeling of others

 This can destroy a community, or at least prevent its expansion.
 [And the "Commons" project's (with the word "project" as in "an
 Apache project") community certainly does not benefit from a
 pool of contributors commensurate with its purported goal and
 user base.]

 On the practical side, I'm not (yet) against having a single "dev"
 list: discussions about design are usually interesting even if
 applied to another project's codebase (with the the word "project"
 as in "programming project").

 But lately, the flood of automatic notifications (commits and CI)
 has drowned the useful discussions.

>>>
>>> commits are already sent to a separate list.
>>>
>>
>> The more stringent problem is getting _all_ the projects' commits!
>>
>>  I have just recently changed Continuum and the Jenkins Math job to use
>>> commits as well.
>>>
>>> What other automatic notifications are still affecting the dev list?
>>>
>>> Maybe they can be redirected elsewhere.
>>>
>>>  For people who do not contribute to a project (i.e. neither
 providing code nor checking it), a commit diff is just noise
 because they lack context (not being aquainted with the codebase).

>>>
>>> Indeed, which is why it is good that they are sent to a different
>>> mailing list.
>>>
>>
>> Good, yes. Enough, no.
>>
>>
>>>  The Commons community's implied answer to the stated fact is
 that people who feel that way should change their perception of
 reality, or go away.

 The respectful answer would be to solve the problem with the
 readily available technology of the 1990s: separate MLs for
 each project's _notifications_ (with the word "project" as in
 "programming project").

>>>
>>> As already previously noted, the PMC are responsible for oversight and
>>> so must see all the commits.
>>>
>>
>> No, they _must_ not. Because you cannot enforce the "must". [As noted
>> by several people, they use filters...]
>> People do what they want, and what they can.
>>
>
> In addition to segregated commit MLs, I think that one _digest_ message
> every day, summarizing all the commits (of all projects) of the day might
> help a lot: policy would be safe.
>
>
> Gilles
>
>
>  The number of people voting for any one release of a given
>> (programming) project is proof enough that not everybody checks
>> everything.
>> Even those who vote "should" review, but not necessarily do so
>> extensively (if, for example, what is more important for them is
>> that the release happens).
>> [To avoid instant flaming, I immediately stress that it is _not_
>> to say that Apache should publish unreviewed code...]
>>
>>  Would it really make enough of a difference to non-PMC members to be
>>> worth the additional work (ours and Infra) of setting up individual
>>> commit lists?
>>>
>>
>> The result would be worth it; oh, yes!
>>
>> Unfortunately, I cannot imagine how much work this is going to be,
>> as I never delved into commit trigger scripts.
>>
>>
>> Gilles
>>
>>
 Regards,
 Gilles


  Ole
>
> On 01/16/2015 10:21 AM, Ben McCann wrote:
>
>>
>> I find the whole I idea of a mailing list very 1990s. I'd much prefer
>> something like Google Groups where I can set my notification
>> preferences
>> easily to send me updates only on certain threads such as threads I've
>> started, which has a nice easily browsable and searchable web
>> interface,
>> and where I do not have to go through a signup process for each new
>> group/list I want to post to. I feel many of the problems folks are
>> talking
>> about here are caused by using a frustrating technology. E.g. it was
>> mentioned that if we split mailing lists that joining every list
>> would be
>> very painful. Perhaps that's because the process of joining just a
>> single
>> list is too difficult. Having to s

Re: AW: [PROPOSAL][test] Apache Commons JUnit

2017-11-05 Thread Mark Fortner
Just out of curiosity, wouldn't it be easier (and more intuitive) for users
of JUnit to find a collection of JUnit-related tools on the JUnit project
site?

Regards,

Mark

On 5 Nov 2017 11:51 a.m., "Romain Manni-Bucau" 
wrote:

> This is a bit different since my case was to get annoutput of where a test
> can lock and not a diff. But technically it is close.
>
> Le 5 nov. 2017 20:21, "Bernd Eckenfels"  a écrit :
>
> > Hello,
> >
> >
> > commons-vfs does this (at the Moment it only dumps the threads and does
> > not break the build)
> >
> > https://github.com/apache/commons-vfs/blob/trunk/
> > commons-vfs2/src/test/java/org/apache/commons/vfs2/test/
> > AbstractTestSuite.java#L213
> >
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> >
> > Von: Romain Manni-Bucau
> > Gesendet: Sonntag, 5. November 2017 16:31
> > An: Commons Developers List
> > Betreff: Re: [PROPOSAL] Apache Commons JUnit
> >
> > This daemon thing is interesting, I something similar to dump each N
> > seconds threads to investigate some tests locking on a CI. Can goes
> > there as well probably.
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> >
> >
> > 2017-11-05 16:23 GMT+01:00 Gary Gregory :
> > > On Sat, Nov 4, 2017 at 11:12 AM, Gary Gregory 
> > > wrote:
> > >
> > >> So are you advocating for a multi-module project?
> > >>
> > >> - commons-testing
> > >> - commons-testing-junit4
> > >> - commons-testing-junit5
> > >>
> > >> ?
> > >>
> > >> Gary
> > >>
> > >>
> > >> On Sat, Nov 4, 2017 at 10:58 AM, Bernd Eckenfels <
> > e...@zusammenkunft.net>
> > >> wrote:
> > >>
> > >>> I like the idea (and prefer Commons Testing), for example a method to
> > >>> list all non-daemon threads after a test run (to see there is no
> > resource
> > >>> leak) can be used independent of the Unit Test Framework.
> > >>>
> > >>
> > > Do you have such a gadget?
> > >
> > > Gary
> > >
> > >
> > >>
> > >>> Gruss
> > >>> Bernd
> > >>> --
> > >>> http://bernd.eckenfels.net
> > >>> 
> > >>> From: Hasan Diwan 
> > >>> Sent: Saturday, November 4, 2017 5:42:39 PM
> > >>> To: Commons Developers List
> > >>> Subject: Re: [PROPOSAL] Apache Commons JUnit
> > >>>
> > >>> How about "Apache Commons Testing"? -- H
> > >>>
> > >>> On 4 November 2017 at 09:10, Gary Gregory 
> > wrote:
> > >>>
> > >>> > On Sat, Nov 4, 2017 at 9:32 AM, Pascal Schumacher <
> > >>> > pascalschumac...@gmx.net>
> > >>> > wrote:
> > >>> >
> > >>> > > JUnit 5 is not backwards compatible (Package/Annotation-Names
> have
> > >>> > > changed, Rules were replaced by a new extension model), but it
> can
> > run
> > >>> > > JUnit 3 and JUnit 4 Tests if you add an additional dependency.
> See
> > >>> > > http://junit.org/junit5/docs/current/user-guide/#migrating-f
> > >>> rom-junit4
> > >>> > > for details.
> > >>> >
> > >>> >
> > >>> > OK, so "Apache Commons Extras for Junit 4"
> > >>> >
> > >>> > Gary
> > >>> >
> > >>> >
> > >>> > >
> > >>> > >
> > >>> > > Am 04.11.2017 um 15:53 schrieb Gary Gregory:
> > >>> > >
> > >>> > >> I am assuming that JUnit 5 will be backward compatible with
> JUnit
> > 4,
> > >>> I
> > >>> > >> might be wrong. I'd like to focus on a single dependency for now
> > >>> (JUnit)
> > >>> > >> and not do a multi-module project. If someone want to do the
> same
> > for
> > >>> > >> TestNG, then have at it. KISS and small for 1.0.
> > >>> > >>
> > >>> > >> Gary
> > >>> > >>
> > >>> > >> On Fri, Nov 3, 2017 at 10:41 PM, Bruno P. Kinoshita <
> > >>> > >> brunodepau...@yahoo.com.br.invalid> wrote:
> > >>> > >>
> > >>> > >> +1 for the idea and for looking at JUnit 5.x and maybe AssertJ.
> > >>> > >>> CheersBruno
> > >>> > >>>
> > >>> > >>>From: Matt Sicker 
> > >>> > >>>   To: Commons Developers List 
> > >>> > >>>   Sent: Saturday, 4 November 2017 1:44 PM
> > >>> > >>>   Subject: Re: [PROPOSAL] Apache Commons JUnit
> > >>> > >>>
> > >>> > >>> I certainly like the idea, especially if the docs are good
> about
> > >>> > pulling
> > >>> > >>> in
> > >>> > >>> other related dependencies to complement the whole thing.
> General
> > >>> > >>> resource
> > >>> > >>> management rules would be great, though, like the ones we have
> in
> > >>> > Log4j.
> > >>> > >>>
> > >>> > >>> Also, I haven't looked closely at it yet, but supporting JUnit
> > 5.x
> > >>> as
> > >>> > >>> well
> > >>> > >>> would be nice.
> > >>> > >>>
> > >>> > >>> On 3 November 2017 at 18:11, Gary Gregory <
> > garydgreg...@gmail.com>
> > >>> > >>> wrote:
> > >>> > >>>
> > >>> > >>> Hi All,
> > >>> > 
> > >>> >  I'd propose we start a new component called "Apache Commons
> > JUnit".
> > >>> > 
> > >>> >  The goal would be to gather useful and reusable code like
> JUnit
> > >>> rules.
> > >>> > 
> > >>> >  This component would be focused on JUnit 4.x only.
> > >>> > 
> > >>> >  For example: org.apache.commons.collections4.junit.
> > >>> >  SetDefaultLocaleTestRule
> > >>> > 
> > >>> >  I have other rul

Re: Commons VFS support for Amazon S3?

2011-12-23 Thread Mark Fortner
Looks like there is an S3 plugin already.  I'm not sure what version of VFS
it works with, but it might do the trick.

https://github.com/abashev/vfs-s3

Hope this helps,

Mark




On Fri, Dec 23, 2011 at 4:03 PM, Liviu Tudor  wrote:

> D'oh, good point about unit testing, Gary! Hasn't crossed my mind what a
> problem this could be h food for thought I suppose…
> I'll go and talk to my team after the holiday season see if I can pull
> some resources towards this.
> Thanks for the heads-up!
>
>
> Liv
>
> Liviu Tudor
>
> E: liviu.tu...@gmail.com
> M: +44 (0)7917696626
> W: http://about.me/liviutudor
> Skype: liviutudor
>
> I'm nobody, nobody's perfect -- therefore I'm perfect!
>
>
>
>
>
>
>
> On 23/12/2011 23:49, "Gary Gregory"  wrote:
>
> >The whole commons community is responsible for VFS but some developers
> >are more focused on a subset of commons. There are no plans that I
> >know of for S3. You are welcome to contribute a patch with a JIRA. The
> >tricky part is unit testing. Usually tests runs with every build but
> >in this case I am not sure how you can do this without mocking.
> >
> >Gary
> >
> >On Dec 23, 2011, at 18:38, Liviu Tudor  wrote:
> >
> >> Hi everyone,
> >>
> >>
> >> One of the projects I am to work on in the new year requires amongst
> >>other
> >> things storage of certain files in the Amazon S3. VFS sprang to mind as
> >>I
> >> knew from browsing the Commons repository that it provides an
> >>abstraction
> >> layer for dealing with file system ‹ however, it appears there is no S3
> >> support in VFS. Are there plans to include this in a future release? If
> >>so,
> >> is there an estimated release date? And also who are the developers
> >> responsible for this? I'm only asking because I'm thinking/hoping that I
> >> might be able to convince my company to put some effort perhaps into
> >> building S3 support into VFS ‹ and as such would be good to be in direct
> >> contact with the lead developers on this if I manage to pull this off.
> >> (Don't take this as a promise though, it's more of a dream I suppose at
> >>this
> >> stage :) But you don't find out till you try it so fingers crossed!)
> >>
> >>
> >>
> >>
> >> Liv
> >>
> >>
> >> Liviu Tudor
> >>
> >> E: liviu.tu...@gmail.com 
> >> M: +44 (0)7917696626
> >> W: http://about.me/liviutudor 
> >> Skype: liviutudor
> >>
> >> I'm nobody, nobody's perfect -- therefore I'm perfect!
> >>
> >>
> >>
> >>
> >>
> >
> >-
> >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] Feedback on VFS-422 please

2012-06-21 Thread Mark Fortner
Gary,
There was some talk a while back about implementing File System-specific
Operations.  I think what Mario had in mind was supporting version control
system functionality through VFS.  It strikes me that this might be the
best way for implementing functionality that makes use of the JSch bells
and whistles without breaking encapsulation.

Regards,

Mark


On Thu, Jun 21, 2012 at 2:00 PM, Gary Gregory wrote:

> Hi All:
>
> WRT VFS-422: [SFTP] Allows to create other channels in SftpFileSystem (
> https://issues.apache.org/jira/browse/VFS-422)
>
> I'll like to solicit feedback from the list on this issue. I've cleaned up
> the proposed patch in the ticket and attached it back to the issue as
>
> https://issues.apache.org/jira/secure/attachment/12532940/vfs-422-v2-by-gg.diff
>
> First and foremost is whether this feature should be in VFS at all.
>
> Internally, VFS does not use the feature, so it is a convenience to the
> client application.
>
> A simpler solution from VFS' POV would be to make the Jsch Session object
> accessible via a public getSession() method. The client would then be
> responsible for the resources created and be free to use all of the Jsch
> bells and whistles.
>
> One can argue that this breaks encapsulation and surfaces VFS' private
> parts (pun intended). But because the point of the feature is get to
> another Jsch object (a Channel) through a Session, encapsulation would be
> broken anyway, so this point is moot IMO.
>
> A second issue has to do with implementation of the method
> com.jcraft.jsch.CommonsVFSChannelFactory.createChannel(AtomicLong,
> SftpChannelType)
>
> - Should finalization be used?
> - Should the counts be managed through the connect and disconnect methods
> instead?
> - There is a lot of repeated code in the method, should a delegate/proxy to
> a channel be used instead such that there is no code duplication?
>
> Thank you,
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>


Re: [VFS] Feedback on VFS-422 please

2012-06-22 Thread Mark Fortner
Gary,
The S3 provider has an implementation
https://github.com/abashev/vfs-s3/tree/master/src/main/java/com/intridea/io/vfs/provider/s3/operations

You'd probably need to talk with Mario about specifics.  From what I can
tell, it's basically an implementation of the Command pattern with the
implementations registered in the concrete implementation
FileOperationsProvider interface.  This basically let's you ask "what
operations are available from this file system", you can then select and
invoke the operation that you want.

The original idea was that you would be able to use it with SVN, or other
version control systems, but also with Sanselan (
http://wiki.apache.org/commons/VfsNext).  But the SVN implementation seems
to be blocked now due to licensing issues:
https://issues.apache.org/jira/browse/VFS-43.  I don't know of any other
implementations (other than S3) attempting to use it, but I would imagine
that it would be pretty useful.

Mark



On Thu, Jun 21, 2012 at 5:59 PM, Gary Gregory wrote:

> On Thu, Jun 21, 2012 at 6:38 PM, Ralph Goers  >wrote:
>
> >
> >
> > On Jun 21, 2012, at 2:41 PM, Gary Gregory wrote:
> >
> > > On Thu, Jun 21, 2012 at 5:10 PM, Mark Fortner 
> > wrote:
> > >
> > >> Gary,
> > >> There was some talk a while back about implementing File
> System-specific
> > >> Operations.  I think what Mario had in mind was supporting version
> > control
> > >> system functionality through VFS.  It strikes me that this might be
> the
> > >> best way for implementing functionality that makes use of the JSch
> bells
> > >> and whistles without breaking encapsulation.
> > >>
> > >
> > > Hi Mark,
> > >
> > > I am not sure I understand what you are proposing.
> > >
> >
> > Look at the org.apache.commons.vfs2.operations package.
> >
>
> hm... ok, I do not see any implementers of this package. Where is there an
> example? I assume that this can be used to implement this new feature. What
> would that look like?
>
> Thank you,
> Gary
>
>
> >
> > Ralph
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>


Re: [VFS] Feedback on VFS-422 please

2012-06-22 Thread Mark Fortner
I think the idea was to implement functionality that doesn't fit with what
File Systems do, in this version control system operations.  So that
operations like update, commit, revert, etc could be supported.  I too,
implemented something on top of SVNKit (for an internal project), and
another project on top of YANNFS -- I wonder how many implementations are
floating around there just due to licensing restrictions?

Mark



On Fri, Jun 22, 2012 at 10:06 AM, Ralph Goers wrote:

> I'm not sure why SVN support would require the operations stuff. I
> actually implemented an SVN provider at one point but didn't commit it here
> due to the svnkit license.
>
> Ralph
>
> On Jun 22, 2012, at 7:49 AM, Mark Fortner wrote:
>
> > Gary,
> > The S3 provider has an implementation
> >
> https://github.com/abashev/vfs-s3/tree/master/src/main/java/com/intridea/io/vfs/provider/s3/operations
> >
> > You'd probably need to talk with Mario about specifics.  From what I can
> > tell, it's basically an implementation of the Command pattern with the
> > implementations registered in the concrete implementation
> > FileOperationsProvider interface.  This basically let's you ask "what
> > operations are available from this file system", you can then select and
> > invoke the operation that you want.
> >
> > The original idea was that you would be able to use it with SVN, or other
> > version control systems, but also with Sanselan (
> > http://wiki.apache.org/commons/VfsNext).  But the SVN implementation
> seems
> > to be blocked now due to licensing issues:
> > https://issues.apache.org/jira/browse/VFS-43.  I don't know of any other
> > implementations (other than S3) attempting to use it, but I would imagine
> > that it would be pretty useful.
> >
> > Mark
> >
> >
> >
> > On Thu, Jun 21, 2012 at 5:59 PM, Gary Gregory  >wrote:
> >
> >> On Thu, Jun 21, 2012 at 6:38 PM, Ralph Goers <
> ralph.go...@dslextreme.com
> >>> wrote:
> >>
> >>>
> >>>
> >>> On Jun 21, 2012, at 2:41 PM, Gary Gregory wrote:
> >>>
> >>>> On Thu, Jun 21, 2012 at 5:10 PM, Mark Fortner 
> >>> wrote:
> >>>>
> >>>>> Gary,
> >>>>> There was some talk a while back about implementing File
> >> System-specific
> >>>>> Operations.  I think what Mario had in mind was supporting version
> >>> control
> >>>>> system functionality through VFS.  It strikes me that this might be
> >> the
> >>>>> best way for implementing functionality that makes use of the JSch
> >> bells
> >>>>> and whistles without breaking encapsulation.
> >>>>>
> >>>>
> >>>> Hi Mark,
> >>>>
> >>>> I am not sure I understand what you are proposing.
> >>>>
> >>>
> >>> Look at the org.apache.commons.vfs2.operations package.
> >>>
> >>
> >> hm... ok, I do not see any implementers of this package. Where is there
> an
> >> example? I assume that this can be used to implement this new feature.
> What
> >> would that look like?
> >>
> >> Thank you,
> >> Gary
> >>
> >>
> >>>
> >>> Ralph
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> >> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> >> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> >> 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
>
>


Re: Promote vfs-cift out of sandbox?

2012-07-18 Thread Mark Fortner
These questions about license compatibility bring to mind the difficulty
that most developers have with frameworks like VFS which have multiple
plugin implementations.   Because of license incompabilities, the plugins
are often not part of the main VFS distribution.  This means, that you may
consider VFS potentially useful, only to find out that the file system you
need is not supported -- or at least it appears that way. Currently, we
list implementations in the wiki page, but that's not always kept up to
date, and people don't always check there.

Would it be possible for SPI implementers to register their implementations
in mvnrepository?  We would at least have a way of finding them at that
point -- and increase the chance that VFS would be used, and that their
implementation would be used.  It would then be up to the user to figure
out if the license for a particular implementation worked for his project.
There may also be a way to query for all plugins compatible with a
particular version of the VFS API.

Mark




On Wed, Jul 18, 2012 at 6:36 AM, sebb  wrote:

> On 18 July 2012 13:28, Gary Gregory  wrote:
> > On Wed, Jul 18, 2012 at 7:53 AM, sebb  wrote:
> >
> >> On 18 July 2012 12:49, Gary Gregory  wrote:
> >> > Ideally:
> >> >
> >> > - Implement the test case such that it starts and stops an embedded
> Samba
> >> > server, like other tests do (see HTTP, FTP, and so on.) This will
> require
> >> > using someone's Smb server.
> >> >
> >> > Once that is in place:
> >> >
> >> > - Migrate to the current version of JCIFS.
> >>
> >> JCIFS is LGPL, so is that permissible?
> >>
> >
> >
> > It's not OK to distribute but OK to depend on?
> >
> > "The LGPL v2.1 is ineligible from being a Category B
> > license(a category
> > that includes the MPL, CPL, EPL, and CDDL) primarily due to the
> > restrictions it places on larger works, violating the third license
> > criterion .
> Therefore,
> > LGPL v2.1-licensed works must not be included in Apache products,
> although
> > they may be listed as system
> > requirements<
> http://www.apache.org/legal/3party.html#options-systemrequirements>or
> > distributed elsewhere as optional
> > works ." from
> > www.apache.org/legal/3party.html
> >
> > Can the above be read as follows for VFS and JCIFS: you cannot copy the
> > JCIFS jar into VFS (which we do not) but the VFS POM can point to it
> (which
> > we do).
>
> The above document is only proposed, not actual policy.
>
> The following is the resolved list of questions:
>
> http://www.apache.org/legal/resolved.html
>
> In particular:
>
> http://www.apache.org/legal/resolved.html#optional
>
> "Will the majority of users want to use my product without adding the
> optional components?
>
>
> > ?
> >
> > Gary
> >
> >
> >> > Then:
> >> >
> >> > - Fill in holes in tests (if any)
> >> > - Fill in holes in features (if any as your needs dictate)
> >> >
> >> > Gary
> >> >
> >> > On Tue, Jul 17, 2012 at 11:12 PM, Dan Tran  wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> I have a forked a copy of vfs-cift to codehaus [1] to test it out.
>  It
> >> >> works so far for me.
> >> >>
> >> >> What would it take to promote the current VFS's CIFT out of sandbox
> to
> >> >> be released with VFS-2.x?
> >> >>
> >> >> Thanks
> >> >>
> >> >> -Dan
> >> >>
> >> >> [1] https://svn.codehaus.org/mojo/trunk/sandbox/vfs/vfs-smb/
> >> >>
> >> >> -
> >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> >> > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> >> > Spring Batch in Action: http://bit.ly/bqpbCK
> >> > 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
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> > Spring Batch in Action: http://bit.ly/bqpbCK
> > 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
>
>


Re: [VFS] Softening the exceptions...

2010-10-25 Thread Mark Fortner
-1

At the risk of playing Devils Advocate here, what's the downside to checked
exceptions? A few extra lines of code?  I can foresee a problem with
unchecked exceptions though.  Imagine that you're using the API to build a
desktop application.  You want to display a dialog box to the user
indicating that some problem has occurred.  With an unchecked exception, the
stack trace and exception message may appear in a log file or in the
console, but the user would in all likelihood never see it.

Moreover if a developer is unfamiliar with the API, with a checked
exception, they would be able to make an informed decision about how to
handle the exception. The developer can easily trap the exception, and
display a semi-informative dialog indicating that something has gone wrong.
 Although the user may not be able to fix it, they would still know that a
problem occurred, and would hopefully be able to file a bug report to that
effect. If you don't want the user informed, you can always swallow the
exception. But at least, as a developer, you have a choice about how to deal
with it, and it's not something that just pops up out of no where and
surprises both user and developer.

Mark

card.ly: 


On Mon, Oct 25, 2010 at 9:01 AM, James Carman wrote:

> On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers
>  wrote:
> > I'm not in favor of changing much at this point. I'd really like to get a
> release done without too many more changes.
> >
>
> There's a problem with that, Ralph.  If we publish a 2.0, we can't
> "break" the API later.  So, we'd have to go to 3.0 if we wanted to
> break anything.  So, we need to figure out if this is the way we want
> to go and do it.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


Re: [ANNOUNCE] Commons VFS 2.0 Released

2011-08-24 Thread Mark Fortner
Thanks for all the hard work guys.  I'm really looking forward to using VFS2
in a couple of the projects that I'm working on.

Regards,

Mark Fortner


On Wed, Aug 24, 2011 at 4:53 AM, Gary Gregory wrote:

> The 1.1-SNAPSHOT site is still up. 2.0 coming soon!
>
> Gary
>
> On Wed, Aug 24, 2011 at 7:08 AM, Ralph Goers  >wrote:
>
> > The Apache Commons team is pleased to announce the release of Commons VFS
> > 2.0
> >
> > 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
> >
> > Ralph
> > on behalf of the Apache Commons community
> >
> >
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>


Re: [CSV] Headers and the first record

2013-07-31 Thread Mark Fortner
I took a brief look at the API for CSV, and thought I would share a typical
use case from the biotech industry.  We deal with a lot of instruments that
produce a multiline header.  The header usually contains "experiment
conditions".  You can think of this as metadata for the columnar data.  The
experiment conditions usually contain things like the name of the scientist
using the instrument, the time of day the experiment was run, and some
instrument configuration settings.  Usually when we parse CSV files, we
have to parse the header first, extract all relevant data, and then parse
the rows of data.

In addition to the experiment conditions header, there are also column
headers.  The column headers can be multi-lined as well.  For example, you
might have a column header whose first line contains chemical compound IDs
or names, and the second line of the column header contains the
concentrations for those compounds. The data values represent the percent
inhibition at those concentrations. Like this:

Erlotinib
1uM 10 uM 100 uM 1nM
0.01  0.001  0.0001 0.1
...

Since the position and types of header and body data vary, we typically use
 parse configuration files that describe "what data can be found where".
 The parse configuration varies not only per instrument but also per
experimental protocol. So there are usually numerous configuration files in
your typical lab.  The configuration files can also be stored in a
database.  This is usually part of a file-watching web app.  It allows
scientists to add support for new experiments or instruments without having
to get a developer to write more code.

In the API I saw support for hard-coded configurations via the CSVFormat
object, but I didn't see any support for creating and using persistable
configurations.  You may want to consider that as you move forward.

Hope this helps,

Mark



On Wed, Jul 31, 2013 at 6:36 AM, Gary Gregory wrote:

> On Wed, Jul 31, 2013 at 8:58 AM, Gary Gregory  >wrote:
>
> > On Jul 31, 2013, at 3:38, Benedikt Ritter  wrote:
> >
> > > 2013/7/31 Gary Gregory 
> > >
> > >> On Tue, Jul 30, 2013 at 5:29 PM, Emmanuel Bourg 
> > wrote:
> > >>
> > >>> Le 30/07/2013 23:26, Gary Gregory a écrit :
> >  And another thing: internally, the header should be a Set,
> not
> > >> a
> >  String[]. I plan on fixing that later too.
> > >>>
> > >>> Why should it be a set? Is there an impact on the performance?
> > >>
> > >> Well, I did not finish my though on that one, sorry about that, please
> > >> allow me to walk through my use cases. The issue is about the feature,
> > not
> > >> performance.
> > >>
> > >> At first glance, using a set avoids an inherent problem with any
> non-set
> > >> data structure: defining duplicates. What does the following mean?
> > >>
> > >> withHeader("A", "B", "C", "A");
> > >>
> > >> It's is a recipe for garbage results: record.get("A") returns what?
> > >>
> > >> Today, I added some CSVFormat validation code that checks for
> duplicate
> > >> column names. If you build a format with withHeader("A", "B", "C",
> "A");
> > >> you will get an ISE when validate() is called.
> > >>
> > >> If we had withHeader(Set) and document it as the 'main' way to specify
> > >> column names, then we can say that withHeader(String...) is just a
> > >> syntactical convenience and turn the String[] into a Set. But that
> will
> > not
> > >> work.
> > >>
> > >> The problem with a Java Set is that it is not ordered and the current
> > >> implementation relies on order of the String[]. But why? What the
> > current
> > >> implementation says is: ignore what the header line of the file is and
> > use
> > >> the given column names at the given positions. A perfectly good user
> > story.
> > >> So for withHeader("A", "B", "C"), "A" is column 0, "B" is column 1,
> and
> > so
> > >> on. Ok, that's one usage.
> > >>
> > >> Taking a step back, I want to talk about why should the column name
> > order
> > >> matter when you are calling withHeader(). I would like to be able to
> > tell
> > >> the parser that I want to use a Set of column names and have it figure
> > out,
> > >> based on the header line, the columns indices. This is quite different
> > than
> > >> what we have now.
> > >>
> > >> A use case I have now is a CSV file with a lot of columns (~90) but I
> > only
> > >> care about a small subset of the columns (~10). I'd like to be able to
> > say
> > >> withHeader(Set) where the Set may be a subset of the actual column
> > names in
> > >> the header line. This is different from withHeader(String[]) because
> the
> > >> names in the Set must match the names in the header record.
> > >
> > > I'm not sure if we should try to build in all this different cases
> > > (guessing headers, using the first record as headers, only use a subset
> > of
> > > the available headers) into one implementation.
> > >
> > > What you are talking about sounds more like a view or a projection of
> the
> > > actual content being parsed.
> > > Do we really nee

Re: [CSV] Headers and the first record

2013-07-31 Thread Mark Fortner
Hi Gary,
One other complication I forgot to mention.  Compounds are usually run
multiple times.  So the same compound will appear with the same set of
concentrations.  In practice you would end up with column headers that have
the same text in them, so this issue with using a Set vs String[] for the
column names would complicate things.


> CSVFormat implements Serializable, so you can use plain old Java
> serialization, it's not human readable, but it's something.
>

A human readable configuration would probably be a high priority.


>
> If we moved to Java 6, we could annotate CSVFormat with JAXB so you can
> have XML IO. Personally, I do not think we should do our own XML IO, so
> JAXB is the best path IMO since it is built-in Java 6.
>

It would be best if there were a CSVFormat serializer so that the CSVFormat
could be injected.  Using JAXB would be fine as a default implementation,
but I imagine that the configuration format would change.  Or that a user
might decide to store individual configuration items in a database.


>
> What do you currently use to parse your CSV files?
>

Most biotech companies have their own home grown tools for parsing
instrument files.  There isn't a standard library.


>
> Would Commons-CSV work for you as well? If not, how so?
>

As I understand it, the code doesn't support "experiment condition"-type
parameters, like this:

Date: 12/10/13
Protocol: Selectivity Profile 1Instrument Name: Gandalf
Scientist: John Smith


> Would you be willing to experiment with the current code?
>
>
Sure. If the previous issues were addressed.

I'm curious if other industries have similar issues?  I assume that anyone
that deals with instrument data might have similar needs.

Mark


Re: [CSV] Headers and the first record

2013-07-31 Thread Mark Fortner
Hi Gary,


> This does not look like a classic CSV file.


I guess it depends on what your definition of "classic" is. :-)  This is
pretty typical for most drug discovery companies.


> It sounds like your files contain different sections in different formats.
>

True.


>
> In its current state, commons-csv might not be right for you. What does the
> rest of the file look like?


The data section looks similar to this.

  Erlotinib - Run 1  Erlotinib - Run 2
Target   1uM 10 uM 100 uM 1nM 1uM 10 uM 100 uM 1nM
BRCA1   0.01  0.001  0.0001 0.1   0.01  0.001  0.0001 0.1
BRCA2   0.20.002  0.0002 0.2   0.20.002  0.0002 0.2


Regards,

Mark


[VFS] Code Review Tool?

2013-08-08 Thread Mark Fortner
Recently Bernd posted a code review of a few of the RAM provider classes.
That kind of feedback is very useful, and it made me wonder if there was a
standard way within commons to do code reviews?  I know that apache makes a
lot of use of Atlassian software, and I've used their Crucible code review
tool before.  Is Crucible available for use?  Or is there some other
approach that should be used?

Cheers,

Mark


Re: [VFS] Code Review Tool?

2013-08-08 Thread Mark Fortner
Bernd,
That looks interesting, but I don't see any way to publish the review.  The
nice thing about Crucible is that it's web-based and integrated with JIRA.

Cheers,

Mark



On Thu, Aug 8, 2013 at 11:31 AM, Bernd Eckenfels wrote:

> Am 08.08.2013, 20:03 Uhr, schrieb Mark Fortner :
>
>
>  Recently Bernd posted a code review of a few of the RAM provider classes.
>> That kind of feedback is very useful, and it made me wonder if there was a
>> standard way within commons to do code reviews?  I know that apache makes
>> a
>> lot of use of Atlassian software, and I've used their Crucible code review
>> tool before.  Is Crucible available for use?  Or is there some other
>> approach that should be used?
>>
>
> I cant speak for Apache Commons, but if you want me to use a tool in the
> future, I could use Jupiter(Eclipse) it kind of works without the need for
> any server project infrastructure.
>
> http://code.google.com/p/**jupiter-eclipse-plugin/wiki/**UserGuide<http://code.google.com/p/jupiter-eclipse-plugin/wiki/UserGuide>
>
> Greetings
> Bernd
> --
> http://www.zusammenkunft.net
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@commons.**apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


Re: [VFS] developer ping - future direction

2013-10-09 Thread Mark Fortner
Hi Bernd,
I'm a user rather than a developer of VFS.  I have a weekend project to
create a file browser in JavaFX. Prior to that I wrote an NFS provider for
a company I was working for.

Concurrency/thread safety should definitely be a priority.  Part of my
weekend project uses a threadpool to handle a variety of different types of
file operations.

If there was an adapter that could adapt VFS2 calls to NIO2 calls that
would be nice.  But I think that rewriting all of the current providers to
make them NIO2 providers would be a bit of a stretch.

In your previous posting about VFS-490 you mentioned not wanting to browse
JAR files as though they were directories.  It would be nice if that was
configurable -- I actually use that functionality and find it pretty useful.

Metadata support would also be useful:
http://apache-commons.680414.n4.nabble.com/vfs-File-Metadata-td739249.html

Plugin download support would also be useful.  One of the current problems
that most users face is that the available file systems aren't downloadable
from a single point.  So if you encounter a URL that requires a different
provider, you have to hunt around for the provider and manually install it.
 It would be useful VFS could simply check a registry of providers, and
download the appropriate provider.  It would keep the core download fairly
small and make it easy for 3rd party providers to be used.

The biggest challenge for most 3rd party developers is finding a way to do
automated testing without installing a file system to test with.  It would
be interesting to find out how the NIO2 file system developers are testing
their providers.

Anyway, his is all probably more than you were asking for, but I hope this
helps.

Cheers,

Mark



On Wed, Oct 9, 2013 at 10:38 AM, Bernd Eckenfels wrote:

> Dear [VFS] Developer and Contributors,
>
> Please excuse the spam (bcc to all emails mentioned as developers (8) or
> contributors (6) in the project pom).
>
> The project is currently a bit in sleeping state. I raised a few concerns
> and questions on the commons-dev mailinglist and wanted to direct your
> attention to the list - it would also help me to provide more patches when
> I know how you would prefer to solve things I raised.
>
> Could you maybe get ack to the list and let us know if you have any
> current plans/needs with/for VFS2 and if you had looked at the recent VFS
> discussions on the commons developer list.
>
> Currently I am mostly concerend with concurrency and atomic transactions,
> but also some unclear API meanings, dirty (commented out) code and the unit
> test "suite" system is somewhat confusing to use if you want to write
> providers outside of the main archive (with a -tests.jar dependency only).
>
> I have two new providers, one which allows to project VFS on Blobs in a
> JDBC table and one which simulates a virtual filesystem on top of git-style
> trees. 
> (https://github.com/ecki/**seeburger-vfs2).
> For the former I need to implement some atomicity and concurrency (for the
> content). And for the later some questions around injecting the datasource
> and having additional fs operations come to mind.
>
> Besides that it might be time to think about 
> java.nio.file.spi.**FileSystemProvider
> as well.
>
> If you feel fluent in one of the points mentioned let me know. (if too
> much discussion is coming out of that we can conser moving to an google
> group for those, but for now it is just a dream that that could happen :)
>
> What would be the quickest way for me to get acccess to the VFS wiki?
>
> Greetings
> Bernd
> --
> http://www.zusammenkunft.net
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@commons.**apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


Re: [VFS] developer ping - future direction

2013-10-09 Thread Mark Fortner
On Wed, Oct 9, 2013 at 2:05 PM, Bernd Eckenfels wrote:

> Am 09.10.2013, 21:53 Uhr, schrieb Mark Fortner :
>
>
>  Hi Bernd,
>> I'm a user rather than a developer of VFS.  I have a weekend project to
>> create a file browser in JavaFX. Prior to that I wrote an NFS provider for
>> a company I was working for.
>>
>
> Thats nice, is it available somewhere?


It was proprietary code for the company I worked for at the time.  I don't
have access to the code any longer, but it was based on Sun/Oracle's YANFS
implementation and wasn't that difficult to write.   YANFS uses BSD now (it
used to be CDDL).  I'm not sure if the licenses are compatible.

Part of the reason that I'd like to have some way of resolving 3rd party
providers, is that the user would be able to get the provider, regardless
of the flavor of open source license used.

Cheers,

Mark


Re: [VFS] developer ping - future direction

2013-10-09 Thread Mark Fortner
Hi Jörg,
Thanks for the link, but I don't think that quite addresses the issue.

What I'd like to see is the ability to automatically install a VFS provider
that isn't already on your local machine.  For example, if I wanted to see
a directory listing of "sftp://someserver/somedir"; and I don't already have
the SFTP provider installed, VFS would download and install it for me.
 This is similar to the way in which Groovy's @Grab annotation
automatically installs dependencies when you attempt to run a script whose
dependencies you don't have.

Cheers,

Mark



On Wed, Oct 9, 2013 at 4:50 PM, Jörg Schaible  wrote:

> Mark Fortner wrote:
>
> [snip]
>
> > It was proprietary code for the company I worked for at the time.  I
> don't
> > have access to the code any longer, but it was based on Sun/Oracle's
> YANFS
> > implementation and wasn't that difficult to write.   YANFS uses BSD now
> > (it
> > used to be CDDL).  I'm not sure if the licenses are compatible.
> >
> > Part of the reason that I'd like to have some way of resolving 3rd party
> > providers, is that the user would be able to get the provider, regardless
> > of the flavor of open source license used.
>
> This has always been possible:
> http://commons.apache.org/proper/commons-vfs/api.html#Configuring_Commons_VFS
>
> - Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


Re: [compress] Strong Crypto in Tests

2013-10-23 Thread Mark Fortner
As you're probably aware, aes is export restricted. So it might be better
to simply check for the availability of a particular encryption algorithm
before running a test and avoid making restricted libraries generally
available.

Mark
On Oct 23, 2013 6:10 AM, "Stefan Bodewig"  wrote:

> On 2013-10-23, Bear Giles wrote:
>
> > Should that be PKCS7Padding? Or would that be worse - I don't recall
> > if it's one of the "must have" paddings in the spec.
>
> 7z uses "AES/CBC/NoPadding" and that's what I use during the check
> inside the unit tests as well now.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


Re: [SCXML]Eclipse plunge-in based visual editor,debugger and code generation tool for SCXML

2010-04-01 Thread Mark Fortner
Just out of curiosity, wouldn't it be easier to simply create a SCXML
serializer plug-in for the EMF, since EMF already supports state diagrams
(in addition to all the other diagram types)?  It might save you some time
and effort.

Hope this helps,

Mark


On Wed, Mar 31, 2010 at 10:39 PM, xunlong gui  wrote:

> Hi guys,
> I have finish my Project Proposal, you can find it here
> http://wiki.apache.org/commons/guixl, any one who is interested in
> mentoring
> me,please let me know ,thank you very much :-)
>
> 2010/3/31 xunlong gui 
>
> >   Hi all,
> >
> > I have been using Apache Commons SCXML Engine for more than two years,Now
> i
> > have an idea to improve it, and I wanted to post it and see if there
> would
> > be any interest in it in the Apache SCXML community. If possible, i want
> to
> > hold it as a GSoC(url:http://socghop.appspot.com/<
> http://socghop.appspot.com/>)
> > open source project.
> > The basic idea of the project is to create a Eclipse based visual editor
> > and debugger for SCXML which can also generate SCXML statechart to Java
> > code.
> >
> > State Chart XML (SCXML) is currently a Working Draft published by the
> World
> > Wide Web Consortium (W3C). SCXML provides a generic state-machine based
> > execution environment based on Harel State Tables. SCXML is a candidate
> for
> > the control language within multiple markup languages coming out of the
> > W3C.It is very useful to handler complex status transfer logic,but if a
> > SCXML file is really so huge and complex,it will become too difficult to
> > maintain and refactor or to test its logic validity.
> >
> > This project is to develop a Eclipse plunge-in visual editor which is
> > capable of showing a graphical representation of the process model and
> > allows for adding breakpoints to activities, variable modifications and
> > managing the debugging process for SCXML.I have already done some work on
> > both SCXML and Eclipse GMF,even i tried to implement a SCXML editor using
> > GMF and got a little achievement,so i want to develop this editor with
> GMF
> > and have enough confidence to finish it.
> > Usually,State Chart XML file will be running on a SCXML engine(for
> example,
> > our Apache Commons SCXML),if some one only want to achieve the SCXML
> file's
> > business logic,but do not want to or can not use some SCXML engine due to
> > licence problem etc,this tool can export SCXML file's logic to
> executeable
> > Java code which has the same state logic translation with the SCXML file.
> >
> > This is my mainly idea,if anyone has any questions or comments, or would
> be
> > interested in mentoring this project, please let me know. Thanks.
> >
> > Gui
> >
> >
>


[VFS] NIO Version Questions

2016-06-01 Thread Mark Fortner
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.


Cheers,

Mark


Re: [VFS] NIO Version Questions

2016-06-01 Thread Mark Fortner
Hi Benson,
While I don't have a strong preference in terms of the approach, my gut
feel is that the adapter approach would force people through additional
layers of VFS code.

Cheers,

Mark


On Wed, Jun 1, 2016 at 4:28 PM, 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.
>
>


Re: [VFS] NIO Version Questions

2016-06-01 Thread Mark Fortner
During the push for the last release, it seemed like some of the API
changes were breaking backward compatibility with some of the
implementations. If each implementation resides in its own repo, this would
probably be a recurrent problem, especially if the API is changing
rapidly. Has anyone given any thought to how we would be able to quickly
determine if a change breaks existing implementations?

Also, is there a subset of the Java TCK that could be used to determine
whether we're implementing the APIs consistently?

Cheers,

Mark


On Wed, Jun 1, 2016 at 5:18 PM, Schalk Cronjé  wrote:

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

2016-06-01 Thread Mark Fortner
Hi Peter,
Implementing a new file system just to support "home" or "Photos" virtual
roots, would be a rather heavyweight approach for something that should be
configurable. Each operating system (and OS version) could have different
mappings for these roots.

Cheers,

Mark


On Wed, Jun 1, 2016 at 4: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
>
>


Re: [general] How to link JIRA issues and commits

2009-02-03 Thread Mark Fortner
Hi Stefan,
I'm not a committer to the project, but I've worked on other projects with
svn and JIRA.  If you use the Eclipse, there's a plugin called Mylyn that
you can use that makes this process a little easier.  As you work on an
issue, Mylyn keeps track of the files that you worked on (called a context
or change set).  To commit all changes for a particular issue, you simply
open the issue in Eclipse, and commit the files that you see listed under
the Context tab.  You can also attach the context to the issue, this makes
it easier if the issue is reopened in the future, since Mylyn automatically
reopens all files that are in the attached context -- so somebody can pickup
where you left off.  You can see a demo of this here:

http://www.redmonk.com/cote/2007/12/11/the-jira-connector-for-mylyn-demo/

Hope this helps,

Mark



On Tue, Feb 3, 2009 at 9:14 PM, Stefan Bodewig  wrote:

> Hi all,
>
> since I'm sort of a new commons committer (technically I've always
> been, I've just not used it much) I'm unsure whether there is a policy
> of how you connect svn commits and JIRA issues around here.
>
> So far I've named the JIRA issue in the commit message and noted the
> svn revision inside a comment to the JIRA issue.  Is there anything
> else I should have done like adding an explicit link to the svn
> revision in JIRA (bugzilla adds them automatically nowadays)?
>
> Thanks
>
>Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Mark Fortner

blog: http://feeds.feedburner.com/jroller/ideafactory


Re: [compress] Some merging in zip package

2009-02-10 Thread Mark Fortner
>
> > ZipArchiveOutputStream will now use the platform's native encoding
> > instead of UTF8 by default now, while JarArchiveOutputStream
> > explicitly sets the encoding to UTF8.  Does anybody consider this a
> > problem?
>
>
What happens if you try to take a file that was created on a machine with
one default encoding, and send it to another machine with a different
default encoding (i.e. Linux  -> Windows)?

Regards,

Mark Fortner


Re: [compress] Some merging in zip package

2009-02-10 Thread Mark Fortner
I meant specifically if I was using this library at both ends of the
equation.  I assume that if you use different tools at either end, you may
have some challenges.  But if I use this library at both ends, and use the
default settings, then I imagine I would have some difficulty on the
decompression side.  I think Linux may default to the UTF-8 encoding, and
Windows to the ISO-8859-1 encoding.

Mark

On Tue, Feb 10, 2009 at 8:57 AM, Stefan Bodewig  wrote:

> On 2009-02-10, Mark Fortner  wrote:
>
>
> >>> ZipArchiveOutputStream will now use the platform's native encoding
> >>> instead of UTF8 by default now, while JarArchiveOutputStream
> >>> explicitly sets the encoding to UTF8.  Does anybody consider this a
> >>> problem?
>
> > What happens if you try to take a file that was created on a machine with
> > one default encoding, and send it to another machine with a different
> > default encoding (i.e. Linux  -> Windows)?
>
> It depends on what you use to extract the archive, I guess.  In a
> situation like this you are much better off specifiying the encoding
> explicitly.
>
> Most tools don't assume UTF-8 (the old default) at all, so you
> wouldn't be able to extract an archive created by the jar command (or
> the prevision version of ZipArchiveOutputStream) in a scenario like
> this either.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Mark Fortner

blog: http://feeds.feedburner.com/jroller/ideafactory


[math] GaussNewtonEstimator

2009-02-16 Thread Mark Fortner
I was wondering if someone could add a default no-args constructor to the
GaussNewtonEstimator?  I'm trying to add a simple SPI-based factory to my
code and the ServiceLoader fails because it can't find a no-args constructor
for the estimator.

Regards,

-- 
Mark Fortner

blog: http://feeds.feedburner.com/jroller/ideafactory


Re: [math] GaussNewtonEstimator

2009-02-16 Thread Mark Fortner
Thanks Luc.  I appreciate the heads up about the upcoming changes.  I'll
keep an eye out for the discussion on the mailing list.

Regards,

Mark

On Mon, Feb 16, 2009 at 1:49 PM, Luc Maisonobe wrote:

> Mark Fortner a écrit :
> > I was wondering if someone could add a default no-args constructor to the
> > GaussNewtonEstimator?  I'm trying to add a simple SPI-based factory to my
> > code and the ServiceLoader fails because it can't find a no-args
> constructor
> > for the estimator.
>
> I'll check it in when subversion repository will be available again.
>
> Beware that the estimation and optimization packages are going to be
> changed quite a lot soon, to address issues
> http://issues.apache.org/jira/browse/MATH-177,
> http://issues.apache.org/jira/browse/MATH-246 and perhaps
> http://issues.apache.org/jira/browse/MATH-196. I will probably start a
> discussion on these topics in the next few days on this list.
>
> regards,
> Luc
>
> >
> > Regards,
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Mark Fortner

blog: http://feeds.feedburner.com/jroller/ideafactory


Re: gauging sandbox interest - openmodels

2009-03-01 Thread Mark Fortner
Hi Matt,
I like the idea; however, it might make more sense to simply have domain
objects (and in the case of dbutils perhaps a small derby database) in each
project as necessary. This can be used to both improve the unit tests and
provide working examples of the code.

Mark

On Sun, Mar 1, 2009 at 9:15 AM, Matt Benson  wrote:

>
> For awhile I've had an itch that it would be nice to have a project whose
> purpose is to provide small, realistic domain models for consumption
> primarily by tests of library-type code (if the domain models are actually
> usable/extensible for real work, so much the better).  It seems to me that
> particularly at Commons it could be beneficial for tests/examples of various
> components to reference common object models, giving potential users a
> better point of reference to see how various components might be used with
> their own models.  Is there any interest in having such a project in
> Commons; do we feel this would be too large and not precisely the mission of
> Commons; are there other opinions?
>
> Thanks,
> Matt
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Mark Fortner

blog: http://feeds.feedburner.com/jroller/ideafactory


Re: [Laboratory Toolkit] proposing a new Apache Commons component

2013-12-07 Thread Mark Fortner
You might also be interested in apache uima which is a popular text mining
platform.

Mark
On Dec 7, 2013 1:49 AM, "Valentin Waeselynck" 
wrote:

> Thanks to all for your interest!
>
> The code examples are on their way, I'm trying to make them as diverse as
> possible. I'll let you know as soon as  they're ready.
>
>
> Thanks for telling me about tika, Oliver, it's very interesting! An
> algorithm that tries to extract the meaning of a variety of documents could
> typically be a combination of tika and the Laboratory Toolkit.
>
> However, the Laboratory Toolkit is less specialized (in fact, it's not
> specialized at all) and less concrete. It is similar in its genericity and
> in the nature of its benefits to, for example, the Executor API in
> java.concurrent. As the Executor API lets you think and design concurrent
> algorithms in terms of tasks and executors, the Laboratory Toolkit lets you
> think and design some other (I haven't found a satisfying description yet)
> algorithms in terms of analyses and laboratories.
>
> Bests,
>
>
> Valentin WAESELYNCK
> Étudiant en 3° année à l'École Polytechnique
> valentin.waesely...@polytechnique.edu
> +33 6 80 84 99
>  54
>
>
>
>
> Le Vendredi 6 décembre 2013 21h30, Oliver Heger <
> oliver.he...@oliver-heger.de> a écrit :
>
>
>
> Am 05.12.2013 13:44, schrieb Valentin Waeselynck:
> > Hello, and pleased to meet you,
> >
> > Thank you for your answer.
> >
> > I just asked for confirmation, and I do have full intellectual property
> on this software.
> >
> > About the use cases : no problem, I'll include some code samples. As a
> foreword, let's say it provides a convenient API for creating all sorts of
> custom "information extraction" algorithms.
> If the library is about information extraction, you may also want to
> have a look at the Apache Tika project [1].
>
> Oliver
>
> [1] http://tika.apache.org/
>
> >
> > As for the group of persons willing to maintain this : well, for the
> moment, there is me. As this is a quite small toolkit, I think it's
> sufficient, at least for a start.
> >
> > I'll start working towards the other requirements (maven + test
> coverage) right away and let you know as soon as it's ready.
> >
> >
> >
> > Should I keep answering to the whole ML about this, or only to you?
> >
> > Best regards,
> >
> >
> > Valentin WAESELYNCK
> > Étudiant en 3° année à l'École Polytechnique
> > valentin.waesely...@polytechnique.edu
> > +33 6 80 84 99 54
> >
> >
> >
> >
> > Le Jeudi 5 décembre 2013 8h53, Benedikt Ritter  a
> écrit :
> >
> > Bonjour Valentin,
> >
> >
>  welcome to the ML. Good to hear that you've decided to join the open
> source
> > movement.
> >
> > First of all, it would really help, if you could elaborate some use cases
> > for your library. You're talking about building algorithms. What kind of
> > algorithms can be build with Laboratory Toolkit? Can you give some code
> > examples (just create some gists at github that show the the use of
> > Laboratory Toolkit)?
> >
> > There is an important requirement for any code to be incorporated into
> the
> > Apache code base:
> > - the interlectual property (IP) of the code has to be owned completely
> by
> > the contributor. You said, that you've build the Laboratory Toolkit for a
> > research project. Are you sure that you own the code? Or
>  is it the result
> > of your work and thus is owned by your employer?
> >
> > At commons we have some additinal requirements:
> > - There should be a group of people who is willing to maintain the code
> > - Commons components should in general not depend on any other libraries
> > - Commons uses maven as the main build tool, so there should be a maven
> > build available
> > - The code should have a good test coverage
> >
> > You have to figure the IP issue out on your own first.
> > After that, if the community decides to accept this contribution, we can
> > work on the commons requirements.
> >
> > Best regards and thank you,
> > Benedikt
> >
> >
> >
> > 2013/12/4 Valentin Waeselynck 
> >
> >>   Hello to all,
> >>
> >> As part of a small research project (which combined techniques of
> >> text-mining, machine-learning and natural language generation, not that
> >> it's really relevant) I have come to design a small JavaSE library,
> which
> >> I'm for the moment calling the Laboratory Toolkit, for developing our
> >> algorithms in a comfortable and flexible manner.
> >>
> >> I have found it to be quite generic and reusable, not tied to any
> >> application domain, while still being rather accessible, and
>  small enough
> >> to comprehend it easily. Therefore, I would like to propose it as a new
> >> Apache Commons component. I would be very grateful if one of you could
> >> tell me what steps I should follow for that purpose.
> >>
> >> I have uploaded it on Github :
> >> https://github.com/alvalval/Laboratory-Toolkit.git. There you may
> >> find the sources, the javadoc, and a small guide I have started to write
> >> for it (also attached to th

Re: Apache Commons & ApacheCon Europe 2014 ... [VFS]

2014-04-17 Thread Mark Fortner
I'm in the process of creating a file browser-like tool in JavaFX, and my
original intent was to use VFS as the underlying file system abstraction.
 After looking at a lot of the features in Java 7 and 8 (like
DirectoryStreams, parallelStreams, and lambdas) I'm now having second
thoughts.  So I'd be really interested to learn what the "future directions
of VFS" will be.  Is the goal to create an adapter layer between the NIO
file system, and VFS, and perhaps gradually remove that layer and replace
it with direct adapters for each of the file systems?  Or is there some
commitment from the jCIFS, jackrabbit, and other teams to provide NIO
adapters directly? Is there a wiki page, or a thread I should look at? Is
there a time frame when this will happen? Unfortunately, I won't be able to
make it to ApacheCon.

Cheers,

Mark



On Thu, Apr 17, 2014 at 12:27 PM, Bernd Eckenfels wrote:

> Hello,
>
>
> Am Thu, 17 Apr 2014 08:02:36 -0600
> schrieb Siegfried Goeschl :
> > * Who would volunteer for presenting his/her Apache Commons component?
>
> As a new committer I would really join you crowd, so I am currently
> planning to visit the Europe Con and have some holiday (unfortunatelly
> its not the best time of the year to make holiday, but hey...).
>
> So my current planning is to attend, and I can also think about
> presenting something or leading a BOF, however I dont want to steal
> attention. I would be able to speak a bit in VFS, but there is not much
> news (and I dont know all the details).
>
> So maybe instead of a longish component presentation only a BOF "future
> directions VFS". For example discussion in the light of
> java.nio.file.spi...
>
> A similiar discussion BOF around Git usage?
>
> Gruss
> Bernd
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


Re: Apache Commons & ApacheCon Europe 2014 ... [VFS]

2014-04-17 Thread Mark Fortner
Schalk,
It's my understanding that new providers in NIO2 are simply added using the
ServiceLoader.

Cheers,

Mark



On Thu, Apr 17, 2014 at 3:31 PM, Schalk Cronj é  wrote:

> On 17/04/2014 22:38, Bernd Eckenfels wrote:
>
> 
>
>  But theoretically both is possible: consume FileSystems as a provider
>> or implement an adapter which makes a VFS filesystem(manager) to
>> provide the FileSystem SPI.
>>
> I have been playing with that and it looks possible, but it is far from
> trivial. The meagre documentation or even lack of published success in
> writing NIO2 providers shows that this is a road less travelled. I have
> looked at the supplied ZIP example that comes with the JDK and IMHO still
> very much prototype code.
>
>  I think VFS has some things going for it that I could not see in NIO2 -
> even something as simple as having two schemes for one provider. In
> addition, adding providers on the fly is easy in VFS, by just calling
> addProvider on FilesystemManager. From my initial investigation I could not
> see a clear way of doing the equivalent in NIO2. There will be more things
> like these, I am sure.
>
> I am very interesting in where this is going in future and the maintainer
> of Groovy VFS, I have a vested interest. I might be interested to go to
> Budapest in November if this gets discussed.
>
> 
>
> --
> Schalk W. Cronjé
> @ysb33r
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


Re: [discuss] Vote to git it?

2014-09-09 Thread Mark Fortner
If I had to pick one feature that makes git more useful than svn, it would
be the ease in creating feature branches.  If you want to add a feature,
you simply create a local branch to implement the feature, implement it,
and commit it, and create a pull request.  If you're using Atlassian's
Crucible or Stash, it's pretty easy to do a code review of the pull
request.

Feature branching makes it easy for developers to get their feet wet with a
code base. You can try out experiments.  Have branches for each experiment.
 It makes it easier to attract new developers to a project.

>From the previous discussion thread, it seems like the main objections were
(paraphrasing a bit here):

   - I'm not familiar with git. I've got a process that works for me and I
   don't want to change it.
   - I don't see the value in it.
   - We don't know the impact on the release process.


In order to address these concerns, it makes sense to try it out on a
project.  The next question is -- which project.  The project needs to be
central enough that everyone has some skin in the game.  It should be a
project that you have an interest in.  If you haven't used git before, then
you need to try implementing a feature in that project. The project lead
should also be someone who's familiar with git, and feels comfortable with
answering questions about git.

I think if we can identify a project, and get commitment from everyone who
hasn't tried git, to add a small feature, add some comments, or add a unit
test, we'll learn enough.  The project lead can look at the impact on the
release process, and report any findings.  At least at that point, we'll
have learned enough from the process to make an informed decision.


Regards,

Mark



On Tue, Sep 9, 2014 at 8:27 AM, Emmanuel Bourg  wrote:

> Le 09/09/2014 16:52, Paul Benedict a écrit :
> > Is there an itch to scratch (need) by moving to git as opposed to just
> > continue using svn?
>
> I guess the "itch" is simply an increasing preference for Git among the
> people involved here. I don't think the migration will fix any important
> problem.
>
> Emmanuel Bourg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


Re: [discuss] Vote to git it?

2014-09-09 Thread Mark Fortner
Gary,


One thing that is a PITA is when getting pull requests from GitHub. The GH
patches are not usable as it.


Atlassian's Stash makes that easier to deal with. This video describes a
fork-based workflow using Stash, and shows you how code reviews work.  It
also means that people can contribute to projects without having commit
access to the project.  They just submit a pull request to the project.
http://youtu.be/JYC9yDJ0dZo


Cheers,

Mark


Re: [discuss] Vote to git it?

2014-09-09 Thread Mark Fortner
Schalk,
The only problem I see with the way that you do code reviews on Github, is
the fact that you can only review change sets.  You can't simply go through
an existing codebase and point out the problems.  I suggested Stash and
Crucible since they're both linked with JIRA, and I think Apache has free
access to Atlassian's stack for its projects

Cheers,

Mark



On Tue, Sep 9, 2014 at 10:15 AM, Schalk Cronj é  wrote:

> On 09/09/2014 16:57, Mark Fortner wrote:
>
>> If I had to pick one feature that makes git more useful than svn, it would
>> be the ease in creating feature branches.  If you want to add a feature,
>> you simply create a local branch to implement the feature, implement it,
>> and commit it, and create a pull request.  If you're using Atlassian's
>> Crucible or Stash, it's pretty easy to do a code review of the pull
>> request.
>>
> For me that is the killer feature of Git where it beats Subversion
> hands-down.
>
> Personally I also find that performing a code review of a pull request on
> Github easy enough.
>
> --
> Schalk W. Cronjé
> @ysb33r
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


Re: [discuss] Vote to git it?

2014-09-09 Thread Mark Fortner
Paul,
Git branching is faster, computationally cheaper, and requires less disk
space than svn branching.  This link provides more information:
https://git.wiki.kernel.org/index.php/GitSvnComparison.

In git, you have a remote repo, and a local repo.  Typically, people create
local branches for experiments or new features and then merge and create
pull-requests whenever they have something that they want to share with the
community.  In svn, whenever you branch, you're branching on the server
first.  Usually, if you're new to a code base, you don't want to do that if
you're just experimenting.  Ideally, you want to encourage experimentation
(and attract new developers), so "feature branches" make a lot of sense in
that context.

Cheers,

Mark



On Tue, Sep 9, 2014 at 10:46 AM, Paul Benedict  wrote:

> Mark, can you help me understand why git branches (the "feature" branch) is
> better than an svn branch?
>
>
> Cheers,
> Paul
>
> On Tue, Sep 9, 2014 at 10:57 AM, Mark Fortner  wrote:
>
> > If I had to pick one feature that makes git more useful than svn, it
> would
> > be the ease in creating feature branches.  If you want to add a feature,
> > you simply create a local branch to implement the feature, implement it,
> > and commit it, and create a pull request.  If you're using Atlassian's
> > Crucible or Stash, it's pretty easy to do a code review of the pull
> > request.
> >
> > Feature branching makes it easy for developers to get their feet wet
> with a
> > code base. You can try out experiments.  Have branches for each
> experiment.
> >  It makes it easier to attract new developers to a project.
> >
> > From the previous discussion thread, it seems like the main objections
> were
> > (paraphrasing a bit here):
> >
> >- I'm not familiar with git. I've got a process that works for me and
> I
> >don't want to change it.
> >- I don't see the value in it.
> >- We don't know the impact on the release process.
> >
> >
> > In order to address these concerns, it makes sense to try it out on a
> > project.  The next question is -- which project.  The project needs to be
> > central enough that everyone has some skin in the game.  It should be a
> > project that you have an interest in.  If you haven't used git before,
> then
> > you need to try implementing a feature in that project. The project lead
> > should also be someone who's familiar with git, and feels comfortable
> with
> > answering questions about git.
> >
> > I think if we can identify a project, and get commitment from everyone
> who
> > hasn't tried git, to add a small feature, add some comments, or add a
> unit
> > test, we'll learn enough.  The project lead can look at the impact on the
> > release process, and report any findings.  At least at that point, we'll
> > have learned enough from the process to make an informed decision.
> >
> >
> > Regards,
> >
> > Mark
> >
> >
> >
> > On Tue, Sep 9, 2014 at 8:27 AM, Emmanuel Bourg 
> wrote:
> >
> > > Le 09/09/2014 16:52, Paul Benedict a écrit :
> > > > Is there an itch to scratch (need) by moving to git as opposed to
> just
> > > > continue using svn?
> > >
> > > I guess the "itch" is simply an increasing preference for Git among the
> > > people involved here. I don't think the migration will fix any
> important
> > > problem.
> > >
> > > Emmanuel Bourg
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
>


[VFS] Committer Privileges

2008-01-17 Thread Mark Fortner
Hi Henri,
I saw your posts earlier about the bugs you've found.  Are you using
FindBugs to locate these?  Mario mentioned that he was going to be
tied up for a while.  Are there other committers to the project that
would be able to fix these bugs?  Do you have class and line numbers
or patches to address them?

Regards,

Mark Fortner

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VFS] Committer Privileges

2008-01-18 Thread Mark Fortner
I wonder if it would be possible to add FindBugs to the automated builds?

Mark

On Jan 18, 2008 1:08 AM, Henri Yandell <[EMAIL PROTECTED]> wrote:
>
> On Jan 17, 2008 7:43 AM, Mark Fortner <[EMAIL PROTECTED]> wrote:
> > Hi Henri,
> > I saw your posts earlier about the bugs you've found.  Are you using
> > FindBugs to locate these?  Mario mentioned that he was going to be
> > tied up for a while.  Are there other committers to the project that
> > would be able to fix these bugs?  Do you have class and line numbers
> > or patches to address them?
>
> I signed up with Fortify for there 'Java Open Review' a while back,
> and remembered the other day to go look at what they had there. So
> it's FindBugs, but with extra bits on from the Fortify side of the
> product (afaik).
>
> I can get the line numbers, but hopefully I gave enough information
> that each one should be pretty obvious. Let me know if not.  I added
> issues for a bunch of projects - I'll probably work on patches
> someday, but Lang 2.4 takes priority.
>
> If any patches show up I'll apply them :)
>
> Hen
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [io] 2.0 Moving to minimum of JDK 1.5

2008-02-09 Thread Mark Fortner
Just out of curiosity, would it be possible to maintain a single API and
have separate implementation JARs?  Or are there plans to change method
signatures as well (such as to add generics or NIO support)?  If the method
signatures remained the same but the internal implementations were updated
it might be possible to give users a more easily pluggable update to IO.

Regards,

Mark Fortner

On Feb 8, 2008 8:07 AM, Gary Gregory <[EMAIL PROTECTED]> wrote:

> Ag, let's not have /both/ io and io2, this gets messy.
>
> Thank you,
> Gary
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > On Behalf Of James Carman
> > Sent: Friday, February 08, 2008 5:50 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
> >
> > So, you are suggesting having part of a release in the o.a.c.io
> > package and the other part in the o.a.c.io2?  It seems rather
> > inconsistent, but I guess it would work.   Isn't that going to get
> > ugly with 3.x and 4.x releases adding to the mix?
> >
> > On 2/8/08, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > On Feb 6, 2008 1:51 PM, Niall Pemberton <[EMAIL PROTECTED]>
> wrote:
> > > > So the changes are pretty minimal for IO - question is are these
> > > > incompatible changes with generics being erased? If not then perhaps
> > > > we can do this without breaking anything.
> > >
> > > +1 If there are cases where we can't avoid breaking backwards
> > > compatibility, then let's use the name2 pattern on individual classes
> > > or interfaces instead of the entire o.a.c.io package. There are large
> > > parts of Commons IO that don't need to change when upgrading to Java 5
> > > and I don't see why a client that only uses those parts should be
> > > affected in any way by the upgrade.
> > >
> > > BR,
> > >
> > > Jukka Zitting
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Mark Fortner

blog: http://www.jroller.com/phidias


Re: commons-vfs current status?

2008-02-29 Thread Mark Fortner
I have an NFS implementation (using Sun's YANFS implementation) that I'm in
the process of testing.  I also have GUI components (a file chooser, and a
basic file browser) in addition to a metadata API for reading image and MS
Office metadata.  I'd be glad to donate any or all of these if there's any
interest.

Regards,

Mark

On Fri, Feb 29, 2008 at 3:13 AM, James Carman <[EMAIL PROTECTED]>
wrote:

> On 2/29/08, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> > Hi!
> >
> > > I've been using the project for the last 6 months or so and haven't
> seen
> >  > very many commits or activity on JIRA. Is there intention for on
> going
> >  > support?
> >  >
> >
> > As long as no code work needs to be done I think support is still there.
> >
> >  Unhappily VFS lacks of developers and my time is limited too. Still, I
> >  don't want to say VFS is dead. I still have hope that we manage to
> spend
> >  more time again or finally other developers jump up too.
>
> I posted a patch a while back that fixed a problem we were having with
> symbolic links within the FTP file system.  I also got the m2 build
> working.  I don't mind helping out a bit and committing this stuff
> myself.  I just didn't want to step on anyone else's toes, since I've
> never done any VFS development before.  If you don't mind, I'll go
> ahead and commit my stuff.  I guess it could always be backed out if
> deemed unworthy. :)
>
>
> >
> >  Ciao,
> >  Mario
> >
> >
> >  -
> >  To unsubscribe, e-mail: [EMAIL PROTECTED]
> >  For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Mark Fortner

blog: http://www.jroller.com/phidias


Re: commons-vfs current status?

2008-02-29 Thread Mark Fortner
yanfs uses a BSD license.  I think that's compatible.  You can see the
project here: http://yanfs.dev.java.net

Mark

On Fri, Feb 29, 2008 at 9:44 AM, Thorbjørn Ravn Andersen <
[EMAIL PROTECTED]> wrote:

> Mark Fortner skrev  den 29-02-2008 17:18:
> > I have an NFS implementation (using Sun's YANFS implementation) that I'm
> in
> > the process of testing.  I also have GUI components (a file chooser, and
> a
> > basic file browser) in addition to a metadata API for reading image and
> MS
> > Office metadata.  I'd be glad to donate any or all of these if there's
> any
> > interest.
> >
> >
> I think this would be great to have!
>
> Is the YANFS licensing terms compatible with Apache?
> --
>   Thorbjørn
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Mark Fortner

blog: http://www.jroller.com/phidias


[CLI] Usage Patterns Question

2008-03-22 Thread Mark Fortner
I've been using CLI 1 for a while and I noticed that there's been renewed
interest in developing CLI2.  I was wondering how people are currently using
CLI, and whether I'm using it properly?

Most of the command line apps that I've developed do more than one thing.
In order to make it easier to plugin more functionality I use a basic
Command pattern.  Each plugin interface looks something like this:

Command
+ isValid(options: Options):boolean
+ getDescription():String
+ execute(options:Options):void
+ getPrimaryOption():Option

Each command has a primaryOption which uniquely identifies the command from
the command line.  For example, if you have a command which scales images,
then it might be identified by the --scale option.

The main application is responsible for discovering and loading all plugins
at runtime (using the SPI mechanism), determining which plugin to execute,
and printing out help information.  It also invokes the command by first
invoking the command's isValid method to validate the input before invoking
its execute method.

I'm curious if other people are using CLI in a similar manner, or if people
create separate CLI applications for each piece of functionality?  If this
usage pattern is common, should CLI2 incorporate that usage pattern more
formally into its design?

Regards,


-- 
Mark Fortner

blog: http://www.jroller.com/phidias

-- 
Mark Fortner

blog: http://www.jroller.com/phidias


[VFS] Operations API Question

2008-03-24 Thread Mark Fortner
I was looking at the Operations API which seems to imply that the developer
would be able to provide their own operations for different types of file
systems.  The only example seems to be a version control system which at
present seems to be just a collection of interfaces.  I was wondering if
someone has some examples of how this is supposed to be used.  There are no
package comments, or class comments to point people in the right direction.

My thought is that I might be able to use this to combine the Javabeans
Activation Framework's support for files-specific actions with the
Operations API.  This would allow the user to right-click on a file and see
a list of operations that are pertinent to that file type.  For example, if
the user selects a music file, it might allow them to open an external music
player, or view song metadata.

Regards,

-- 
Mark Fortner

blog: http://www.jroller.com/phidias


Re: [jira] Commented: (VFS-165) After fixed bug:113 NullPointerException during getting InputStream from SftpFileObject:I am getting this error

2007-07-30 Thread Mark Fortner
Please stop filing bugs for things that are not bugs, or that are bugs in
your code.  If you have a question, simply send it to the list and place the
text "[vfs]" in the subject along with a brief description and some sample
code that shows where you're having the problem, along with a stack trace.

I assume with respect to this issue that you tried using some other software
like FileZilla or JEdit to confirm that the URL is correct and that the file
exists where you specified in the URL.

There are a couple of things you can do in your code to determine where
things are going wrong:

Try getting the parent directory of the file you're looking for, and
determining if the file exists;

myFile.getParent().exists().

If this returns false, then you know you're URL path is wrong.


Regards,

Mark

On 7/30/07, vikas (JIRA) <[EMAIL PROTECTED]> wrote:
>
>
> [
> https://issues.apache.org/jira/browse/VFS-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516312]
>
> vikas commented on VFS-165:
> ---
>
> Hi Mario Ivankovits
> Pls give me suggestion on above issue.
> How can i solve above problem.
>
> > After fixed bug:113 NullPointerException during getting InputStream from
> SftpFileObject:I am getting this error
> >
> ---
> >
> > Key: VFS-165
> > URL: https://issues.apache.org/jira/browse/VFS-165
> > Project: Commons VFS
> >  Issue Type: Bug
> > Environment: window 2000
> >Reporter: vikas
> >
> > org.apache.commons.vfs.FileSystemException: Could not read file "
> sftp://maan:[EMAIL PROTECTED]/transport/source/students1.txt".
> >   at
> org.apache.commons.vfs.provider.AbstractFileObject.getInputStream(
> AbstractFileObject.java:1163)
> >   at
> org.apache.commons.vfs.provider.DefaultFileContent.getInputStream(
> DefaultFileContent.java:360)
> >   at com.adeptia.indigo.services.transport.ftp.SecuredFtp.download(
> SecuredFtp.java:161)
> >   at
> com.adeptia.indigo.services.transport.ftp.FtpSource.createInputStream(
> FtpSource.java:179)
> >   at
> com.adeptia.indigo.services.transport.support.AbstractStreamSource.initialize
> (AbstractStreamSource.java:44)
> >   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> >   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> >   at java.lang.reflect.Method.invoke(Unknown Source)
> >   at org.apache.commons.modeler.BaseModelMBean.invoke(
> BaseModelMBean.java:483)
> >   at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(Unknown
> Source)
> >   at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(Unknown Source)
> >   at 
> > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown
> Source)
> >   at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source)
> >   at
> com.adeptia.indigo.utils.RemoteMBeanProxy$LocalHandler.invokeOperation(
> RemoteMBeanProxy.java:441)
> >   at com.adeptia.indigo.utils.RemoteMBeanProxy$Handler.invoke(
> RemoteMBeanProxy.java:294)
> >   at $Proxy2.initialize(Unknown Source)
> >   at com.adeptia.indigo.jelly.ActivityTag.runSync(ActivityTag.java
> :313)
> >   at com.adeptia.indigo.jelly.ActivityTag.doTag(ActivityTag.java
> :250)
> >   at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:278)
> >   at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java
> :133)
> >   at com.werken.blissed.jelly.JellyActivity.perform(
> JellyActivity.java:120)
> >   at com.werken.blissed.ProcessEngine.enterState(ProcessEngine.java
> :391)
> >   at com.werken.blissed.ProcessEngine.followTransition(
> ProcessEngine.java:509)
> >   at com.werken.blissed.ProcessEngine.checkTransitions(
> ProcessEngine.java:458)
> >   at com.werken.blissed.ProcessEngine.startProcess(
> ProcessEngine.java:366)
> >   at com.werken.blissed.ProcessEngine.spawn(ProcessEngine.java:299)
> >   at com.adeptia.indigo.processflow.BlissedProcessFlow.execute(
> BlissedProcessFlow.java:159)
> >   at com.adeptia.indigo.transaction.IndigoTransaction.execute(
> IndigoTransaction.java:423)
> >   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> >   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> >   at java.lang.reflect.Method.invoke(Unknown Source)
> >   at org.apache.commons.modeler.BaseModelMBean.invoke(
> BaseModelMBean.java:483)
> >   at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(Unknown
> Source)
> >   at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(Unknown Source)
> >   at 
> > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown
> Source)
> >   at com.s