up to give the necessary permissions and committed his GPG
key.
On 25 April 2016 at 17:10, Gary Gregory wrote:
Hi,
Agreed, VFS 2.1 has been too long in the making. We can release ASAP
without fixing more bugs IMO. RERO and all.
As an Apache committer, your are also an Apache Commons committer, so
It's from the thread called "Whatever happened to commons-io 2.5?" A few
people stepped up to give the necessary permissions and committed his GPG
key.
On 25 April 2016 at 17:10, Gary Gregory wrote:
> Hi,
>
> Agreed, VFS 2.1 has been too long in the making. We can relea
Hi,
Agreed, VFS 2.1 has been too long in the making. We can release ASAP
without fixing more bugs IMO. RERO and all.
As an Apache committer, your are also an Apache Commons committer, so feel
free to create JIRAs, fix bugs and so on.
There might be some karma issues with a non-PMC member
been fixed (but not release) which is spurring me to take some action.
There have been emails reaching back as far as 2014 asking when the next
release might be, not to mention the fact that vfs-2.0 was released in
2011 (!).
History aside, I'm reaching out today to:
1) See if anyone on th
Am Tue, 22 Mar 2016 16:33:12 +
schrieb "Epstein, Ezra" :
> Is commons-vfs being maintained? And is GitHub the up-to-date code
> repo?
Yes, github is a mirror of the apache git repo and the apache git repo
mirrors the SVN based master. They should be in sync. The project h
Is commons-vfs being maintained? And is GitHub the up-to-date code repo?
I notice a number of open pull requests, one from yours truly.
https://github.com/apache/commons-vfs/pulls
Just checking in to see if something more is needed for contributing to
this project
he JIRA:
>
> https://issues.apache.org/jira/browse/VFS/
>
> It seems to be safe to ignore that failure.
>
Hm, I think we should really fix this :-)
Maybe it is possible to use the Test Containers project [1] to spin up the
needed infrastructure for running the test?
Benedikt
[1]
FileObject f =
VFS.getManager().resolveFile("http://www.w3schools.com/xml/tempconvert.asmx
?WSDL");
This change is included in this pull request:
https://github.com/apache/commons-vfs/pull/12
Thanks.
On 3/21/16, 2:38 PM, "Epstein, Ezra" wrote:
>I¹ve forked and cloned t
Hello,
I think it is a new problem. It is a bit unfortunate that those tests
rely on external web sites (and those seeem to no longer exist).
If you want, you can file the report directly in the JIRA:
https://issues.apache.org/jira/browse/VFS/
It seems to be safe to ignore that failure.
Gruss
I’ve forked and cloned the repo from GitHub and the build fails with:
Tests run: 90, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.223 sec <<<
FAILURE! - in org.apache.commons.vfs2.provider.http.test.HttpProviderTestCase
testHttp405(org.apache.commons.vfs2.provider.http.test.HttpProviderT
Eckenfels
Cc: u...@commons.apache.org, dev@commons.apache.org
Sent: Mi., 09 Dez. 2015 23:02
Subject: Re: [vfs] New Properties for FtpFileSystemConfigBuilder
Hi Bernd,
I wanted to touch base and ask what are my next steps--should I enter a
feature request on the Commons VFS JIRA board? Also, my app
Hi Bernd,
I wanted to touch base and ask what are my next steps--should I enter a
feature request on the Commons VFS JIRA board? Also, my app is using
Commons VFS 2.0, so I was hoping to make the fix there and port it to 2.1.
Will there be any more releases in the 2.0 branch?
On Mon, Dec 7
Hi Bernd,
For now I was using a max and min property so I could pass int values
directly from my adaptor layer to VFS. What do you recommend? A string
range's only issue that I can see is parsing, but something simple could
work.
On Mon, Dec 7, 2015 at 1:54 PM, Bernd Eckenfels
wrote:
&g
Hello Roger,
sounds useful to me. Do you plan to parse a string range ("1-100") or
define a min and max property?
Gruss
Bernd
Am Mon, 7 Dec 2015 13:26:35 -0800
schrieb Roger Membreno :
> Hello Apache Community, how are you doing?
>
> We use Commons VFS in our FTP connectio
We have started down this path several times before. I'd like to revisit it as
the Accumulo community is dependent on Commons VFS. I have been advising people
to download the 2.1-SNAPSHOT jar from Continuum as it resolves several issues
for our users. Can the Accumulo community provid
I have opened issue https://issues.apache.org/jira/browse/VFS-586 with my
proposed patch attached, and these questions included in the issue. Updated
the patch with some things I noticed after the initial post also.
Thanks,
~Roger
-Original Message-
From: dlmar...@comcast.net
I have created https://issues.apache.org/jira/browse/VFS-586 and attached the
proposed patch there for your consideration.
The original questions I had still apply, and will be added to the issue.
Thanks,
~Roger Whitcomb
-Original Message-
From: Pascal Schumacher [mailto:pascalschumac
Okay, I'll go ahead and make a new JIRA issue, then, and attach the patch there.
Thanks,
~Roger
From: Pascal Schumacher
Sent: Tuesday, November 17, 2015 9:48 AM
To: Commons Developers List
Subject: Re: [VFS] Further changes to HDFS Provider for alte
Sent: Monday, November 16, 2015 5:12 PM
To: Commons Developers List
Subject: [VFS] Further changes to HDFS Provider for alternate configuration
support
Hi all,
In trying to solve some customer issues we're having, mainly
to do with trying to browse HDFS files when the
I don't see the patch. It might be stripped off by the mail server.
From: Roger Whitcomb [mailto:roger.whitc...@actian.com]
Sent: Monday, November 16, 2015 5:12 PM
To: Commons Developers List
Subject: [VFS] Further changes to HDFS Provider for alternate configuration
support
H
Hi all,
In trying to solve some customer issues we're having, mainly to
do with trying to browse HDFS files when the Name Node is configured for
High-Availability, I found I needed to make some more changes/additions to the
VFS HDFS Provider. I have attached a diff/patch
+1
Gary
On Nov 2, 2015 2:23 PM, "Schalk Cronjé" wrote:
> What I have noticed whilst playing around with JackRabbit is that the
> jackrabbit-standalone.jar used as part of testing is not available under
> the later 2.x releases. I think the VFS 2.1 release should probably s
What I have noticed whilst playing around with JackRabbit is that the
jackrabbit-standalone.jar used as part of testing is not available under
the later 2.x releases. I think the VFS 2.1 release should probably
stick to the 1.6.5 release. I would rather see VFS 2.1 get released,
than waste
Hi again,
The issue was discovered during some work I was doing for Groovy-VFS. In
that situtation the webdav provider is consumed and it will fail to work
if anything JackRabbit 2.0+ is used as a depedency. The webdav provider
released with VFS 2.0 is depending on a static field
d
> to bump the dependency (but it is not impossible, as you can also test
> against other servers). But isnt this only a test dependency?
>
No, looks like it is an optional dependency in compile scope of vfs core [1]
Benedikt
[1]
https://github.com/apache/commons-vfs/blob/422c4f5d6822a77679a2c
also test against
other servers). But isnt this only a test dependency?
Gruss
Bernd
--
http://bernd.eckenfels.net
-Original Message-
From: "Schalk Cronjé"
To: Commons Developers List
Sent: Do., 29 Okt. 2015 1:30 AM
Subject: [VFS] Jackrabbit
Bernd,
Is it possible t
Bernd,
Is it possible to bump the Jackrabbit version to 2.11.1 for the VFS 2.1
release?
The current 1.6.5 is quite old and later versions of jackrabbit-webdav
cannot be used with the existing 2.0.
I did a quick check and there seems to be only one test failure when the
version is bumped
It is in a good shape now, it only needs a compatibility statement for the
release notes explaining the clirr-warnings and probably merging the hdfs write
changes.
Gruss
Bernd
Von: Gary Gregory
Gesendet: Freitag, 2. Oktober 2015 19:36
An: Commons Developers List
Betreff: [VFS] Release road
Hi,
What is left to do to release VFS?
Gary
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://
de it. No need to over-standardize. I just
responded with how I do it.
Phil
>
> 2015-09-24 18:47 GMT+02:00 Phil Steitz :
>> On 9/24/15 8:59 AM, Bernd wrote:
>>> Hello,
>>>
>>> do we have this rule to include the name of a patch contributor into
>>> the commit
Phil, Is this somewhere codified?
2015-09-24 18:47 GMT+02:00 Phil Steitz :
> On 9/24/15 8:59 AM, Bernd wrote:
>> Hello,
>>
>> do we have this rule to include the name of a patch contributor into
>> the commit message? I havent seen that beeing used so far in
>>
On 9/24/15 8:59 AM, Bernd wrote:
> Hello,
>
> do we have this rule to include the name of a patch contributor into
> the commit message? I havent seen that beeing used so far in
> commons-vfs, and the commit does contain Antonio's name in the
> changes.xml due-to= credits.
-- Original message
From: Bernd
Date: 09/24/2015 08:59 (GMT-08:00)
To: Commons Developers List
Subject: Contributor names in commit logs? (was: [jira] [Commented] (VFS-567)
Timeout in vsFTPd causes exception when executing another command)
Hello,
do we have this rule to incl
Hello,
do we have this rule to include the name of a patch contributor into
the commit message? I havent seen that beeing used so far in
commons-vfs, and the commit does contain Antonio's name in the
changes.xml due-to= credits. I think a while back we had the
discussion that not even th
e-notex.txt are already commited, I will also deploy a new
>>> site on my private account before RC1, anything else needed?
>>>
>>> Gruss
>>> Bernd
>>>
>>> 2015-09-18 17:46 GMT+02:00 Gary Gregory (JIRA) :
>>
notex.txt are already commited, I will also deploy a new
>> site on my private account before RC1, anything else needed?
>>
>> Gruss
>> Bernd
>>
>> 2015-09-18 17:46 GMT+02:00 Gary Gregory (JIRA) :
>> >
>> > [
>> https://issues.apach
release-notex.txt are already commited, I will also deploy a new
> site on my private account before RC1, anything else needed?
>
> Gruss
> Bernd
>
> 2015-09-18 17:46 GMT+02:00 Gary Gregory (JIRA) :
> >
> > [
> https://issues.apache.org/jira/browse/VFS-576?page=c
(JIRA) :
>
> [
> https://issues.apache.org/jira/browse/VFS-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14875806#comment-14875806
> ]
>
> Gary Gregory commented on VFS-576:
> --
>
&g
aven VM.
> >
> > However I am not quite sure what the
> > outcome was. I think it was an old ASM dependency which has been
> > dragged into the maven classpath by some other plugin, but I am not
> > sure.
> >
> > VFS uses animal-sniffer-maven-plugin:1.
Hi Bernd.
I can confirm that issue was gone after VFS-426 fix.
Thank you.
WBR, Alex.
On 19.08.2015 11:29, Bernd Eckenfels wrote:
Hello Alexander,
there is no ETA but there is work towards a release (latest update
yesterday), see here: https://wiki.apache.org/commons/VfsReleaseState
I
t; When new release of commons-vfs planned ?
>
>
> There is critical bug https://issues.apache.org/jira/browse/VFS-503?,
> with patch, but patch is not integrated into svn about 2 years, and
> commons-vfs was not released 4 years.
>
>
>> outcome was. I think it was an old ASM dependency which has been
>> dragged into the maven classpath by some other plugin, but I am not
>> sure.
>>
>> VFS uses animal-sniffer-maven-plugin:1.13:check with java16 signatures
>> as defined in commons-parent:38.
>
Hi All.
When new release of commons-vfs planned ?
There is critical bug https://issues.apache.org/jira/browse/VFS-503?, with
patch, but patch is not integrated into svn about 2 years, and commons-vfs was
not released 4 years.
Is it dead project ?
WBR, Alex.
at aninal sniffer does fail, when it is
> invoked from a Java 8 maven VM.
>
> However I am not quite sure what the
> outcome was. I think it was an old ASM dependency which has been
> dragged into the maven classpath by some other plugin, but I am not
> sure.
>
> VFS uses anima
Hello,
we had the problem before that aninal sniffer does fail, when it is
invoked from a Java 8 maven VM.
However I am not quite sure what the
outcome was. I think it was an old ASM dependency which has been
dragged into the maven classpath by some other plugin, but I am not
sure.
VFS uses
On 1 July 2015 at 22:33, Schalk Cronjé wrote:
> VFS correctly depends on Compress as it uses the Tar etc. libraries from
> there.
>
> What I was referring to is backporting the provider code to VFS. The
> provider relies on the CPIO code from Compress,
I see, sorry for the nois
VFS correctly depends on Compress as it uses the Tar etc. libraries from
there.
What I was referring to is backporting the provider code to VFS. The
provider relies on the CPIO code from Compress,
On 01/07/2015 22:01, sebb wrote:
Commons Compress already supports CPIO.
Perhaps that needs
Commons Compress already supports CPIO.
Perhaps that needs extending to fit better with VFS, but it seems
wrong to put the CPIO code in VFS which already depends on Compress.
On 1 July 2015 at 21:25, Schalk Cronjé wrote:
> Would anyone fancy backporting this cpio-provider
> (https://gith
Would anyone fancy backporting this cpio-provider
(https://github.com/ysb33r/groovy-vfs/tree/development/cpio-provider)
into Java and adding it to VFS?
I pretty much wrote it based upon the Tar provider.
--
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r
Hello Michael,
thanks for the reminder. For some reasons we do not get notifications
for the commons-vfs project on GitHub, but I have seen the Pull Request
in the Jira comment, thats fine to track it.
I somewhat dislike this code duplication and wished there would be a
more generic way to make
Hello Dave,
the Wiki page reflects my current progress. I am not aware of any
blocker bugs (besides VFS-498), but I havent scanned for new ones I must
admit.
What really needs to be done is to craft a compatibility-announcement
justifying the Clirr report differences and maybe cleanup the
Bernd,
Looking at the release state wiki page I noticed that some progress has been
made since we last talked. Looking at the page, it appears that VFS-498 is the
only issue called out for resolution before the release. In JIRA, there are
several unresolved issues with a 2.1 fix version and
Hello Antonio,
yes I think its a bug in disconnect (), actually there is a similar one (on
failure to retry) one open already in Jira.
Gruss
Bernd
Am 27.03.2015 15:42 schrieb "Antonio Petrelli" :
> Hello
> we are experiencing a strange behaviour of VFS with vsFTPd
> with 2.1-
Hello
we are experiencing a strange behaviour of VFS with vsFTPd
with 2.1-SNAPSHOT version on trunk.
We have a cycle in which periodically tests if a file exists, exiting once
it has been found.
If the vsFTPd session timeout (idle_session_timeout parameter) has been
met, we receive a
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
The "VFS" page has been changed by BerndEckenfels:
https://wiki.apache.org/commons/VFS?action=diff&rev1=21&rev2=22
Comment:
added vfs-azure
*
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
The "VFS" page has been changed by BerndEckenfels:
https://wiki.apache.org/commons/VFS?action=diff&rev1=20&rev2=21
== Usage and Solutions =
This is a nice commit comment but it should show up in the Javadoc as well
please.
Gary
-- Forwarded message --
From:
Date: Thu, Jan 29, 2015 at 1:01 PM
Subject: svn commit: r1655773 - in
/commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs2/provider/hdfs
to sandbox/NOTICE.txt, update copyright year
>>
>> Modified:
>> commons/proper/vfs/trunk/NOTICE.txt
>>
>> Modified: commons/proper/vfs/trunk/NOTICE.txt
>> URL:
>> http://svn.apache.org
Do you have a logfile with the complete stacktrace? I guess this has a
nested cause pointing to some system resources. If not, it is a good idea
to add exception logging to this location in your app, so we can figure out
next tjme this happens.
Which VFS method was throwi g tnis, is it
Hi all
OI got my app running using vfs-2.0 for connecting through SFTP for 48
hours no problem,
and the all of a sudden I got Exception saying:
"Could not determine the type of file "sftp://appshob:***@host/LOG.log";
While the app was able to connect the file few minutes earlier
://people.apache.org/~ecki/commons-vfs/commons-vfs2-sandbox/
I don't think we will find a good replacement for jcifs (and I am
certainly not trying to built it :), so I would guess the smb provider
stays there for some time or we drop it (i.e. if externally maintained).
There might be an option for the
On 1/11/15 10:33 AM, e...@apache.org wrote:
> Author: ecki
> Date: Sun Jan 11 17:33:44 2015
> New Revision: 1650930
>
> URL: http://svn.apache.org/r1650930
> Log:
> notice: add pointer to sandbox/NOTICE.txt, update copyright year
>
> Modified:
> commons/proper/vfs
Am
Sun, 11 Jan 2015 10:40:15 -0700 schrieb Phil Steitz
:
>
>
> On 1/11/15 10:22 AM, Bernd Eckenfels wrote:
> > Hello,
> >
> > the Sandbox module of VFS is and will not be built or released by
> > Apache Commons, however I think we should nevertheless have an
&
On 1/11/15 10:22 AM, Bernd Eckenfels wrote:
> Hello,
>
> the Sandbox module of VFS is and will not be built or released by
> Apache Commons, however I think we should nevertheless have an
> up-to-date NOTICE file for the artifacts.
Why, exactly? We are not releasing / redis
Hello,
the Sandbox module of VFS is and will not be built or released by
Apache Commons, however I think we should nevertheless have an
up-to-date NOTICE file for the artifacts.
So what I did is I created a seperate file and commited (r1650926) it.
Once the PMC aproves, I will also add it to
Updated to the latest commit, built with 'mvn clean install' and 'mvn clean
install site'. Both succeeded, anything else you need me to try?
- Original Message -
From: "Bernd Eckenfels"
To: "Commons Developers List"
Sent: Saturday, Januar
Regarding the warning, it is something the user can change in their hdfs
configuration files. It comes from the hdfs client object, not the vfs code.
Original message From: Bernd Eckenfels
Date:01/10/2015 7:25 PM (GMT-05:00)
To: dlmar...@comcast.net Cc: Commons Developers
Yes, it failed with clean as well.
I am currently let the Site build run in a Loop and it seems to be stable.
Gruss
Bernd
--
http://bernd.eckenfels.net
- Ursprüngliche Nachricht -
Von: "dlmarion"
Gesendet: 11.01.2015 02:57
An: "Commons Developers List"
: Bernd Eckenfels
Date:01/10/2015 8:37 PM (GMT-05:00)
To: Commons Developers List Cc:
Subject: Re: [VFS] Implementing custom hdfs file system using
commons-vfs
2.0
Hello,
with this commit I added a cleanup of the data dir before the
DfsMiniCluster is started. I also use absolute file
; Hello,
>
> Am Sat, 10 Jan 2015 03:12:19 + (UTC)
> schrieb dlmar...@comcast.net:
>
> > Bernd,
> >
> > Regarding the Hadoop version for VFS 2.1, why not use the latest on
> > the first release of the HDFS provider? The Hadoop 1.1.2 release was
> > r
Hello,
Am Sat, 10 Jan 2015 03:12:19 + (UTC)
schrieb dlmar...@comcast.net:
> Bernd,
>
> Regarding the Hadoop version for VFS 2.1, why not use the latest on
> the first release of the HDFS provider? The Hadoop 1.1.2 release was
> released in Feb 2013.
Yes, you are right.
Bernd,
Regarding the Hadoop version for VFS 2.1, why not use the latest on the first
release of the HDFS provider? The Hadoop 1.1.2 release was released in Feb
2013.
I just built 2.1-SNAPSHOT over the holidays with JDK 6, 7, and 8 on Ubuntu.
What type of test errors are you getting? Testing
Am Sat, 10 Jan 2015 01:04:56 + (UTC)
schrieb dlmar...@comcast.net:
> To answer your question about the HDFS version, I went back and
> looked at the patches I supplied for VFS-530. In the patches that I
> supplied to bump the Hadoop version to 2.4.0 and 2.6.0 the only
> changes
Bernd,
To answer your question about the HDFS version, I went back and looked at the
patches I supplied for VFS-530. In the patches that I supplied to bump the
Hadoop version to 2.4.0 and 2.6.0 the only changes were in the pom. This should
mean that, for the parts of the Hadoop client objects
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
The "VFS" page has been changed by BerndEckenfels:
https://wiki.apache.org/commons/VFS?action=diff&rev1=19&rev2=20
Comment:
current commons-vfs link, htt
Bernd,
Wanted to get back to you right away. I should be able to get the information
to you in a day or so (hopefully tonight). I don't know of any public HDFS
instances, but I will see what I can find. Regarding VFS-530, I just wanted to
bump the version to the latest for the 2.1 relea
Hello Dave,
for the download page (staged:
http://people.apache.org/~ecki/commons-vfs/download.html) I need a list
of libraries needed to run VFS to access hdfs. Could you maybe produce
an example VFS Shell session similiar to
https://wiki.apache.org/commons/VfsReleaseState
where you list the
gt; > should be announced as good/critical change.
>
> VFS-540 has commit comment from VFS-541.
Hm, not sure VFS-540 is about commons logging, VFS-541 is about commons
compress? At least in changes.xml and JIRA?
> VFS-476 and VFS-540 are dupes, but both are listed in
>
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
The "VFS" page has been changed by BerndEckenfels:
https://wiki.apache.org/commons/VFS?action=diff&rev1=18&rev2=19
Comment:
Add release preparation page
> -Original Message-
> From: Bernd Eckenfels [mailto:e...@zusammenkunft.net]
> Sent: Wednesday, December 03, 2014 6:28 PM
> To: Commons Developers List
> Cc: dlmar...@comcast.net
> Subject: Re: [VFS] Release Preparations 2.1 (again)
>
> Hello,
>
> Am Wed,
zon S3? I saw this:
>
> https://github.com/abashev/vfs-s3
>
> which also mentions "Why using commons-vfs is a bad idea" :D
>
> Could this be merged in the VFS source?
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> ht
Is is possible to use the VFS2 with Amazon S3? I saw this:
https://github.com/abashev/vfs-s3
which also mentions "Why using commons-vfs is a bad idea" :D
Could this be merged in the VFS source?
--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.p
Hello,
all of them (math, csv, codec) do not define repos, so I removed them
in vfs as well.
codec seems to have an old distributionManagement entry for the site
stagingSite
${commons.deployment.protocol}://people.apache.org/www/commons.apache.org/${commons.componentid}/).
I guess it is not
Hi,
We recently released Commons CVS and Codec, so you could check how it is
done there.
Gary
On Mon, Dec 22, 2014 at 3:49 PM, Bernd Eckenfels
wrote:
>
> Hello,
>
> currently the POM of VFS contains:
>
>
>
>
>apache.snapshots.https
>Apache
On 22 December 2014 at 22:37, Bernd Eckenfels wrote:
> Am Mon, 22 Dec 2014 22:29:34 +
> schrieb sebb :
>
>> But if we always use the same symbolic name, it may look as though an
>> app that was built using VFS2.0 will just be able to use VFS19.2
>> without any adjustments.
>> However, that may
Am Mon, 22 Dec 2014 22:29:34 +
schrieb sebb :
> But if we always use the same symbolic name, it may look as though an
> app that was built using VFS2.0 will just be able to use VFS19.2
> without any adjustments.
> However, that may not be the case.
Actually in OSGi a new major number means th
R. It is together
> with the version uniquely identifying a bundle in OSGi.
OK, so provided that VFS does not re-use version numbers then AFAICT a
fixed name should be OK from that particular point of view.
> It is mostly used for other jars to depend on it with "Require-Bundle".
Am Mon, 22 Dec 2014 21:43:01 +
schrieb sebb :
> > a) follow the math lead and make it org.apache.commons.vfs2 (asuming
> > this does not break anything from 2.0 to 2.1)
>
> If the OSGi bundle name relates to the Java package name or the Maven
> coordinates then this might break things.
Well,
On 22 December 2014 at 20:59, Bernd Eckenfels wrote:
> Hello,
>
> in commons-math I see the comment, that the OSGi bundle-symbolic name
> should be aligned with the package name (i.e. major version).
>
> For VFS2 this is currently not the case. I can see multiple solutions
> for 2.1:
>
> a) follow
Hello,
in commons-math I see the comment, that the OSGi bundle-symbolic name
should be aligned with the package name (i.e. major version).
For VFS2 this is currently not the case. I can see multiple solutions
for 2.1:
a) follow the math lead and make it org.apache.commons.vfs2 (asuming
this does
Hello,
currently the POM of VFS contains:
apache.snapshots.https
Apache Snapshot Repository
https://repository.apache.org/content/repositories/snapshots
false
apache.snapshots
Apache Snapshot Repository
http://people.apache.org/repo/m2-snapshot
Hello Gary,
not sure why this has not been fixed before. Anyway, I added one header
and excluded the test files which have only trivial content. I also
made sure the RAT report does not depend on include-sendbox profile.
With this revision the RAT reports now show no unknown licenses anymore:
ht
Hi All,
The RAT report needs to be clean IMO before we start a release.
Each file must be excluded in the POM with a comment (IMO) as to why it is
OK to exclude, or that file must be dealt with somehow (add header, remove,
who knows).
Gary
On Fri, Dec 19, 2014 at 9:08 PM, Bernd Eckenfels
wrote
Hello,
currently the RAT report shows 20 text files and a few archives (all
test data) with unknown license.
Can we add that to some exclude, is it ok to keep the files in the RAT
report or do I need to do something else before release?
Gruss
Bernd
20 Unknown Licenses
*
I have not forgotten about the todo list. Have been swamped at work and hope
to get some of it done over the holidays.
-Original Message-
From: Bernd Eckenfels [mailto:e...@zusammenkunft.net]
Sent: Friday, December 19, 2014 5:48 PM
To: dev@commons.apache.org
Subject: [vfs] next release
Hello,
sorry for coming back to this topic, but I did not really received any
oppinions or help on it, and I really want to do a release.
I would like to release the VFS trunk as 2.1, because it contains a lot
of bug fixes and is asked for by people. If we decide to release it as
3.0 (with the
Am Mon, 8 Dec 2014 21:52:45 +0100
schrieb Bernd Eckenfels :
> I plan to commit changes to a lot of resources to remove some of the
> checkstyle and other bugcheck reports in preparation of 2.1.
I have commited this, there are some checkstyle warnings left. Some
Javadoc (I plan to address next). S
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=38963&projectId=129
Build statistics:
State: Failed
Previous State: Ok
Started at: Wed 17 Dec 2014 22:21:08 +
Finished at: Wed 17 Dec 2014 22:21:34 +
Total time: 25s
Build Trigger: Schedule
Dec 4, 2014 at 9:41 AM
Subject: Fwd: [VFS] VFS sandbox?
To: Commons Developers List
Hi all
I was trying to follow Gary's advice (and thank you again, Gary) but I ran
into two issues when trying to build the classes
On SmbFileObject
line 46: extends AbstractFileObject
AbstractFileObj
On Mon, Dec 8, 2014 at 4:32 PM, Bernd Eckenfels
wrote:
> Am Mon, 8 Dec 2014 16:26:55 -0500
> schrieb Gary Gregory :
>
> > I also think we should change the { } style to keeping { at the end
> > of a line instead of on a line by itself. This would probably cause a
> > lot of changes which some fol
701 - 800 of 2214 matches
Mail list logo
