[GitHub] commons-text issue #49: TEXT-89: UTF-32 support for WordUtils.initials using...

[ecki]

Github user ecki commented on the issue:

https://github.com/apache/commons-text/pull/49
  
Not sure I understand the question, surrogate Pairs only exist in UTF-16. 
UTF-8 uses a multi byte encoding for code points outside the BMP and UTF-32 
uses 4 bytes (and skips the high/low surrogate regions)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text issue #49: TEXT-89: UTF-32 support for WordUtils.initials using...

[ecki]

Github user ecki commented on the issue:

https://github.com/apache/commons-text/pull/49
  
It does not provide support for UTF-32 (which is a 4 byte encoding not 
implemented in the patch) but it provides support for UTF-16 surrogate pairs 
(1..2 x 2bytes). The both encodings are not compatible.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text issue #49: TEXT-89: UTF-32 support for WordUtils.initials using...

[ecki]

Github user ecki commented on the issue:

https://github.com/apache/commons-text/pull/49
  
It still uses missleading UTF-32


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text issue #49: TEXT-89: UTF-32 support for WordUtils.initials

[ecki]

Github user ecki commented on the issue:

https://github.com/apache/commons-text/pull/49
  
I think using UTF-32 to describe UTF-16 with surrogate pairs is a bit 
misleading. So I would adjust subject and comment, as this does not enable 
fixed-4-byte characters.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-fileupload issue #6: improve GC by avoiding FileInput/Output-Streams

[ecki]

Github user ecki commented on the issue:

https://github.com/apache/commons-fileupload/pull/6
  
Note that this might improve slightly the finalizer pressure however 
FileChannel(InputStreams) have pretty much internal overheads including locks 
and synchronized, so the actual performance might regress badly.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-io pull request #33: [IO-531] JavaDoc to describe accept-any file fi...

[ecki]

GitHub user ecki opened a pull request:

https://github.com/apache/commons-io/pull/33

[IO-531] JavaDoc to describe accept-any file filter



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ecki/commons-io patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-io/pull/33.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #33


commit 118d673fd7f8ac9bc9e342c0a3bbea05236e4b83
Author: Bernd <be...@eckenfels.net>
Date:   2017-04-20T20:05:48Z

[IO-531] JavaDoc to describe accept-any file filter




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

AW: [compress] Added in-memory support for zip and 7z

[ecki]

Hello,

Even when a stream is not thread safe I try at least to make close() 
safe/atomic as aborts and finalizers or shutdown hooks are natural sources for 
concurrency – all using close().

Using a AtomicBoolean or flag is good for that.

(However I guess it is less problematic for memory resources)


Gruss
Bernd
-- 
http://bernd.eckenfels.net
>From Win 10 Mobile

Von: M N
Gesendet: Donnerstag, 20. Oktober 2016 23:11
An: dev@commons.apache.org
Betreff: Re: [compress] Added in-memory support for zip and 7z

Hi Stefan,

I have created tests for SeekableInMemoryByteChannel and spot small error.
Attached is a patch with tests and proposed fix.

Regarding thread safety I think would be more clear to remove volatile and 
document a class as not thread safe.
I think the need for thread safe SeekableInMemoryByteChannel will be a rare 
case.

Cheers,
Maciej

Re: [vfs] Wiki update for Manta VFS provider

[ecki]

Hello Elija,

I can do that for you, let me know the wording and link you want to be included.

Gruss
Bernd
-- 
http://bernd.eckenfels.net
>From Win 10 Mobile

Von: Elijah Zupancic
Gesendet: Montag, 3. Oktober 2016 14:16
An: Commons Developers List
Betreff: [vfs] Wiki update for Manta VFS provider

I just finished writing the first version of a VFS provider for the open
source object store Manta (https://www.joyent.com/manta).

I would like to add a line under "Related Projects" on the VFS Wiki for:
https://github.com/joyent/commons-vfs-manta and I don't have access to make
this change myself.

Is there someone who can do this one line addition for me?

Thanks,
Elijah Zupancic

Re: open source projects that are using SCXML

[ecki]

Hello,

I guess there are some search engines to do that. Versioneye for example can 
show all projects using 0.9 in the maven repo:

https://www.versioneye.com/java/commons-scxml:commons-scxml/references


Gruss
Bernd
-- 
http://bernd.eckenfels.net
>From Win 10 Mobile

Von: Benedikt Ritter

Re: [VOTE][LAZY] Migrate Apache Commons Fileupload to Git

[ecki]

+1 for Git

-- 
http://bernd.eckenfels.net

-Original Message-
From: Jochen Wiedmann 
To: Apache Commons Developers List 
Sent: So., 10 Juli 2016 12:46
Subject: [VOTE][LAZY] Migrate Apache Commons Fileupload to Git

Hello,

I'd like to call a VOTE by LAZY
consensus for migrating the Apache Commons Fileupload component to git. Please
object to this vote if you see a problem with this. Otherwise this vote
will be considered as passed after 72 hours from now (10th June 2016, 09:00
CET)

Thank you,

Jochen


-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

-
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] CI in POM?

[ecki]

Hello,

I will take a look at the failing solaris builds, something in the hadoop test 
cluster does not work there.

Jenkins Karma would be fine, Gary. (e...@apache.org)

Can I sent failed jobs announcement to dev@ or maybe the commit@ list, i think 
we had that for continuum before.

I will check how to get the jenkins-url in the POM, maybe I need to update the 
parent version (it is not currently in the effective pom of vfs)

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: Benedikt Ritter 
To: Commons Developers List 
Sent: Do., 09 Juni 2016 9:20
Subject: Re: [VFS] CI in POM?

Bernd, if you like, Gary can grant you karma for Jenkins.

AFAIK Jenkins has already been added to parent POM.

Benedikt

Gary Gregory  schrieb am Do., 9. Juni 2016 um 01:03:

> On Wed, Jun 8, 2016 at 3:59 PM,  wrote:
>
> > Thanks, had found it meanwhile. Should we add Jenkins to the parent POM
> or
> > a more specific section into the project pom?
> >
> > Can anybody with Jenkins Karma reconfigure the Jobs to use minimum Java
> 7,
> > the Jobs fail since that change:
> >
> >  > (latest),label=Ubuntu/431/>
> >
>
> Done and building...
>
> Gary
>
> >
> > Gruss
> > Bernd
> >
> > --
> > http://bernd.eckenfels.net
> >
> > -Original Message-
> > From: Gary Gregory 
> > To: Commons Developers List 
> > Sent: Do., 09 Juni 2016 0:50
> > Subject: Re: [VFS] CI in POM?
> >
> > Continuum has been retired:
> > https://attic.apache.org/projects/continuum.html
> >
> > We need use switch Jenkins:
> > https://builds.apache.org/view/Apache%20Commons/job/commons-vfs-trunk/
> >
> > Gary
> >
> > On Wed, Jun 8, 2016 at 3:35 PM, Bernd Eckenfels 
> > wrote:
> >
> > > Hello,
> > >
> > > continuum-ci.apache.org seems to be gone, or at least it is not
> > > responding right now. In the VFS POM we have a CI section (from the
> > > parent) poiting to this CI.
> > >
> > > Should this be replaced by some other integration server, if yes, where
> > > is the Job currently setup?
> > >
> > > (And I havent found the info on the commons.apache.org site easily,
> > > should we do something about that?)
> > >
> > > I think there is somewhere a Jenkins running (for us?)
> > >
> > > Gruss
> > > Bernd
> > >
> > > -
> > > 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
> > Java Persistence with Hibernate, Second Edition
> > 
> > JUnit in Action, Second Edition 
> > Spring Batch in Action 
> > 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
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> 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] CI in POM?

[ecki]

Thanks, had found it meanwhile. Should we add Jenkins to the parent POM or a 
more specific section into the project pom?

Can anybody with Jenkins Karma reconfigure the Jobs to use minimum Java 7, the 
Jobs fail since that change:



Gruss
Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: Gary Gregory 
To: Commons Developers List 
Sent: Do., 09 Juni 2016 0:50
Subject: Re: [VFS] CI in POM?

Continuum has been retired: https://attic.apache.org/projects/continuum.html

We need use switch Jenkins:
https://builds.apache.org/view/Apache%20Commons/job/commons-vfs-trunk/

Gary

On Wed, Jun 8, 2016 at 3:35 PM, Bernd Eckenfels 
wrote:

> Hello,
>
> continuum-ci.apache.org seems to be gone, or at least it is not
> responding right now. In the VFS POM we have a CI section (from the
> parent) poiting to this CI.
>
> Should this be replaced by some other integration server, if yes, where
> is the Job currently setup?
>
> (And I havent found the info on the commons.apache.org site easily,
> should we do something about that?)
>
> I think there is somewhere a Jenkins running (for us?)
>
> Gruss
> Bernd
>
> -
> 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
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
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: [crypto] Logging dependency

