Code Donation Inquiry

[Lewis John Mcgibbney]

hi Commons Dev@,
Over in the Crawler Commons project [0] we are discussing the topic of
donating code to TheASF and potentially under the Apache Commons project.
Crawler commons is a Java library which builds and maintains shares
components for crawlers. We have been making pretty regular releases
recently and the code is in a pretty decent state with around 4 active
committers.
I wondered if someone could describe how such efforts have worked
previously. This will hopefully give us a better idea of what is required
to bring the codebase to Apache.
The code is already licensed under ASLv2.0
[0] https://code.google.com/p/crawler-commons/


-- 
*Lewis*

[Commons Wiki] Update of "VfsExampleShell" by BerndEckenfels

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Commons Wiki" for 
change notification.

The "VfsExampleShell" page has been changed by BerndEckenfels:
https://wiki.apache.org/commons/VfsExampleShell?action=diff&rev1=5&rev2=6

Comment:
Thanks to Dave Marion for HDFS example and testing.

  = Commons VFS Example Shell =
  This page shows some examples to configure the classpath and use the VFS 
Example Shell.
  
- All examples expect to be started from within the Apache Commons VFS source 
directory (refering to build artifacts as well as external dependencies in a 
local maven repository). Linux/Unix commands are marked with `$` prompt, for 
sample Windows command you see a `C:vfs>` prompt.
+ All examples expect to be started from within the Apache Commons VFS source 
directory (refering to build artifacts as well as external dependencies in a 
local maven repository). Linux/Unix commands are marked with `$ ` prompt, for 
sample Windows command you see a `C:vfs> ` prompt. Commands entered into the 
VFS Example Shell are marked with the `> ` prompt.
  
  Enabling the SMB provider from the sandbox:
  
@@ -77, +77 @@

  Crawl-Delay: 4
  }}}
  
+ The following example describes how to set up a file in HDFS and how to 
access it with the VFS Example Shell:
+ {{{
+ $ HADOOP_HOME=/home/user/hadoop-2.6.0 
+ $ HADOOP_CLASSPATH=`$HADOOP_HOME/bin/hadoop classpath` 
+ $ $HADOOP_HOME/bin/hadoop fs -mkdir /vfs-test 
+ $ $HADOOP_HOME/bin/hadoop fs -copyFromLocal /tmp/test.txt /vfs-test/text.txt 
+ $ $HADOOP_HOME/bin/hadoop fs -ls -R / 
+ drwxr-xr-x - user supergroup  0 2015-01-09 21:56 /vfs-test 
+ -rw-r--r-- 3 user supergroup 15 2015-01-09 21:56 /vfs-test/text.txt 
+ 
+ $ REP=~/.m2/repository 
+ $ LIBS=$REP/commons-logging/commons-logging/1.2/commons-logging-1.2.jar 
+ $ 
LIBS=$LIBS:core/target/commons-vfs2-2.1-SNAPSHOT.jar:examples/target/commons-vfs2-examples-2.1-SNAPSHOT.jar
+ $ java -cp $LIBS:$HADOOP_CLASSPATH org.apache.commons.vfs2.example.Shell 
+ 15/01/09 22:01:44 INFO impl.StandardFileSystemManager: Using "/tmp/vfs_cache" 
as temporary files store. 
+ VFS Shell 2.1-SNAPSHOT 
+ > info   
+ Default manager: "org.apache.commons.vfs2.impl.StandardFileSystemManager" 
version 2.1-SNAPSHOT 
+ Provider Schemes: [https, res, gz, hdfs, sftp, ftps, ram, http, file, ftp, 
tmp, bz2] 
+ Virtual Schemes: [zip, war, par, ear, jar, sar, ejb3, tar, tbz2, tgz] 
+ > info hdfs   
+ Provider Info for scheme "hdfs": 
+ capabilities: [GET_TYPE, READ_CONTENT, URI, GET_LAST_MODIFIED, ATTRIBUTES, 
RANDOM_ACCESS_READ, DIRECTORY_READ_CONTENT, LIST_CHILDREN] 
+ > ls hdfs://server:8020/vfs-test/   
+ 15/01/09 22:02:06 INFO Configuration.deprecation: fs.default.name is 
deprecated. Instead, use fs.defaultFS 
+ 15/01/09 22:02:06 WARN util.NativeCodeLoader: Unable to load native-hadoop 
library for your platform... using builtin-java classes where applicable 
+ Contents of hdfs://server:8020/vfs-test 
+ text.txt 
+ > cat hdfs://server:8020/vfs-test/text.txt
+ This is a test 
+ }}}
+ 

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

Re: [vfs] PMC: please review sandbox' NOTICE.txt

[Bernd Eckenfels]

Hello,

thanks for the comments Phil.

I have removed the mention of sandbox from the toplevel NOTICE.txt and
the sandbox/NOTICE.txt again.

I am not sure what to put in a readme, but since I already explained
the sandbox situation on the new site, I will not anything besides that:

http://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 mime provider, will see if I can get
help with that.

I have understood that I do not have to improve the situation that a
sandbox artifact could "look" official, so I keep the notice files in
there (just as 2.0 was).

Gruss
Bernd

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

Re: [MATH] Jenkins unit test failure

[Phil Steitz]

On 1/11/15 11:19 AM, Phil Steitz wrote:
> On 1/10/15 10:49 PM, Phil Steitz wrote:
>> On 1/9/15 6:09 PM, sebb wrote:
>>> On 10 January 2015 at 01:01, Phil Steitz  wrote:
 On 1/9/15 5:32 PM, sebb wrote:
> On 9 January 2015 at 23:48, sebb  wrote:
>> Of the last 6 runs, only 1 had a problem with unit test failures.
>>
>> All the builds ran on ubuntu3, apart from the failure which ran on H10.
>> This may have some bearing on the result; I don't yet know.
>>
>> I had a quick look at 2 tests that failed:
>>
>> SimpleRegressionTest.testPerfect
>>
>> SimpleRegressionTest.testPerfectNegative
>>
>> Although the test case has some instance data, these particular tests
>> do not use any, so it does not look like a concurrency issue in the
>> unit test itself.
>>
>> The SimpleRegression class has mutable instance data, but the test
>> cases create their own instance.
>>
>> I don't know anything about the math functions involved, but it looks
>> as though Infinity might result from getSignificance() if
>> getSlopeStdErr() returns 0, as the latter is used as a divisor. Or if
>> the field sumXX is 0 because that is also used as a divisor.
>>
>> Maybe the H10 host has different floating point hardware?
>>
>> I'll try running some more tests on H10.
> the build failed again on H10; exactly the same tests failed as before:
>
> This test:
> https://builds.apache.org/job/Commons%20Math%20H10/1/console
>
> Previous failure:
> https://builds.apache.org/job/Commons%20Math/14/console
 This is actually a bug.  Thanks, sebb (and Jenkins)!

 Has been here since 1.x.  What is going on is that the data sets
 used in the test cases are set up to be perfect linear
 relationships, which should in fact lead to mean square error (and
 hence slope standard error) equal to 0.  The Jenkins box must be
 getting exact 0.  The funny thing is the test is there to validate
 correct performance for models like this.  Its success unfortunately
 depends on poor precision.

 I will open a JIRA for this.  I don't think it is a release blocker
 for 3.4.1, as I am sure you would get the same thing in any earlier
 version of [math].
