Re: [REPORT][DRAFT] Apache Commons Board Report 2015-12-09

2015-12-09 Thread Benedikt Ritter 
Hello Gary,

2015-12-10 3:56 GMT+01:00 Gary Gregory :

> Here is what I plan to send tonight:
>
> [REPORT] Apache Commons Board Report 2015-12-09
>
> The Apache Commons project focuses on all aspects of reusable Java
> components.
>
> The Apache Commons components are widely used in many projects, both within
> Apache and without.
>
> The last report was on September 9 2015.
>
> No issues require board attention at this time.
>
> Overall project health is good with 5 releases this period:
>
>  - Apache Commons Validator 1.5.0 was released on Mon Nov 23 2015
>  - Apache Commons Net .4 was released on Wed Nov 25 2015
>  - Apache Commons Configuration 2.0-beta2 was released on Fri Dec 04 2015
>  - Apache Commons Collection 4.1 was released on Thu Nov 26 2015
>  - Apache Commons Collection 3.2.2 was released on Fri Nov 13 2015
>
> Of note, the Apache Commons Collections releases where pushed out to
> address a security issue, see the Collections site or release notes for
> details.
>
> Here are the stats:
>
> ## PMC changes:
>
>  - Currently 37 PMC members.
>  - Bernd Eckenfels was added to the PMC on Sat Nov 21 2015
>
> ## Committer base changes:
>
>  - Currently 124 committers.
>  - New commmitters:
> - Loic Guibert was added as a committer on Wed Oct 14 2015
> - Kristian Rosenvold was added as a committer on Thu Sep 10 2015
>

Kristian has also been added to the PMC.


>
> ## Mailing list activity:
>
>  - dev@commons.apache.org:
> - 679 subscribers (up 15 in the last 3 months):
> - 910 emails sent to list (590 in previous quarter)
>
>  - iss...@commons.apache.org:
> - 306 subscribers (down -4 in the last 3 months):
> - 1594 emails sent to list (1541 in previous quarter)
>
>  - u...@commons.apache.org:
> - 1221 subscribers (up 4 in the last 3 months):
> - 134 emails sent to list (158 in previous quarter)
>
>  - notificati...@commons.apache.org:
> - 9 subscribers (up 0 in the last 3 months):
> - 74 emails sent to list (286 in previous quarter)
>
> ## JIRA activity:
>
>  - 168 JIRA tickets created in the last 3 months
>  - 157 JIRA tickets closed/resolved in the last 3 months
>
> Gary Gregory
> Apache Commons Chair
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [REPORT][DRAFT] Apache Commons Board Report 2015-12-09

2015-12-09 Thread Gary Gregory 
On Wed, Dec 9, 2015 at 8:22 PM, Phil Steitz  wrote:

> On 12/9/15 7:56 PM, Gary Gregory wrote:
> > Here is what I plan to send tonight:
> >
> > [REPORT] Apache Commons Board Report 2015-12-09
> >
> > The Apache Commons project focuses on all aspects of reusable Java
> > components.
> >
> > The Apache Commons components are widely used in many projects, both
> within
> > Apache and without.
> >
> > The last report was on September 9 2015.
> >
> > No issues require board attention at this time.
> >
> > Overall project health is good with 5 releases this period:
> >
> >  - Apache Commons Validator 1.5.0 was released on Mon Nov 23 2015
> >  - Apache Commons Net .4 was released on Wed Nov 25 2015
> >  - Apache Commons Configuration 2.0-beta2 was released on Fri Dec 04 2015
> >  - Apache Commons Collection 4.1 was released on Thu Nov 26 2015
> >  - Apache Commons Collection 3.2.2 was released on Fri Nov 13 2015
> Should be Collections above (missing s)
> >
> > Of note, the Apache Commons Collections releases where pushed out to
> > address a security issue, see the Collections site or release notes for
> > details.
> >
> > Here are the stats:
> >
> > ## PMC changes:
> >
> >  - Currently 37 PMC members.
> >  - Bernd Eckenfels was added to the PMC on Sat Nov 21 2015
> >
> > ## Committer base changes:
> >
> >  - Currently 124 committers.
>
> I am not sure what that statistic means any more given that any ASF
> committer can commit now.  Might be best to drop it.
>

I will note that Commons is open to any ASF committers.


> >  - New commmitters:
> > - Loic Guibert was added as a committer on Wed Oct 14 2015
> > - Kristian Rosenvold was added as a committer on Thu Sep 10 201
> >
> > ## Mailing list activity:
> >
> >  - dev@commons.apache.org:
> > - 679 subscribers (up 15 in the last 3 months):
> > - 910 emails sent to list (590 in previous quarter)
> >
> >  - iss...@commons.apache.org:
> > - 306 subscribers (down -4 in the last 3 months):
> > - 1594 emails sent to list (1541 in previous quarter)
> >
> >  - u...@commons.apache.org:
> > - 1221 subscribers (up 4 in the last 3 months):
> > - 134 emails sent to list (158 in previous quarter)
> >
> >  - notificati...@commons.apache.org:
> > - 9 subscribers (up 0 in the last 3 months):
> > - 74 emails sent to list (286 in previous quarter)
> >
> > ## JIRA activity:
> >
> >  - 168 JIRA tickets created in the last 3 months
> >  - 157 JIRA tickets closed/resolved in the last 3 months
>
> I don't personally see the point in providing all of the stats above
> unless there is something interesting / alarming to report, but if
> it is correct and easy to do, OK...
>

This stat is automatically generated.

Gary


> Phil
> >
> > Gary Gregory
> > Apache Commons Chair
> >
>
>
>
> -
> 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

Build failed in Jenkins: Commons-Compress #34

2015-12-09 Thread Apache Jenkins Server 
See 

Changes:

[sebb] Moved DOAP

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
JDK installation skipped: Unknown CPU name: freebsd
Building remotely on freebsd1 (freebsd bsd) in workspace 

JDK installation skipped: Unknown CPU name: freebsd
JDK installation skipped: Unknown CPU name: freebsd
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/commons-compress.git # timeout=10
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/commons-compress.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/commons-compress.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 86148ca23eb9caa0ac16b270b1a444230dfef2a9 
(refs/remotes/origin/master)
JDK installation skipped: Unknown CPU name: freebsd
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 86148ca23eb9caa0ac16b270b1a444230dfef2a9
 > git rev-list 7aa8e75a91013d51348b2e15745972cd6e9aad50 # timeout=10