[ecki]

Loggin Infrastructure can be quite complex including formatters, filters, api- 
or file based reconfiguration and so on. It can inckude dynamcally registering 
loggers and stuff. Switching the loggin backend is a (non-functional) major 
work in larger products/systems and app servers.

It would be good if dropping a component using a (newer facade) would not 
require this major change. This works for most older log frameworks or newer 
facades (but as it seems not yet for log4j2?).

But I totally agree if a library can communicate most of its error conditions 
in a synchronous exception it is better to integrate than components who log 
verbosely but dont make the errors available to callers or listeners (Warnings 
however might be a different thing)

Gruss
Bernd
-- 
http://bernd.eckenfels.net

-Original Message-
From: Gary Gregory 
To: Commons Developers List 
Sent: Mi., 08 Juni 2016 0:48
Subject: Re: [crypto] Logging dependency

Log4j 2 provides minimal support for v1 properties file, and its not
documented yet beyond the code itself. Log4j 2 does support the Log4j 1 API
though, which is the most important level of compatibility.

You make it sound like some folks will not adopt a new library and API
because of the format in a properties file or XML file? Wow!

Gary
On Jun 7, 2016 3:41 PM, "Chris Nauroth"  wrote:

> Could you please elaborate on the argument for not logging at all?  As a
> potential user of commons-crypto, I'll be reluctant to use it if it
> doesn't provide adequate diagnostic logging when something goes wrong.
>
> Regarding the choice of Log4J 2, this is also something that could prevent
> uptake.  For better or worse, I need to support applications that
> currently use Log4J 1, and therefore they will have an expectation that
> logging can be tuned through a Log4J 1 log4j.properties or log4j.xml file.
>  I am not aware of any way for Log4J 2 to provide backwards-compatibility
> with Log4J 1 configuration files.
>
> --Chris Nauroth
>
>
>
>
> On 6/7/16, 9:07 AM, "sebb"  wrote:
>
> >On 7 June 2016 at 16:42, Benedikt Ritter  wrote:
> >> Hello Gary,
> >>
> >> Gary Gregory  schrieb am Di., 7. Juni 2016 um
> >> 04:01 Uhr:
> >>
> >>> Hi All:
> >>>
> >>> IMO. if [crypto] is to have a dependency on a logging framework, it
> >>>should
> >>> be Log4j 2, not Commons Logging. Log4j 2 has an API module, which you
> >>>can
> >>> pair with any number of implementations: Log4j's own Core, JUL, SLF4J,
> >>>and
> >>> so on.
> >>>
> >>
> >> I agree, but I'd say a low level component like crypto should not do any
> >> logging at all.
> >>
> >
> >+1 to not logging
> >
> >>>
> >>> Gary
> >>>
> >>> --
> >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> >>> Java Persistence with Hibernate, Second Edition
> >>> 
> >>> JUnit in Action, Second Edition 
> >>> Spring Batch in Action 
> >>> 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
> >
> >
>
>
> -
> 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: [NET] - FtpClient.getStatus(path) does not seem to be working as documented.

[ecki]

According to RFC959 the STAT command can be used with a pathname (and without 
while transfer is ongoing). I think your problem in the sample output is, that 
your FTP command client is not really issuing a STAT command. I would recommand 
you use a raw TCP connection like netcat/telnet to debug the command or at 
least use "QUOTE STAT /filename" if the client supports it.

I think it is rarely used for its actual return code as it is hard to parse but 
it is used as a NOP-like command to keep control connection active or signal 
interactions after file transfers (some servers need that to recognize complete 
transfers).

BTW, I think this is a users-list question.

Bernd
-- 
http://bernd.eckenfels.net

-Original Message-
From: Clark Stuth 
To: "dev@commons.apache.org" 
Sent: Di., 07 Juni 2016 21:53
Subject: [NET] - FtpClient.getStatus(path) does not seem to be working as 
documented.