>>> OK good to know.
>>>
>>> I'll leave the H10 Jenkins job for now to make it easy to retest.
>> My first guess here was wrong.  The infinities are being handled
>> correctly for the JDKs I have.  Something must be going awry in the
>> t distribution cumulative probability computation for +INF on the
>> box that is failing.  Is there a way to find out exactly what JDK
>> and OS version are being used? 
> I just committed a test that tests the t distribution computations
> directly.  It seems to have run clean; but the other test ran clean
> too.  Is there any way to force the build to use the host that fails?

I can't make any sense of what is going on with the Jenkins builds. 
Clean runs and then lots of errors.  This one explains the
SimpleRegression "problem" (which is not a problem with that class
at least)

testCumulativeProbablilityExtremes(org.apache.commons.math3.distribution.TDistributionTest)
  Time elapsed: 0.001 sec  <<< FAILURE!
java.lang.AssertionError: expected:<1.0> but was:<-Infinity>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:494)
at org.junit.Assert.assertEquals(Assert.java:592)
at 
org.apache.commons.math3.distribution.TDistributionTest.testCumulativeProbablilityExtremes(TDistributionTest.java:109)

Earlier runs this ran clean. There is nothing non-deterministic about this test 
(or quite a few of the others that randomly seem to fail).

I wonder if we have a bad cpu or something somewhere.

Phil


>
> Phil
>> Phil
 Phil
> -
> 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

Jenkins build became unstable: Commons Math #22

[Apache Jenkins Server]

See 


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

Re: [RESULT][VOTE][RC1] Release Commons Math 3.4.1

[Thomas Neidhart]

On 01/11/2015 07:38 PM, Luc Maisonobe wrote:
> Le 08/01/2015 20:24, Luc Maisonobe a écrit :
>> This is a [VOTE] for releasing Apache Commons Math 3.4.1 from release
>> candidate 1.
>>
>> Tag name:
>>   MATH_3_4_1_RC1 (signature can be checked from git using 'git tag -v')
>>
>> Tag URL:
>>
>> 
>>
>> Commit ID the tag points at:
>>   ef6e0f882819e7c5230aece1610297e67775cca2
>>
>> Site:
>>   
>>
>> Distribution files:
>>   https://dist.apache.org/repos/dist/dev/commons/math/
>>
>> Distribution files hashes (SHA1):
>> 165244fec72fa874ac5efe2d3b7926ab853e0783 commons-math3-3.4.1-bin.tar.gz
>> 2e9b1df32db85e3bc290d06eda26a01ef5ed6182 commons-math3-3.4.1-bin.zip
>> 5068444e55b27a506183a86b2df071b3868b0104 commons-math3-3.4.1-src.tar.gz
>> 2c4f0742a235a71f9b3cb09dee1946e270055d43 commons-math3-3.4.1-src.zip
>>
>> KEYS file to check signatures:
>>   http://www.apache.org/dist/commons/KEYS
>>
>> Maven artifacts:
>>
>> 
>>
>> [ ] +1 Release it.
>> [ ] +0 Go ahead; I don't care.
>> [ ] -0 There are a few minor glitches: ...
>> [ ] -1 No, do not release it because ...
>>
>> This vote will close in 72 hours, at 2015-01-11T19:30:00Z (this is UTC
>> time).
> 
> This vote passes with binding +1 from Jörg, Luc, Phil and no other votes.
> 
> Thaks to all who reviewed and voted on this release.
> 
> I will push the artifacts.

Sorry, I could not review / vote as I was driving back from vacation but
thanks for your quick effort to release a bugfix release!

Thomas

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

Re: [compress] Finished with my changes

[Stefan Bodewig]

On 2015-01-10, Kristian Rosenvold wrote:

> 2015-01-10 15:29 GMT+01:00 Stefan Bodewig :
>> what about the (unrelated) COMPRESS-290?
> I'll see what I can do. Should be simple compared to the other stuff
> I've been dealing with :)

Just asking whether you intend to do anything about it or whether we
should leave for the moment.

>>  Test coverage of the zip package is better, complexity lower than it
>> has been in 1.9.

> W00t? Did *I* manage to /reduce/ complexity ? Must be someone else :)

:-)

Thanks

Stefan

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

Re: svn commit: r1650632 - in /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip: ZipArchiveEntry.java ZipArchiveOutputStream.java

[Stefan Bodewig]

On 2015-01-09,  wrote:

> @@ -336,20 +338,48 @@ public class ZipArchiveEntry extends jav
>   * @since 1.1
>   */
>  public ZipExtraField[] getExtraFields(boolean includeUnparseable) {
>+return includeUnparseable ?
>+getAllExtraFields() :
>+getParseableExtraFields();
>+}

This is inconsistent WRT copying arrays or returning the internal
structure.  getAllExtraFields will create a copy of extraFields (unless
there has been unparseable data), but getParseableExtraFields() does
not.

I think it would be good to always create copies here, maybe call the
no-arg version of getExtraFields instead of getParseableExtraFields?

Stefan

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

Re: svn commit: r1650930 - /commons/proper/vfs/trunk/NOTICE.txt