JDK installation skipped: Unknown CPU name: freebsd
JDK installation skipped: Unknown CPU name: freebsd
Setting JDK_1_5_LATEST__HOME=/home/jenkins/tools/java/latest1.5
Parsing POMs
Downloaded artifact 
http://repo.maven.apache.org/maven2/org/apache/commons/commons-parent/38/commons-parent-38.pom
Downloaded artifact 
http://repo.maven.apache.org/maven2/org/apache/apache/16/apache-16.pom
JDK installation skipped: Unknown CPU name: freebsd
JDK installation skipped: Unknown CPU name: freebsd
Established TCP socket on 46320
maven3-agent.jar already up to date
maven3-interceptor.jar already up to date
maven3-interceptor-commons.jar already up to date
[Commons-Compress] $ 
/home/hudson/hudson-slave/tools/hudson.model.JDK/JDK_1.7_latest_/bin/java 
-Xmx2g -Xms256m -XX:MaxPermSize=512m -cp 
/home/hudson/hudson-slave/maven3-agent.jar:/home/jenkins/tools/maven/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar
 org.jvnet.hudson.maven3.agent.Maven3Main 
/home/jenkins/tools/maven/apache-maven-3.0.4 
/usr/home/hudson/hudson-slave/slave.jar 
/home/hudson/hudson-slave/maven3-interceptor.jar 
/home/hudson/hudson-slave/maven3-interceptor-commons.jar 46320
ERROR: Failed to parse POMs
java.io.IOException: Cannot run program 
"/home/hudson/hudson-slave/tools/hudson.model.JDK/JDK_1.7_latest_/bin/java" (in 
directory ": 
java.io.IOException: error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:488)
at hudson.Proc$LocalProc.(Proc.java:244)
at hudson.Proc$LocalProc.(Proc.java:216)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:803)
at hudson.Launcher$ProcStarter.start(Launcher.java:381)
at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1136)
at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1101)
at hudson.remoting.UserRequest.perform(UserRequest.java:121)
at hudson.remoting.UserRequest.perform(UserRequest.java:49)
at hudson.remoting.Request$2.run(Request.java:326)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:679)
at ..remote call to freebsd1(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1413)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:221)
at hudson.remoting.Channel.call(Channel.java:778)
at hudson.Launcher$RemoteLauncher.launch(Launcher.java:916)
at hudson.Launcher$ProcStarter.start(Launcher.java:381)
at 
hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:364)
at hudson.maven.ProcessCache.get(ProcessCache.java:236)
at 
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:778)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:536)
at hudson.model.Run.execute(Run.java:1738)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:3

Re: [vfs] New Properties for FtpFileSystemConfigBuilder

2015-12-09 Thread 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: [REPORT][DRAFT] Apache Commons Board Report 2015-12-09

2015-12-09 Thread Phil Steitz 
On 12/9/15 7:56 PM, Gary Gregory wrote:
> Here is what I plan to send tonight:
>
> [REPORT] Apache Commons Board Report 2015-12-09
>
> The Apache Commons project focuses on all aspects of reusable Java
> components.
>
> The Apache Commons components are widely used in many projects, both within
> Apache and without.
>
> The last report was on September 9 2015.
>
> No issues require board attention at this time.
>
> Overall project health is good with 5 releases this period:
>
>  - Apache Commons Validator 1.5.0 was released on Mon Nov 23 2015
>  - Apache Commons Net .4 was released on Wed Nov 25 2015
>  - Apache Commons Configuration 2.0-beta2 was released on Fri Dec 04 2015
>  - Apache Commons Collection 4.1 was released on Thu Nov 26 2015
>  - Apache Commons Collection 3.2.2 was released on Fri Nov 13 2015
Should be Collections above (missing s)
>
> Of note, the Apache Commons Collections releases where pushed out to
> address a security issue, see the Collections site or release notes for
> details.
>
> Here are the stats:
>
> ## PMC changes:
>
>  - Currently 37 PMC members.
>  - Bernd Eckenfels was added to the PMC on Sat Nov 21 2015
>
> ## Committer base changes:
>
>  - Currently 124 committers.

I am not sure what that statistic means any more given that any ASF
committer can commit now.  Might be best to drop it.
>  - New commmitters:
> - Loic Guibert was added as a committer on Wed Oct 14 2015
> - Kristian Rosenvold was added as a committer on Thu Sep 10 201
>
> ## Mailing list activity:
>
>  - dev@commons.apache.org:
> - 679 subscribers (up 15 in the last 3 months):
> - 910 emails sent to list (590 in previous quarter)
>
>  - iss...@commons.apache.org:
> - 306 subscribers (down -4 in the last 3 months):
> - 1594 emails sent to list (1541 in previous quarter)
>
>  - u...@commons.apache.org:
> - 1221 subscribers (up 4 in the last 3 months):
> - 134 emails sent to list (158 in previous quarter)
>
>  - notificati...@commons.apache.org:
> - 9 subscribers (up 0 in the last 3 months):
> - 74 emails sent to list (286 in previous quarter)
>
> ## JIRA activity:
>
>  - 168 JIRA tickets created in the last 3 months
>  - 157 JIRA tickets closed/resolved in the last 3 months

I don't personally see the point in providing all of the stats above
unless there is something interesting / alarming to report, but if
it is correct and easy to do, OK...

Phil
>
> Gary Gregory
> Apache Commons Chair
>



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

Build failed in Jenkins: Commons-Compress #33

2015-12-09 Thread Apache Jenkins Server 
See 

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on mac-mini-1 (osx mac) in workspace 

java.io.IOException: Failed to install 
http://archive.apache.org/dist/maven/binaries/apache-maven-3.0.4-bin.zip to 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:831)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:70)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:205)
at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:621)
at 
hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:183)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1036)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1274)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531)
at hudson.model.Run.execute(Run.java:1738)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:381)
Caused by: java.io.IOException: Failed to mkdirs: 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.mkdirs(FilePath.java:1162)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:797)
... 16 more
Retrying after 10 seconds
java.io.IOException: Failed to install 
http://archive.apache.org/dist/maven/binaries/apache-maven-3.0.4-bin.zip to 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:831)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:70)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:205)
at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:621)
at 
hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:183)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1036)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1274)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531)
at hudson.model.Run.execute(Run.java:1738)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:381)
Caused by: java.io.IOException: Failed to mkdirs: 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.mkdirs(FilePath.java:1162)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:797)
... 16 more
Retrying after 10 seconds
java.io.IOException: Failed to install 
http://archive.apache.org/dist/maven/binaries/apache-maven-3.0.4-bin.zip to 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:831)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:70)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:205)
at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:621)
at 
hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:183)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1036)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1274)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBui

Build failed in Jenkins: Commons-Compress #32

2015-12-09 Thread Apache Jenkins Server 
See 

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on mac-mini-1 (osx mac) in workspace 

java.io.IOException: Failed to install 
http://archive.apache.org/dist/maven/binaries/apache-maven-3.0.4-bin.zip to 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:831)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:70)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:205)
at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:621)
at 
hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:183)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1036)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1274)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531)
at hudson.model.Run.execute(Run.java:1738)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:381)
Caused by: java.io.IOException: Failed to mkdirs: 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.mkdirs(FilePath.java:1162)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:797)
... 16 more
Retrying after 10 seconds
java.io.IOException: Failed to install 
http://archive.apache.org/dist/maven/binaries/apache-maven-3.0.4-bin.zip to 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:831)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:70)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:205)
at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:621)
at 
hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:183)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1036)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1274)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531)
at hudson.model.Run.execute(Run.java:1738)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:381)
Caused by: java.io.IOException: Failed to mkdirs: 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.mkdirs(FilePath.java:1162)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:797)
... 16 more
Retrying after 10 seconds
java.io.IOException: Failed to install 
http://archive.apache.org/dist/maven/binaries/apache-maven-3.0.4-bin.zip to 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:831)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:70)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:205)
at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:621)
at 
hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:183)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1036)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1274)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBui

[REPORT][DRAFT] Apache Commons Board Report 2015-12-09

2015-12-09 Thread Gary Gregory 
Here is what I plan to send tonight:

[REPORT] Apache Commons Board Report 2015-12-09

The Apache Commons project focuses on all aspects of reusable Java
components.

The Apache Commons components are widely used in many projects, both within
Apache and without.

The last report was on September 9 2015.

No issues require board attention at this time.

Overall project health is good with 5 releases this period:

 - Apache Commons Validator 1.5.0 was released on Mon Nov 23 2015
 - Apache Commons Net .4 was released on Wed Nov 25 2015
 - Apache Commons Configuration 2.0-beta2 was released on Fri Dec 04 2015
 - Apache Commons Collection 4.1 was released on Thu Nov 26 2015
 - Apache Commons Collection 3.2.2 was released on Fri Nov 13 2015

Of note, the Apache Commons Collections releases where pushed out to
address a security issue, see the Collections site or release notes for
details.

Here are the stats:

## PMC changes:

 - Currently 37 PMC members.
 - Bernd Eckenfels was added to the PMC on Sat Nov 21 2015

## Committer base changes:

 - Currently 124 committers.
 - New commmitters:
- Loic Guibert was added as a committer on Wed Oct 14 2015
- Kristian Rosenvold was added as a committer on Thu Sep 10 2015

## Mailing list activity:

 - dev@commons.apache.org:
- 679 subscribers (up 15 in the last 3 months):
- 910 emails sent to list (590 in previous quarter)

 - iss...@commons.apache.org:
- 306 subscribers (down -4 in the last 3 months):
- 1594 emails sent to list (1541 in previous quarter)

 - u...@commons.apache.org:
- 1221 subscribers (up 4 in the last 3 months):
- 134 emails sent to list (158 in previous quarter)

 - notificati...@commons.apache.org:
- 9 subscribers (up 0 in the last 3 months):
- 74 emails sent to list (286 in previous quarter)

## JIRA activity:

 - 168 JIRA tickets created in the last 3 months
 - 157 JIRA tickets closed/resolved in the last 3 months

Gary Gregory
Apache Commons Chair

Build failed in Jenkins: Commons-Compress #31

2015-12-09 Thread Apache Jenkins Server 
See 

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on mac-mini-1 (osx mac) in workspace 

java.io.IOException: Failed to install 
http://archive.apache.org/dist/maven/binaries/apache-maven-3.0.4-bin.zip to 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:831)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:70)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:205)
at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:621)
at 
hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:183)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1036)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1274)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531)
at hudson.model.Run.execute(Run.java:1738)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:381)
Caused by: java.io.IOException: Failed to mkdirs: 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.mkdirs(FilePath.java:1162)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:797)
... 16 more
Retrying after 10 seconds
java.io.IOException: Failed to install 
http://archive.apache.org/dist/maven/binaries/apache-maven-3.0.4-bin.zip to 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:831)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:70)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:205)
at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:621)
at 
hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:183)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1036)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1274)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531)
at hudson.model.Run.execute(Run.java:1738)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:381)
Caused by: java.io.IOException: Failed to mkdirs: 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.mkdirs(FilePath.java:1162)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:797)
... 16 more
Retrying after 10 seconds
java.io.IOException: Failed to install 
http://archive.apache.org/dist/maven/binaries/apache-maven-3.0.4-bin.zip to 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:831)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:70)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:205)
at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:621)
at 
hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:183)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1036)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1274)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBui

Build failed in Jenkins: Commons-Compress #30

2015-12-09 Thread Apache Jenkins Server 
See 

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on mac-mini-1 (osx mac) in workspace 

java.io.IOException: Failed to install 
http://archive.apache.org/dist/maven/binaries/apache-maven-3.0.4-bin.zip to 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:831)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:70)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:205)
at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:621)
at 
hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:183)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1036)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1274)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531)
at hudson.model.Run.execute(Run.java:1738)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:381)
Caused by: java.io.IOException: Failed to mkdirs: 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.mkdirs(FilePath.java:1162)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:797)
... 16 more
Retrying after 10 seconds
java.io.IOException: Failed to install 
http://archive.apache.org/dist/maven/binaries/apache-maven-3.0.4-bin.zip to 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:831)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:70)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:205)
at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:621)
at 
hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:183)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1036)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1274)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531)
at hudson.model.Run.execute(Run.java:1738)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:381)
Caused by: java.io.IOException: Failed to mkdirs: 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.mkdirs(FilePath.java:1162)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:797)
... 16 more
Retrying after 10 seconds
java.io.IOException: Failed to install 
http://archive.apache.org/dist/maven/binaries/apache-maven-3.0.4-bin.zip to 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:831)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:70)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:205)
at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:621)
at 
hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:183)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1036)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1274)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBui

Build failed in Jenkins: Commons-Compress #29

2015-12-09 Thread Apache Jenkins Server 
See 

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on mac-mini-1 (osx mac) in workspace 

java.io.IOException: Failed to install 
http://archive.apache.org/dist/maven/binaries/apache-maven-3.0.4-bin.zip to 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:831)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:70)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:205)
at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:621)
at 
hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:183)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1036)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1274)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531)
at hudson.model.Run.execute(Run.java:1738)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:381)
Caused by: java.io.IOException: Failed to mkdirs: 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.mkdirs(FilePath.java:1162)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:797)
... 16 more
Retrying after 10 seconds
java.io.IOException: Failed to install 
http://archive.apache.org/dist/maven/binaries/apache-maven-3.0.4-bin.zip to 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:831)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:70)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:205)
at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:621)
at 
hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:183)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1036)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1274)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531)
at hudson.model.Run.execute(Run.java:1738)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:381)
Caused by: java.io.IOException: Failed to mkdirs: 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.mkdirs(FilePath.java:1162)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:797)
... 16 more
Retrying after 10 seconds
java.io.IOException: Failed to install 
http://archive.apache.org/dist/maven/binaries/apache-maven-3.0.4-bin.zip to 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:831)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:70)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:205)
at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:621)
at 
hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:183)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1036)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1274)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBui

Build failed in Jenkins: Commons-Compress #28

2015-12-09 Thread Apache Jenkins Server 
See 

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Installing JDK jdk-7u80-oth-JPR
Downloading JDK from 
http://download.oracle.com/otn-pub/java/jdk/7u80-b15/jdk-7u80-macosx-x64.dmg
Downloading 206510745bytes
Installing 
/Users/jenkins/jenkins-home/tools/hudson.model.JDK/JDK_1.7_latest_/jdk.dmg
$ hdiutil attach -puppetstrings -mountpoint 
/Users/jenkins/jenkins-home/tools/hudson.model.JDK/jdk2148972722859615260dmg 
/Users/jenkins/jenkins-home/tools/hudson.model.JDK/JDK_1.7_latest_/jdk.dmg
PERCENT:0.00
MESSAGE:Checksumming Protective Master Boot Record (MBR : 0)…
MESSAGE:
MESSAGE:Protective Master Boot Record (MBR :: verified   CRC32 $A63E199D
MESSAGE:Checksumming GPT Header (Primary GPT Header : 1)…
MESSAGE:
MESSAGE: GPT Header (Primary GPT Header : 1): verified   CRC32 $DAF7B809
MESSAGE:Checksumming GPT Partition Data (Primary GPT Table : 2)…
MESSAGE:
MESSAGE:GPT Partition Data (Primary GPT Tabl: verified   CRC32 $035A270F
MESSAGE:Checksumming  (Apple_Free : 3)…
MESSAGE:
MESSAGE:(Apple_Free : 3): verified   CRC32 $
MESSAGE:Checksumming disk image (Apple_HFS : 4)…
PERCENT:99.996094
MESSAGE:
MESSAGE:  disk image (Apple_HFS : 4): verified   CRC32 $775B02CA
MESSAGE:Checksumming  (Apple_Free : 5)…
MESSAGE:
MESSAGE:(Apple_Free : 5): verified   CRC32 $
MESSAGE:Checksumming GPT Partition Data (Backup GPT Table : 6)…
MESSAGE:
MESSAGE:GPT Partition Data (Backup GPT Table: verified   CRC32 $035A270F
MESSAGE:Checksumming GPT Header (Backup GPT Header : 7)…
MESSAGE:
MESSAGE:  GPT Header (Backup GPT Header : 7): verified   CRC32 $453AE7A7
PERCENT:-1.00
MESSAGE:verified   CRC32 $51FE5723
/dev/disk3  GUID_partition_scheme   
/dev/disk3s1Apple_HFS   
/Users/jenkins/jenkins-home/tools/hudson.model.JDK/jdk2148972722859615260dmg
$ pkgutil --expand 
"/Users/jenkins/jenkins-home/tools/hudson.model.JDK/jdk2148972722859615260dmg/JDK
 7 Update 80.pkg" 
/Users/jenkins/jenkins-home/tools/hudson.model.JDK/jdk6512690069386118956pkg
$ umount 
/Users/jenkins/jenkins-home/tools/hudson.model.JDK/jdk2148972722859615260dmg
[hudson.model.JDK] $ tar xzf 
/Users/jenkins/jenkins-home/tools/hudson.model.JDK/jdk6512690069386118956pkg/jdk17080.pkg/Payload
Building remotely on mac-mini-1 (osx mac) in workspace 

java.io.IOException: Failed to install 
http://archive.apache.org/dist/maven/binaries/apache-maven-3.0.4-bin.zip to 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:831)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:70)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:205)
at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:621)
at 
hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:183)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1036)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1274)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531)
at hudson.model.Run.execute(Run.java:1738)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:381)
Caused by: java.io.IOException: Failed to mkdirs: 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.mkdirs(FilePath.java:1162)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:797)
... 16 more
Retrying after 10 seconds
java.io.IOException: Failed to install 
http://archive.apache.org/dist/maven/binaries/apache-maven-3.0.4-bin.zip to 
/home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:831)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:70)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:205)
at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:621)
at 
hudson.maven.MavenModuleSetBuild.getEnvironment(Maven

Re: [vfs] New Properties for FtpFileSystemConfigBuilder

2015-12-09 Thread Roger Membreno 
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

Re: [math] branch merge to come, prepare for a huge flood of git messages

2015-12-09 Thread Phil Steitz 
On 12/9/15 12:53 PM, Luc Maisonobe wrote:
> Le 09/12/2015 19:22, James Ring a écrit :
>> On Wed, Dec 9, 2015 at 9:45 AM, Phil Steitz  wrote:
>>> On 12/9/15 9:13 AM, luc wrote:
 Le 2015-12-09 16:49, Phil Steitz a écrit :
>> On Dec 9, 2015, at 8:39 AM, luc  wrote:
>>
>> Hi all,
>>
>> The development status for the field-ode branch (linked to issue
>> MATH-1288)
>> is now stable. I will therefore merge this branch into the
>> MATH_3_X branch
>> very soon now.
> What about master?
 I may merge all the commits as a single one in master or reproduce
 all
 commits from the branch one by one. A single big commit will
 probably be
 more friendly to the list. Separate commits will show the development
 steps.

 Also in master, the primitive double API for ode will be changed to
 be consistent with the new API developed for field ode. I could not
 do that in 3.X because these are publis user-oriented interfaces, so
 changing them would introduce a huge incompatibility.

 At the end, this is a new feature, not a modification of an
 existing feature,
 so I don't know if the steps before the feature is complete are
 interesting or not. These steps will be available in the MATH_3_X
 branch (and in the field-ode branch), but not in the master branche
 if I do a single big commit.


 What do you prefer?
>>> I am not sure.  I just wanted to make sure the new feature got into
>>> master as well as 3_X.
>>>
>>> I have been following the branch commits and as long as the record
>>> of these granular commits can be traced, I am fine with the single
>>> commit to master.  If you take the single commit approach to master,
>>> will the steps be traceable from master or will we have to go back
>>> to 3_X to trace things?  If the latter, it would be good to add
>>> something to the big commit message to direct later archaeological
>>> investigations back to the 3_X branch.
> As MATH_3_X and master have forked a few months ago and will never
> benn merged back, nothing in master will track back to anything
> in MATH_3_X that occurred after the fork.
>
>>> What is the standard git way
>>> of dealing with kind of thing?
> The standard way is to use a regular merge, but it doesn't work for us
> as per our directories layout change.
>
>> Just an outsider's perspective, I would expect that people would want
>> the branches to be merged without squashing all the commits down into
>> one mega commit. It's unfortunate that an email would be generated for
>> each one of these, but oh well. ;)
> OK, then I think I will try to replay all the commits. It will just be a
> few lines scripting with shell and sed. It will mean lots of mail on
> the list. The good news will be we can refer back to the tracks at some
> time in the future.
>
> I don't now if I will do it very soon or not, it will depend on
> available time and priorities.