We think we've identified a mis-documented feature with FTPClient in
commons-net, specifically the getStatus() methods. According to the FTP
protocol, STAT should return server status information. However,
according to the FTPClient documentation
(https://github.com/apache/commons-net/blob/trunk/src/main/java/org/apache/commons/net/ftp/FTPClient.java#L3510),
 the STAT command is used to retrieve remote file listings. As a result,
we are running into an issue with how Spring Framework Integration is
using the FtpClient.getStatus(path) command.

>From our own testing it does not appear that the FTP Server's stat()
command returns a different result when presented with a pathname or
not.  The STAT command primarily seems to return server and connection
status information, not file information.

The following two examples will show the FTP Server Output when
presented with the STAT command against no path, a file that exists, and
an invalid path (file does not exist).
OpenVMS Implementation:
https://raw.githubusercontent.com/clarkstuth/spring-ftp-template-spike/master/status_command_OpenVMS.txt
 
PureFTPD Implementation:
https://raw.githubusercontent.com/clarkstuth/spring-ftp-template-spike/master/status_command_PureFTPD.txt
 

Is it possible we are misinterpreting what this stat command should be
doing?  It appears the FTP protocol functions differently than how this
method is documented.

If the functionality of the STAT command is vendor dependent, would it
be possible to update the documentation to include this?

Thanks,
Clark Stuth, Sean Lally
Carfax Software

-
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: [crypto] On Java 6, really?

[ecki]

Hello,

IBM, SAP and HP also maintain/support Java 6 runtimes for still some time. The 
audience get smaller and we should not restrict developers to use/provide Java 
8 features but if a component team is happy to start a new project with Java 6, 
why not... (especially since there are also Hadoop landscapes stuck with Java 
6).

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: sebb 
To: Commons Developers List 
Sent: Di., 07 Juni 2016 21:27
Subject: Re: [crypto] On Java 6, really?

I have just checked Oracle support for Java 6.

The Support Life for Java 6 has been extended to Dec 2018 [1]
I think this means that there are critical systems that cannot yet be
updated to Java 7+.

This does not mean that we should ensure that all Commons code still
works on Java 6.
But it should be taken into account when evaluating the pros and cons
of requiring a later version.

[1] http://www.oracle.com/technetwork/java/eol-135779.html#extended6

On 7 June 2016 at 20:02, Jochen Wiedmann  wrote:
>> Gary Gregory  wrote on Tue., 7. Juni 2016
>>
>>> Are we really starting a new component on a dead platform like Java 6?
>
>
> You are, of course, right, that the component is more than welcome to
> use another version. OTOH, given our latest experiences: Is this
> really someting, that we should care for? IMO, let the component have,
> whatever they want.
>
> Jochen
>
> -
> 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


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [crypto] Instructions MUST mention running the tests

[ecki]

Hello,

I also make a habit out of using "mvn verify" instead of "mvn package" (for the 
same reason, do never document circumventing potential tests).

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: Gary Gregory 
To: Commons Developers List 
Sent: Di., 07 Juni 2016 4:37
Subject: [crypto] Instructions MUST mention running the tests

Hi All:

When I see instructions in BUILDING.txt like:

Create binary distribution:

  $ mvn package -DskipTests

I am worried!

Why would you NOT want to run unit tests? Skipping tests from Maven is a
hack when you know what you are doing. Like when I just ran the tests, all
passed, and I changed something that is not Java source.

IMO, we need better build instructions.

I've added steps for RAT and Clirr, a must for any Maven component here.

Thank you,
Gary
-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
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: [ALL] About binary compatibility

[ecki]

Hello,

Unhappy with it but agreeing that your definition sounds like it should apply.

I would vote for always bumping at least the minor version when requiring newer 
dependencies (including Java Version). Strictly speaking semver would require a 
major version but with our policy of using new package names for major versions 
that would annoy lots of users.

And we really really need to avoid VFS-style release congestions (because 
backporting becomes prohibitively painful).

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: Benedikt Ritter 
To: Commons Developers List 
Sent: Do., 02 Juni 2016 22:43
Subject: [ALL] About binary compatibility

Hi,

we do seem to have different opinions when it comes to binary compatibility
and how it should be handled. Usually we would say "this should be decided
on a component basis". However this discussion is coming up again and again
and I think we should try the impossible and agree on something that we can
document.

So here is my view on the topic:

- since our components are depended upon by a lot of projects, we need to
take special care regarding compatibility.
- we must not break BC in a release that could collide with an earlier
version. In other words, when we break BC, we have to change package and
maven coordinates.
- BUT since we're all doing this on our spare time, there is no need to
hold on old APIs just for the sake of it. For this reason, BC may be broken
any time, if the steps above a followed and it has been discussed on the
ML. Fixes can always be backported to old releases, by people who need it.
- If there are committers who are willing to work on old version and
committers who want to work on API redesigns, we can branch and work in
paralell.
- Changing the Java Language requirement does not break BC and can
therefore be done without pumping the major version.

What is your view on the topic?

Benedikt

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[Vfs] to git (was: Apache Commons git repositories now writable for all ASF committers)

[ecki]

I would nominate VFS to move to git, the question is do we keep want to do that 
one by one?

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: Gary Gregory 
To: Commons Developers List 
Cc: annou...@apache.org, Commons Users List 
Sent: Di., 24 Mai 2016 22:36
Subject: Re: [ANNOUNCE] Apache Commons git repositories now writable for all 
ASF committers

The more this goes on the more I wish we'd switch all Commons components to
git lock stock and two smoking barrels.

Gary
On May 24, 2016 12:43 PM,  wrote:

> Hello Jochen,
>
> I think the announcement is refering to the Apache hosted Git (writeable)
> repositories (https://git-wip-us.apache.org/) - not the apache
> organisation on github or the public git mirror (https://git.apache.org).
> Those are always read-only mirrors. (Note that most commons projects are
> still in SVN, which means there is no writeable git master repo for them
> either)
>
> Gruss
> Bernd
>
> --
> http://bernd.eckenfels.net
>
> -Original Message-
> From: Jochen Wiedmann 
> To: Commons Developers List 
> Cc: Commons Users List , "annou...@apache.org" <
> annou...@apache.org>
> Sent: Di., 24 Mai 2016 12:24
> Subject: Re: [ANNOUNCE] Apache Commons git repositories now writable for
> all ASF committers
>
> On Sat, May 21, 2016 at 5:13 PM, Benedikt Ritter 
> wrote:
> > Hello,
> >
> > a while back, the Apache Commons project decided to grant write access to
> > all ASF committers [1]. While setting this up for our SVN repositories
> was
> > easy, we had some problems to grant the necessary karma to all ASF
> > committers for our git repositories. This problem has now been fixed [2].
> > All ASF committers should now be able to commit to our git repositories
> as
> > well. This includes the repositories of the following components:
> >
> > - Apache Commons Lang
> > - Apache Commons Math
> > - Apache Commons Compress
> > - Apache Commons SCXML
> >
> > If you experience any issues, please report them on
> dev@commons.apache.org.
> >
> > Have fun,
> > Benedikt, on behalf of the Apache Commons community
> >
> > [1] https://s.apache.org/RKWl
> > [2] https://issues.apache.org/jira/browse/INFRA-10636
>
> Doesn't work for my Github User (jochenw):
>
> $ git push
> Username for 'https://github.com':
> Password for 'https://joch...@github.com':
> remote: Permission to apache/commons-fileupload.git denied to jochenw.
> fatal: unable to access
> 'https://github.com/apache/commons-fileupload.git/': The requested URL
> returned error: 403
>
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> -
> 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
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ANNOUNCE] Apache Commons git repositories now writable for all ASF committers

[ecki]

Hello Jochen,

I think the announcement is refering to the Apache hosted Git (writeable) 
repositories (https://git-wip-us.apache.org/) - not the apache organisation on 
github or the public git mirror (https://git.apache.org). Those are always 
read-only mirrors. (Note that most commons projects are still in SVN, which 
means there is no writeable git master repo for them either)

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: Jochen Wiedmann 
To: Commons Developers List 
Cc: Commons Users List , "annou...@apache.org" 

Sent: Di., 24 Mai 2016 12:24
Subject: Re: [ANNOUNCE] Apache Commons git repositories now writable for all 
ASF committers

On Sat, May 21, 2016 at 5:13 PM, Benedikt Ritter  wrote:
> Hello,
>
> a while back, the Apache Commons project decided to grant write access to
> all ASF committers [1]. While setting this up for our SVN repositories was
> easy, we had some problems to grant the necessary karma to all ASF
> committers for our git repositories. This problem has now been fixed [2].
> All ASF committers should now be able to commit to our git repositories as
> well. This includes the repositories of the following components:
>
> - Apache Commons Lang
> - Apache Commons Math
> - Apache Commons Compress
> - Apache Commons SCXML
>
> If you experience any issues, please report them on dev@commons.apache.org.
>
> Have fun,
> Benedikt, on behalf of the Apache Commons community
>
> [1] https://s.apache.org/RKWl
> [2] https://issues.apache.org/jira/browse/INFRA-10636

Doesn't work for my Github User (jochenw):

$ git push
Username for 'https://github.com':
Password for 'https://joch...@github.com':
remote: Permission to apache/commons-fileupload.git denied to jochenw.
fatal: unable to access
'https://github.com/apache/commons-fileupload.git/': The requested URL
returned error: 403


-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

-
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

[Rdf] Re: Nexus: Promotion Completed

[ecki]

Hello,

It would be good if Incubator "releases" would be announced here on the 
development list. I havent been aware of all the (excellent) work going on in 
the commons-rdf sub project until I saw this release. The Incubator site and 
the maven artifacts are all fully commons branded already, so it is good to 
keep us in the loop.

(Besides I wonder why Incubator has not its own maven repo)

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: Nexus Repository Manager 
To: comm...@commons.apache.org
Sent: Di., 24 Mai 2016 8:54
Subject: Nexus: Promotion Completed

Message from: https://repository.apache.org

Description:

released commonsrdf 0.2.0-incubating based on RC3



Deployer properties:
"userAgent" = "Apache-Maven/3.3.3 (Java 1.8.0_66-internal; Linux 
4.2.0-35-generic), Apache-Maven/3.3.3 (Java 1.8.0_66-internal; Linux 
4.2.0-35-generic)""userId" = "wikier""ip" = "216.123.155.195"
Details:

The following artifacts have been promoted to the "Releases" [id=releases] 
repository

/org/apache/commons/commons-rdf-simple/0.2.0-incubating/commons-rdf-simple-0.2.0-incubating-sources.jar.asc
(SHA1: a6550c5385210182371cda56dee7bebe438250fe)
/org/apache/commons/commons-rdf-simple/0.2.0-incubating/commons-rdf-simple-0.2.0-incubating.jar
(SHA1: 4151ca8abd36fc365ee89be8f87f6b71d24e41a6)
/org/apache/commons/commons-rdf-simple/0.2.0-incubating/commons-rdf-simple-0.2.0-incubating-test-sources.jar.asc
(SHA1: 0a8b9f011862819cd0f410e657c6da74cccbef67)
/org/apache/commons/commons-rdf-simple/0.2.0-incubating/commons-rdf-simple-0.2.0-incubating-javadoc.jar
(SHA1: 8f46bbf06c80f7cf2180f3542605af9c3bf357a2)
/org/apache/commons/commons-rdf-simple/0.2.0-incubating/commons-rdf-simple-0.2.0-incubating.jar.asc
(SHA1: 87b2aa6b0801c6639f4ec741d11be37a909d9536)
/org/apache/commons/commons-rdf-simple/0.2.0-incubating/commons-rdf-simple-0.2.0-incubating-tests.jar.asc
(SHA1: b2c5d30d145e4e69ec4d78bbb947e71f3f1485e4)
/org/apache/commons/commons-rdf-simple/0.2.0-incubating/commons-rdf-simple-0.2.0-incubating.pom
(SHA1: b81dc3dfed34b037db78cbaac2e8da28cf4a3c2e)
/org/apache/commons/commons-rdf-simple/0.2.0-incubating/commons-rdf-simple-0.2.0-incubating-tests.jar
(SHA1: 7e45e96e2c394d9fd2064a4450e32da4405fa273)
/org/apache/commons/commons-rdf-simple/0.2.0-incubating/commons-rdf-simple-0.2.0-incubating-javadoc.jar.asc
(SHA1: 9db2aa23d2bfc403edff715cfcd77a613b3093f0)
/org/apache/commons/commons-rdf-simple/0.2.0-incubating/commons-rdf-simple-0.2.0-incubating-sources.jar
(SHA1: 818594bd8f9d1762c1c193ab558f6ae1589cc2ad)
/org/apache/commons/commons-rdf-simple/0.2.0-incubating/commons-rdf-simple-0.2.0-incubating.pom.asc
(SHA1: dd4d327082080702bddc99553c479d403bb19aed)
/org/apache/commons/commons-rdf-simple/0.2.0-incubating/commons-rdf-simple-0.2.0-incubating-test-sources.jar
(SHA1: cb37606d40817aa66ea057d61d457d79b081)
/org/apache/commons/commons-rdf-parent/0.2.0-incubating/commons-rdf-parent-0.2.0-incubating-site.xml.asc
(SHA1: b06161c3a677ad9da7f3562ac484cb702b9b0fc6)
/org/apache/commons/commons-rdf-parent/0.2.0-incubating/commons-rdf-parent-0.2.0-incubating-src.tar.gz.asc
(SHA1: a3bdbf6657bfae08c3b1cd53fb2466271f4dd0f7)
/org/apache/commons/commons-rdf-parent/0.2.0-incubating/commons-rdf-parent-0.2.0-incubating-source-release.zip.asc
(SHA1: 6b0b944f98cd4f52f28960cfabc0f70338adc12e)
/org/apache/commons/commons-rdf-parent/0.2.0-incubating/commons-rdf-parent-0.2.0-incubating-source-release.zip
(SHA1: e4099bea9fce075e12dc0ace597f236ca1dedf68)
/org/apache/commons/commons-rdf-parent/0.2.0-incubating/commons-rdf-parent-0.2.0-incubating.pom.asc
(SHA1: 03799b4b13a8291498afe043c40e08eb88d24bde)
/org/apache/commons/commons-rdf-parent/0.2.0-incubating/commons-rdf-parent-0.2.0-incubating.pom
(SHA1: da2260f72cfeeea44f36c34e58c6cb7f8112e951)
/org/apache/commons/commons-rdf-parent/0.2.0-incubating/commons-rdf-parent-0.2.0-incubating-src.tar.gz
(SHA1: a466076c9bbadec9530bc03bc6ef8bc4b0466e8b)
/org/apache/commons/commons-rdf-parent/0.2.0-incubating/commons-rdf-parent-0.2.0-incubating-site.xml
(SHA1: b669567cdb26b4af9802be63c0f20e0cd957df28)
/org/apache/commons/commons-rdf-parent/0.2.0-incubating/commons-rdf-parent-0.2.0-incubating-src.zip.asc
(SHA1: d8f2c172b6375623d26e2485e998762622809395)
/org/apache/commons/commons-rdf-parent/0.2.0-incubating/commons-rdf-parent-0.2.0-incubating-src.zip
(SHA1: 282bec1a5cf0397d9e17ea5d2b5e59e99bf3830e)
/org/apache/commons/commons-rdf-api/0.2.0-incubating/commons-rdf-api-0.2.0-incubating-test-sources.jar
(SHA1: 2fa49f0f13b804f9ed9f2043140948aaa5493676)
/org/apache/commons/commons-rdf-api/0.2.0-incubating/commons-rdf-api-0.2.0-incubating-sources.jar
(SHA1: e43203a8f6eb34332c42f41d93bd300056a7b2be)
/org/apache/commons/commons-rdf-api/0.2.0-incubating/commons-rdf-api-0.2.0-incubating-javadoc.jar
(SHA1: ba30badaf7152cc501af5036465f3b26fc021e97)
/org/apache/commons/commons-rdf-api/0.2.0-incubating/commons-rdf-api-0.2.0-incubating.pom
(SHA1: 

Re: [VFS] Final steps for 2.1

[ecki]

Hello,

I understand the dist module as preparing the artifacts for the binary and 
source distribution of the ASF download. And I agree that those target files 
must not be attached to the maven repository. As such the POM can be changed to 
a POM only module (or manually removed from the repo). In that case the 
artifact names can be consistently created. Creating the checksum files in this 
case would be good.

The actual core artifact (and its related src and javadoc archives) in the 
maven repo are for consumption (by Maven and IDEs). They are different from the 
-bin and -src artifacts distributed by the download servers.

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: Josh Elser 
To: Commons Developers List 
Sent: Di., 24 Mai 2016 4:20
Subject: Re: [VFS] Final steps for 2.1

sebb wrote:
> On 22 May 2016 at 03:54, Josh Elser  wrote:
>> >  It's not a problem, it's an inconvenience.
>> >
>> >  Ideally, Maven builds the artifacts with the intended names. This creates
>> >  consistency through every VOTE message, xsum/sig verification automation,
>> >  website links, and dist.a.o files.
>
> Does not follow, see below.
>
>> >  Renaming them by hand just makes things harder, IMO.
>
> The vote mail should be on the dist/dev archives for the archives
> intended for the ASF mirrors and on Nexus for the Maven jars.
> The distribution files don't belong in Maven Central and they should
> be copied/deleted from Nexus to dist/dev before the vote.
>
> So there should be no inconsistency.
>
> The only extra  manual stage is the rename which must be done before
> the dist/dev files are committed.
>
> I agree it would be simpler if no rename was involved.
> But it does not affect vote consistency.

Wasn't implying that the VOTE'd artifacts were inconsistent, just the 
files are inconsistently named presently. Sorry for not being more 
specific the first time around. My only point was avoiding the rename at 
various stages in the release process.

I agree with your assessment.

-
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: [eclipse-dev] Notice that Eclipse Platform plans to no longer provide MD5 and SHA1 checksums for Neon (but still SHA512)

[ecki]

Hello,

Fully agree for checksum files no stronger hashes are needed. For the pgp 
signatures we should however avoid md5/sha1. The advantage isnthat this is 
pretty transparent (alg encoded in .asc file). It only breaks for some very old 
invoked pgp binaries. (Theoretically we can add multiple signatures using 
sha1+sha2 but that might break even more pgp implementations anf the 
maven/gnupg-plugin does not support it afaik).

Gruss
Bernd
-- 
http://bernd.eckenfels.net

-Original Message-
From: sebb 
To: Commons Developers List 
Sent: Di., 10 Mai 2016 11:53
Subject: Re: [eclipse-dev] Notice that Eclipse Platform plans to no longer 
provide MD5 and SHA1 checksums for Neon (but still SHA512)

Why bother changing?

Checksums/hashes are only intended for checking that a download has
completed OK.

They don't provide any authentication as anyone can generate them.
AFAICT the strength of the hash has no bearing on its utility.

People should use the sigs instead.

Switching to a stronger hash might give the impression that the hash
is intended for authentication.

Note that any change ought to be run past Infra, because the release
distribution policy might need to be updated.

On 10 May 2016 at 10:30, Benedikt Ritter  wrote:
> Hi Gary,
>
> What changes are required for this? Is this just a setting in
> commons-parent?
>
> Benedikt
>
> Gary Gregory  schrieb am Di., 10. Mai 2016 um
> 02:51 Uhr:
>
>> Should we follow suit?
>>
>> Gary
>>
>> -- Forwarded message --
>> From: David M Williams 
>> Date: Mon, May 9, 2016 at 5:37 PM
>> Subject: [eclipse-dev] Notice that Eclipse Platform plans to no longer
>> provide MD5 and SHA1 checksums for Neon (but still SHA512)
>> To: eclipse-...@eclipse.org, equinox-...@eclipse.org,
>> cross-project-issues-...@eclipse.org
>>
>>
>> The topic of this note is about the downloads and checksums obtained
>> directly from the the Eclipse Project. It does not involve the checksums
>> from the "select a mirror" page -- that is controlled by the Eclipse
>> Foundation -- nor any of the packages downloaded from
>> http://www.eclipse.org/downloads-- also controlled by the Eclipse
>> Foundation.  My intuition is that few "casual users" use our checksums but
>> some adopters or committers might use them in automated scripts or builds.
>>
>> If any of you do get checksums directly from
>> .../eclipse/downloads/drops4//checksum/... then this note is for
>> you.
>>
>> We announced in Luna we would "stop producing MD5 and SHA1 checksums" after
>> Luna's release (*Bug 423714*
>> )... and I am just
>> now getting around to it. Since it has been a long time since that
>> announcement, and since we are late in this cycle, I am cross-posting to 3
>> lists to be sure those that might be impacted will be notified.
>>
>> We will continue to provide SHA512 checksums and I recently decided to also
>> provide SHA256 checksums since SHA256 seems to be popular "in the
>> industry".
>>
>> This RC1 effort is documented in *Bug 454784*
>> . If the removal of
>> the MD5 and SHA1 checksums would unduly burden anyone, please say so in
>> that *Bug 454784* 
>> and
>> we would be happy to accommodate.
>>
>> I will soon be updating our wiki on *How to verify a download*
>> <
>> http://wiki.eclipse.org/Platform-releng/How_to_check_integrity_of_downloads
>> >
>> to contain accurate information for Neon, but wanted to get this notice out
>> now so if you are negatively impacted you would have time to say so.
>>
>> Thank you,
>>
>>
>>
>>
>>
>>
>> ___
>> eclipse-dev mailing list
>> eclipse-...@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> 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


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VFS] WIP specific release instructions

[ecki]

Hello,

BTW: I would use "mvn verify" instead of "mvn package" (I am  not sure what has 
changed for CP40)

(And yes the release plugin and the commons procedure for releases is a match 
in hell ,)

Gruss
Bernd
-- 
http://bernd.eckenfels.net

-Original Message-
From: Josh Elser 
To: Commons Developers List 
Sent: Do., 05 Mai 2016 6:49
Subject: Re: [VFS] WIP specific release instructions



sebb wrote:
> Have a look at the scripts in
>
> http://svn.apache.org/viewvc/commons/scripts/
>
> I used those for VALIDATOR and NET.

Cool. Thanks for sharing. It would be good if the generic commons 
release documents referenced these if they are expected to be re-used by 
other commons projects' RMs.

> On 4 May 2016 at 04:43, Josh Elser  wrote:
>> Here's what I've been doing. The generic instructions are woefully
>> incomplete (before someone chimes in again - no, not just because "VFS is a
>> multi-module project"). I think I have this on point for rc1, so I'm writing
>> it down here before I forget (we can figure out where it *should* go later).
>>
>> rc0 only:
>> # Make the branch
>> $ svn cp trunk branches/VFS-XXX
>> $ cd branches/VFS-XXX
>> # Set the proper versions
>> $ mvn release:prepare
>
> We use a tag not a branch, but perhaps that is what the release plugin does.
> In which case I assume the branch is taken to avoid mangling trunk?

release:prepare doesn't do the tagging (this is what release:perform 
does). All it's really doing are some pre-condition checks and version 
updates. TBQH, I don't have any idea how the maven-release-plugin and 
SVN are remotely useful for the ASF's vote-then-promote process.

That said, it's ok if I don't get it. This is what worked for me and I'm 
happy with it. If there's something obvious I could have done 
differently, great.

>> ---
>>
>> # Or just set it to your JDK6 installation -- this works on OSX
>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.6)
>>
>> # Where ${asf.username} for me is "elserj"
>> $ mvn clean package -Duser.name=${asf.username}
>
> No need to use package if using CP40

What are you using instead of `package` to build the code...

>
>> # Set back to 1.7 because my 1.6 installation has trouble deploying to nexus
>> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.7)
>
> So does mine; in which case use -Pjava-1.6 below.
>
>> $ mvn deploy -Prelease -Duser.name=${asf.username}
>>
>> # This is what could be consolidated via one invocation of `mvn site`
>> $ mvn site:site site:stage
>>
>> # Move back to the root SVN repo
>> $ cd ../..
>> $ svn cp branches/VFS-XXX tags/commons-vfs-project-XXX-rcN
>
> Isn't that what the release plugin does?
>
> You might find
>
> http://svn.apache.org/viewvc/commons/scripts/create_RC_tag.sh
>
> easier to use - it does it all for you without needing to create a
> temporary branch.