[Phil Steitz]

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/trunk/NOTICE.txt
>
> Modified: commons/proper/vfs/trunk/NOTICE.txt
> URL: 
> http://svn.apache.org/viewvc/commons/proper/vfs/trunk/NOTICE.txt?rev=1650930&r1=1650929&r2=1650930&view=diff
> ==
> --- commons/proper/vfs/trunk/NOTICE.txt (original)
> +++ commons/proper/vfs/trunk/NOTICE.txt Sun Jan 11 17:33:44 2015
> @@ -1,6 +1,9 @@
>  Apache Commons VFS
> -Copyright 2002-2014 The Apache Software Foundation
> +Copyright 2002-2015 The Apache Software Foundation
>  
>  This product includes software developed at
>  The Apache Software Foundation (http://www.apache.org/).
>  
> +
> +The Apache Commons VFS Sandbox module is not officially released,
> +see sandbox/NOTICE.txt for details.

Nothing in the sandbox is released.  I would drop this. 

Phil
> \ No newline at end of file
>
>
>


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

[RESULT][VOTE][RC1] Release Commons Math 3.4.1

[Luc Maisonobe]

Le 08/01/2015 20:24, Luc Maisonobe a écrit :
> This is a [VOTE] for releasing Apache Commons Math 3.4.1 from release
> candidate 1.
> 
> Tag name:
>   MATH_3_4_1_RC1 (signature can be checked from git using 'git tag -v')
> 
> Tag URL:
> 
> 
> 
> Commit ID the tag points at:
>   ef6e0f882819e7c5230aece1610297e67775cca2
> 
> Site:
>   
> 
> Distribution files:
>   https://dist.apache.org/repos/dist/dev/commons/math/
> 
> Distribution files hashes (SHA1):
> 165244fec72fa874ac5efe2d3b7926ab853e0783 commons-math3-3.4.1-bin.tar.gz
> 2e9b1df32db85e3bc290d06eda26a01ef5ed6182 commons-math3-3.4.1-bin.zip
> 5068444e55b27a506183a86b2df071b3868b0104 commons-math3-3.4.1-src.tar.gz
> 2c4f0742a235a71f9b3cb09dee1946e270055d43 commons-math3-3.4.1-src.zip
> 
> KEYS file to check signatures:
>   http://www.apache.org/dist/commons/KEYS
> 
> Maven artifacts:
> 
> 
> 
> [ ] +1 Release it.
> [ ] +0 Go ahead; I don't care.
> [ ] -0 There are a few minor glitches: ...
> [ ] -1 No, do not release it because ...
> 
> This vote will close in 72 hours, at 2015-01-11T19:30:00Z (this is UTC
> time).

This vote passes with binding +1 from Jörg, Luc, Phil and no other votes.

Thaks to all who reviewed and voted on this release.

I will push the artifacts.

best regards,
Luc


> 
> -
> 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: [MATH] Jenkins unit test failure

[Phil Steitz]

On 1/10/15 10:49 PM, Phil Steitz wrote:
> On 1/9/15 6:09 PM, sebb wrote:
>> On 10 January 2015 at 01:01, Phil Steitz  wrote:
>>> On 1/9/15 5:32 PM, sebb wrote:
 On 9 January 2015 at 23:48, sebb  wrote:
> Of the last 6 runs, only 1 had a problem with unit test failures.
>
> All the builds ran on ubuntu3, apart from the failure which ran on H10.
> This may have some bearing on the result; I don't yet know.
>
> I had a quick look at 2 tests that failed:
>
> SimpleRegressionTest.testPerfect
>
> SimpleRegressionTest.testPerfectNegative
>
> Although the test case has some instance data, these particular tests
> do not use any, so it does not look like a concurrency issue in the
> unit test itself.
>
> The SimpleRegression class has mutable instance data, but the test
> cases create their own instance.
>
> I don't know anything about the math functions involved, but it looks
> as though Infinity might result from getSignificance() if
> getSlopeStdErr() returns 0, as the latter is used as a divisor. Or if
> the field sumXX is 0 because that is also used as a divisor.
>
> Maybe the H10 host has different floating point hardware?
>
> I'll try running some more tests on H10.
 the build failed again on H10; exactly the same tests failed as before:

 This test:
 https://builds.apache.org/job/Commons%20Math%20H10/1/console

 Previous failure:
 https://builds.apache.org/job/Commons%20Math/14/console
>>> This is actually a bug.  Thanks, sebb (and Jenkins)!
>>>
>>> Has been here since 1.x.  What is going on is that the data sets
>>> used in the test cases are set up to be perfect linear
>>> relationships, which should in fact lead to mean square error (and
>>> hence slope standard error) equal to 0.  The Jenkins box must be
>>> getting exact 0.  The funny thing is the test is there to validate
>>> correct performance for models like this.  Its success unfortunately
>>> depends on poor precision.
>>>
>>> I will open a JIRA for this.  I don't think it is a release blocker
>>> for 3.4.1, as I am sure you would get the same thing in any earlier
>>> version of [math].
>> OK good to know.
>>
>> I'll leave the H10 Jenkins job for now to make it easy to retest.
> My first guess here was wrong.  The infinities are being handled
> correctly for the JDKs I have.  Something must be going awry in the
> t distribution cumulative probability computation for +INF on the
> box that is failing.  Is there a way to find out exactly what JDK
> and OS version are being used? 

I just committed a test that tests the t distribution computations
directly.  It seems to have run clean; but the other test ran clean
too.  Is there any way to force the build to use the host that fails?

Phil
>
> Phil
>>> Phil
 -
 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] PMC: please review sandbox' NOTICE.txt

[Bernd Eckenfels]

Hello,

my main reason is, that currently the build artifacts of sandbox do
contain a notice file which does not contain anything on that issue.

So, I can understand you do not want to have a specific NOTICE file for
sandbox, but in that case I would suggest to not ship the missleading
generic files. Would you prefer that?

My thinking was that if anybody compiles (or finds somewhere a compiled
version) it looks very "official" since it has a apache-commons
groupid, it contains LICENSE.txt and NOTICE.txt and so on. So it would
be a good thing to have this disclaimer.

Gruss
Bernd


 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
> > up-to-date NOTICE file for the artifacts.
> 
> Why, exactly?  We are not releasing / redistributing these things. 
> NOTICE is only for sources we actually distribute.
> >
> > So what I did is I created a seperate file and commited (r1650926)
> > it.
> >
> > Once the PMC aproves, I will also add it to the POM. Currently it
> > ships the parent ../NOTICE.txt which does not mention any of the
> > sandbox restrictions.
> >
> > Please let me know if this is fine with PMC.
> -1
> 
> I don't see the need to do this and don't want what is actually
> released to have pointers to or dependencies on unreleased /
> unreleasable code or artifacts.
> 
> Phil
> >
> > http://svn.apache.org/viewvc/commons/proper/vfs/trunk/sandbox/NOTICE.txt?revision=1650926&view=markup
> >
> >
> > Greetings
> > Bernd
> >
> > -
> > 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] PMC: please review sandbox' NOTICE.txt

