Re: Wondering VFS will support Read/Write on Google Cloud Storage?

[楊閔富]

At first I mount my Google Cloud Storage onto directory /tmp/gcs using
`gcsfuse`,
then I create a small project: https://github.com/tilumi/apache-vfs-debug
for testing it VFS can detect my mounting point or not.

the execution log:
```
$ls -al /tmp/gcs
total 0
drwxrwxrwx 1 root root 0 Jun 17 00:42 hive-warehouse
drwxrwxrwx 1 root root 0 Jun 17 00:42 softwares
drwxrwxrwx 1 root root 0 Jun 17 00:42 zeppelin-notebooks
$sudo java -cp apache-vfs-debug-1.0-SNAPSHOT-jar-with-dependencies.jar
Sample "file:///tmp/gcs"
false
$sudo java -cp apache-vfs-debug-1.0-SNAPSHOT-jar-with-dependencies.jar
Sample "file:///tmp"
true
```
It seems that it cannot correctly identify the directory mounted by gcsfuse.


2017-06-15 16:48 GMT+08:00 Bernd Eckenfels :

> Hello,
>
> The Local file provider should be able to deal with fuse mounted
> directories. It is hard to say what the problem is. Can you tell us how the
> path is named, what operations you tried, what exceptions are happening and
> what `ls` is returning.
>
>
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: 楊閔富 
> Sent: Thursday, June 15, 2017 3:03:12 AM
> To: dev@commons.apache.org
> Subject: Re: Wondering VFS will support Read/Write on Google Cloud Storage?
>
> Another question is that VFS cannot identify directory mounted by fuse?
>
> 2017-06-15 8:47 GMT+08:00 楊閔富 :
>
> > Hi
> >
> > I am using Zeppelin on Google Cloud DataProc and want make the notebooks
> > to be stored on the Google Cloud Storage.
> > At first, I used `gcsfuse`(https://github.com/
> GoogleCloudPlatform/gcsfuse)
> > to mount my Google Cloud Storage bucket as a local directory, but VFS
> used
> > by Zeppelin to manage files said the directory didn't exist.
> >
> > So I am wondering is support for Google Cloud Storage is in the VFS plan?
> > If yes, It's my pleasure to implement it. If not, why?
> >
>

Re: [all] Custom build containers in Travis-CI.

[Rob Tompkins]