Cool. I didn't find these from the generic commons release document.

>> --
>>
>> Things not covered above:
>>
>> * Copying artifacts (tarballs/zips, xsums, and sigs) into
>> dist.a.o/dev/commons/... (building md5/sha1 files)
>> * Closing staging repo in Nexus
>
> That can be done using Nexus2DistDev.sh

Again, great. It would have been good to know about these beforehand.

>
>> --
>>
>> Some things that could still be improved that I didn't fix:
>>
>> * Artifacts in dist/target are renamed when they're installed/deployed, but
>> not in the local directory. Should do a rename of the file on disk so that
>> what is on the RM's computer matches what is in their m2 repo and ASF nexus.
>
> Or ignore the local copies and use Nexus2DistDev.sh which copies the
> bin/src artifacts from Nexus and deploys to dist/dev and can remove
> them from Nexus before closing the staging repo.
>
> AFAIK only the deploy directory (i.e. Nexus) has the hashes.
>
>> * `mvn site` which invokes site:site and site:stage automatically (which
>> would make for a more natural build process -- `mvn deploy` would build the
>> site automatically)
>
> I don't follow that.

`mvn site` is invoking the "site" maven lifecycle phase. "mvn site:site` 
and `mvn site:stage` are invoking executions on the maven-site-plugin. 
These are two distinct kinds of actions. We can configure the 
maven-site-plugin (and/or other necessary tasks) to run at the 'site' 
lifecycle phase for a more 'natural' process.