[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
> up-to-date NOTICE file for the artifacts.

Why, exactly?  We are not releasing / redistributing these things. 
NOTICE is only for sources we actually distribute.
>
> So what I did is I created a seperate file and commited (r1650926) it.
>
> Once the PMC aproves, I will also add it to the POM. Currently it ships
> the parent ../NOTICE.txt which does not mention any of the sandbox
> restrictions.
>
> Please let me know if this is fine with PMC.
-1

I don't see the need to do this and don't want what is actually
released to have pointers to or dependencies on unreleased /
unreleasable code or artifacts.

Phil
>
> http://svn.apache.org/viewvc/commons/proper/vfs/trunk/sandbox/NOTICE.txt?revision=1650926&view=markup
>
>
> Greetings
> Bernd
>
> -
> 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

[vfs] PMC: please review sandbox' NOTICE.txt

[Bernd Eckenfels]

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 the POM. Currently it ships
the parent ../NOTICE.txt which does not mention any of the sandbox
restrictions.

Please let me know if this is fine with PMC.

http://svn.apache.org/viewvc/commons/proper/vfs/trunk/sandbox/NOTICE.txt?revision=1650926&view=markup


Greetings
Bernd

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

Re: [math] tail probabilites

[Phil Steitz]

On 1/11/15 10:04 AM, Phil Steitz wrote:
> On 1/11/15 9:26 AM, Gilles wrote:
>> On Fri, 09 Jan 2015 10:55:53 -0700, Phil Steitz wrote:
>>> There is a feature request implicit in MATH-1185 - to add direct
>>> computation of (upper) tail probabilities, so users can avoid loss
>>> of significance errors when computing them from cumulative
>>> probabilities, which is the only thing they can do with current
>>> implementations.  In some cases, we can fairly easily provide direct
>>> estimates; in others, not so easy.
>>>
>>> What might make sense would be:
>>>
>>> *  Add an upperTail(x) method to the 4.0 distributions interface
>>> (maybe with a better name)
>>> *  Add default implementation to AbstractXxDistribution (3.x and 4)
>>> that returns naive results
>>> *  Add - and doc - better implementations for individual
>>> distributions as and when we get them
>> +1
>> [Although we could consider throwing an exception instead of
>> returning the naive result. Or one method that would throw
>> and one that would return possibly inaccurate results.]
> Yeah, UnsupportedOperationException might make sense in place of the
> naive implementation.  Would have to be documented carefully if we
> decide to do that.

I guess another idea would be not to add the method to the
interfaces, but just to the distributions that have good
implementations.

Phil
>
> Phil
>>
>> Gilles
>>
>>> Phil
>>
>> -
>> 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: [math] tail probabilites

[Phil Steitz]

On 1/11/15 9:26 AM, Gilles wrote:
> On Fri, 09 Jan 2015 10:55:53 -0700, Phil Steitz wrote:
>> There is a feature request implicit in MATH-1185 - to add direct
>> computation of (upper) tail probabilities, so users can avoid loss
>> of significance errors when computing them from cumulative
>> probabilities, which is the only thing they can do with current
>> implementations.  In some cases, we can fairly easily provide direct
>> estimates; in others, not so easy.
>>
>> What might make sense would be:
>>
>> *  Add an upperTail(x) method to the 4.0 distributions interface
>> (maybe with a better name)
>> *  Add default implementation to AbstractXxDistribution (3.x and 4)
>> that returns naive results
>> *  Add - and doc - better implementations for individual
>> distributions as and when we get them
>
> +1
> [Although we could consider throwing an exception instead of
> returning the naive result. Or one method that would throw
> and one that would return possibly inaccurate results.]
Yeah, UnsupportedOperationException might make sense in place of the
naive implementation.  Would have to be documented carefully if we
decide to do that.

Phil
>
>
> Gilles
>
>> Phil
>
>
> -
> 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: [math] tail probabilites

[Gilles]

On Fri, 09 Jan 2015 10:55:53 -0700, Phil Steitz wrote:

There is a feature request implicit in MATH-1185 - to add direct
computation of (upper) tail probabilities, so users can avoid loss
of significance errors when computing them from cumulative
probabilities, which is the only thing they can do with current
implementations.  In some cases, we can fairly easily provide direct
estimates; in others, not so easy.

What might make sense would be:

*  Add an upperTail(x) method to the 4.0 distributions interface
(maybe with a better name)
*  Add default implementation to AbstractXxDistribution (3.x and 4)
that returns naive results
*  Add - and doc - better implementations for individual
distributions as and when we get them


+1
[Although we could consider throwing an exception instead of
returning the naive result. Or one method that would throw
and one that would return possibly inaccurate results.]


Gilles


Phil



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

Re: [VOTE] Release Aoache Commons Validator 1.4.1 based on RC3

[Phil Steitz]

On 1/11/15 5:25 AM, James Carman wrote:
> Why is any of this being done manually?

So we know what we are doing and so we can inspect tags and
artifacts. The "push one button" mutate tags approach is not
appealing to many of us.  Every Commons RC I have ever cut, and
hopefully will ever cut follows the pattern:

0) Get source in shape for release
1) Create a tag
2) Inspect the tag
3) If the tag is good, commit it
4) Do a clean checkout of the tag and create the source distro and
any convenience binaries from the tag
5) Inspect the artifacts
6) If the artifacts are good, publish them for VOTE

Trying to skip steps 2) - 4) via "automation" takes control away
from the RM and results in stressful revert / cleanup activities
when we screw up (which we all do regularly).  The inspection steps
are all steps you end up taking anyway, so "push one button" doesn't
actually save any time. 

Phil
>
> On Sunday, January 11, 2015, Benedikt Ritter  wrote:
>
>> 2015-01-11 11:03 GMT+01:00 Luc Maisonobe > >:
>>
>>> Le 10/01/2015 19:51, Benedikt Ritter a écrit :
 Hi all,

 we have fixed the issues which where found in RC2 (and a lot more ;-))
>> so
 I'd like to call a new vote to release Apache Commons Validator 1.4.1
>>> based
 on RC3.

 Changes between RC2 and RC3:
 - Removed dependency to methods > Java 1.4
 - [VALIDATOR-342] URLValidator returns false for http://example.rocks
 - [VALIDATOR-235] UrlValidator rejects url with Unicode characters in
 domain label or TLD
 - [VALIDATOR-339] URLValidator fails validating domain names with a
 trailing period, which are valid.
 - [VALIDATOR-306] DomainValidator accepts labels longer than 63 chars
>> and
 domain name lengths exceeding 255 chars
 - [VALIDATOR-349] TLD tables should be pre-sorted
 - [VALIDATOR-290] Create new url validation using rfc3986 and IDN -
>> added
 new test
 - [VALIDATOR-350] Should "x.root" validate as a domain name? Removed
>>> "root"
 from TLD list. Also "um" and "yu" as they are currently "Not assigned"
 - [VALIDATOR-308] Logical errors in util.Flags affecting check of
