Hello Ravishankar.
I would like us to migrate to Mina as well, the tracking ticket is
https://issues.apache.org/jira/projects/VFS/issues/VFS-838
I like option 3, more specifically:
Create a new Maven module commons-vfs2-ssh-jsch and move the current
code there, same package, all code is deprecat
Hi Gary and Konrad,
I am a new user of VFS (version 2.9.0) and new to open source mailing lists.
I am writing to inquire about the progress on the jsch upgrade/migration.
Do we have any plans of migrating to jsch fork or Apache Mina?
Thank you for your time and assistance.
Thanks,
Ravishankar Jos
Need to correct myself a bit: the change which prompted for my initial mail is
not about escaping blanks in getPath(), getPath() (Depending on the provider)
only escapes % (and ? and !). So the missing decode Variant of getRelativeName
is limited to those.
The escaped blanks happen in getURL an
Yeah, this needs more research IMO.
One things I am sure of is that a global setting is a no-go for me as it is
bound to cause problems in larger apps that may want conflicting values.
Gary
On Wed, Apr 16, 2025, 12:48 Bernd Eckenfels wrote:
>
> I think the encoding caused a lot of confusion wi
I think the encoding caused a lot of confusion with people (and also I dont see
how it is user friendly - besides if the calling Convention required it), but I
dont think we can change that now. So I agree with Review and documenting.
Maybe we need to provide at least a UriParser.decode() publ
Hi all,
We probably need a general review of the API to see if we have an overall
consistency issue RE encoded vs decoded.
I prefer us to be considerate before adding APIs here and there.
We could at least document what is expected for methods that return a
String or consume a String.
I wonder
I responded on the PR: while I agree the PR fixes a few cases, there are
more issues in this part of the codebase.
Earlier[0], I changed UriParser.normalisePath to support URI-encoded
characters, as that seemed like the least invasive change to fix the
particular issue I was dealing with back then
TY Bernd!
Gary
On Mon, May 27, 2024 at 12:33 PM Bernd Eckenfels wrote:
>
> Hello,
>
> I pushed a PR which fixes the issue and
> Contains a test (which fails if the fix is not
> Present. Besides the uneeded double
> Indirection this code also leads to prematurely
> Dropped listeners and therefore
Hello,
I pushed a PR which fixes the issue and
Contains a test (which fails if the fix is not
Present. Besides the uneeded double
Indirection this code also leads to prematurely
Dropped listeners and therefore loses change events.
Unfortunately a CI Acrion on Girhub failed with a unrelated spora
Hi Bernd,
Thank you for researching this issue and presenting your findings.
In 2.9.0, we had (as you found):
public static void installListener(final FileObject file, final
FileListener listener) {
final WeakRefFileListener weakListener = new WeakRefFileListener(file,
listener);
I have a release candidate out but some files are missing, so there is
something off in the build process.
It's been on my to-do list, so within a week or two I hope.
Gary
On Mon, Apr 29, 2024 at 7:19 AM Elric V wrote:
>
> Hi folks,
>
> Any chance of getting a new VFS release soonish? There hav
There must be a bug in the assembly descriptors...
Gary
On Sun, Jan 28, 2024 at 12:31 PM Gary Gregory wrote:
>
> Ah, I guess I can add do 'site' and 'deploy' at the same time:
>
> mvn -V -Ptest-deploy -Prelease -P japicmp -P jacoco site deploy
>
> to get:
>
> [INFO] --- assembly:3.6.0:single (bi
Ah, I guess I can add do 'site' and 'deploy' at the same time:
mvn -V -Ptest-deploy -Prelease -P japicmp -P jacoco site deploy
to get:
[INFO] --- assembly:3.6.0:single (binary) @ commons-vfs2-distribution ---
[INFO] Reading assembly descriptor: src/assembly/bin.xml
[INFO] ---
The best bet is probably to switch to Apache Mina, another item on my todo
list, unless we get a PR on GitHub first ;-)
Gary
On Mon, Dec 18, 2023, 7:36 AM Konrad Samburski wrote:
> Hello,
>
> The latest version (2.9.0) of VFS is using com.jcraft.jsch for sftp.
> Unfortunately it seems jsch is
Hello,
On Wed, Sep 13, 2023 at 5:57 PM Mark Fortner wrote:
>
> 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*
You'll notice all GitHub builds are green, so either your code changes
broke something, your environment is different enough to cause the issue,
or this is a random error. Maybe the server fixture could not be created, I
can't tell from what's below.
Gary
On Mon, Sep 11, 2023, 11:51 PM Woonsan K
Then there is the licensing issue. I don't see an Apache license on GitHub,
and as soon as I saw GNU...
Gary
On Thu, May 25, 2023, 08:08 Gary Gregory wrote:
> I'm aware of that port but I'd rather rip the band-aid and go with a
> modern implementation supported by a well-know active community.
I'm aware of that port but I'd rather rip the band-aid and go with a modern
implementation supported by a well-know active community. Using the port
would be a last resort IMO.
Gary
On Thu, May 25, 2023, 08:03 David Dellsperger
wrote:
> The other option would be to migrate to the new fork of js
The other option would be to migrate to the new fork of jsch -
https://github.com/mwiede/jsch, there's a few issues with connection
algorithms, etc but there's now at least support to add algorithms to the
list of existing ones in 3 ways (though not sure how VFS might support this
currently).
Davi
@commons.apache.org ; Benjamin Marwell
Betreff: Re: [VFS] unexpected 'relative path' in verify.groovy
Okay,
the exact error message is:
Could not find file with URI
"tar:file:home/user/git/apache/vfs-invoker-groovy/target/it/vfs-it/target/dependency/vfs-invoker-groovy-1.0
Okay,
the exact error message is:
Could not find file with URI
"tar:file:home/user/git/apache/vfs-invoker-groovy/target/it/vfs-it/target/dependency/vfs-invoker-groovy-1.0.0-SNAPSHOT.tar!/hello.txt"
because it is a relative path, and no base URI was provided.
In fact, adding commons-compress
Hi everyone,
I think I figured part of it out myself.
The wiki page
https://cwiki.apache.org/confluence/display/COMMONS/ExtractAndDecompressGzipFiles
does not mention that commons-compress is needed in the classpath.
The github project has some other flaws, too. I will put in some more work.
Be
sorry wrong link ('example' on the api page) is not working
https://commons.apache.org/proper/commons-vfs/apidocs/org/apache/commons/vfs2/example/package-summary.html
Jens
Am 02.04.21 um 02:33 schrieb Gary Gregory:
For me, on my phone, that link just goes to where it is supposed to
https:
For me, on my phone, that link just goes to where it is supposed to
https://commons.apache.org/proper/commons-vfs/api.html
Gary
On Thu, Apr 1, 2021, 19:48 Jens Kapitza
wrote:
> Hi, is this a bug?
>
> Call: https://commons.apache.org/proper/commons-vfs/api.html
>
> i get: The requested URL was
Closing the loop on this thread as this PR has been merged.
Gary
On Wed, Mar 3, 2021, 13:06 Gary Gregory wrote:
> Note that the PR fixes issues found by Spotbugs/PMD. The current in master
> sync on the lock obj looks like an oddity... and it's confusing especially
> if intentional as it's not
an notification email per edit.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> Von: Gary Gregory
> Gesendet: Sunday, March 14, 2021 4:52:18 AM
> An: Commons Developers List
> Betreff: Re: [VFS] Help with FileContent implementation
That is what I used, but it creates an notification email per edit.
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Gary Gregory
Gesendet: Sunday, March 14, 2021 4:52:18 AM
An: Commons Developers List
Betreff: Re: [VFS] Help with FileContent implementation
On
On Sat, Mar 13, 2021 at 3:16 PM Bernd Eckenfels wrote:
>
> I added a comment (and sorry for the edits, would be cool if the GitHub
> integration does allow some typo fix cooldowns for hotshots like me ,)
On my GH comments, I can click the "..." menu on that comment and
chose "Edit". You?
Gary
I added a comment (and sorry for the edits, would be cool if the GitHub
integration does allow some typo fix cooldowns for hotshots like me ,)
--
http://bernd.eckenfels.net
Von: Gary Gregory
Gesendet: Friday, March 12, 2021 10:58:00 PM
An: Commons Developers Lis
Note that the PR fixes issues found by Spotbugs/PMD. The current in master
sync on the lock obj looks like an oddity... and it's confusing especially
if intentional as it's not commented to "double up" the use of the lock
object as both a real lock and the use of its monitor.
I'm tending to merge
I plan on cutting a release candidate this week but I do not see this PR as
a blocker, just a nice-to-have if appropriate.
I encourage all to review PRs and Jiras.
I like RERO so if you guys can only help later, that's fine as well.
Gary
On Tue, Mar 2, 2021, 13:46 Bernd Eckenfels wrote:
> He
Hello,
I do agree that we don’t need to worry about removing synchronized for the
purpose of beeing compatible with early versions of Loom (at least not for all
commons projects). This is especially true if the code gets more ugly, might
have subtle behavior changes or similar.
However I think
It looks like we need more in
https://javadoc.io/static/org.apache.commons/commons-vfs2/2.7.0/org/apache/commons/vfs2/provider/ftp/FtpFileSystemConfigBuilder.html
as well as FTPClientWrapper...
PRs on GitHub are welcome ; -)
Gary
On Thu, Jan 28, 2021, 07:16 消逝 wrote:
> FTPClient has the solu
I also fixed the test on Java 11.
Gary
On Sun, Sep 20, 2020 at 3:27 PM Gary Gregory wrote:
> While I fixed the bug and the build passes on Java 8 for me, it does not
> on Java 11. This could be an issue in the test itself or between the test
> and the Apache Mina FTP server embedded in the test
While I fixed the bug and the build passes on Java 8 for me, it does not on
Java 11. This could be an issue in the test itself or between the test and
the Apache Mina FTP server embedded in the test.
I'd like to release (or someone else) 3.7.1 to fix the regression in FTPS.
javax.net.ssl.SSLHands
I fixed the bug in master and provided a test.
Gary
On Fri, Sep 18, 2020, 06:03 sebb wrote:
> On Thu, 17 Sep 2020 at 16:39, Gary Gregory
> wrote:
> >
> > On Thu, Sep 17, 2020 at 6:47 AM sebb wrote:
> > >
> > > Does VFS actually *need* the latest version of NET?
> >
> > Sigh, that's irrelevan
On Thu, 17 Sep 2020 at 16:39, Gary Gregory wrote:
>
> On Thu, Sep 17, 2020 at 6:47 AM sebb wrote:
> >
> > Does VFS actually *need* the latest version of NET?
>
> Sigh, that's irrelevant as you can't control downstream stacks. This
> is a regression from the user's point of view.
OK, I see now.
I can confirm that PR https://github.com/apache/commons-net/pull/59
fixes the regressing bug in Apache Commons VFS master tests in
**org.apache.commons.vfs2.provider.ftps.test** which was introduced by
Commons Net 3.7.
The PR does not have a test though.
Gary
On Thu, Sep 17, 2020 at 12:14 PM Gar
Connecting dots FTR: https://issues.apache.org/jira/browse/NET-687
On Fri, Sep 11, 2020 at 9:46 AM Gary Gregory wrote:
>
> Hi All:
>
> Updating Commons VFS from Commons Net 3.6 to 3.7 causes failures. Please see:
>
> https://github.com/apache/commons-vfs/pull/128
>
> For example:
>
> https://gith
On Thu, Sep 17, 2020 at 6:47 AM sebb wrote:
>
> Does VFS actually *need* the latest version of NET?
Sigh, that's irrelevant as you can't control downstream stacks. This
is a regression from the user's point of view.
> i.e. does it fix a bug or a security issue that impacts VFS?
I hope that's a
Does VFS actually *need* the latest version of NET?
i.e. does it fix a bug or a security issue that impacts VFS?
If not, then downdate until such time as the issue can be fixed.
It would be helpful to have a simple test case that shows the issue.
On Tue, 15 Sep 2020 at 14:08, Gary Gregory wrote
On Wed, Sep 16, 2020 at 8:31 AM Jochen Wiedmann
wrote:
>
> On Sun, Sep 6, 2020 at 3:39 PM Gary Gregory wrote:
>
> > The idea behind making *Util constructors private is that it does not make
> > sense to instantiate a class that only has static methods.
>
> True, but that also eliminates reuse by
On Sun, Sep 6, 2020 at 3:39 PM Gary Gregory wrote:
> The idea behind making *Util constructors private is that it does not make
> sense to instantiate a class that only has static methods.
True, but that also eliminates reuse by subclassing, and similar
techniques. In my opinion, static utility
Is anyone available to help?
Gary
On Sat, Sep 12, 2020 at 3:53 PM Gary Gregory wrote:
>
> The culprit commit seems to be 41e514cda5f68c444edc1058a18e2196b2c1d7d5.
> If I checkout the commit before that one, all is well with the FTPS
> tests in Commons VFS master.
> The fundamental problem is tha
The culprit commit seems to be 41e514cda5f68c444edc1058a18e2196b2c1d7d5.
If I checkout the commit before that one, all is well with the FTPS
tests in Commons VFS master.
The fundamental problem is that there is not a single test for the
class FTPSClient, so all commits against that class are "blind
I’ve seen a different approach in libraries like Mockito and Hamcrest that
split up utility classes by category, then they use a tool to copy all the
static stuff to generated aggregate classes.
On Sun, Sep 6, 2020 at 09:23 Xeno Amess wrote:
> > I am not a big fan of extending Static Utility cla
> I am not a big fan of extending Static Utility classes. And Joshua
Bloch is not either from his book "Effective Java"...
Yep I'm sure he will never like this lol.
Melloware 于2020年9月6日周日 下午10:18写道：
> I am not a big fan of extending Static Utility classes. And Joshua
> Bloch is not either fro
I am not a big fan of extending Static Utility classes. And Joshua
Bloch is not either from his book "Effective Java"...
See: https://www.informit.com/articles/article.aspx?p=1216151&seqNum=4
On 9/6/2020 10:06 AM, Xeno Amess wrote:
class AUtil {
public static String getStringA() {
class AUtil {
public static String getStringA() {
return "A";
}
}
class ExtendedAUtil extends AUtil {
public static String getStringABCDE() {
return "ABCDE";
}
}
public class Main {
public static void main(String[] args) {
System.out.println(ExtendedAUt
Well sometimes we want to extend(or modify) some behaviors of one Util
Class.That is why I don't want the constructor be private.
For example, there be a AUtil:
public class AUtil{
public static String getStringA(){
return "A";
}
}
then some people need a function that returns "
That is why I love Lombok's @UtilityClass.
https://projectlombok.org/features/experimental/UtilityClass
It enforces a static class is truly static by making the constructor
private and throwing an exception, making sure all methods are static,
marking the class as Final etc.
On 9/6/2020 9:5
But I agree that only very few people/usecase would write codes which
extending the *Util classes.
Xeno Amess 于2020年9月6日周日 下午9:53写道：
> > Inheritance in Java on the static side is
> not the same as on the instance side
>
> Yep, I know it. It will not override but just, hiding.
> I admit it might
> Inheritance in Java on the static side is
not the same as on the instance side
Yep, I know it. It will not override but just, hiding.
I admit it might confuse people sometimes.
> subclassing a class that only
provides static methods is no help.
Well actually I personally use it for a shortcut
On Sun, Sep 6, 2020 at 9:44 AM Xeno Amess wrote:
> The idea behind not making *Util constructors private is that it makes
> people be able to extend that class.
> for example:
>
> https://github.com/apache/commons-lang/blob/master/src/main/java/org/apache/commons/lang3/StringUtils.java#L9627
I
The idea behind not making *Util constructors private is that it makes
people be able to extend that class.
for example:
https://github.com/apache/commons-lang/blob/master/src/main/java/org/apache/commons/lang3/StringUtils.java#L9627
Gary Gregory 于2020年9月6日周日 下午9:39写道：
> The idea behind making *
The idea behind making *Util constructors private is that it does not make
sense to instantiate a class that only has static methods.
Gary
On Sun, Sep 6, 2020 at 12:49 AM Xeno Amess wrote:
> for example: can we make its constructor public instead of private?
>
Hello,
I guess we can document this on the site, I would not change the tests as
running with root is a unusual thing to do, anyway.
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: shuming chen
Gesendet: Wednesday, May 13, 2020 12:20:46 PM
An: dev@commons.apach
Obvious junk Javadoc, fixed in master.
Gary
On Sat, Feb 22, 2020 at 8:53 AM Otto Fowler wrote:
> I’m running `mvn site` on a PR I’ve authored, and i get an error unrelated
> to my changes. Has anyone else seen this?
>
> ```bash
>
> *INFO*]
> *---
Uh, glad it was reported soon and you can cut a new release Gary. Will try to
monitor inbox to review the release once it's out.
CheersBruno
On Monday, 6 January 2020, 2:07:19 am NZDT, Gary Gregory
wrote:
Hi All:
It looks like Commons VFS 2.5.0 contains an incompatibility for existin
No idea what's causing that issue. I reproduced it locally with Maven in the
command line, but couldn't debug it due to an old Eclipse version.
In case it helps, when I run Webdav4ProviderTestCase locally, I get two test
errors. When I run in the command line, I get a single one, exactly the sam
On 19.12.2019 15:16, Gary Gregory wrote:
Looking for help to resolve this failure:
https://travis-ci.org/apache/commons-vfs/jobs/627014664?utm_medium=notification&utm_source=email
This seems to use Jackrabbit 1, which won't work with Java 14.
Best regards, Julian
Hi Gary, just to state the obvious, it seems to be 15-ea which fails, not 14.
have you been able to reproduce it locally (currently have no good access to a
machine to reproduce it), yet?
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Gary Gregory
Gesendet: Don
Hi Gary,
I've just posted a PR for VFS-687 (with HttpClient *5*).
When you have some time, please take a review.
Thanks!
Woonsan
On Wed, Jan 2, 2019 at 12:11 PM Woonsan Ko wrote:
>
> Thanks again, Gary!
> Just as heads-up, I've created two tickets: VFS-686 and VFS-687. The
> former is about up
Hi Gary,
Thank you very much for your attention and pointing out the test
failure in JDK 11 and 13.
I've just pushed a fix and it shows successes except of openjdk-ea
like master branch:
-
https://travis-ci.org/apache/commons-vfs/builds/599058148?utm_source=github_status&utm_medium=notification
Hi Woonsan,
I apologize for such a long delay in getting this PR integrated.
I've not looked at the actual PR in a long while but I can see an
interesting difference with master and this PR in Travis builds.
With master, all builds pass except Java 14-EA, that's Java 8, 11, 12, 13:
https://travi
On Thu, 2 May 2019 at 00:09, Bruno P. Kinoshita
wrote:
>
> Yesterday I submitted a pull request against the wrong branch in GitHub.
> Spent a couple of minutes scratching my head and trying to find out how to
> change that... then found the option while editing it.
>
> GitHub help has a page ex
Yesterday I submitted a pull request against the wrong branch in GitHub. Spent
a couple of minutes scratching my head and trying to find out how to change
that... then found the option while editing it.
GitHub help has a page explaining how to do that:
https://help.github.com/en/articles/chang
On Wed, May 1, 2019 at 6:23 PM sebb wrote:
> On Wed, 1 May 2019 at 23:02, Gary Gregory wrote:
> >
> > On Wed, May 1, 2019 at 5:30 PM sebb wrote:
> >
> > > On Wed, 1 May 2019 at 21:48, Gary Gregory
> wrote:
> > > >
> > > > On Wed, May 1, 2019 at 3:54 PM Gary Gregory
> > > wrote:
> > > >
> > >
On Wed, 1 May 2019 at 23:02, Gary Gregory wrote:
>
> On Wed, May 1, 2019 at 5:30 PM sebb wrote:
>
> > On Wed, 1 May 2019 at 21:48, Gary Gregory wrote:
> > >
> > > On Wed, May 1, 2019 at 3:54 PM Gary Gregory
> > wrote:
> > >
> > > > I created https://issues.apache.org/jira/browse/INFRA-18316
> >
On Wed, May 1, 2019 at 4:54 PM Mark Thomas wrote:
> On 01/05/2019 21:48, Gary Gregory wrote:
> > On Wed, May 1, 2019 at 3:54 PM Gary Gregory
> wrote:
> >
> >> I created https://issues.apache.org/jira/browse/INFRA-18316
> >>
> >
> > And the work is done. Note that open PRs on trunk have been clos
On Wed, May 1, 2019 at 5:30 PM sebb wrote:
> On Wed, 1 May 2019 at 21:48, Gary Gregory wrote:
> >
> > On Wed, May 1, 2019 at 3:54 PM Gary Gregory
> wrote:
> >
> > > I created https://issues.apache.org/jira/browse/INFRA-18316
> > >
> >
> > And the work is done. Note that open PRs on trunk have b
On Wed, 1 May 2019 at 21:48, Gary Gregory wrote:
>
> On Wed, May 1, 2019 at 3:54 PM Gary Gregory wrote:
>
> > I created https://issues.apache.org/jira/browse/INFRA-18316
> >
>
> And the work is done. Note that open PRs on trunk have been closed
> automatically, so they would need to be re-opened.
> On May 1, 2019, at 4:54 PM, Mark Thomas wrote:
>
>> On 01/05/2019 21:48, Gary Gregory wrote:
>>> On Wed, May 1, 2019 at 3:54 PM Gary Gregory wrote:
>>>
>>> I created https://issues.apache.org/jira/browse/INFRA-18316
>>>
>>
>> And the work is done. Note that open PRs on trunk have been cl
On 01/05/2019 21:48, Gary Gregory wrote:
> On Wed, May 1, 2019 at 3:54 PM Gary Gregory wrote:
>
>> I created https://issues.apache.org/jira/browse/INFRA-18316
>>
>
> And the work is done. Note that open PRs on trunk have been closed
> automatically, so they would need to be re-opened.
Note that
On Wed, May 1, 2019 at 3:54 PM Gary Gregory wrote:
> I created https://issues.apache.org/jira/browse/INFRA-18316
>
And the work is done. Note that open PRs on trunk have been closed
automatically, so they would need to be re-opened.
Gary
>
> Gary
>
> On Wed, May 1, 2019 at 3:55 AM Benedikt Ri
I created https://issues.apache.org/jira/browse/INFRA-18316
Gary
On Wed, May 1, 2019 at 3:55 AM Benedikt Ritter wrote:
> Am Di., 30. Apr. 2019 um 14:43 Uhr schrieb Gary Gregory <
> garydgreg...@gmail.com>:
>
> > Should we take a broader stroke and remove ALL trunk branches from all
> > Commons
Am Di., 30. Apr. 2019 um 14:43 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:
> Should we take a broader stroke and remove ALL trunk branches from all
> Commons git repos?
>
I think we should remove all trunk branches from git repos.
>
> Gary
>
> On Mon, Apr 29, 2019 at 11:25 AM Otto Fowle
Am Di., 30. Apr. 2019 um 15:04 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:
> Hi All:
>
> For the first time in a while, we have a green build suite on Travis:
>
> https://travis-ci.org/apache/commons-vfs/
Awesome!
>
>
> Gary
>
Should we take a broader stroke and remove ALL trunk branches from all
Commons git repos?
Gary
On Mon, Apr 29, 2019 at 11:25 AM Otto Fowler
wrote:
> Probably need INFRA
>
>
> On April 29, 2019 at 11:23:38, Gary Gregory (garydgreg...@gmail.com)
> wrote:
>
> On Mon, Apr 29, 2019 at 11:22 AM Gary
Probably need INFRA
On April 29, 2019 at 11:23:38, Gary Gregory (garydgreg...@gmail.com) wrote:
On Mon, Apr 29, 2019 at 11:22 AM Gary Gregory
wrote:
> Well, crud, neither these works:
>
> C:\git\commons-vfs>git push origin --delete trunk
> remote: Rewinding refs/heads/trunk is forbidden.
> rem
On Mon, Apr 29, 2019 at 11:22 AM Gary Gregory
wrote:
> Well, crud, neither these works:
>
> C:\git\commons-vfs>git push origin --delete trunk
> remote: Rewinding refs/heads/trunk is forbidden.
> remote:
> To https://gitbox.apache.org/repos/asf/commons-vfs
> ! [remote rejected] trunk (pre-recei
Well, crud, neither these works:
C:\git\commons-vfs>git push origin --delete trunk
remote: Rewinding refs/heads/trunk is forbidden.
remote:
To https://gitbox.apache.org/repos/asf/commons-vfs
! [remote rejected] trunk (pre-receive hook declined)
error: failed to push some refs to '
https://gitbo
+1
> On Apr 29, 2019, at 10:58 AM, Otto Fowler wrote:
>
> +1
>
>
> On April 29, 2019 at 08:01:43, Gary Gregory (garydgreg...@gmail.com) wrote:
>
> I am going to delete the branch 'trunk'.
>
> It's too confusing.
>
> Gary
+1
On April 29, 2019 at 08:01:43, Gary Gregory (garydgreg...@gmail.com) wrote:
I am going to delete the branch 'trunk'.
It's too confusing.
Gary
I don't know what kind of coffee I was drinking! Sorry about that ;-)
Gary
On Sun, Apr 28, 2019 at 9:08 AM sebb wrote:
> On Sat, 27 Apr 2019 at 18:09, Gary Gregory wrote:
> >
> > Hi All:
> >
> > Can anyone say why we build a SftpFileSystem here:
> >
> >
> https://github.com/apache/commons-vfs/
On Sat, 27 Apr 2019 at 18:09, Gary Gregory wrote:
>
> Hi All:
>
> Can anyone say why we build a SftpFileSystem here:
>
> https://github.com/apache/commons-vfs/blob/master/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/sftp/SftpFileProvider.java#L90
>
>
> instead of here:
>
> https://g
Can anyone lend a hand ?
Gary
On Fri, Apr 12, 2019 at 7:43 AM Gary Gregory wrote:
> Help needed ;-)
>
> Gary
>
On Fri, Apr 19, 2019 at 6:13 PM Gary Gregory wrote:
>
> Hi,
>
> WRT
> https://builds.apache.org/job/Apache%20Commons%20VFS/org.apache.commons$commons-vfs2/9/testReport/junit/org.apache.commons.vfs2.test/UriTests/testAbsoluteURI/
>
> I just replaced the old svn-based build with a git-based build.
>
+1 then, from looking at the code, I don’t see why RuntimeException would
be required there.
On April 19, 2019 at 12:38:02, Gary Gregory (garydgreg...@gmail.com) wrote:
On Fri, Apr 19, 2019 at 11:38 AM Otto Fowler
wrote:
> Where these written to be used as lambdas?
>
They were not. These were
On Fri, Apr 19, 2019 at 11:38 AM Otto Fowler
wrote:
> Where these written to be used as lambdas?
>
They were not. These were written a long time ago as part of Apache Commons
IO and recently ported to VFS.
Gary
>
>
> On April 19, 2019 at 10:07:28, Gary Gregory (garydgreg...@gmail.com)
> wrote
Where these written to be used as lambdas?
On April 19, 2019 at 10:07:28, Gary Gregory (garydgreg...@gmail.com) wrote:
Hi All:
In our new file filters ported from Commons IO, we have code like:
} catch (final FileSystemException ex) {
throw new RuntimeException(ex);
}
I propose instead that w
Hi Gary,
I forgot to ask: I ended up copying the test data files and test class
files (in src/test/resources/test-data and src/test/java/code/) from
the core to commons-vfs-jackrabbit3. Is there a good way to avoid
duplicates?
I didn't choose Maven dependency plugin's unpack as it requires
'packa
Hi Gary,
I've created a pull request: https://github.com/apache/commons-vfs/pull/52
But it's just for early-review purpose, not ready for merging yet,
mainly because it depends on Jackrabbit 2.19.2-SNAPSHOT at the moment.
I'll merge my PR [1] to Jackrabbit myself, and I will need to wait for
cutti
On Mon, Feb 25, 2019 at 9:28 AM Gary Gregory wrote:
>
> Stepping back, It seems to me we have two paths:
> - Update Jackrabbit transparently and open ourselves up to _potential_
> compatibility issues.
> - Do it the way we did for HttpCore 3 to 4 (which is what we are talking
> about here.)
>
> Wh
Stepping back, It seems to me we have two paths:
- Update Jackrabbit transparently and open ourselves up to _potential_
compatibility issues.
- Do it the way we did for HttpCore 3 to 4 (which is what we are talking
about here.)
What about this:
- Instead of adding code to the sandbox, create a new
On Mon, Feb 25, 2019 at 8:07 AM Gary Gregory wrote:
>
> On Sun, Feb 24, 2019 at 4:00 PM Woonsan Ko wrote:
>
> > On Mon, Feb 18, 2019 at 2:09 PM Woonsan Ko wrote:
> > >
> > > On Mon, Feb 18, 2019 at 1:45 PM Gary Gregory
> > wrote:
> > > >
> > > > Hi Woonsan,
> > > >
> > > > Why disable existing
On Sun, Feb 24, 2019 at 4:00 PM Woonsan Ko wrote:
> On Mon, Feb 18, 2019 at 2:09 PM Woonsan Ko wrote:
> >
> > On Mon, Feb 18, 2019 at 1:45 PM Gary Gregory
> wrote:
> > >
> > > Hi Woonsan,
> > >
> > > Why disable existing tests?
> >
> > I think the new Jackrabbit dependency 2.19.x would conflict
On Mon, Feb 18, 2019 at 2:09 PM Woonsan Ko wrote:
>
> On Mon, Feb 18, 2019 at 1:45 PM Gary Gregory wrote:
> >
> > Hi Woonsan,
> >
> > Why disable existing tests?
>
> I think the new Jackrabbit dependency 2.19.x would conflict with the
> old one, 1.6.5.
> Jackrabbit upgraded httpclient dependency
On Mon, Feb 18, 2019 at 1:45 PM Gary Gregory wrote:
>
> Hi Woonsan,
>
> Why disable existing tests?
I think the new Jackrabbit dependency 2.19.x would conflict with the
old one, 1.6.5.
Jackrabbit upgraded httpclient dependency to 4.x since 2.16.0 with no
changes in maven coordinates nor package n
Hi Woonsan,
Why disable existing tests?
Gary
On Mon, Feb 18, 2019, 13:19 Woonsan Ko Hi,
>
> I'm trying to create a PR as a fix to VFS-686.
> At first, I've tried to fix those in
> org.apache.commons.vfs2.provider.webdav package, but realized that the
> changes will break API compatibility. For
1 - 100 of 1062 matches
Mail list logo