>
>> Again, for now, this is just for my benefit. When this is all over, I'll try
>> to add this all to the website. Please point out anything wrong/missing.
>> Thanks.
>>
>> - Josh
>>
>> -
>> 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: [VOTE] Apache Commons VFS 2.1 rc1

[ecki]

Hello,

Java 9 is not supported (only 8), for the other problems I am not sure, do you 
consider that an blocker?

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: "Jörg Schaible" 
To: dev@commons.apache.org
Sent: Do., 05 Mai 2016 0:39
Subject: Re: [VOTE] Apache Commons VFS 2.1 rc1

Hi,

I've tried to build the release from the source tarball using my compiler 
zoo.

Passes:
 - Sun JDK 1.6
 - IcedTea/OpenJDK 6
 - Oracle JDK 1.7
 - IcedTea/OpenJDK 7
 - Oracle JDK 1.8

Tests fail with IBM JDKs 1.6 and 1.7, IcedTea/OpenJDK 3 and Java 9:

= %< ==
$ mvn-3.2 -version
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 
2014-12-14T18:29:23+01:00)
Maven home: /usr/share/maven-bin-3.2
Java version: 1.6.0, vendor: IBM Corporation
Java home: /opt/ibm-jdk-bin-1.6.0.9_p2/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix"
= %< ==
Failed tests: 
org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testGetResourcesJARs(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)
  Run 1: PASS
  Run 2: PASS
  Run 3: PASS
  Run 4: PASS
  Run 5: PASS
  Run 6: PASS
  Run 7: PASS
  Run 8: PASS
  Run 9: VfsClassLoaderTests>AbstractProviderTestCase.runTest:218-
>testGetResourcesJARs:154 First resource must refer to nested.jar but was 
jar:file:/opt/ibm-jdk-
bin-1.6.0.9_p2/jre/lib/amd64/default/jclSC160/vm.jar!/META-INF/MANIFEST.MF
  Run 10: PASS
  Run 11: PASS
  Run 12: PASS
  Run 13: PASS
  Run 14: PASS
  Run 15: PASS
  Run 16: PASS
  Run 17: PASS
  Run 18: PASS
  Run 19: PASS
  Run 20: PASS
  Run 21: PASS
  Run 22: PASS
  Run 23: PASS
  Run 24: PASS
  Run 25: PASS
= %< ==
$ mvn -version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-10T17:41:47+01:00)
Maven home: /usr/share/maven-bin-3.3
Java version: 1.7.0, vendor: IBM Corporation
Java home: /opt/ibm-jdk-bin-1.7.0.5/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix"
= %< ==
Failed tests: 
org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testGetResourcesJARs(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)
  Run 1: PASS
  Run 2: PASS
  Run 3: PASS
  Run 4: PASS
  Run 5: PASS
  Run 6: PASS
  Run 7: PASS
  Run 8: PASS
  Run 9: VfsClassLoaderTests>AbstractProviderTestCase.runTest:218-
>testGetResourcesJARs:154 First resource must refer to nested.jar but was 
jar:file:/opt/ibm-jdk-
bin-1.7.0.5/jre/lib/amd64/compressedrefs/jclSC170/vm.jar!/META-
INF/MANIFEST.MF
  Run 10: PASS
  Run 11: PASS
  Run 12: PASS
  Run 13: PASS
  Run 14: PASS
  Run 15: PASS
  Run 16: PASS
  Run 17: PASS
  Run 18: PASS
  Run 19: PASS
  Run 20: PASS
  Run 21: PASS
  Run 22: PASS
  Run 23: PASS
  Run 24: PASS
  Run 25: PASS
= %< ==
$ mvn -version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-10T17:41:47+01:00)
Maven home: /usr/share/maven-bin-3.3
Java version: 1.8.0_77, vendor: Oracle Corporation
Java home: /opt/icedtea-bin-3.0.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix"
= %< ==
Tests in error: 
  GetContentInfoFunctionalTest.testGoogle:76 » FileSystem Unknown message 
with code "java.lang.RuntimeException: 
java.security.NoSuchAlgorithmException: EC AlgorithmParameters not 
available".
at 
org.apache.commons.vfs2.provider.http.HttpFileContentInfoFactory.create(HttpFileContentInfoFactory.java:51)
at 
org.apache.commons.vfs2.provider.DefaultFileContent.getContentInfo(DefaultFileContent.java:806)
at 
org.apache.commons.vfs2.provider.https.test.GetContentInfoFunctionalTest.testGoogle(GetContentInfoFunctionalTest.java:76)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at 

Re: [VOTE] Apache Commons-VFS2 2.1 rc0

[ecki]

Hello,

Agree, the sandbox profile should be in the site build enabled, but we cannot 
distribute the binaries as official release since it has dependencies which are 
not Apache approved (and potentially unfinished suff).

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: Josh Elser 
To: Commons Developers List 
Sent: Di., 03 Mai 2016 2:33
Subject: Re: [VOTE] Apache Commons-VFS2 2.1 rc0

I had just tried to make sure it was included in the build because I 
assumed that it was meant to be released :)

It's becoming apparent that was inaccurate.