>>> multiple
 flags as well as flag 64
 - [VALIDATOR-344] AbstractCheckDigit class does not fully test invalid
 strings. Fix up the testCalculateInvalid() invalid method to allow for
 either invalid checksum or syntax (CheckDigitException) error when
>>> testing
 the entries in the invalid array.
 - [VALIDATOR-297] Punycode url is not valid. Top-level domain regex
 matching was wrong; did not allow embedded "-" as per RFC2396
 - [VALIDATOR-334] UrlValidator: isValidAuthority() returning true when
 supplied authority validator fails
 - [VALIDATOR-309] UrlValidator does not validate uppercase URL schemes
 - [VALIDATOR-343] Doc URL update for broken link

 Changes between RC1 and RC2:
 - [VALIDATOR-307] - isValid checks if the given address is only IPV4
 address and not IPV6
 - [VALIDATOR-347] - toLowerCase() method is Locale-sensitive and should
>>> not
 be used
 - [VALIDATOR-348] - Update TLD list to latest version (Version
>>> 2014123000)
 - [VALIDATOR-336] - CUSIPCheckDigit thinks invalid CUSIP is valid.
 - [VALIDATOR-345] - ISINCheckDigit fails to reject invalid
>> (non-numeric)
 check digits
 - [VALIDATOR-346] - SedolCheckDigit fails to reject invalid
>> (non-numeric)
 check digits
 - Removed STATUS.html
 - Added README.md to binary and source distribution
 - Fixed encoding of source files in build by setting commons.encoding
 property
 - Fixed JIRA report to contain the issues of the project
 - Reverted dependency to commons-beanutils to 1.8.3 since this is the
 latest JDK 1.4 compatible release
 - Added JDK requirements to release notes.

 Validator 1.4.1-RC2 is available for review here:
   https://dist.apache.org/repos/dist/dev/commons/validator/ (svn
>>> revision
 7682)

 The tag is here:


>> http://svn.apache.org/repos/asf/commons/proper/validator/tags/VALIDATOR_1_4_1_RC3/
 (svn
 revision 1650789)

 Maven artifacts are here:


>> https://repository.apache.org/content/repositories/orgapachecommons-1076/commons-validator/commons-validator/1.4.1/
 Details of changes since 1.4 are in the release notes:

>> https://dist.apache.org/repos/dist/dev/commons/validator/RELEASE-NOTES.txt
 I have tested this with JDK 1.6, 1.7 and 1.8 using maven 3.2.5.

 Site (some links my be broken but will be fixed when the site is
>>> deployed):
   http://people.apache.org/~britter/validator-1.4.1-RC3/

 Clirr Report:

>>> http://people.apache.org/~britter/validator-1.4.1-RC3/clirr-report.html
 RAT Report:

>> http://people.apache.org/~britter/validator-1.4.1-RC3/rat-report.html
 Keys:
   https://www.apache.org/dist/commons/KEYS

 Please review this release candidate and vote.
 This

Re: AW: [VFS] Implementing custom hdfs file system using commons-vfs 2.0

[dlmarion]

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, January 10, 2015 9:00:37 PM 
Subject: AW: [VFS] Implementing custom hdfs file system using commons-vfs 2.0 

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"  
Betreff: Re: [VFS] Implementing custom hdfs file system using commons-vfs 2.0 

Glad that you were able to make it work. When it failed for you, were you 
executing the clean lifecylcle target for maven? It should work in consecutive 
runs with mvn clean. I did not test with consecutive runs without the clean 
target being executed. 



 Original message From: 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 names to make 
debugging a bit easier and I moved initialisation code to the 
setUp() method 

http://svn.apache.org/r1650847 & http://svn.apache.org/r1650852 

This way the test do not error out anymore. But I have no idea why this 
was happening on one machine and not on others (maybe a race, the 
failing machine had SSD?). 

So this means, now I can concentrate on merging the new version. 

Gruss 
Bernd 


Am Sun, 11 Jan 2015 01:25:48 +0100 schrieb Bernd Eckenfels 
: 

> 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. We dont need to care about 2.0 as this is a new 
> provider. I will make the changes, just want to fix the current test 
> failures I see first. 
> 
> 
> > 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 is 
> > disabled on Windows unless you decide to pull in windows artifacts 
> > attached to VFS-530. However, those artifacts are associated with 
> > patch 3 and are for Hadoop 2.4.0. Updating to 2.4.0 would also be 
> > sufficient in my opinion. 
> 
> Yes, what I mean is: I typically build under Windows so I would not 
> notice if the test starts to fail. However it seems to pass on the 
> integration build: 
> 
> https://continuum-ci.apache.org/continuum/projectView.action?projectId=129&projectGroupId=16
>  
> 
> Running 
> org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest 
> Starting DataNode 0 with dfs.data.dir: 
> target/build/test/data/dfs/data/data1,target/build/test/data/dfs/data/data2 
> Cluster is active Cluster is active Tests run: 13, Failures: 0, 
> Errors: 0, Skipped: 0, Time elapsed: 11.821 sec - in 
> org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest 
> Running 
> org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTestCase 
> Starting DataNode 0 with dfs.data.dir: 
> target/build/test2/data/dfs/data/data1,target/build/test2/data/dfs/data/data2 
> Cluster is active Cluster is active Tests run: 76, Failures: 0, 
> Errors: 0, Skipped: 0, Time elapsed: 18.853 sec - in 
> org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTestCase 
> 
> Anyway, on a Ubuntu, I get this exception currently: 
> 
> Running 
> org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTestCase 
> Starting DataNode 0 with dfs.data.dir: 
> target/build/test/data/dfs/data/data1,tar 
> get/build/test/data/dfs/data/data2 Cluster is active Cluster is 
> active Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time 
> elapsed: 1.486 sec <<< FA 
> ILURE! - in 
> org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTestCase 
> junit.framework.TestSuite@56c77035(org.apache.commons.vfs2.provider.hdfs.test.Hd
>  
> fsFileProviderTestCase$HdfsProviderTestSuite) Time elapsed: 1.479 
> sec <<< ERRO R! 
> java.lang.RuntimeException: Error setting up mini cluster at 
> org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTestCase$H 
> dfsProviderTestSuite.setUp(HdfsFileProviderTestCase.java:112) at 
> org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTest 
> Suite.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(JUnit4Provide 
> r.java:283) at 
> org.apache.maven.s

Re: [MATH] Github pull request notifications don't work

[Emmanuel Bourg]

Le 11/01/2015 11:23, Luc Maisonobe a écrit :

> Does anyone know how to handle this?

If a commit message contains a reference to the issue number it'll be
closed automatically (For example "Fixed issue foo (#123)").
Alternatively the infra team can be asked to close the issue.

Emmanuel Bourg


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

