[GitHub] commons-io pull request #14: [IO-480] Removed the deprectaed method closeQui...

[rajivpjs]

Github user rajivpjs closed the pull request at:

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


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

Jenkins build is back to normal : commons-dbcp #3

[Apache Jenkins Server]

See 


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

Jenkins build is back to normal : commons-dbcp » Apache Commons DBCP #3

[Apache Jenkins Server]

See 



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

Early Access builds of JDK 8u112 b03, JDK 9 b128 are available on java.net

[Rory O'Donnell]

Hi Benedikt,

Early Access b128  for JDK 9 is 
available on java.net, summary of  changes are listed here 
.


Early Access b127  (#5304) for JDK 9 with 
Project Jigsaw is available on java.net, summary of changes are listed 
here 



Early Access b03  for JDK 8u112 is 
available on java.net, summary of  changes are listed here 



Alan Bateman posted new EA builds contain initial implementation of 
current proposals , more info [0]


   The jigsaw/jake forest has been updated with an initial
   implementation of the proposals that Mark brought to the
   jpms-spec-experts mailing list last week. For those that don't build
   from source then the EA build/downloads [1] has also been refreshed.


Rgds,Rory

[0] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008467.html
[1] https://jdk9.java.net/jigsaw/

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

RE: [CRYPTO]1.0.0 Release Plan

[Sun, Dapeng]

Hi all,

I want to kick off the process of the first release on July 25th (next Monday) 
, please let me know if you have any concerns.

And here is the latest binary.(contains Linux/Mac/Windows)
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.0.0-SNAPSHOT/commons-crypto-1.0.0-20160722.085755-6.jar

Thanks & Regards
Dapeng

-Original Message-
From: Sun, Dapeng [mailto:dapeng@intel.com] 
Sent: Tuesday, July 19, 2016 6:48 PM
To: Commons Developers List
Subject: RE: [CRYPTO]1.0.0 Release Plan

Thank Dennis for your suggestion, but it seems maven and apache site don't 
provide the feature. And the native files are all small size, putting them into 
one jar would be okay.

Regards
Dapeng

-Original Message-
From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org]
Sent: Thursday, July 14, 2016 11:18 PM
To: 'Commons Developers List'
Subject: RE: [CRYPTO]1.0.0 Release Plan

I don't know if the deployment method for the binaries (.jar, etc.) of these 
releases provides useful download statistics for the Commons project.

If it does, differentiating by the native platforms for which there are native 
shared-libraries that need to also be on the runtime path (e.g., to work with 
JNI) is important.  You will have some evidence for what your users intend to 
run the related classes on.

That might be important to know if you are considering a triage with respect to 
native support.

 - Dennis

> -Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Tuesday, July 12, 2016 09:09
> To: Commons Developers List 
> Subject: Re: [CRYPTO]1.0.0 Release Plan
> 
> On 12 July 2016 at 14:54, sebb  wrote:
> > On 12 July 2016 at 14:20, Sun, Dapeng  wrote:
> >> Separating artifacts for each native library, I think it should be
> same as copying the native binary files. We also need to collect the 
> artifacts for unpacking and bundling.
> >
> > Yes.
> >
> >> About using the 'all' artifact, users may be confused about
> downloading the artifacts for all the different platforms, especially 
> for the platforms they don't need.
> >
> > I think we could have a separate project that creates a jar 
> > containing the Java classes plus all released native builds.
> >
> > AIUI the code can automatically extract the native code from the 
> > jar, so it should be easy to use.
> >
> > If we also release the Java classes and native builds as separate 
> > jars, then users would have the choice:
> >
> > - download the jar containing the Java classes plus all released
> native builds
> > - download the Java classes jar plus any native builds they need
> >
> > Or maybe when releasing a native build, we could package it with the 
> > Java classes.
> 
> It looks like that already happens - the MacOSX installed jar includes 
> the jnilib file.
> 
[  ]


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

B CB  [  
X  ܚX KK[XZ[
 ] ][  X  ܚX P  [[ۜ˘\X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
 ] Z[  [[ۜ˘\X K ܙ B