Personally, I would rather see your available [math] time spent
advancing the code :)  Every backward-looking use case I can imagine
would be served by an indication in the large master commit that
granular history is in the 3_X branch, which is not going away. 
What you might do is separate out the 4.x-specific refactoring into
a separate set of commits.  I guess that will happen naturally anyway.

Phil
>
> best regards,
> Luc
>
>>> Phil
>> Regards,
>> James
>>
>> -
>> 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 commons-io 2.5 based on RC1

2015-12-09 Thread Kristian Rosenvold 
The Charset related tests fail due some character set that is installed in
your environment that is nor present in mine (commons.io builds fine on IBM
jdk6 & 7 here). To try to identify which character set we're talking about
I added the name to the assert message; there is already logic in place in
these tests to ignore specific character sets.

If you can run the latest commons-io trunk on your system right now, you
should get the name of the failing character set and hopefully I can
install it here and analyze the problem a little more or ignore that
specific character set.

The TailerTest was doing two different things which are both problematic;
it was relying on Thread.sleep(X) sleeping anything remotelly similar to X
ms, which is known to be untrue. Additionally there is a reliance on gc
actually running in this interval, which is even more questionable.

I have "fixed" the sleep part of this issue, leaving the reliance on
deterministic gc invocation (which I still believe cannot really be done
reliably without resorting to the debugger api). If this test fails on any
of your environments I'm partial to just deleting the tests as "not
possible".

Let me know about the charset and any other problems you might encounter
and I'll try to fix them  before spinning RC2 (hopefully this weekend).

Kristian


2015-11-26 14:20 GMT+01:00 Jörg Schaible :

> Kristian Rosenvold wrote:
>
> >   We have fixed quite a few bugs and added some significant
> > enhancements since commons-io was released,
> >   so I would like to release commons-io 2.5
> >
> >   Foo 2.5 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/io/ (svn revision
> > 11266)
> >
> >   Maven artifacts are here:
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1123
> >
> >   Details of changes since 2.4 are in the release notes:
> > https://dist.apache.org/repos/dist/dev/commons/io/RELEASE-NOTES.txt
> >
> http://people.apache.org/~krosenvold/commons-io-2.5-RC1/changes-report.html
> >
> >   I have tested this with JDK 1.6, 1.7 and 1.8.
> >
> >   The tag is here:
> >
> https://svn.apache.org/repos/asf/commons/proper/io/tags/commons-io-2.5-RC1
> > (r1715890)
> >
> >   Site:
> >  http://people.apache.org/~krosenvold/commons-io-2.5-RC1/
> >   (note some *relative* links are broken and the 2.5 directories are
> >   not yet created - these will be OK once the site is deployed)
> >
> >   Clirr Report (compared to 2.4):
> >
> http://people.apache.org/~krosenvold/commons-io-2.5-RC1/clirr-report.html
> >
> >
> >   RAT Report:
> >
> http://people.apache.org/~krosenvold/commons-io-2.5-RC1/rat-report.html
> >
> >   KEYS:
> >   https://www.apache.org/dist/commons/KEYS
> >
> >   Please review the release candidate and vote.
> >   This vote will close no sooner that 72 hours from now, i.e. after
> > 19:00 CET 26-March 2015
> >
> >   [ ] +1 Release these artifacts
> >   [ ] +0 OK, but...
> >   [ ] -0 OK, but really should fix...
> >   [ ] -1 I oppose this release because...
>
>
> IBM JDK 1.6 fails (as usual):
> === %< ===
> Failed tests:
>   CharSequenceInputStreamTest.testBufferedRead_AvailableCharset:96-
> >testBufferedRead:72 bytes should agree expected:<65> but was:<71>
>   WriterOutputStreamTest.testUTF16WithSingleByteWrite:81-
> >testWithSingleByteWrite:47 expected:<[à peine arrivés nous entrâmes dans
> sa
> chambre]> but was:<[＀ 瀀攀椀渀攀 愀爀爀椀瘀猀 渀漀甀猀 攀渀琀爀洀攀猀 搀愀渀猀 猀愀 挀栀愀洀戀爀]>
> Tests in error:
>   BOMInputStreamTest.testReadXmlWithBOMUcs2:602->parseXml:158 » SAXParse
> Content...
>   BOMInputStreamTest.testReadXmlWithBOMUcs4:615->parseXml:158 » SAXParse
> Content...
>   BOMInputStreamTest.testReadXmlWithBOMUtf32Be:638->parseXml:158 » SAXParse
> Inva...
>   BOMInputStreamTest.testReadXmlWithBOMUtf32Le:647->parseXml:158 » SAXParse
> Inva...
>   BOMInputStreamTest.testReadXmlWithoutBOMUtf32Be:664->parseXml:158 »
> SAXParse I...
>   BOMInputStreamTest.testReadXmlWithoutBOMUtf32Le:672->parseXml:158 »
> SAXParse I...
>   CharSequenceInputStreamTest.testAvailable:430->testAvailableSkip:391 »
> UnsupportedOperation
>
> Tests run: 1156, Failures: 2, Errors: 7, Skipped: 2
> === %< ===
>
> IBM JDK 1.7 fails also:
> === %< ===
> Failed tests:
>   CharSequenceInputStreamTest.testBufferedRead_AvailableCharset:96-
> >testBufferedRead:72 bytes should agree expected:<111> but was:<-3>
>   WriterOutputStreamTest.testUTF16WithSingleByteWrite:81-
> >testWithSingleByteWrite:47 expected:<[à peine arrivés nous entrâmes dans
> sa
> chambre]> but was:<[＀ 瀀攀椀渀攀 愀爀爀椀瘀猀 渀漀甀猀 攀渀琀爀洀攀猀 搀愀渀猀 猀愀 挀栀愀洀戀爀]>
> Tests in error:
>   BOMInputStreamTest.testReadXmlWithBOMUcs2:602->parseXml:158 » SAXParse
> Content...
>   BOMInputStreamTest.testReadXmlWithBOMUcs4:615->parseXml:158 » SAXParse
> Content...
>   BOMInputStreamTest.testReadXmlWithBOMUtf32Be:638->parseXml:158 » SAXParse
> Inva...
>   BOMI