Re: [VOTE] Release Aoache Commons Validator 1.4.1 based on RC3

[James Carman]

Why is any of this being done manually?

On Sunday, January 11, 2015, Benedikt Ritter  wrote:

> 2015-01-11 11:03 GMT+01:00 Luc Maisonobe  >:
>
> > Le 10/01/2015 19:51, Benedikt Ritter a écrit :
> > > Hi all,
> > >
> > > we have fixed the issues which where found in RC2 (and a lot more ;-))
> so
> > > I'd like to call a new vote to release Apache Commons Validator 1.4.1
> > based
> > > on RC3.
> > >
> > > Changes between RC2 and RC3:
> > > - Removed dependency to methods > Java 1.4
> > > - [VALIDATOR-342] URLValidator returns false for http://example.rocks
> > > - [VALIDATOR-235] UrlValidator rejects url with Unicode characters in
> > > domain label or TLD
> > > - [VALIDATOR-339] URLValidator fails validating domain names with a
> > > trailing period, which are valid.
> > > - [VALIDATOR-306] DomainValidator accepts labels longer than 63 chars
> and
> > > domain name lengths exceeding 255 chars
> > > - [VALIDATOR-349] TLD tables should be pre-sorted
> > > - [VALIDATOR-290] Create new url validation using rfc3986 and IDN -
> added
> > > new test
> > > - [VALIDATOR-350] Should "x.root" validate as a domain name? Removed
> > "root"
> > > from TLD list. Also "um" and "yu" as they are currently "Not assigned"
> > > - [VALIDATOR-308] Logical errors in util.Flags affecting check of
> > multiple
> > > flags as well as flag 64
> > > - [VALIDATOR-344] AbstractCheckDigit class does not fully test invalid
> > > strings. Fix up the testCalculateInvalid() invalid method to allow for
> > > either invalid checksum or syntax (CheckDigitException) error when
> > testing
> > > the entries in the invalid array.
> > > - [VALIDATOR-297] Punycode url is not valid. Top-level domain regex
> > > matching was wrong; did not allow embedded "-" as per RFC2396
> > > - [VALIDATOR-334] UrlValidator: isValidAuthority() returning true when
> > > supplied authority validator fails
> > > - [VALIDATOR-309] UrlValidator does not validate uppercase URL schemes
> > > - [VALIDATOR-343] Doc URL update for broken link
> > >
> > > Changes between RC1 and RC2:
> > > - [VALIDATOR-307] - isValid checks if the given address is only IPV4
> > > address and not IPV6
> > > - [VALIDATOR-347] - toLowerCase() method is Locale-sensitive and should
> > not
> > > be used
> > > - [VALIDATOR-348] - Update TLD list to latest version (Version
> > 2014123000)
> > > - [VALIDATOR-336] - CUSIPCheckDigit thinks invalid CUSIP is valid.
> > > - [VALIDATOR-345] - ISINCheckDigit fails to reject invalid
> (non-numeric)
> > > check digits
> > > - [VALIDATOR-346] - SedolCheckDigit fails to reject invalid
> (non-numeric)
> > > check digits
> > > - Removed STATUS.html
> > > - Added README.md to binary and source distribution
> > > - Fixed encoding of source files in build by setting commons.encoding
> > > property
> > > - Fixed JIRA report to contain the issues of the project
> > > - Reverted dependency to commons-beanutils to 1.8.3 since this is the
> > > latest JDK 1.4 compatible release
> > > - Added JDK requirements to release notes.
> > >
> > > Validator 1.4.1-RC2 is available for review here:
> > >   https://dist.apache.org/repos/dist/dev/commons/validator/ (svn
> > revision
> > > 7682)
> > >
> > > The tag is here:
> > >
> > >
> >
> http://svn.apache.org/repos/asf/commons/proper/validator/tags/VALIDATOR_1_4_1_RC3/
> > > (svn
> > > revision 1650789)
> > >
> > > Maven artifacts are here:
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1076/commons-validator/commons-validator/1.4.1/
> > >
> > > Details of changes since 1.4 are in the release notes:
> > >
> >
> https://dist.apache.org/repos/dist/dev/commons/validator/RELEASE-NOTES.txt
> > >
> > > I have tested this with JDK 1.6, 1.7 and 1.8 using maven 3.2.5.
> > >
> > > Site (some links my be broken but will be fixed when the site is
> > deployed):
> > >   http://people.apache.org/~britter/validator-1.4.1-RC3/
> > >
> > > Clirr Report:
> > >
> > http://people.apache.org/~britter/validator-1.4.1-RC3/clirr-report.html
> > >
> > > RAT Report:
> > >
> http://people.apache.org/~britter/validator-1.4.1-RC3/rat-report.html
> > >
> > > Keys:
> > >   https://www.apache.org/dist/commons/KEYS
> > >
> > > Please review this release candidate and vote.
> > > This vote will close no sooner than 72 hours from now, i.e. after
> > > 2015/01/04 19:00CET
> >
> > Since the vote started on January 10th, I suppose the real closing date
> > should be January 13th, not January 4th ;-)
> >
> > >
> > > [ ] +1 Release these artifacts
> > > [X] +0 OK, but...
> >
> > One problem is that the MANIFEST.MF file in the binaries jar
> > does not contain the build number. The corresponding entry reads:
> >
> >  Implementation-Build: UNKNOWN_BRANCH@r??; 2015-01-10 18:25:42+
> >
> > It has probably been built from a non-svn checkout.
> >
> > As binaries are only a convenience, I don't think it's a blocker,
> > hence my +0.
> >
>
> Hello Luc,
>
> I usually do a svn export of the tag before I create the artifacts. This
> s

Re: [VOTE] Release Aoache Commons Validator 1.4.1 based on RC3

[Benedikt Ritter]

2015-01-11 11:03 GMT+01:00 Luc Maisonobe :