Ralph Goers wrote:
> As I recall 2.0 did not really include sandbox as part of the release because 
> we didn’t want to officially support the sandbox components. They might have 
> been included in the source distribution though. But these emails make it 
> sound like it is exactly the opposite of what I would have expected.
>
> Ralph
>
>> On May 2, 2016, at 6:35 AM, Josh Elser  wrote:
>>
>> sebb wrote:
>>> The "Download and Build" page is more suitable for developers than end
>>> users (especially if it points to trunk, which is not voted on) so
>>> should not be the primary download page.
>>>
>>> Also there seem to be two identical copies of each of the non-Maven
>>> release artifacts:
>>> commons-vfs-2.1-bin
>>> and
>>> commons-vfs2-distribution-2.1-bin
>>>
>>> etc.
>>>
>>>
>>> Are they supposed to be the same? If not what is missing from one of them?
>> I have no idea. This is just what your build process did...
>>
>> -
>> 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
>

-
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] 2.1 clirr report

[ecki]

Hello,

I will/would vote for releasing 2.1 even when there are some minor problems (if 
it is well documented). Because I do see a large number of bugs for 2.0 and 
those users wont easily profit from a 3.0 (and I dont think backporting or 
removing of all incompatibilities will happen).

Having said that I do have a 2.0 provider which runs fine with 2.1 (source and 
binary).

Maybe some of the clirr violations could be addressed to keep the changes 
strictly on the spi side.

It should not stop us from also releasing a 3.0 shortly afterwards. (Personally 
I would however more work on the 2.x branch as I have the api packages in a 
product where i cannot ask customers to upgrade (but I can ask them to not use 
the incompat classes).

Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: Josh Elser 
To: Commons Developers List 
Sent: Sa., 30 Apr. 2016 0:11
Subject: Re: [VFS] 2.1 clirr report

Hah, thanks for the details, Ralph. I will be sure to bring myself up to 
speed.

That being said: I would still like to get some consensus from those who 
will be voting from the PMC on what should be done, given the current 
report (since my opinion and thus vote are non-binding :D)

http://home.apache.org/~elserj/commons-vfs/commons-vfs-2.1-site/

Ralph Goers wrote:
> FWIW, these discussions are not new.  You might enjoy reading these threads - 
> http://www.mail-archive.com/user@commons.apache.org/msg03711.html. But maybe 
> not! ;-)
>
> Ralph
>
>
>> On Apr 29, 2016, at 12:43 PM, Ralph Goers  wrote:
>>
>>> On Apr 29, 2016, at 10:57 AM, Josh Elser  wrote:
>>>
>>>
>>>
>>> Ralph Goers wrote:
> On Apr 29, 2016, at 9:27 AM, Josh Elser   wrote:
>
> sebb wrote:
>> On 29 April 2016 at 16:19, Josh Elserwrote:
>>> sebb wrote:
 On 29 April 2016 at 15:59, Josh Elser wrote:
>> How does changing the package name help? Doesn't that just push a
>> NoClassDefFound error instead of some missing implementation for a 
>> new
>> method?
 That means we change ALL the package names and the Maven coords.
 Effectively it's a different component, and users have to change the
 import package names.
>>> How is that at all improving *any* level of compatibility? I really 
>>> don't
>>> see how that is providing any service to your users. Now, instead of 
>>> just
>>> updating the version for the artifact and adding the new methods, they
>>> *also* have to change the package...
>> It's not about compatibility, it's about avoiding jar hell.
> Hold up now. We were talking about compatibility. I also don't know 
> specifically what you mean by "jar hell", but it sounds like this is not 
> relevant to the source/binary compatibility discussion (and thus not 
> relevant to this thread). Please correct me if I'm wrong.
 If a user of VFS drops in the new jar in place of the old one and their 
 application gets runtime errors then, by definition, binary compatibility 
 is broken.  This can happen if the user implemented their own FileSystem 
 and are using interfaces that have had new methods added. It can happen if 
 public methods have had signatures change.  If any of these happen then 
 Commons policy is that the package names must change and the artifact id 
 must change, as the jar is no longer compatible with the old one.  This 
 allows the old jar and the new jar to be used side-by-side.
>>> Ok. Can you point me at this documentation? Apparently the issues I take 
>>> with this are more engrained into all of Commons :)
>> I would have to search the dev mailing list but this has been discussed in 
>> the past.  The first link below discusses the versioning policy but does not 
>> explicitly call out changing the package name and artifactid. The second two 
>> links are example of release announcements for incompatible releases.
>>
>> https://commons.apache.org/releases/versioning.html
>>   
>> >
>> http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html
>>   
>> >
>> https://commons.apache.org/proper/commons-collections/release_4_0.html
>>   
>> 

Re: [VFS] 2.1 Release Plan

[ecki]

The components have been updated multiple times. The more we modernize it 
(including new java version) the less useful the release will be as a drop-in 
replacement for 2.0. I had the impression some bug reporters would like that. 
(Just for the record I wondered about having an additional a 2.0.1. Branch but 
I doubt we find resources for that painful task). It would allow us to release 
3.0 (with java 8)...