Re: [math] branch merge to come, prepare for a huge flood of git messages

2015-12-09 Thread Luc Maisonobe 
Le 09/12/2015 19:22, James Ring a écrit :
> On Wed, Dec 9, 2015 at 9:45 AM, Phil Steitz  wrote:
>> On 12/9/15 9:13 AM, luc wrote:
>>> Le 2015-12-09 16:49, Phil Steitz a écrit :
> On Dec 9, 2015, at 8:39 AM, luc  wrote:
>
> Hi all,
>
> The development status for the field-ode branch (linked to issue
> MATH-1288)
> is now stable. I will therefore merge this branch into the
> MATH_3_X branch
> very soon now.

 What about master?
>>>
>>> I may merge all the commits as a single one in master or reproduce
>>> all
>>> commits from the branch one by one. A single big commit will
>>> probably be
>>> more friendly to the list. Separate commits will show the development
>>> steps.
>>>
>>> Also in master, the primitive double API for ode will be changed to
>>> be consistent with the new API developed for field ode. I could not
>>> do that in 3.X because these are publis user-oriented interfaces, so
>>> changing them would introduce a huge incompatibility.
>>>
>>> At the end, this is a new feature, not a modification of an
>>> existing feature,
>>> so I don't know if the steps before the feature is complete are
>>> interesting or not. These steps will be available in the MATH_3_X
>>> branch (and in the field-ode branch), but not in the master branche
>>> if I do a single big commit.
>>>
>>>
>>> What do you prefer?
>>
>> I am not sure.  I just wanted to make sure the new feature got into
>> master as well as 3_X.
>>
>> I have been following the branch commits and as long as the record
>> of these granular commits can be traced, I am fine with the single
>> commit to master.  If you take the single commit approach to master,
>> will the steps be traceable from master or will we have to go back
>> to 3_X to trace things?  If the latter, it would be good to add
>> something to the big commit message to direct later archaeological
>> investigations back to the 3_X branch.

As MATH_3_X and master have forked a few months ago and will never
benn merged back, nothing in master will track back to anything
in MATH_3_X that occurred after the fork.

>> What is the standard git way
>> of dealing with kind of thing?

The standard way is to use a regular merge, but it doesn't work for us
as per our directories layout change.

> 
> Just an outsider's perspective, I would expect that people would want
> the branches to be merged without squashing all the commits down into
> one mega commit. It's unfortunate that an email would be generated for
> each one of these, but oh well. ;)

OK, then I think I will try to replay all the commits. It will just be a
few lines scripting with shell and sed. It will mean lots of mail on
the list. The good news will be we can refer back to the tracks at some
time in the future.

I don't now if I will do it very soon or not, it will depend on
available time and priorities.

best regards,
Luc

> 
>> Phil
> 
> Regards,
> James
> 
> -
> 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

[GitHub] commons-collections pull request: Fix not being dis...

2015-12-09 Thread RAnders00 
GitHub user RAnders00 opened a pull request:

https://github.com/apache/commons-collections/pull/16

Fix  not being displayed in javadoc



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

$ git pull https://github.com/RAnders00/commons-collections patch-1

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

https://github.com/apache/commons-collections/pull/16.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 #16


commit dcf43b573e176c461c40f39c9495a1e3ad0e0d57
Author: Ruben Anders 
Date:   2015-12-09T18:44:44Z

Fix  not being displayed in javadoc




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

Re: [math] branch merge to come, prepare for a huge flood of git messages

2015-12-09 Thread James Ring 
On Wed, Dec 9, 2015 at 9:45 AM, Phil Steitz  wrote:
> On 12/9/15 9:13 AM, luc wrote:
>> Le 2015-12-09 16:49, Phil Steitz a écrit :
 On Dec 9, 2015, at 8:39 AM, luc  wrote:

 Hi all,

 The development status for the field-ode branch (linked to issue
 MATH-1288)
 is now stable. I will therefore merge this branch into the
 MATH_3_X branch
 very soon now.
>>>
>>> What about master?
>>
>> I may merge all the commits as a single one in master or reproduce
>> all
>> commits from the branch one by one. A single big commit will
>> probably be
>> more friendly to the list. Separate commits will show the development
>> steps.
>>
>> Also in master, the primitive double API for ode will be changed to
>> be consistent with the new API developed for field ode. I could not
>> do that in 3.X because these are publis user-oriented interfaces, so
>> changing them would introduce a huge incompatibility.
>>
>> At the end, this is a new feature, not a modification of an
>> existing feature,
>> so I don't know if the steps before the feature is complete are
>> interesting or not. These steps will be available in the MATH_3_X
>> branch (and in the field-ode branch), but not in the master branche
>> if I do a single big commit.
>>
>>
>> What do you prefer?
>
> I am not sure.  I just wanted to make sure the new feature got into
> master as well as 3_X.
>
> I have been following the branch commits and as long as the record
> of these granular commits can be traced, I am fine with the single
> commit to master.  If you take the single commit approach to master,
> will the steps be traceable from master or will we have to go back
> to 3_X to trace things?  If the latter, it would be good to add
> something to the big commit message to direct later archaeological
> investigations back to the 3_X branch.  What is the standard git way
> of dealing with kind of thing?