> Le 10/01/2015 19:51, Benedikt Ritter a écrit :
> > Hi all,
> >
> > we have fixed the issues which where found in RC2 (and a lot more ;-)) so
> > I'd like to call a new vote to release Apache Commons Validator 1.4.1
> based
> > on RC3.
> >
> > Changes between RC2 and RC3:
> > - Removed dependency to methods > Java 1.4
> > - [VALIDATOR-342] URLValidator returns false for http://example.rocks
> > - [VALIDATOR-235] UrlValidator rejects url with Unicode characters in
> > domain label or TLD
> > - [VALIDATOR-339] URLValidator fails validating domain names with a
> > trailing period, which are valid.
> > - [VALIDATOR-306] DomainValidator accepts labels longer than 63 chars and
> > domain name lengths exceeding 255 chars
> > - [VALIDATOR-349] TLD tables should be pre-sorted
> > - [VALIDATOR-290] Create new url validation using rfc3986 and IDN - added
> > new test
> > - [VALIDATOR-350] Should "x.root" validate as a domain name? Removed
> "root"
> > from TLD list. Also "um" and "yu" as they are currently "Not assigned"
> > - [VALIDATOR-308] Logical errors in util.Flags affecting check of
> multiple
> > flags as well as flag 64
> > - [VALIDATOR-344] AbstractCheckDigit class does not fully test invalid
> > strings. Fix up the testCalculateInvalid() invalid method to allow for
> > either invalid checksum or syntax (CheckDigitException) error when
> testing
> > the entries in the invalid array.
> > - [VALIDATOR-297] Punycode url is not valid. Top-level domain regex
> > matching was wrong; did not allow embedded "-" as per RFC2396
> > - [VALIDATOR-334] UrlValidator: isValidAuthority() returning true when
> > supplied authority validator fails
> > - [VALIDATOR-309] UrlValidator does not validate uppercase URL schemes
> > - [VALIDATOR-343] Doc URL update for broken link
> >
> > Changes between RC1 and RC2:
> > - [VALIDATOR-307] - isValid checks if the given address is only IPV4
> > address and not IPV6
> > - [VALIDATOR-347] - toLowerCase() method is Locale-sensitive and should
> not
> > be used
> > - [VALIDATOR-348] - Update TLD list to latest version (Version
> 2014123000)
> > - [VALIDATOR-336] - CUSIPCheckDigit thinks invalid CUSIP is valid.
> > - [VALIDATOR-345] - ISINCheckDigit fails to reject invalid (non-numeric)
> > check digits
> > - [VALIDATOR-346] - SedolCheckDigit fails to reject invalid (non-numeric)
> > check digits
> > - Removed STATUS.html
> > - Added README.md to binary and source distribution
> > - Fixed encoding of source files in build by setting commons.encoding
> > property
> > - Fixed JIRA report to contain the issues of the project
> > - Reverted dependency to commons-beanutils to 1.8.3 since this is the
> > latest JDK 1.4 compatible release
> > - Added JDK requirements to release notes.
> >
> > Validator 1.4.1-RC2 is available for review here:
> >   https://dist.apache.org/repos/dist/dev/commons/validator/ (svn
> revision
> > 7682)
> >
> > The tag is here:
> >
> >
> http://svn.apache.org/repos/asf/commons/proper/validator/tags/VALIDATOR_1_4_1_RC3/
> > (svn
> > revision 1650789)
> >
> > Maven artifacts are here:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1076/commons-validator/commons-validator/1.4.1/
> >
> > Details of changes since 1.4 are in the release notes:
> >
> https://dist.apache.org/repos/dist/dev/commons/validator/RELEASE-NOTES.txt
> >
> > I have tested this with JDK 1.6, 1.7 and 1.8 using maven 3.2.5.
> >
> > Site (some links my be broken but will be fixed when the site is
> deployed):
> >   http://people.apache.org/~britter/validator-1.4.1-RC3/
> >
> > Clirr Report:
> >
> http://people.apache.org/~britter/validator-1.4.1-RC3/clirr-report.html
> >
> > RAT Report:
> >   http://people.apache.org/~britter/validator-1.4.1-RC3/rat-report.html
> >
> > Keys:
> >   https://www.apache.org/dist/commons/KEYS
> >
> > Please review this release candidate and vote.
> > This vote will close no sooner than 72 hours from now, i.e. after
> > 2015/01/04 19:00CET
>
> Since the vote started on January 10th, I suppose the real closing date
> should be January 13th, not January 4th ;-)
>
> >
> > [ ] +1 Release these artifacts
> > [X] +0 OK, but...
>
> One problem is that the MANIFEST.MF file in the binaries jar
> does not contain the build number. The corresponding entry reads:
>
>  Implementation-Build: UNKNOWN_BRANCH@r??; 2015-01-10 18:25:42+
>
> It has probably been built from a non-svn checkout.
>
> As binaries are only a convenience, I don't think it's a blocker,
> hence my +0.
>

Hello Luc,