If we try to stick to 2.1 I would not do (more) dependency upgrades and Java 7 
later (having said that we already switched to java 6 but that offers way more 
important features than we wohld use in 7 (what java 7 feature you would want 
to use?)

But I am fine with both 

-- 
http://bernd.eckenfels.net

-Original Message-
From: Gary Gregory 
To: Commons Developers List 
Cc: Josh Elser 
Sent: Fr., 29 Apr. 2016 0:16
Subject: Re: [VFS] 2.1 Release Plan

Why don't we bring [vfs] 2.1 from Java 6 to 7 and update 3rd party
components?

Gary

On Tue, Apr 26, 2016 at 12:36 PM, Gary Gregory 
wrote:

> Yes, there is a BC breakage for providers, is that grounds for a package
> and Maven coordinate rename to vfs3?
>
> Gary
>
> On Tue, Apr 26, 2016 at 12:31 PM, Bernd Eckenfels 
> wrote:
>
>> Hello Josh,
>>
>> I think a VFS 2.1 release would be cool and it is good that you
>> volunteer, so I dont object. My latest todo list is here:
>>
>> https://wiki.apache.org/commons/VfsReleaseState
>>
>> As you can see, I did plan to do the release and did quite some work to
>> get VFS into a releaseable state. But I am quite happy that you want to
>> step in as I havent had the time to do the procedure yet.
>>
>> And this is not the actual release procedure (which should be doable as
>> long as you do not try to use the release-plugin and be careful about
>> the multi-module+sandbox nature of VFS (as opposed to other commons
>> projects)). Also be carefull about branch and tag namings (the SVN is a
>> bit messy in this regard).
>>
>> My main concern I am afraid I would not have enough capacity is because
>> of the Clirr report and a lot of partially incompatible changes. Most
>> of them only affect providers if they do not properly use abstract base
>> classes, but still the list of Clirr violations is long and developers
>> here have not yet voiced if they would accept a RC with this situation
>> (or not).
>>
>> Anyway, I do agree that the current critical and blocker bugs are
>> important but should not stop the 2.1 release (especially if a 2.1.1
>> release aferwards is much faster to do.) It would be cool to have
>> VFS-570 (write suport for VFS, but even that could be delivered with
>> 2.1.1 - it might annoy the HDFS folks a bit)
>>
>> So I can help you in case you need me to sponsor some changes (I hope I
>> have enough karma now).
>>
>> We could even make a joined RC1, I am just not sure it wont open a big
>> chunk of additional work.
>>
>> Gruss
>> Bernd
>>
>>  Am Tue, 26 Apr 2016 09:40:01 -0400
>> schrieb Josh Elser :
>>
>> > Thanks Matt and Gary.
>> >
>> > I do recall seeing the asf-wide note that my commit-bit also applies
>> > to commons-*. Thanks for bringing that up. Specifically though, I am
>> > only interested in cutting a release -- if we can get a new release
>> > cut that we can use downstream, that increases the likelihood that I
>> > will have more things to contribute back :)
>> >
>> > I'll pull up the thread in the archives and get back to ya'll with
>> > any questions I have after that.
>> >
>> > - Josh
>> >
>> > Matt Sicker wrote:
>> > > 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 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 performing a
>> > >> release, and I think we just went through this (sorry, I'm in
>> > >> settling in a new house, not much time to dig in the ML archives).
>> > >>
>> > >> Does anyone recall?
>> > >>
>> > >> Gary
>> > >>
>> > >>
>> > >>
>> > >> On Mon, Apr 25, 2016 at 12:06 PM, Josh Elser
>> > >> wrote:
>> > >>
>> > >>> Hi all,
>> > >>>
>> > >>> There are presently 171 resolved issues sitting in commons-vfs2
>> > >>> 2.1-SNAPSHOT, with 4 outstanding (none of which look like
>> > >>> blockers to
>> > >> me).
>> > >>> The lack of any release of commons-vfs2 in years has been a big
>> > >>> problem downstream. This past weekend, I was again annoyed by
>> > >>> bugs that have been fixed (but not 

RE: Maintain sub pools within Commons pool - is it possible

[ecki]

Hello,

You can programmatically create and configure pools at runtime. (At least if 
you skip container infrastructures). You can even dynamically register the 
pools in JNDI. I dont think you need sub-pools for this. (Subpools would be 
more interesting for partitioning connections by transaction or session state).

The only problem I see would be to access the dynamic pools from JPA persitence 
declarations, however thats a problem which is nkt really solved with sub-pools 
either.

Gruss
Bernd

PS: i think this part of the discussion is better done on the user mailing list

-- 
http://bernd.eckenfels.net

-Original Message-
From: Krishnakumar Parasuram 
To: dev@commons.apache.org
Sent: Do., 28 Jan. 2016 16:27
Subject: RE: FW: Maintain sub pools within Commons pool - is it possible

Hi Jochen,

 

Thanks for your message.  The difference between to two separate pools is that 
in our framework we don't know exactly how many no of separate pool we might 
require, it is not two, but can scale more than 10, 20 in production 
environment and I think to have so many pools and that to we have to create 
dynamically at runtime, not practical

 

If it was a sub pool, I can always create the sub pool based on demand at 
runtime.  Moreover we have few parameters for each sub pool to maintain a min 
and max connection objects, which parameters can be different for each sub pool 
and cannot be implemented while design as we do not know these value of these 
parameters at design time.

 

Please let me know if this answers your question else let know

 

Regards

Krishnakumar

 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

RE: Maintain sub pools within Commons pool - is it possible

[ecki]

(Ignore my mail, I missed the fact that the initial discussion was about REST 
clients not JdBC)

-- 
http://bernd.eckenfels.net

-Original Message-
From: e...@zusammenkunft.net
To: dev@commons.apache.org
Sent: Fr., 29 Jan. 2016 7:39
Subject: RE: Maintain sub pools within Commons pool - is it possible

Hello,

You can programmatically create and configure pools at runtime. (At least if 
you skip container infrastructures). You can even dynamically register the 
pools in JNDI. I dont think you need sub-pools for this. (Subpools would be 
more interesting for partitioning connections by transaction or session state).

The only problem I see would be to access the dynamic pools from JPA persitence 
declarations, however thats a problem which is nkt really solved with sub-pools 
either.

Gruss
Bernd

PS: i think this part of the discussion is better done on the user mailing list

-- 
http://bernd.eckenfels.net

-Original Message-
From: Krishnakumar Parasuram 
To: dev@commons.apache.org
Sent: Do., 28 Jan. 2016 16:27
Subject: RE: FW: Maintain sub pools within Commons pool - is it possible

Hi Jochen,

 

Thanks for your message.  The difference between to two separate pools is that 
in our framework we don't know exactly how many no of separate pool we might 
require, it is not two, but can scale more than 10, 20 in production 
environment and I think to have so many pools and that to we have to create 
dynamically at runtime, not practical

 

If it was a sub pool, I can always create the sub pool based on demand at 
runtime.  Moreover we have few parameters for each sub pool to maintain a min 
and max connection objects, which parameters can be different for each sub pool 
and cannot be implemented while design as we do not know these value of these 
parameters at design time.

 

Please let me know if this answers your question else let know

 

Regards

Krishnakumar

 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Add 64-bits based RNG (Was: [Math] New base class for all RNGs)

[ecki]

BTW, there are some unsignedLong supporting methods in Java 8, I think some of 
them are even intrinsics, this includes unsigned parsing, printing, comparision 
and division/reminder. I think not yet a modular add.

https://docs.oracle.com/javase/8/docs/api/java/lang/Long.html#remainderUnsigned-long-long-

Gruss
Bernd
-- 
http://bernd.eckenfels.net

-Original Message-
From: Thomas Neidhart 
To: Commons Developers List 
Sent: Mo., 11 Jan. 2016 7:47
Subject: Re: [Math] Add 64-bits based RNG (Was: [Math] New base class for all 
RNGs)

On 01/10/2016 05:09 AM, Gilles wrote:
> Hi.
> 
> Relevant excerpt of previous posts:
> 
>>> [...]
>>>
>>> Something implicit in "BitStreamGenerator": the maximum number of
>>> bits is 32 (cf. return type of "next(int)" and the ubiquitous use
>>> of hard-coded "32".
>>>
>>> What about the possibility of using a "long" as a building block
>>> for another family of RNG?
>>
>> Why?  We don't have contributions of other RNGs implemented using
>> 64-bit blocks of data.  In theory, I guess you could do that, but I
>> don't know of any and all the ones we have use 32-bit words.
>>
>> Phil
>>>
>>> Gilles
> 
> (1)
> CPUs and OS are nowadays commonly 64-bits based.
> Thus one could legitimately wonder whether, on such systems, generating
>   one "long" value
> would not be faster than generating
>   two "int" values,
> especially when 64 bits are necessary in order to produce the next random
> "long" or "double" value.
> 
> (2)
> There indeed exist 64-bits implementations of RNGs:
>  
> http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/VERSIONS/C-LANG/mt19937-64.c
> 
>   http://burtleburtle.net/bob/rand/isaacafa.html
> 
> 
> I thus propose to create a feature branch that will contain
> * a new interface, for when "nextLong()" is the "random bits" producer

be aware that (at least some of) the 64-bit variants rely on unsigned
long arithmetic operations which can't be done in java without losing a
*lot* performance.

Thomas

> * the (adapted) "xorshift1024*" RNG implementation from
> http://xorshift.di.unimi.it/
> * an "adapter" to the existing generic methods
> * benchmarking code
> 
> 
> Gilles
> 
> 
> -
> 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


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [vfs] New Properties for FtpFileSystemConfigBuilder

[ecki]

Hello,

Yes it would be good if you can open a Jira bug. You can then either attach 
your patch as a file attachment or add an URL to the GitHub pull request.

I dont think there will be any point release like 2.0.1 but the next target 
version is 2.1 (based on the current trunk). This is supposed to be more or 
less drop-in compatible (unfortunatelly there arenquite a few changes in the 
long time since the last release so I expect some problems.)

If you use VFS2 somewhere already it would be very helpfull if you actually try 
to replace it with 2.1-SNAPSHOT and report all problems you encountered with 
this step.

I am fine with both variants, a string range is less API clutter but more 
complicated parsing, a typed min/max property is most likely much simpler to 
implement.

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: Roger Membreno 
To: Bernd 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 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, 2015 at 2:16 PM, Roger Membreno 
wrote:

> 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:
>
>> 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 connection projects, and for a recent
>> > project we only able to connect to our FTP site when using Passive
>> > mode.  If we used Active mode we could login to the FTP site but all
>> > files in the directory did not exist and could not be accessed.
>> >
>> > Since our server is behind a firewall with NAT translation we
>> > determined that the data connection could not be established even if
>> > we opened up some ports on the firewall.  We were able to connect to
>> > the FTP site using a stanadalone FTPClient by setting the following
>> > properties to match our NAT security settings:
>> > setReportActiveExternalIPAddress()
>> > client.setActivePortRange()
>> >
>> > With these properties set the PORT command issued by our client to
>> > the FTP site will create a valid data connection.  What I'd like to
>> > do is submit a change via GitHub that does the following:
>> > 1. Add "reportActiveExternalIPAddress" and "activePortRange"
>> > properties to the class
>> > org.apache.commons.vfs2.provider.ftp.FtpFileSystemConfigBuilder 2.
>> > Ehance createConnection in
>> > org.apache.commons.vfs2.provider.ftp.FtpClientFactory to read these
>> > new FtpFileSystemConfigBuilder properties from the config instance
>> > and set them on the FTPClient.
>> >
>> > Let me know if you have any questions.  If you think this is a good
>> > change I'll make a new issue in JIRA for this enhancement.  I also
>> > think that these changes could help resolve VFS-201 (
>> > https://issues.apache.org/jira/browse/VFS-201)
>> >
>>
>>
>
>
> --
> -Thanks,
> Roger
>
>
> *Roger Membreno *| Senior Software Engineer
> Celigo, Inc
>
> O 650.579.0210 x101
> F 650.240.0143
> E roger.membr...@celigo.com
> W www.celigo.comFollow Us 
> 
> 
>   
>
>
>
>
>
>


-- 
-Thanks,
Roger


*Roger Membreno *| Senior Software Engineer
Celigo, Inc

O 650.579.0210 x101
F 650.240.0143
E roger.membr...@celigo.com
W www.celigo.comFollow Us 


  

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Blog post "commons" vulnerability

[ecki]

Hello Sally,

Yes it is just a screenshot of a tweet, I could not come up with a useful 
graohic for the topic and since discussion on Twitter somewhat powered all the 
fuzz I figured it would fit.

Regarding Phils comment I think having some "apache commons" communication on 
blogs does help the bonding with the project, however since the topic is urgend 
I suggest two minor edits

Authors: Bernd Eckenfels and Gary Gregory (Apache Commons Committers)
Title: Widespread Java Object de-serialisation vulnerabilities

(I.e. less formal. Gary I guess you would agree not to mention PMC?)

Gruss
Bernd


-- 
http://bernd.eckenfels.net

-Original Message-
From: Sally Khudairi 
To: "Frohoff, Chris" , Gabriel Lawrence 
, Commons Developers List 
Sent: Mo., 09 Nov. 2015 22:36
Subject: Re: Blog post "commons" vulnerability

Thanks, Chris. I'll include your edits.
Status-wise, I'm uploading the copy to blogs.apache.org. I noticed that the 
"screenshot" referenced at https://twitter.com/gebl/status/662786601425080320 
is simply the tweet status. Is that intentional? Do  you want me to include a 
screenshot of this?
Please forward any additional comments/corrections/additions within the next 
hour if possible. I'd like to get this out before close of business Pacific 
Time if at all possible.
Thanking you in advance,Sally = = = = = vox +1 617 921 8656 off2 +1 646 583 
3362 skype sallykhudairi
  From: "Frohoff, Chris" 
 To: Gabriel Lawrence ; Commons Developers List 
 
Cc: Sally Khudairi  
 Sent: Monday, November 9, 2015 12:31 PM
 Subject: RE: Blog post "commons" vulnerability
   
#yiv5525942083 #yiv5525942083 -- _filtered #yiv5525942083 {panose-1:2 4 5 3 5 4 
6 3 2 4;} _filtered #yiv5525942083 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 
3 2 4;}#yiv5525942083 #yiv5525942083 p.yiv5525942083MsoNormal, #yiv5525942083 
li.yiv5525942083MsoNormal, #yiv5525942083 div.yiv5525942083MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv5525942083 a:link, 
#yiv5525942083 span.yiv5525942083MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv5525942083 a:visited, #yiv5525942083 
span.yiv5525942083MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv5525942083 
span.yiv5525942083hoenzb {}#yiv5525942083 span.yiv5525942083EmailStyle18 
{color:#1F497D;}#yiv5525942083 span.yiv5525942083EmailStyle19 
{color:windowtext;}#yiv5525942083 .yiv5525942083MsoChpDefault {} _filtered 
#yiv5525942083 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv5525942083 
div.yiv5525942083WordSection1 {}#yiv5525942083 Minor grammatical changes and 
comments inline. The main thing I’d suggest is expanding your patch to include 
any Serializable classes that perform reflection for completeness.---
Apache Commons statement to widespread Java object de-serialisation
vulnerability

Authors: Bernd Eckenfels, Gary Grogory for Apache Commons

In their
[talk](http://frohoff.github.io/appseccali-marshalling-pickles/)
"Marshalling Pickles - how deserializing objects will ruin your day" at
AppSecCali2015 Gabriel Lawrence ([@gebl](https://twitter.com/gebl)) and
Chris Frohoff ([@frohoff](https://twitter.com/frohoff)) presented
various security problems when applications accept serialized objects
from untrusted source. A major finding describes a way to execute
arbitrary Java functions and even inject manipulated bytecode when
using Java Object Serialization (as used in some remote communication
and persistence protocols).

Building on Frohoff's tool ( add “ing”)
[ysoserial](https://github.com/frohoff/ysoserial), Stephen Breen
([@breenmachine](https://twitter.com/breenmachine)) of Foxglove
Security inspected various products like WebSphere, JBoss, Jenkins,
WebLogic, and OpenNMS and describes
(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/)
for each of them various attack scenarios.

Both research works show[s] that developers put too much trust in Java  ( 
remove plural)
Object Serialization. Some even de-serialize objects
pre-authentication. When deserializing an Object in Java you typically
cast it to an expected type, and therefore Java's strict type system
will ensure you only get valid object trees. Unfortunately, by the time
the type checking happens, platform code has already created and
executed significant logic. So, before the final type is checked, a lot
of code is executed from the readObject() methods of various objects,
all of which is out of the developer's control. By combining the
readObject() methods of various classes which are available on the
classpath of the vulnerable application an attacker can execute
functions (including calling Runtime.exec() to execute local OS
commands).

The best protection against this, 

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

[ecki]

>> Both sample payloads have "gadget chains" which do start (readObject())
>> in JCL classes and then use pretty generic interfaces like Annotations
>> or Comparators, so there is really no link between the types and the
>> specific weakness.

> I did not see JCL (commons logging?) used in the gadget chains.

JCL = Jaca Class Library (in this case ,)

-- 
http://bernd.eckenfels.net

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VFS] Jackrabbit

[ecki]

Hello,

Unfortunatelly the whole webdav filesystem tests depend on that specific 
version as it wraps the server as an endpoint. The setUp fails so the whole 
test suite will get skipped. I havent been able to quickly fix when I tried to 
bump the dependency (but it is not impossible, as you can 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 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:

junit.framework.AssertionFailedError: Folder does not exist:
webdav://admin@localhost:61279/repository/default/read-tests
 at junit.framework.Assert.fail(Assert.java:57)
 at junit.framework.Assert.assertTrue(Assert.java:22)
 at

org.apache.commons.vfs2.test.AbstractTestSuite.setUp(AbstractTestSuite.java:190)
 at

org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1.setUp(WebdavProviderTestCase.java:284)
 at

org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:148)
 at junit.framework.TestResult.runProtected(TestResult.java:142)
 at

org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:154)
 at

org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
 at

org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
 at

org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
 at

org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
 at

org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
 at

org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
 at

org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
 at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)


-- 
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Proposed Contribution to Apache Commons,

[ecki]

Hello,

I wish the below cited introduction mail which mentioned how ugly RE for email 
addresses is, had actually shown a naomi example. Actually for each critisised 
RE construct.

Besides that, scalability and maintenanceability of regular expressions are an 
old topic: there are for example things like Grok (in logstash) who make things 
modular. I guess showing that naomi can replace that as well would help.

Folklore is interesting, but not something I would use to convince people. I 
read your mail but I dont feel to look up Naomi examples. So until cool syntax 
constructs are presented it might not really get people excited.

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: n...@dad.org
To: Gary Gregory , Dave Brosius 
, Jochen Wiedmann , 
Commons Developers List 
Cc: jeff_rothenb...@acm.org, n...@dad.org
Sent: Sa., 24 Okt. 2015 5:15 PM
Subject: Re: Proposed Contribution to Apache Commons,

My colleague, Jeff Rothenberg, and I are retired computer scientists and are
no strangers to regular expression theory and practice. Both of us have used
regular expressions for decades and have taught many other programmers how to
use them. Stephen Kleene (https://en.wikipedia.org/wiki/Stephen_Cole_Kleene),
the inventor of regular expressions and I
(https://en.wikipedia.org/wiki/Norman_Shapiro) were both doctoral students of
Alonzo Church (https://en.wikipedia.org/wiki/Alonzo_Church). Rothenberg used
SNOBOL3 and SNOBOL4 (more powerful than all but a few of the most recent
versions of regular expressions) extensively in his graduate work in
Artificial Intelligence in the late 1960 and early 1970s.

In our experience, although skilled programmers can write regular expressions
that solve a wide range of problems, for all but the simplest tasks regular
expressions quickly become "write only". That is, once they have aged for a
while, no one other than their authors (and, in our experience, often not even
they) can understand them well enough to verify, modify, debug, or maintain
them without considerable effort. Analogous low-level programming formalisms,
such as machine code and assembly language, have been replaced by
higher-level, more readable and modular languages to produce programs that
have proven easier and more cost-effective to debug, verify, maintain, reuse,
and extend.

In a similar fashion, Naomi is a means of "taming" complex regular
expressions, as well as offering an easier alternative for those who are
unfamiliar with them. Naomi makes pattern matching programs more readable,
modular, and therefore verifiable, maintainable, and extensible. Naomi
ultimately generates regular expressions, and it can do everything they can
do, but it provides a higher-level API that uses object-oriented constructs to
define complex, modular, parameterized patterns and subpatterns.

Naomi's advantages over bare regular expressions become apparent only for
larger scale pattern matching tasks. Whereas regular expressions are highly
compact and terse, this virtue becomes a vice for complex patterns. Coupled
with the extensive use of metacharacters and escape sequences, this makes even
moderately complex regular expressions effectively unreadable for all but the
most experienced and practiced regular expression programmers. Newer features
that go beyond the original regular expression formalism--such as namable
groups, built-in names for common character classes, comments, and free white
space--make regular expressions less terse. But their use is not enough to
render complex regular expressions easily readable. These extensions are
analogous to replacing binary machine language by assembly language coding. It
is only necessary to consider a complex problem--such as that of parsing the
e-mail date-time specification of RFC 2822 in src/DateTime.java--to appreciate
the obscurity of regular expressions and to understand Naomi's advantages.



Norman Shapiro

-
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