Jenkins build is back to normal : Commons-Compress » Apache Commons Compress #100

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-Compress #100

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

Re: [VFS] 2.1 Release Plan

As I recall, I performed the VFS 2.0 release. I did use the Maven release plugin. It has been so long that I have forgotten the details of what had to be done, but I know I ended up using it as the model for setting up Log4j 2’s build. As I recall I would sort of test “pre-releasing” by running

RE: [CRYPTO] Switch from JNI to JNA

Thanks folks. An alpha release is a good suggestion! I am checking with the Spark guys as to the Spark 2.0 code freeze timeline and check whether we can meet it with an alpha release While at Commons, we try move fast to make everything clean. Try best stabilize the API. If folks in community h

Re: [VFS] 2.1 Release Plan

Hello, see inline. Am Tue, 26 Apr 2016 18:05:01 -0400 schrieb Josh Elser : > Thanks for the great details, Bernd. Some questions/comments: > > I hadn't even stumbled across VFS-570 due to its lack of > fixVersion=2.1. Are there more that need to be correctly tagged which > could potentially blo

Re: [VFS] 2.1 Release Plan

Thanks for the great details, Bernd. Some questions/comments: I hadn't even stumbled across VFS-570 due to its lack of fixVersion=2.1. Are there more that need to be correctly tagged which could potentially block the release of 2.1? I'm not sure I follow you about the concern of using maven-

[Commons Wiki] Update of "VfsReleaseState" by BerndEckenfels

Dear Wiki user, You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification. The "VfsReleaseState" page has been changed by BerndEckenfels: https://wiki.apache.org/commons/VfsReleaseState?action=diff&rev1=19&rev2=20 = Upcoming commons-vfs2-2.1 release = +

Re: [VFS] 2.1 Release Plan

Yes, there is a BC breakage for providers, is that grounds for a package and Maven coordinate rename to vfs3? Gary On Tue, Apr 26, 2016 at 12:31 PM, Bernd Eckenfels wrote: > Hello Josh, > > I think a VFS 2.1 release would be cool and it is good that you > volunteer, so I dont object. My latest

[Commons Wiki] Update of "VfsReleaseState" by BerndEckenfels

Dear Wiki user, You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification. The "VfsReleaseState" page has been changed by BerndEckenfels: https://wiki.apache.org/commons/VfsReleaseState?action=diff&rev1=18&rev2=19 Comment: added some caveats * create and

Re: [VFS] 2.1 Release Plan

Hello Josh, I think a VFS 2.1 release would be cool and it is good that you volunteer, so I dont object. My latest todo list is here: https://wiki.apache.org/commons/VfsReleaseState As you can see, I did plan to do the release and did quite some work to get VFS into a releaseable state. But I am

Re: [VFS] 2.1 Release Plan

Best as I can see, Benson was able to do the commons-io 2.5 release after someone else added his key to the KEYS file (because had some separate karma being applied to it which was not included in the universal-commit change). Consider this my formal volunteer offer to be RM for commons-vfs 2.

Re: [lang] LANG-1221: add changes.xml entry. This closes #129 from github. Thanks to Pierre Templier

Gary Gregory schrieb am Mo., 25. Apr. 2016 um 23:35 Uhr: > IMO, fixing typos in Javadoc is not worth mentioning as changes.xml > entries. > If they have been explicitly contributed by someone, I think this contribution should be mentioned. Doc fixes by Commons developers don't have to be include

Re: [io] Make requirement Java 7?

On Apr 26, 2016 5:57 AM, "Dave Brosius" wrote: > > People stuck on Java 6, for whatever inane reason, are in a very restrictive use case, and as such are not likely doing 'progressive' things like upgrading 3rdparty jars. I just don't see the point of trying to support some of the new release's co

Re: [CRYTPO] Alpha release

There are also missing @Overrides that can be added. I'll create a Jira... On Apr 26, 2016 4:22 AM, "sebb" wrote: > I raised a couple of JIRAs (29,30) that would affect the API. > I hope these can be considered for the first release. > > I would be happy to commit some or all of the necessary cha

Re: Gary's presence on-line...

On Mon, Apr 25, 2016 at 10:23 PM, Gary Gregory wrote: > ... will be on/off until 2016-05-4 due to ISP incompetence (moving house > and switching from Frontier to Time Warner). > > Please be patient if you expect something from me ;-) Hope, you can be patient. I, most likely, wouldn't. :-) --

Re: [VFS] 2.1 Release Plan

Thanks Matt and Gary. I do recall seeing the asf-wide note that my commit-bit also applies to commons-*. Thanks for bringing that up. Specifically though, I am only interested in cutting a release -- if we can get a new release cut that we can use downstream, that increases the likelihood that

Re: [io] Make requirement Java 7?

Le 26/04/2016 15:35, Dave Brosius a écrit : > The other side would say we are enabling crap code on unsupported, > unprotected jvms. New Java 6 development will die (more quickly) when > big libraries like commons-io stop supporting it. As it is, we are the > Java 6 drug dealers. We are not alone

Re: [io] Make requirement Java 7?

Le 26/04/2016 15:30, Jochen Wiedmann a écrit : > Besides, what is the problem with creating a 2.x branch new and > changing trunk to version 3? If there is further development in the > 2.x (aka Java 6) branch: Very well. If not, what is the problem? There is no problem, just more maintenance work

Re: [io] Make requirement Java 7?

The other side would say we are enabling crap code on unsupported, unprotected jvms. New Java 6 development will die (more quickly) when big libraries like commons-io stop supporting it. As it is, we are the Java 6 drug dealers. On 04/26/2016 09:28 AM, Emmanuel Bourg wrote: Le 26/04/2016 14:5