Just an outsider's perspective, I would expect that people would want
the branches to be merged without squashing all the commits down into
one mega commit. It's unfortunate that an email would be generated for
each one of these, but oh well. ;)

> Phil

Regards,
James

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

Re: [math] branch merge to come, prepare for a huge flood of git messages

2015-12-09 Thread Phil Steitz 
On 12/9/15 9:13 AM, luc wrote:
> Le 2015-12-09 16:49, Phil Steitz a écrit :
>>> On Dec 9, 2015, at 8:39 AM, luc  wrote:
>>>
>>> Hi all,
>>>
>>> The development status for the field-ode branch (linked to issue
>>> MATH-1288)
>>> is now stable. I will therefore merge this branch into the
>>> MATH_3_X branch
>>> very soon now.
>>
>> What about master?
>
> I may merge all the commits as a single one in master or reproduce
> all
> commits from the branch one by one. A single big commit will
> probably be
> more friendly to the list. Separate commits will show the development
> steps.
>
> Also in master, the primitive double API for ode will be changed to
> be consistent with the new API developed for field ode. I could not
> do that in 3.X because these are publis user-oriented interfaces, so
> changing them would introduce a huge incompatibility.
>
> At the end, this is a new feature, not a modification of an
> existing feature,
> so I don't know if the steps before the feature is complete are
> interesting or not. These steps will be available in the MATH_3_X
> branch (and in the field-ode branch), but not in the master branche
> if I do a single big commit.
>
>
> What do you prefer?

I am not sure.  I just wanted to make sure the new feature got into
master as well as 3_X.  

I have been following the branch commits and as long as the record
of these granular commits can be traced, I am fine with the single
commit to master.  If you take the single commit approach to master,
will the steps be traceable from master or will we have to go back
to 3_X to trace things?  If the latter, it would be good to add
something to the big commit message to direct later archaeological
investigations back to the 3_X branch.  What is the standard git way
of dealing with kind of thing?

Phil
>
> best regards,
> Luc
>
>>
>> Phil
>>> Unfortunately, our git/mail integration resends the mails
>>> corresponding to all the individual commits performed on a
>>> branch when it
>>> is merged into another branch. So the merge will probably
>>> generate a huge
>>> flood of mails to the list, corresponding to all the work done
>>> on the
>>> field-ode branch since last month.
>>>
>>> I apologize for this flood.
>>>
>>> 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
>
> -
> 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: [jexl] Call for review of JEXL 3.0

2015-12-09 Thread sebb 
On 8 December 2015 at 17:18, Emmanuel Bourg  wrote:
> Hi all,
>
> JEXL 3.0 is ready to be released, thanks to the efforts of Henri
> Biestro. I'd like to help a bit and manage the next release, however
> before cutting the release I'd like to call for reviews of the code
> base, so the vote can then focus on checking the artifacts.

I made some fixes to eliminate all protected and public variables
(except static constants) in the non-internal code.
Mostly there were already getters/setters so I used those.
Some fields have been left as package-protected; this was easier than
adding setter/getters, and the fields can still be made private later
without breaking the API.
(3rd party code should not rely on package-protected items of any kind)

Since this is a new release, there is no API to break, and the changes
will allow subsequent changes without needing to break the API.

I also had to fix the download page settings in the POM.
Note that the CP default is to use the artifactId as the archive name prefix.
Since this has changed, the historic releases have a different
artifact id, so the name has to be overridden.

> If no outstanding issue is raised I'll start the vote on Friday.

Note: I think Jexl 2.1.2 could also be released.
I don't have time this year.

> Thank you for your help,
>
> Emmanuel Bourg
>
> -
> 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] branch merge to come, prepare for a huge flood of git messages

2015-12-09 Thread luc 

Le 2015-12-09 16:49, Phil Steitz a écrit :

On Dec 9, 2015, at 8:39 AM, luc  wrote:

Hi all,

The development status for the field-ode branch (linked to issue 
MATH-1288)
is now stable. I will therefore merge this branch into the MATH_3_X 
branch

very soon now.


What about master?


I may merge all the commits as a single one in master or reproduce all
commits from the branch one by one. A single big commit will probably be
more friendly to the list. Separate commits will show the development
steps.

Also in master, the primitive double API for ode will be changed to
be consistent with the new API developed for field ode. I could not
do that in 3.X because these are publis user-oriented interfaces, so
changing them would introduce a huge incompatibility.

At the end, this is a new feature, not a modification of an existing 
feature,

so I don't know if the steps before the feature is complete are
interesting or not. These steps will be available in the MATH_3_X
branch (and in the field-ode branch), but not in the master branche
if I do a single big commit.


What do you prefer?

best regards,
Luc



Phil

Unfortunately, our git/mail integration resends the mails
corresponding to all the individual commits performed on a branch when 
it
is merged into another branch. So the merge will probably generate a 
huge

flood of mails to the list, corresponding to all the work done on the
field-ode branch since last month.

I apologize for this flood.

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


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

Re: [math] branch merge to come, prepare for a huge flood of git messages

2015-12-09 Thread Phil Steitz 


> On Dec 9, 2015, at 8:39 AM, luc  wrote:
> 
> Hi all,
> 
> The development status for the field-ode branch (linked to issue MATH-1288)
> is now stable. I will therefore merge this branch into the MATH_3_X branch
> very soon now.

What about master?

Phil
> Unfortunately, our git/mail integration resends the mails
> corresponding to all the individual commits performed on a branch when it
> is merged into another branch. So the merge will probably generate a huge
> flood of mails to the list, corresponding to all the work done on the
> field-ode branch since last month.
> 
> I apologize for this flood.
> 
> 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

[math] branch merge to come, prepare for a huge flood of git messages

2015-12-09 Thread luc 

Hi all,

The development status for the field-ode branch (linked to issue 
MATH-1288)
is now stable. I will therefore merge this branch into the MATH_3_X 
branch