I usually do a svn export of the tag before I create the artifacts. This
seems to be the wrong procedure, so all releases I've created will have
this problem :-(
I'll do a svn co from now on.

Thanks!
Benedikt


>
> Luc
>
> > [ ] -0 OK, but really should fix...
> > [ ] -1 I oppose this release because...
> >
> > I'd like to add that all thanks for this RC goes to sebb, who has
> invested
> > a lot of time to get this right.
> > Th

Re: [MATH] Github pull request notifications don't work

[Luc Maisonobe]

Hi,

Le 10/01/2015 22:39, Phil Steitz a écrit :
> On 1/8/15 4:11 AM, James Carman wrote:
>> Apache Camel's pull requests do show up on the dev list.  It might be
>> nice to see these.  Otherwise, we might not know there is a
>> contribution out there waiting for us.
> 
> I would rather see them first on the dev list rather than
> auto-opening JIRAs for them.

There is another thing I find difficult with Github pull requests, it is
how to handle them. This may be because I am not really used to github
process.

The pull request seems really github-centric. If you have write access
on the github original repository, everything is done so you can merge
the request with very little effort.

However, our github repository is only a mirror on our reference
repository, and we don't have write access to it, we have write accesss
to the Apache repository. So we can't use github tools, but in fact we
don't even have access to the explanation buttons to do things manually.
As an example the page
 explains:

 The pull request page on GitHub includes custom instructions for
 manually merging a pull request on the command line. You can use these
 instructions if your pull request can't be merged online, or if you'd
 like to test your changes locally before merging. These instructions
 can be found near the Merge pull request button.

But ... I never found these instructions, most probably because they
don't appear on the web page because I don't have write access there.

So I end up doint thing manually, finding the commands by myself. This
includes declaring the contributor repository as a new remote dependency
in my local repository, fetching the request and reviewing it, and later
pushing it on Apache repository if I am happy with it. This is what I
did a feww weeks ago with Hank request, and more recently with Benedikt
request (this is a simple application of the use case explained in the
wiki).

In Benedikt case, as I directly pushed the original commit, it seems
Github identified it as such when mirroring our repo, and it closed the
request automatically.

In Hank case, however, I did change a few things, so the github did not
identify it. Hence, the pull request number 3 for MATH-1138
 is still open, despite
it has been handled. Here again, as I don't have write access on github
mirror repository, I cannot close it.

Does anyone know how to handle this?

best regards,
Luc

> 
> Phil
>>
>> On Thu, Jan 8, 2015 at 5:53 AM, Benedikt Ritter  wrote:
>>> Hi,
>>>
>>> it looks like the push request notifications are not set up for the new
>>> repository. I've opened https://github.com/apache/commons-math/pull/4 but
>>> nothing was send to the list. Since I don't know whether this is
>>> intentionally, I'll not create an INFRA ticket for this.
>>>
>>> Benedikt
>>> --
>>> http://people.apache.org/~britter/
>>> http://www.systemoutprintln.de/
>>> http://twitter.com/BenediktRitter
>>> http://github.com/britter
>> -
>> 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: [Math] Java version (Was: [MATH] Jenkins build)

[Luc Maisonobe]

Le 08/01/2015 12:34, Gilles a écrit :
> Hi.
> 
> Raising this issue once again.
> Are we going to upgrade the requirement for the next major release?
> 
>  [ ] Java 5
>  [ ] Java 6
>  [ ] Java 7
>  [ ] Java 8
>  [ ] Java 9

I would say 7 or 8.

best regards,
Luc

> 
> ?
> 
> Gilles
> 
> 
> On Thu, 8 Jan 2015 10:34:20 +, sebb wrote:
>> I've had to give up trying to get Continuum to use Git, so I set up a
>> Jenkins build for Math
>>
>> It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME
>> variables don't seem to have been set up on the Jenkins hosts, so the
>> -Pjava-1.5 profile does not work as is.
>>
>> However I found that the JAVA_1_5_HOME variable can be defined on the
>> Maven command-line.
>>
>> This works, provided that Java 1.5 is always installed in the same
>> location on different hosts.
>>
>> [The JAVA_1_x_HOME variables were designed get around this
>> restriction, as they can be differently defined on different hosts]
>>
>> Hopefully the builds will be useful in detecting accidental use of
>> Java 1.6+ APIs
>>
>> So far I have only added Commons Math itself.
>> I hope to add the examples shortly.
>>
>> -
>> 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: [VOTE] Release Aoache Commons Validator 1.4.1 based on RC3

[Luc Maisonobe]

Le 10/01/2015 19:51, Benedikt Ritter a écrit :
> Hi all,
> 
> we have fixed the issues which where found in RC2 (and a lot more ;-)) so
> I'd like to call a new vote to release Apache Commons Validator 1.4.1 based
> on RC3.
> 
> Changes between RC2 and RC3:
> - Removed dependency to methods > Java 1.4
> - [VALIDATOR-342] URLValidator returns false for http://example.rocks
> - [VALIDATOR-235] UrlValidator rejects url with Unicode characters in
> domain label or TLD
> - [VALIDATOR-339] URLValidator fails validating domain names with a
> trailing period, which are valid.
> - [VALIDATOR-306] DomainValidator accepts labels longer than 63 chars and
> domain name lengths exceeding 255 chars
> - [VALIDATOR-349] TLD tables should be pre-sorted
> - [VALIDATOR-290] Create new url validation using rfc3986 and IDN - added
> new test
> - [VALIDATOR-350] Should "x.root" validate as a domain name? Removed "root"
> from TLD list. Also "um" and "yu" as they are currently "Not assigned"
> - [VALIDATOR-308] Logical errors in util.Flags affecting check of multiple
> flags as well as flag 64
> - [VALIDATOR-344] AbstractCheckDigit class does not fully test invalid
> strings. Fix up the testCalculateInvalid() invalid method to allow for
> either invalid checksum or syntax (CheckDigitException) error when testing
> the entries in the invalid array.
> - [VALIDATOR-297] Punycode url is not valid. Top-level domain regex
> matching was wrong; did not allow embedded "-" as per RFC2396
> - [VALIDATOR-334] UrlValidator: isValidAuthority() returning true when
> supplied authority validator fails
> - [VALIDATOR-309] UrlValidator does not validate uppercase URL schemes
> - [VALIDATOR-343] Doc URL update for broken link
> 
> Changes between RC1 and RC2:
> - [VALIDATOR-307] - isValid checks if the given address is only IPV4
> address and not IPV6
> - [VALIDATOR-347] - toLowerCase() method is Locale-sensitive and should not
> be used
> - [VALIDATOR-348] - Update TLD list to latest version (Version 2014123000)
> - [VALIDATOR-336] - CUSIPCheckDigit thinks invalid CUSIP is valid.
> - [VALIDATOR-345] - ISINCheckDigit fails to reject invalid (non-numeric)
> check digits
> - [VALIDATOR-346] - SedolCheckDigit fails to reject invalid (non-numeric)
> check digits
> - Removed STATUS.html
> - Added README.md to binary and source distribution
> - Fixed encoding of source files in build by setting commons.encoding
> property
> - Fixed JIRA report to contain the issues of the project
> - Reverted dependency to commons-beanutils to 1.8.3 since this is the
> latest JDK 1.4 compatible release
> - Added JDK requirements to release notes.
> 
> Validator 1.4.1-RC2 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/validator/ (svn revision
> 7682)
> 
> The tag is here:
> 
> http://svn.apache.org/repos/asf/commons/proper/validator/tags/VALIDATOR_1_4_1_RC3/
> (svn
> revision 1650789)
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1076/commons-validator/commons-validator/1.4.1/
> 
> Details of changes since 1.4 are in the release notes:
>   https://dist.apache.org/repos/dist/dev/commons/validator/RELEASE-NOTES.txt
> 
> I have tested this with JDK 1.6, 1.7 and 1.8 using maven 3.2.5.
> 
> Site (some links my be broken but will be fixed when the site is deployed):
>   http://people.apache.org/~britter/validator-1.4.1-RC3/
> 
> Clirr Report:
>   http://people.apache.org/~britter/validator-1.4.1-RC3/clirr-report.html
> 
> RAT Report:
>   http://people.apache.org/~britter/validator-1.4.1-RC3/rat-report.html
> 
> Keys:
>   https://www.apache.org/dist/commons/KEYS
> 
> Please review this release candidate and vote.
> This vote will close no sooner than 72 hours from now, i.e. after
> 2015/01/04 19:00CET

Since the vote started on January 10th, I suppose the real closing date
should be January 13th, not January 4th ;-)

> 
> [ ] +1 Release these artifacts
> [X] +0 OK, but...

One problem is that the MANIFEST.MF file in the binaries jar
does not contain the build number. The corresponding entry reads:

 Implementation-Build: UNKNOWN_BRANCH@r??; 2015-01-10 18:25:42+

It has probably been built from a non-svn checkout.

As binaries are only a convenience, I don't think it's a blocker,
hence my +0.

Luc

> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
> 
> I'd like to add that all thanks for this RC goes to sebb, who has invested
> a lot of time to get this right.
> Thanks!
> 
> Benedikt
> 
> 


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