Re: [io] Make requirement Java 7?

On Tue, Apr 26, 2016 at 3:28 PM, Emmanuel Bourg wrote: > Le 26/04/2016 14:57, Dave Brosius a écrit : > >> The extra management that's required is not worth the >> 2 people who want a new version of commons-io for java 6. We are talking >> about an end of life date coming up on 4 years. > > There i

Re: [io] Make requirement Java 7?

Le 26/04/2016 14:57, Dave Brosius a écrit : > The extra management that's required is not worth the > 2 people who want a new version of commons-io for java 6. We are talking > about an end of life date coming up on 4 years. There is no extra management besides configuring the Maven compiler plug

Re: [io] Make requirement Java 7?

Piggybacking on what Dave said, Plumbr's latest stats on JDK usage as their stats collection measure it: https://plumbr.eu/blog/java/java-version-and-vendor-data-analyzed-2016-edition Hank On Tue, Apr 26, 2016 at 8:57 AM, Dave Brosius wrote: > People stuck on Java 6, for whatever inane reason,

Re: [io] Make requirement Java 7?

People stuck on Java 6, for whatever inane reason, are in a very restrictive use case, and as such are not likely doing 'progressive' things like upgrading 3rdparty jars. I just don't see the point of trying to support some of the new release's code base on java 6, and others on java 7. The ext

Re: [io] Make requirement Java 7?

Le 26/04/2016 14:47, Jochen Wiedmann a écrit : > I second that, Seems appropriate, given the extremely widespread use of io. I agree, but only if we bump the target level to 1.7. If we keep the target level at 1.6 we can continue with the 2.x versions. Emmanuel Bourg --

Re: [io] Make requirement Java 7?

On Tue, Apr 26, 2016 at 12:34 PM, Uwe Barthel wrote: > +1 BUT only with a MAJOR version change. I second that, Seems appropriate, given the extremely widespread use of io. -- The next time you hear: "Don't reinvent the wheel!" http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/ev

Re: [io] Make requirement Java 7?

Le 26/04/2016 14:29, sebb a écrit : > How can we say that the source code is Java 6 compatible if it cannot > be compiled with Java 6? It's Java 6 compatible at runtime, not at build time. We can say that because: - the project is configured to generate Java 6 compatible bytecode - 99% of the cod

Re: [io] Make requirement Java 7?

On 26 April 2016 at 13:01, Emmanuel Bourg wrote: > Le 26/04/2016 13:47, sebb a écrit : > >> Since the ASF primarily releases source, I think we would need to >> ensure that the code could still be compiled using Java 6. > > I don't think that's necessary. We just have to document that Java 7 is >

Re: [io] Make requirement Java 7?

Le 26/04/2016 13:47, sebb a écrit : > Since the ASF primarily releases source, I think we would need to > ensure that the code could still be compiled using Java 6. I don't think that's necessary. We just have to document that Java 7 is required to build the project. And we can use the enforcer p

Re: [io] Make requirement Java 7?

On 26 April 2016 at 12:31, Emmanuel Bourg wrote: > Le 26/04/2016 13:18, sebb a écrit : > >> But how does one compile the new utils which require Java 7? >> >> Would these be released as separately compiled jar? > > You don't need a separate jar. You just have to build with Java 7 but > set the sou

Re: [io] Make requirement Java 7?

Le 26/04/2016 13:18, sebb a écrit : > But how does one compile the new utils which require Java 7? > > Would these be released as separately compiled jar? You don't need a separate jar. You just have to build with Java 7 but set the source/target of the compiler plugin to 1.6. This will produce

[CRYTPO] Alpha release

I raised a couple of JIRAs (29,30) that would affect the API. I hope these can be considered for the first release. I would be happy to commit some or all of the necessary changes it that suits other devs. - To unsubscribe, e-mai

Re: [io] Make requirement Java 7?

On 26 April 2016 at 11:23, Emmanuel Bourg wrote: > Le 26/04/2016 12:08, sebb a écrit : > >> That would be good, but is it possible to build the code so it >> (mostly) still runs under Java 6? > > Yes if we stick to Java 6 APIs and compile with source/target level 1.6. > We don't have to switch to

Re: [io] Make requirement Java 7?

+1 BUT only with a MAJOR version change. -- barthel - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Re: [io] Make requirement Java 7?

Le 26/04/2016 12:08, sebb a écrit : > That would be good, but is it possible to build the code so it > (mostly) still runs under Java 6? Yes if we stick to Java 6 APIs and compile with source/target level 1.6. We don't have to switch to source/target 1.7 to use the java.nio.file API. Emmanuel Bo

Re: [io] Make requirement Java 7?

On 26 April 2016 at 09:18, Emmanuel Bourg wrote: > Le 25/04/2016 23:53, Gary Gregory a écrit : >> Does anyone object updating [io] to Java 7? >> >> I have a coupe of utils that sit on top of Java 7 IO classes I'd like to >> include. > > +1 > > I'd suggest using the Java 7 API for the new utils, bu

Re: [crypto] The standard indentation is 4 spaces per indent

On 26 April 2016 at 03:07, Chen, Haifeng wrote: > Hi Gary, > >>> Do you really want this level of Jira tracking? It seems over the top to >>> me. Is this process style for this component? In this case I would just do >>> it and not Jira it. Then for detailed history, you just look at the commit

Re: [io] Make requirement Java 7?

Le 25/04/2016 23:53, Gary Gregory a écrit : > Does anyone object updating [io] to Java 7? > > I have a coupe of utils that sit on top of Java 7 IO classes I'd like to > include. +1 I'd suggest using the Java 7 API for the new utils, but preserving the Java 6 compatibility for the existing code.