very soon now. Unfortunately, our git/mail integration resends the mails
corresponding to all the individual commits performed on a branch when 
it
is merged into another branch. So the merge will probably generate a 
huge

flood of mails to the list, corresponding to all the work done on the
field-ode branch since last month.

I apologize for this flood.

best regards,
Luc

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

Re: [SCXML] Proposal to move to Java 8 minimum and drop/replace XML/XPath support with JSON

2015-12-09 Thread Benedikt Ritter 
Hello Ate,

2015-12-09 10:15 GMT+01:00 Ate Douma :

> Since early this year the progress and development of Commons SCXML 2.0 has
> severely declined because of two major technical hurdles, and thereafter of
> both motivation and lack of time:
>
> - The SCXML XML/XPath datamodel support has been dropped from the final
> W3C SCXML 1.0 specification [1], because of too many functional and
> semantic
> complications and limitation, as well as lack of interest for implementing
> it.
>
> The implementation of the XML/XPath datamodel in Commons SCXML has been
> problematic for precisely the same reasons.
> And not being able to provide such implementation properly by us (Commons
> SCXML) actually has been one (final) argument for dropping it from the
> specification...
>
> - The implementation of the Javascript datamodel support based on the
> old/outdated Rhino Javascript engine in Java 7 and below, turned out to be
> quite difficult. While it turns out to be much easier and reliable, but
> different, with the new Nashorn Javascript engine in Java 8+.
>
> After bringing this first up on the user@ list earlier this week, I now
> want to
> propose the following major changes to revive the further development
> towards
> Commons SCXML 2.0:
> - drop the support for XML/XPath based datamodel, and instead introduce a
> much
>   easier to implement and support JSON datamodel as alternative, for all
> current
>   Commons SCXML support 'languages': JEXL, Groovy and Javascript.
> - bump the minimum Java version to 8 so we can leverage and only need to
> support
>   the Nashorn Javascript engine
>
> The only user response so far on user@ is fully in favor of these changes,
> and both myself and Woonsan Ko are motivated to continue developing and
> completing the goals for Commons SCXML 2.0 based on these changes.
>
> If nobody here has strong arguments against the above proposal (and
> assuming
> lazy consensus otherwise), we would like to start on these changes shortly,
> before the end of the year.
>

I'm all for upgrading to Java 8 if it eases the development of Commons
SCXML. Go for it.

Regards,
Benedikt


>
> Kind regards,
> Ate Douma
> Woonsan Ko
>
> [1] http://www.w3.org/TR/2015/REC-scxml-20150901/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [SCXML] Proposal to move to Java 8 minimum and drop/replace XML/XPath support with JSON

2015-12-09 Thread bren 

Good morning,

If you need some help in testing or development process, I could help 
with some hours per month.


I was using the first version.

Juan Antonio

El 2015-12-09 10:15, Ate Douma escribió:
Since early this year the progress and development of Commons SCXML 2.0 
has
severely declined because of two major technical hurdles, and 
thereafter of

both motivation and lack of time:

- The SCXML XML/XPath datamodel support has been dropped from the final
W3C SCXML 1.0 specification [1], because of too many functional and 
semantic
complications and limitation, as well as lack of interest for 
implementing it.


The implementation of the XML/XPath datamodel in Commons SCXML has been
problematic for precisely the same reasons.
And not being able to provide such implementation properly by us 
(Commons

SCXML) actually has been one (final) argument for dropping it from the
specification...

- The implementation of the Javascript datamodel support based on the
old/outdated Rhino Javascript engine in Java 7 and below, turned out to 
be

quite difficult. While it turns out to be much easier and reliable, but
different, with the new Nashorn Javascript engine in Java 8+.

After bringing this first up on the user@ list earlier this week, I now 
want to
propose the following major changes to revive the further development 
towards

Commons SCXML 2.0:
- drop the support for XML/XPath based datamodel, and instead introduce 
a much
  easier to implement and support JSON datamodel as alternative, for 
all current

  Commons SCXML support 'languages': JEXL, Groovy and Javascript.
- bump the minimum Java version to 8 so we can leverage and only need 
to support

  the Nashorn Javascript engine

The only user response so far on user@ is fully in favor of these 
changes,

and both myself and Woonsan Ko are motivated to continue developing and
completing the goals for Commons SCXML 2.0 based on these changes.

If nobody here has strong arguments against the above proposal (and 
assuming
lazy consensus otherwise), we would like to start on these changes 
shortly,

before the end of the year.

Kind regards,
Ate Douma
Woonsan Ko

[1] http://www.w3.org/TR/2015/REC-scxml-20150901/

-
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

[SCXML] Proposal to move to Java 8 minimum and drop/replace XML/XPath support with JSON

2015-12-09 Thread Ate Douma 

Since early this year the progress and development of Commons SCXML 2.0 has
severely declined because of two major technical hurdles, and thereafter of
both motivation and lack of time:

- The SCXML XML/XPath datamodel support has been dropped from the final
W3C SCXML 1.0 specification [1], because of too many functional and semantic
complications and limitation, as well as lack of interest for implementing it.

The implementation of the XML/XPath datamodel in Commons SCXML has been
problematic for precisely the same reasons.
And not being able to provide such implementation properly by us (Commons
SCXML) actually has been one (final) argument for dropping it from the
specification...

- The implementation of the Javascript datamodel support based on the
old/outdated Rhino Javascript engine in Java 7 and below, turned out to be
quite difficult. While it turns out to be much easier and reliable, but
different, with the new Nashorn Javascript engine in Java 8+.

After bringing this first up on the user@ list earlier this week, I now want to
propose the following major changes to revive the further development towards
Commons SCXML 2.0:
- drop the support for XML/XPath based datamodel, and instead introduce a much
  easier to implement and support JSON datamodel as alternative, for all current
  Commons SCXML support 'languages': JEXL, Groovy and Javascript.
- bump the minimum Java version to 8 so we can leverage and only need to support
  the Nashorn Javascript engine

The only user response so far on user@ is fully in favor of these changes,
and both myself and Woonsan Ko are motivated to continue developing and
completing the goals for Commons SCXML 2.0 based on these changes.

If nobody here has strong arguments against the above proposal (and assuming
lazy consensus otherwise), we would like to start on these changes shortly,
before the end of the year.

Kind regards,
Ate Douma
Woonsan Ko

[1] http://www.w3.org/TR/2015/REC-scxml-20150901/

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