> On Jun 16, 2017, at 5:07 AM, Benedikt Ritter  wrote:
> 
> Hi,
> 
>> Am 15.06.2017 um 15:17 schrieb Rob Tompkins :
>> 
>> Hello all,
>> 
>> We’ve started an experiment in [text] in regards to using travis-ci to build 
>> inside containers (specifically ibmjava at this point). It seems that it’s a 
>> non-standard practice with regards to travis-ci.
>> 
>> I suppose my question is: is anyone familiar with using travis-ci and 
>> specifying custom containers in which to run your build? Give the 
>> .travis.yml a look in commons-text 
>> (https://github.com/apache/commons-text/blob/master/.travis.yml) and let me 
>> know what you think. Clearly we’re trying to use ibmjava to build the 
>> project, but it’s definitely running that build on each of the 3 
>> environments that we’re running in and exits with a 0 from the docker run 
>> command regardless of if the build fails.
>> 
>> Any thoughts?
> 
> I don’t think it is possible to implement this in a way that the ibm idk 
> build serves as a build environment the same why like the build in JDKs do.
> 
> Are there any plans by the travis team to make it possible to use ibm idk as 
> build environment? Maybe we can create a PR for that. That feels like a much 
> cleaner solution.

I will give a go at digging through the travis implementation and seeing if I 
can put something together for them for the IBM-jdk.

-Rob

> 
> Regards,
> Benedikt
> 
>> 
>> Cheers,
>> -Rob
> 
> 
> -
> 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-compress pull request #36: COMPRESS-410 Remove Non-NIO character set...

[sesuncedu]

GitHub user sesuncedu opened a pull request:

https://github.com/apache/commons-compress/pull/36

COMPRESS-410 Remove Non-NIO character set encoders.

As a special case, the UTF-8 encoder will replace malformed / unmappable 
input with '?'.
This behavior is required for compatibility with existing behavior.

Signed-off-by: Simon Spero 

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

$ git pull https://github.com/sesuncedu/commons-compress COMPRESS-410

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

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


commit 1c9e1d8218ccd102567273eebdfba187ca545fc8
Author: Simon Spero 
Date:   2017-06-17T00:17:13Z

COMPRESS-410 Remove Non-NIO character set encoders.
As a special case, the UTF-8 encoder will replace malformed / unmappable 
input with '?'.
This behavior is required for compatibility with existing behavior.

Signed-off-by: Simon Spero 




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

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

[GitHub] commons-fileupload pull request #8: FILEUPLOAD-283: add tests for the portle...

[kinow]

GitHub user kinow opened a pull request:

https://github.com/apache/commons-fileupload/pull/8

FILEUPLOAD-283: add tests for the portlet package

Initial tests for the portlet package. I believe there have been updates to 
the portlet specification(s) that have not been applied to Commons FileUpload 
yet. Hopefully, having unit tests will help us later when changing the package.

Removed strings like "US-ASCII" using the `StandardCharsets` class from 
Java 7.

There was a class -`FileUploadTestCase`- that was extended by other tests. 
But it became problematic as there were tests that would be common to any 
implementation of `FileUpload`, while other tests were specific to 
`ServletFileUpload`.

This pull request removed the inheritance from the tests, by a `Util` class 
(open to other suggestions) with methods for parsing uploads and for tests.

Tests related to `ServletFileUpload` are now in `ServletFileUploadTest`, in 
the `.servlet` package in the test sources.

Tests related to `PortletFileUpload` are now in `PortletFileUploadTest`, in 
the `.portlet` package in the test sources.

There are no functional changes in the tests. Coverage remained the same 
for other classes. For the `.portlet` package, it went from 0% to 60% in my 
local working copy.

There are lots of other parts that need better coverage, but at least I 
think having tests in separated classes will make it slightly easier to add 
more.

Cheers
Bruno

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

$ git pull https://github.com/kinow/commons-fileupload FILEUPLOAD-283

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

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


commit f8f529ee0baecc9262317cc5375af1eb42aadab4
Author: Bruno P. Kinoshita 
Date:   2017-06-11T05:23:07Z

FILEUPLOAD-283: add tests for the portlet package




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

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

[GitHub] commons-fileupload pull request #7: FILEUPLOAD-238: add tests for the portle...

[kinow]

Github user kinow closed the pull request at:

https://github.com/apache/commons-fileupload/pull/7


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

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

[GitHub] commons-fileupload pull request #7: FILEUPLOAD-238: add tests for the portle...

[kinow]

GitHub user kinow opened a pull request:

https://github.com/apache/commons-fileupload/pull/7

FILEUPLOAD-238: add tests for the portlet package

Initial tests for the portlet package. I believe there have been updates to 
the portlet specification(s) that have not been applied to Commons FileUpload 
yet. Hopefully, having unit tests will help us later when changing the package.

Removed strings like "US-ASCII" using the StandardCharsets class from Java 
7.

There was a class FileUploadTestCase that was extended by other tests. But 
it became problematic as there were tests that would be common to any 
implementation of FileUpload, while other tests were specific to 
ServletFileUpload.

This pull request removed the inheritance from the tests, by a Util class 
(open to other suggestions) with methods for parsing uploads and for tests.

Tests related to ServletFileUpload are now in ServletFileUploadTest, in the 
.servlet package in the test sources.

Tests related to PortletFileUpload are now in PortletFileUploadTest, in the 
.portlet package in the test sources.

There are no functional changes in the tests. Coverage remained the same 
for other classes. For the .portlet package, it went from 0% to 60% in my local 
working copy.

There are lots of other parts that need better coverage, but at least I 
think having tests in separated classes will make it slightly easier to add 
more.

Cheers
Bruno

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

$ git pull https://github.com/kinow/commons-fileupload FILEUPLOAD-238

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

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


commit 5adc6aefc39aaa39987e909259ef7f1e6bc38e72
Author: Bruno P. Kinoshita 
Date:   2017-06-11T05:23:07Z

FILEUPLOAD-238: add tests for the portlet package




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

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

[GitHub] commons-compress issue #33: add-some-Unit-Tests Added some Unit Tests to inc...

[coveralls]

Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://:/builds/12010056/badge)](https://:/builds/12010056)

Coverage increased (+0.4%) to 84.713% when pulling 
**e0500a6b5f5f3b29c2b9417d20f5dc5966fa47f4 on TheRealHaui:add-some-Unit-Tests** 
into **0d8ab18c86f4edb38a73de1512483bb5b876bb1f on apache:master**.



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

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

[GitHub] commons-compress issue #35: Compress 412

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-compress/pull/35
  

[![Coverage 
Status](https://:/builds/12009215/badge)](https://:/builds/12009215)

Coverage increased (+0.2%) to 84.678% when pulling 
**a0e5dd80b9ec43c315021701f9c2334be45c6271 on TheRealHaui:COMPRESS-412** into 
**7254daa3f84a2b7780050da936304ea42db324ef on apache:master**.



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

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

[GitHub] commons-compress issue #33: add-some-Unit-Tests Added some Unit Tests to inc...

[TheRealHaui]

Github user TheRealHaui commented on the issue:

https://github.com/apache/commons-compress/pull/33
  
Link to the pull request: https://github.com/apache/commons-compress/pull/35


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

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

[GitHub] commons-compress pull request #35: Compress 412

[TheRealHaui]

GitHub user TheRealHaui opened a pull request:

https://github.com/apache/commons-compress/pull/35

Compress 412

Fixed Jira issue Compress 412: 
https://issues.apache.org/jira/browse/COMPRESS-412

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

$ git pull https://github.com/TheRealHaui/commons-compress COMPRESS-412

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

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


commit 2f45456527f2631ef8b4bb09aa0ad30afda02b5f
Author: Michael Hausegger 
Date:   2017-06-13T21:47:50Z

add-some-Unit-Tests Added some Unit Tests to increase code coverage.

commit 96ca8ceeddbd20ec38b9211260b4b91107b0be2d
Author: Michael Hausegger 
Date:   2017-06-16T18:12:20Z

add-some-Unit-Tests Removed @author tags in comments.

commit 5e5dc7f032ffb5b3818410e23d7881a8def46f3d
Author: Michael Hausegger 
Date:   2017-06-16T18:22:10Z

add-some-Unit-Tests Removed test testGetValueThrowsNullPointerException in 
class ChecksumCalculatingInputStreamTest. Test represented a bug/defect which 
is going to be fixed in a different branch.

commit be0f11f4dbffb5ca1f903a6f07de744687d303c3
Author: Michael Hausegger 
Date:   2017-06-16T18:38:00Z

add-some-Unit-Tests Minor variable renaming.

commit 3b46bb5dc3aeb3ca68062c10589e049c9eb8551d
Author: Michael Hausegger 
Date:   2017-06-16T18:44:40Z

add-some-Unit-Tests Added myself as contributor to pom.xml as "requested" 
by Stefan Bodewig.

commit a0e5dd80b9ec43c315021701f9c2334be45c6271
Author: Michael Hausegger 
Date:   2017-06-16T19:30:03Z

COMPRESS-412 NullPointerException defect in 
ChecksumCalculatingInputStream#getValue() fixed.




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

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

[GitHub] commons-compress issue #33: add-some-Unit-Tests Added some Unit Tests to inc...

[TheRealHaui]

Github user TheRealHaui commented on the issue:

https://github.com/apache/commons-compress/pull/33
  
@bodewig 
Thank you for your kind response!
Really appreciate that!

Therefore I've made all the changes you requested/proposed.
And of course added myself as a contributor as heavily requested by you.
Really couldn't disappoint you regarding that special topic. :-)

Furthermore I've created a Jira Task for the bespoken bug: 
https://issues.apache.org/jira/browse/COMPRESS-412
And fixed it in an own branch which I've commited, created tests for and 
pushed too.
And which pull request I am going to link here in the next comment after 
I've created it.



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

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

[GitHub] commons-compress issue #33: add-some-Unit-Tests Added some Unit Tests to inc...

[coveralls]

Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://:/builds/12008449/badge)](https://:/builds/12008449)

Coverage increased (+0.3%) to 84.673% when pulling 
**3b46bb5dc3aeb3ca68062c10589e049c9eb8551d on TheRealHaui:add-some-Unit-Tests** 
into **0d8ab18c86f4edb38a73de1512483bb5b876bb1f on apache:master**.



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

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

[GitHub] commons-compress issue #33: add-some-Unit-Tests Added some Unit Tests to inc...

[coveralls]

Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://:/builds/12008341/badge)](https://:/builds/12008341)

Coverage increased (+0.3%) to 84.673% when pulling 
**be0f11f4dbffb5ca1f903a6f07de744687d303c3 on TheRealHaui:add-some-Unit-Tests** 
into **0d8ab18c86f4edb38a73de1512483bb5b876bb1f on apache:master**.



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

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

[GitHub] commons-io pull request #37: NOP change

[mweagle]

Github user mweagle closed the pull request at:

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


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

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

[GitHub] commons-compress issue #33: add-some-Unit-Tests Added some Unit Tests to inc...

[coveralls]

Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://:/builds/12007847/badge)](https://:/builds/12007847)

Coverage increased (+0.5%) to 84.812% when pulling 
**96ca8ceeddbd20ec38b9211260b4b91107b0be2d on TheRealHaui:add-some-Unit-Tests** 
into **0d8ab18c86f4edb38a73de1512483bb5b876bb1f on apache:master**.



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

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

[GitHub] commons-fileupload issue #1: Commons fileupload headerfix

[developerSid]

Github user developerSid commented on the issue:

https://github.com/apache/commons-fileupload/pull/1
  
Sure I can give that a try.  I had forgotten about having actually done 
this.


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

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

[GitHub] commons-io pull request #37: NOP change

[mweagle]

GitHub user mweagle opened a pull request:

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

NOP change



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

$ git pull https://github.com/ShiftLeftSecurity/commons-io pr_noop_test

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

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


commit f1ce063dd7f627b72173950416f4e848c424bdec
Author: Matt Weagle 
Date:   2017-06-07T21:59:50Z

NOP change

commit 2045cb052fa890db0193ee39add1fab4e52ac387
Author: Vlad A Ionescu 
Date:   2017-06-13T19:47:37Z

NOP change

commit 6dcf51c11812861b8d6bfae29f4fadd3c1d0f64b
Author: Matt Weagle 
Date:   2017-06-16T17:46:49Z

NOP change




---
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: [FUNCTOR] Why do we have an API module?

[Matt Benson]

Yes, the point of the API module was to define the functional interfaces
separately from the utility code around them; particularly pre-Java 8,
these could be used apart from the utility code from the core.

Matt

On Jun 16, 2017 4:27 AM, "Bruno P. Kinoshita"
 wrote:

No objection here too. I've been gathering some links about other libraries
and extensions to Java 8, to have a look at functor in the future and see
if it would be interesting to have something there, unless it made more
sense to put it on lang.


The reason for the API module, if memory serves me well, was to provide a
pre Java 8 implementation. This way we would have

- api
- an implementation for Java 7
- an implementation Java 8 that used Lambdas

Though right now, with Java 9 around the corner, a single module, trying to
provide useful code that doesn't fit in lang would be better IMHO.

Hope that helps.

Thanks
Bruno

From: Benedikt Ritter 
To: Commons Developers List 
Sent: Friday, 16 June 2017 9:04 PM
Subject: [FUNCTOR] Why do we have an API module?



Hi,


I’m about to start work on functor. Looking at the project, I wonder why we
have a separation bewteen an API module and implementations. This feels
like overkill to me for a project like functor. Further more I don’t see
other parties extending the stuff in the API module. If nobody objects, I’d
like to remove the multi-module build and move everything into a single
code base.


Regards,

Benedikt

-

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

JDK 9 EA Build 174 & JDK 8u152 b04 are available on jdk.java.net

[Rory O'Donnell]

Hi Benedikt, *
*
*JDK 9 Early Access*  build 174  is available at : - jdk.java.net/9/

A summary of all the changes in this build are listed here 
.


Changes which were introduced since the last availability email that may 
be of interest :


 * b172 - JDK-8179014 : JFileChooser with Windows look and feel crashes
   on win 10
 * b173 - JDK-8180582 : the bind to rmiregistry is rejected by
   registryFilter even though registryFilter is set
 * b174 - JDK-8181702  : deprecate for removal the following tool
   modules:jdk.xml.bind and jdk.xml.ws

*JDK 9 Schedule Update*

 * The new GA date for JDK 9 is now set to 2017-09-21 [1]
 * We have updated the OpenJDK JDK 9 project page [2] with the new
   milestones and GA date.


*JDK 8u152 Early Access*  build 04 is available at : - jdk.java.net/8/ 



A summary of all the changes in this build are listed here 
.

Information and schedules specific to OpenJDK 8u152 release [3]

Rgds,Rory

[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-June/005867.html
[2] http://openjdk.java.net/projects/jdk9/
[3] http://openjdk.java.net/projects/jdk8u/releases/8u152.html

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

Re: [FUNCTOR] Why do we have an API module?

[Bruno P. Kinoshita]

No objection here too. I've been gathering some links about other libraries and 
extensions to Java 8, to have a look at functor in the future and see if it 
would be interesting to have something there, unless it made more sense to put 
it on lang.


The reason for the API module, if memory serves me well, was to provide a pre 
Java 8 implementation. This way we would have

- api
- an implementation for Java 7
- an implementation Java 8 that used Lambdas 

Though right now, with Java 9 around the corner, a single module, trying to 
provide useful code that doesn't fit in lang would be better IMHO.

Hope that helps.

Thanks
Bruno

From: Benedikt Ritter 
To: Commons Developers List  
Sent: Friday, 16 June 2017 9:04 PM
Subject: [FUNCTOR] Why do we have an API module?



Hi,


I’m about to start work on functor. Looking at the project, I wonder why we 
have a separation bewteen an API module and implementations. This feels like 
overkill to me for a project like functor. Further more I don’t see other 
parties extending the stuff in the API module. If nobody objects, I’d like to 
remove the multi-module build and move everything into a single code base.


Regards,

Benedikt

-

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: [CLI] Changing the code style

[Amey Jadiye]

+1, keeping same discipline throughout components is always better, I liked
the way Lang and Text is maintained at this point.
not only checkstyle but findbug, clirr, javadoc  also should passed clean
for each component.

Regards,
Amey

On Fri, Jun 16, 2017 at 2:20 PM, Benedikt Ritter  wrote:

> Hi,
>
> CLI unlike other components has a custom code style. While other
> components pretty much follow the Sun code guidelines, the CLI code base
> uses a style like the Maven project. For me it’s annoying the switch code
> style configurations between components. If nobody objects, I’d like to
> apply the same rules like we have them in lang or text. I’m also going to
> enforce this rules using checkstyle and will make checkstyle part of the
> Travis CI build.
>
> Cheers,
> Benedikt
> -
> 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: [all] Custom build containers in Travis-CI.

[Benedikt Ritter]

> Am 16.06.2017 um 11:07 schrieb Benedikt Ritter :
> 
> Hi,
> 
>> Am 15.06.2017 um 15:17 schrieb Rob Tompkins :
>> 
>> Hello all,
>> 
>> We’ve started an experiment in [text] in regards to using travis-ci to build 
>> inside containers (specifically ibmjava at this point). It seems that it’s a 
>> non-standard practice with regards to travis-ci.
>> 
>> I suppose my question is: is anyone familiar with using travis-ci and 
>> specifying custom containers in which to run your build? Give the 
>> .travis.yml a look in commons-text 
>> (https://github.com/apache/commons-text/blob/master/.travis.yml) and let me 
>> know what you think. Clearly we’re trying to use ibmjava to build the 
>> project, but it’s definitely running that build on each of the 3 
>> environments that we’re running in and exits with a 0 from the docker run 
>> command regardless of if the build fails.
>> 
>> Any thoughts?
> 
> I don’t think it is possible to implement this in a way that the ibm idk 
> build serves as a build environment the same why like the build in JDKs do.
> 
> Are there any plans by the travis team to make it possible to use ibm idk as 
> build environment? Maybe we can create a PR for that. That feels like a much 
> cleaner solution.

Furthermore it should be possible to integrate the ASF build infrastructure 
with GitHub. So if we can’t get this into the Travis Build, maybe we can setup 
an IBM JDK build on builds.apache.org  set it up, so 
that it also reports build results at the pull request.

Regards.
Benedikt

> 
> Regards,
> Benedikt
> 
>> 
>> Cheers,
>> -Rob
> 

Re: [all] Custom build containers in Travis-CI.

[Benedikt Ritter]

Hi,

> Am 15.06.2017 um 15:17 schrieb Rob Tompkins :
> 
> Hello all,
> 
> We’ve started an experiment in [text] in regards to using travis-ci to build 
> inside containers (specifically ibmjava at this point). It seems that it’s a 
> non-standard practice with regards to travis-ci.
> 
> I suppose my question is: is anyone familiar with using travis-ci and 
> specifying custom containers in which to run your build? Give the .travis.yml 
> a look in commons-text 
> (https://github.com/apache/commons-text/blob/master/.travis.yml) and let me 
> know what you think. Clearly we’re trying to use ibmjava to build the 
> project, but it’s definitely running that build on each of the 3 environments 
> that we’re running in and exits with a 0 from the docker run command 
> regardless of if the build fails.
> 
> Any thoughts?

I don’t think it is possible to implement this in a way that the ibm idk build 
serves as a build environment the same why like the build in JDKs do.

Are there any plans by the travis team to make it possible to use ibm idk as 
build environment? Maybe we can create a PR for that. That feels like a much 
cleaner solution.

Regards,
Benedikt

> 
> Cheers,
> -Rob


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

Re: [Codec] we almost had a release...

[Benedikt Ritter]

Go for it ;-)

> Am 15.06.2017 um 21:34 schrieb Gary Gregory :
> 
> ... a couple of months ago. Fits and starts. Is anyone available for spit,
> polish, and release?
> 
> Gary


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

[FUNCTOR] Why do we have an API module?

[Benedikt Ritter]

Hi,

I’m about to start work on functor. Looking at the project, I wonder why we 
have a separation bewteen an API module and implementations. This feels like 
overkill to me for a project like functor. Further more I don’t see other 
parties extending the stuff in the API module. If nobody objects, I’d like to 
remove the multi-module build and move everything into a single code base.

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

Re: [CLI] Changing the code style

[Bruno P. Kinoshita]

No objection from me. +1 and thanks for taking care of it :)

Cheers
Bruno

From: Benedikt Ritter 
To: Commons Developers List  
Sent: Friday, 16 June 2017 8:50 PM
Subject: [CLI] Changing the code style



Hi,


CLI unlike other components has a custom code style. While other components 
pretty much follow the Sun code guidelines, the CLI code base uses a style like 
the Maven project. For me it’s annoying the switch code style configurations 
between components. If nobody objects, I’d like to apply the same rules like we 
have them in lang or text. I’m also going to enforce this rules using 
checkstyle and will make checkstyle part of the Travis CI build.


Cheers,

Benedikt

-

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

[CLI] Changing the code style

[Benedikt Ritter]

Hi,

CLI unlike other components has a custom code style. While other components 
pretty much follow the Sun code guidelines, the CLI code base uses a style like 
the Maven project. For me it’s annoying the switch code style configurations 
between components. If nobody objects, I’d like to apply the same rules like we 
have them in lang or text. I’m also going to enforce this rules using 
checkstyle and will make checkstyle part of the Travis CI build.

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

[GitHub] commons-compress pull request #34: COMPRESS-405 : Add javadoc for FixedLengt...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-compress/pull/34


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

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

[GitHub] commons-text issue #44: [TEXT-80]: Fixed confusing StrLookup API

[ameyjadiye]

Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-text/pull/44
  
Lets park this for 2.X release.


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