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

[Gary Gregory]

This is Commons, AND this is brand new code, so in my mind there is no
"original" formatting style to respect. 4 spaces per indent like the rest
of the project please. Remember that Commons is a SINGLE project. Hopefully
we won't have to argue about too much about this...

Gary
On Apr 28, 2016 7:24 PM, "Dan Tran"  wrote:

> I would prefer all Commons projects using the same style :-) sorry can't
> help to making some noise :-)
>
> On Thu, Apr 28, 2016 at 7:09 PM, Chen, Haifeng 
> wrote:
>
> > Mixed whitespace styles should be definitely avoided in anyway.
> > Do we have to change 2 spaces indent to 4 spaces? Uma suggest we keep the
> > original 2 spaces style. That makes sense.
> >
> > Any folks have objections?
> >
> > Thanks,
> > Haifeng
> >
> > -Original Message-
> > From: Matt Sicker [mailto:boa...@gmail.com]
> > Sent: Friday, April 29, 2016 9:00 AM
> > To: Commons Developers List 
> > Subject: Re: [crypto] The standard indentation is 4 spaces per indent
> >
> > If you want to prevent mixed whitespace styles and whatnot, you can use
> > EditorConfig .
> >
> > On 28 April 2016 at 19:06, Gangumalla, Uma 
> > wrote:
> >
> > > I am ok with a JIRA and type could be task for the reasons Sebb
> > > mentioned below.
> > >
> > > But I prefer to keep 2 spaces if others also ok who is going to
> > > involve in development. I assume most of Hadoop devs would have set
> > > their indentation
> > > 2 already in their IDEs. So, here also most of them would involve with
> > > indentation space 2 in their IDEs. If that does not hurt other, how
> > > about keeping 2?
> > >
> > > It will make easy to identify the default tabs(tab with 4char space)
> > > from IDEs like eclipse if code format settings are with 2 spaces. Ex:
> > > When some new contributor forgot to modify their IDE setting with
> > > spaces, then code will be easily identifiable if that has default
> > > setting with tabs. But with 4 spaces, it will look same.
> > >
> > > I just read it from Commons site: (Copied from site
> > > https://commons.apache.org/patches.html)
> > > Respect The Original Style
> > > Please respect the style of the orginal file. Make sure that your
> > > additions fit in with that style.
> > > Every component has coding conventions and every contribution is
> > > supposed to adhere to them. You might find it a little difficult to
> > > discover the conventions used by a particular component but if you
> > > stick to the style of the original then that'll be fine.
> > > If a patch is submitted which doesn't satisfy the component's coding
> > > conventions, then either a committer will need to rewrite the
> > > submission or it will be rejected. Getting it right in this first
> > > place will save you having to rewrite it.
> > >
> > > It says that we can continue with original coding format if we want.
> > > But anyway we can decide now.
> > >
> > >
> > >
> > > Regards,
> > > Uma
> > >
> > > On 4/26/16, 3:06 AM, "sebb"  wrote:
> > >
> > > >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 history. Or are you just using Jira as a
> > > to-do list in the early days of this component in its new home in
> > Apache Commons?
> > > >> As when we are working in Hadoop projects, we need a JIRA to start
> > > >>a work and communicate with the community. I am not sure whether
> > > >>Apache Commons allows commit of code without JIRA at this project
> > > >>stage. So I just try to do it in a safe way in a new family:)  If
> > > >>Apache Commons folks thinks it's OK to do it without JIRA, I am OK
> > > >>with it.
> > > >
> > > >If a developer spots a typo or missing/unclear Javadoc, I would say
> > > >just fix it rather than raising a JIRA.
> > > >
> > > >This case is borderline to me since it affects the whole codebase.
> > > >And the change impacts on how easy it is to see where/when changes
> > > >were made.
> > > >(This is more intrusive than a package name change at least as far as
> > > >history is concerned since every line may be changed) Also it ideally
> > > >needs to be co-ordinated with other changes.
> > > >
> > > >So I think it would be wrong to commit the change without some prior
> > > >notification.
> > > >This can either be a JIRA or agreement on the dev list.
> > > >
> > > >> Regards,
> > > >> Haifeng
> > > >>
> > > >> -Original Message-
> > > >> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> > > >> Sent: Tuesday, April 26, 2016 9:53 AM
> > > >> To: Commons Developers List 
> > > >> Subject: RE: [crypto] The standard indentation is 

Re: [VFS] 2.1 Release Plan

[Gary Gregory]

Agreed but thatvis a huge job. A great goal to be sure and I am all for it.

Whether that is 3.0 or 4.0 is a different issue.

Gary
On Apr 28, 2016 4:45 PM, "Ralph Goers"  wrote:

> Not to derail the conversation, but my opinion is (and has been for
> several years) that VFS 3.0 should be modified to use
> java.nio.file.FileSystem and FileStore. I don’t think it makes much sense
> for VFS to have its own constructs any more.
>
> Ralph
>
> > On Apr 28, 2016, at 3:41 PM, e...@zusammenkunft.net wrote:
> >
> > The components have been updated multiple times. The more we modernize
> it (including new java version) the less useful the release will be as a
> drop-in replacement for 2.0. I had the impression some bug reporters would
> like that. (Just for the record I wondered about having an additional a
> 2.0.1. Branch but I doubt we find resources for that painful task). It
> would allow us to release 3.0 (with java 8)...
> >
> > If we try to stick to 2.1 I would not do (more) dependency upgrades and
> Java 7 later (having said that we already switched to java 6 but that
> offers way more important features than we wohld use in 7 (what java 7
> feature you would want to use?)
> >
> > But I am fine with both
> >
> > --
> > http://bernd.eckenfels.net
> >
> > -Original Message-
> > From: Gary Gregory 
> > To: Commons Developers List 
> > Cc: Josh Elser 
> > Sent: Fr., 29 Apr. 2016 0:16
> > Subject: Re: [VFS] 2.1 Release Plan
> >
> > Why don't we bring [vfs] 2.1 from Java 6 to 7 and update 3rd party
> > components?
> >
> > Gary
> >
> > On Tue, Apr 26, 2016 at 12:36 PM, Gary Gregory 
> > wrote:
> >
> >> 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 <
> e...@zusammenkunft.net>
> >> 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 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 quite happy that you want to
> >>> step in as I havent had the time to do the procedure yet.
> >>>
> >>> And this is not the actual release procedure (which should be doable as
> >>> long as you do not try to use the release-plugin and be careful about
> >>> the multi-module+sandbox nature of VFS (as opposed to other commons
> >>> projects)). Also be carefull about branch and tag namings (the SVN is a
> >>> bit messy in this regard).
> >>>
> >>> My main concern I am afraid I would not have enough capacity is because
> >>> of the Clirr report and a lot of partially incompatible changes. Most
> >>> of them only affect providers if they do not properly use abstract base
> >>> classes, but still the list of Clirr violations is long and developers
> >>> here have not yet voiced if they would accept a RC with this situation
> >>> (or not).
> >>>
> >>> Anyway, I do agree that the current critical and blocker bugs are
> >>> important but should not stop the 2.1 release (especially if a 2.1.1
> >>> release aferwards is much faster to do.) It would be cool to have
> >>> VFS-570 (write suport for VFS, but even that could be delivered with
> >>> 2.1.1 - it might annoy the HDFS folks a bit)
> >>>
> >>> So I can help you in case you need me to sponsor some changes (I hope I
> >>> have enough karma now).
> >>>
> >>> We could even make a joined RC1, I am just not sure it wont open a big
> >>> chunk of additional work.
> >>>
> >>> Gruss
> >>> Bernd
> >>>
> >>> Am Tue, 26 Apr 2016 09:40:01 -0400
> >>> schrieb Josh Elser :
> >>>
>  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 I
>  will have more things to contribute back :)
> 
>  I'll pull up the thread in the archives and get back to ya'll with
>  any questions I have after that.
> 
>  - Josh
> 
>  Matt Sicker wrote:
> > It's from the thread called "Whatever happened to commons-io 2.5?"
> > A few people stepped up to give the necessary permissions and
> > committed his GPG key.
> >
> > On 25 April 2016 at 17:10, Gary Gregory
> > wrote:
> >
> >> Hi,
> >>
> >> Agreed, VFS 2.1 has been too long in the making. We can release
> >> ASAP without fixing more bugs IMO. RERO and all.
> >>
> >> As an Apache committer, your are also an Apache Commons committer,
> >> so feel free to 

[patch] Add elserj to KEYS

[Josh Elser]

Can someone add my key to 
https://dist.apache.org/repos/dist/release/commons/KEYS, please? It 
would appear that I lack the required karma.


Thanks in advance.

- Josh
Index: KEYS
===
--- KEYS(revision 13454)
+++ KEYS(working copy)
@@ -5520,3 +5520,100 @@
 EaWfWeQZ4Q==
 =b8+3
 -END PGP PUBLIC KEY BLOCK-
+
+pub   4096R/4677D66C 2013-05-04
+uid  Josh Elser (Apache) 
+sig 34677D66C 2016-04-06  Josh Elser (Apache) 
+uid  Josh Elser 
+sig 34677D66C 2013-05-04  Josh Elser (Apache) 
+sig  00B6899D 2013-05-04  Christopher L Tubbs II (Christopher) 

+sigR ABBA8A49 2013-05-04  Eric Newton 
+sub   4096R/99D5F66C 2013-05-04
+sig  4677D66C 2013-05-04  Josh Elser (Apache) 
+
+-BEGIN PGP PUBLIC KEY BLOCK-
+
+mQINBFGFRlQBEACk3q10Uf5vjHZ8rsSt2DA/GSvST6CCvqPPk56dmtLCs8ojO0rb
+aOXXx1DFrrm9BILSp1edhPpCs+KbQnpO8f1YM+k+WY3lc/Ah0X5oUQQranCjC/Qi
+Uf1tgp9xLG58ic1zVov8QGhyC+7XjA03pZe86izv6UvfL6ufU8XicnIYlRBugkg9
+bkjjM6A3OZLFoxEp20KdeWqhTOjCEDR1ocNcQ4IF64iVU/Stnn5KmywhzlfwWoGZ
+kFAzxEyghD/49+oANPJtnL2aZ1FS9ZiR/dkR73nDPWDioS1MusMwlNDErzoqpJLK
+UyePh3AxY+v3R9oo+Mu1Nxmp7bIoyCmnxufOCUOtxSVpMMWOBsdpMKuMgG6GyBKR
+wP2mAPHgMwKfLeqsiKUTZHzspUshsHovuVYcGbpV9in27fo7K7bKf3M7CE639a+e
+Wz8sIhQ0wj9IPqt96t56LhINDSbG2DOJY5m5ljxmSaM3Z59QgU191b7ZAn6GLszM
+OZL9qpPf/oCjHuYs1qJFrWALvdRFXYD6cd8BrtBP+mpgnYFLEZ8lBBeJKKJxaxxb
+gk/TOzXqBxigz7fvMc9FoNEbZiJkIsquKUko3YohrAYVIIDzJKV6buP6IJg95LYb
+i94zd65OzHvjQV3ljo9mt60wgMhdLDOCKV4d++zutkekzrXNTYhk0HjjwwARAQAB
+tCFKb3NoIEVsc2VyIDxqb3NoLmVsc2VyQGdtYWlsLmNvbT6JAjcEEwEKACEFAlGF
+RlQCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQt9XNRUZ31mzzBBAAkfuT
+HhL5vAxRy780dV4jIE+CjK242DlATe8J8xAP4kF34WD4qijDnysaGqNFNBO7sq1+
+EBn1OizYPcMEIwhoqZ9bBjwRGPmHyM3Y6vKFnXQwl+YR3gpYYR4csh2ZD9iX+U74
+jo+2tHICbCdpjQkAUe0yIivT3GMntKuaGuHZx0+0qmtNeYSjuuKyl+9V1/mTPUQA
+EUcPpG3BFpFURYDf0W39uGJMBUXLGB3dJiwb0Y0/NDFAZubuO2uUc0ihlaYMvYqw
+lhxI4BWxoLwSE1ATAyM04iLld6qNk/c35jb+NNsl07BC26A4nQdNa+L1V2M2pe25
+0zU65CATNdLf5T+Rg9i1k7li1KJmL9SzyDOQd2WEtv67Tx/T5qG5ISL86VIbzAdM
+Shc00FutRgQ5IJIj5msySL3O5x3MGaMUhVocWP4oCShk/BlBOkcjHYzqpI8hm8hf
+Rrip2zbO8Met64/fkwMTMXX4E76hCMblYjTa/H4VlQ08oukwJyZagbhkivAjsETM
+5wXgW/x0QU1Rkfwv6GLoZqS1rumrX6S12x31qBXT/KKuI3QdSStkJU96/MeC8oD6
+AvjtahBLiKalX64VFmM4vX2TIb4OjkO1fySBPXj4GR1F9eg7S2wlSLryG/tGrx9B
+GH7qD6aMCk4xyb5o4YxNylmM9pDGByqveXflDIqJAhwEEAEKAAYFAlGFS0gACgkQ
+bwza5wC2iZ2GQBAAvmZDHFMExlr76mKjw1uiecJB7cGVfOx2Lg/NSoV09K2BKNcV
+4gJrVH2lLIlR19rSP1U+YoWJr+es2HDUZz+uzJNZ8ZcgBfLuaEO2JGA+0P3aPBuJ
+kBkDk3YDSx5Q5U9KFM0RBOebC901ZFyUpRAdeb/a3xfX20G7KyTmfZXegmqKsiwU
+WHNqrOObRnXR2sif3ruuARK2/8SZo6isdRjssxkaJMOOt7rN1j3DxI1x8eiewAUs
+UXleuZZj/3kLP0WeJkJIVZ5Blkptn3owrZWoidKK5I4x0ge6zDGNCn50zechtksU
++iV7Leu61P3s0ssoYlaJi2sJK5aZiInMafI5WJeevbNIeWNoCv5I4KNgw+XRPblU
+31O7BXFxImP3i6eBW4EbUHMycrIvN0itSrCsKpDX2XE6CEPSlhd7lXisXdaNLWP8
+DDvPv+ML7XlOBv0Ebho5PaQMhSjCQKsV1Edq+Po74/mxSRlqw/9qjymiB8a+6+qT
+cQxiGuyr1bD5rR5d2ns73H+QtOlvJ1v1bVNQbElgYTtYq5XL4+O1ZpTJYAmUB0z6
+wCIrmnpkOz82eqr+7eUIW1l2+t1Pi/LXlYOZ9SBIPxF85ZanBsUFyUC2R2woZdIf
+p5g+QtiNYzKZYH4EglztZ09uqWi2r6crMTZiq+c7EXOyQEOspwtaXCg+FiuJAh8E
+EAECAAkFAlGFSu8CBwAACgkQJSyQKKu6ikkdoRAAxfoQuL5cmJpN0Jwdo2ONIRpR
++YkU4BgDPyWAIEsAMBRdZ06ZSsTjRMAWJqfIvsItSfJsN26eJ87aUbKctxmEpZ/e
+hXs2X1wrnjwqIWqDxLDvipRKBFA3S7rItGpskRajnkrc+ZGpUYVVNUF7H/DkRafW
+Fx2WOfZo33Zyoj/a11xmC6TPAzeoaTHd43jbJFLTX1TRdnubd9NLH2RBOZmJwOIu
+3tDuookK4Z6cvDv7HlgS7y869z21m9WQfKD2jcuh8+t7UqLhQITvlBxaPgri9xFn
+8Gsyr+ro7mEhK7vxGi2ozFYFpDbZerqTHysx6Yw6G5wL8UZlIAXaIfOpbA142EUY
+ynQPQbKr6xmKe/5EAM0FKmfRGCx/p3So9FLaYDHBTwu83ie6AUlEY8OhpL5xadMO
+VK+JCC6Y8VSymjnK8zO+743ePw9HCBuArAnSRSOfeJvs3JO6th9v/x18d/oMAy9n
+BMYbF12WTNRhKYcD350RgxucC9kVj+tFSJg/1034JZvg6oX1V1gPu5GuwuFacng/
+zB7XG3Sb7bDKmLWZUVXCD8JLrLY9F4K/jBClBFiARQ1gTUraA/vxvJBaXHtH82Hz
+twzISWWZriBMroj7DIHlJcu9FGKWo4uwvDFhWYsQgGhu1TFBki8hYVox7PpXnh3+
+qoqElhs5kqgzgE8HzzO0J0pvc2ggRWxzZXIgKEFwYWNoZSkgPGVsc2VyakBhcGFj
+aGUub3JnPokCOAQTAQIAIgUCVwUjqQIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgEC
+F4AACgkQt9XNRUZ31mzyPg/8DfHIi7O3T1mqIbucnUvyvOgpzaadprmn0JjcXXTD
+AsQimCRJcbNjHAlN1U3eEt9bK96P53ZgrqqpO7a7p6FG6vxCh1ggX3fWkSKnNyfd
+kaAOyy8XDig6A6NaJ3Wrakd6yJ2q8RXOzPHhe7D56hB+UA5wwjdWM8XDR/mbb/Pt
+tX469LseSONIANRTjl2JWpPKrrjnOcRybC6lyVWFDxBpPXcglVpmiHu1RGvNOwCO
+JtEmC73keUR1PqzXROkk2/+aRFF38beu4DuJCjzCvUK81iCN+BEJMaE8rrfNgIDZ
+BiVUYubwpQZjxEwf1xti+cLH+e6SQ7Ybh0GJdg7K+CUhQq5IMIiTDWucTpfLza9F
+m+RR2gVhr5utNe/G7LACoI0C2yRxUWxCQ7dW3Zy2+RgQrbtJsOHkCWV4kSgz+k/0
+ISkT/jhMr4qARAcEgYwaTaTSXjXQNtoAaMCk6bWkvZe64SRNWagtjMdRQdc+PXc+
+YCbUD4CfBCx49mGKpnAu1VOgAdnBEGhdsoDCexj+i6tBAEBCMJ0anxbQ8Yjq05Be
+/ucuC946CSraggsLU51KLV4c69cA6EFEkNhYbX5sI1qMSJHKGxCt/bCQyZtCeoGm
+5PYRZJZZUyBWSP+VwuMe343CKiZkqhk3VonXZTzsJ+GP3RZE43TVqmSCcOb/LswV
+bSi5Ag0EUYVGVAEQAOhs+yIikgG9GLEzH3Hxm1B0oJG5fN3fnFnNmEeqQ6+vV61V

[VFS] 2.1 clirr report

[Josh Elser]

It looks like there are about 7 areas in core/ where compatibility 
against 2.0 has been broken:


* Methods added to o.a.c.v.{FileContent,FileName,FileObject}
* Method added to o.a.c.v.RandomAccessContent
* Parameters changed on method(s) in 
o.a.c.v.p.{b.Bzip2FileObject,g.GzipFileObject}

* Changes from TarEntry to TarArchiveEntry
* Removed AUTHENTICATOR_TYPES from o.a.c.v.p.w.WebdavFileProvider

Where do you define what are acceptable changes in a release? Is this 
going to be a sticking-point?


http://home.apache.org/~elserj/commons-vfs/commons-vfs-2.1-site/

- Josh

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

[VFS] 2.1 release help

[Josh Elser]

Ok, ran into my first issue. Seems like I don't have the karma to edit 
the existing JIRA issues (changing the fixVersion). Can someone please 
add me to the appropriate role for the project?


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

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

[Dan Tran]

I would prefer all Commons projects using the same style :-) sorry can't
help to making some noise :-)

On Thu, Apr 28, 2016 at 7:09 PM, Chen, Haifeng 
wrote:

> Mixed whitespace styles should be definitely avoided in anyway.
> Do we have to change 2 spaces indent to 4 spaces? Uma suggest we keep the
> original 2 spaces style. That makes sense.
>
> Any folks have objections?
>
> Thanks,
> Haifeng
>
> -Original Message-
> From: Matt Sicker [mailto:boa...@gmail.com]
> Sent: Friday, April 29, 2016 9:00 AM
> To: Commons Developers List 
> Subject: Re: [crypto] The standard indentation is 4 spaces per indent
>
> If you want to prevent mixed whitespace styles and whatnot, you can use
> EditorConfig .
>
> On 28 April 2016 at 19:06, Gangumalla, Uma 
> wrote:
>
> > I am ok with a JIRA and type could be task for the reasons Sebb
> > mentioned below.
> >
> > But I prefer to keep 2 spaces if others also ok who is going to
> > involve in development. I assume most of Hadoop devs would have set
> > their indentation
> > 2 already in their IDEs. So, here also most of them would involve with
> > indentation space 2 in their IDEs. If that does not hurt other, how
> > about keeping 2?
> >
> > It will make easy to identify the default tabs(tab with 4char space)
> > from IDEs like eclipse if code format settings are with 2 spaces. Ex:
> > When some new contributor forgot to modify their IDE setting with
> > spaces, then code will be easily identifiable if that has default
> > setting with tabs. But with 4 spaces, it will look same.
> >
> > I just read it from Commons site: (Copied from site
> > https://commons.apache.org/patches.html)
> > Respect The Original Style
> > Please respect the style of the orginal file. Make sure that your
> > additions fit in with that style.
> > Every component has coding conventions and every contribution is
> > supposed to adhere to them. You might find it a little difficult to
> > discover the conventions used by a particular component but if you
> > stick to the style of the original then that'll be fine.
> > If a patch is submitted which doesn't satisfy the component's coding
> > conventions, then either a committer will need to rewrite the
> > submission or it will be rejected. Getting it right in this first
> > place will save you having to rewrite it.
> >
> > It says that we can continue with original coding format if we want.
> > But anyway we can decide now.
> >
> >
> >
> > Regards,
> > Uma
> >
> > On 4/26/16, 3:06 AM, "sebb"  wrote:
> >
> > >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 history. Or are you just using Jira as a
> > to-do list in the early days of this component in its new home in
> Apache Commons?
> > >> As when we are working in Hadoop projects, we need a JIRA to start
> > >>a work and communicate with the community. I am not sure whether
> > >>Apache Commons allows commit of code without JIRA at this project
> > >>stage. So I just try to do it in a safe way in a new family:)  If
> > >>Apache Commons folks thinks it's OK to do it without JIRA, I am OK
> > >>with it.
> > >
> > >If a developer spots a typo or missing/unclear Javadoc, I would say
> > >just fix it rather than raising a JIRA.
> > >
> > >This case is borderline to me since it affects the whole codebase.
> > >And the change impacts on how easy it is to see where/when changes
> > >were made.
> > >(This is more intrusive than a package name change at least as far as
> > >history is concerned since every line may be changed) Also it ideally
> > >needs to be co-ordinated with other changes.
> > >
> > >So I think it would be wrong to commit the change without some prior
> > >notification.
> > >This can either be a JIRA or agreement on the dev list.
> > >
> > >> Regards,
> > >> Haifeng
> > >>
> > >> -Original Message-
> > >> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> > >> Sent: Tuesday, April 26, 2016 9:53 AM
> > >> To: Commons Developers List 
> > >> Subject: RE: [crypto] The standard indentation is 4 spaces per
> > >> indent
> > >>
> > >> Hi,
> > >>
> > >> 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 history. Or are you just using Jira as a
> > >>to-do list in the early days of this component in its new home in
> Apache Commons?
> > >>
> > >> Gary
> > >> On Apr 25, 2016 6:47 PM, "Chen, Haifeng" 
> > wrote:
> > >>
> > In 

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

[Chen, Haifeng]

Mixed whitespace styles should be definitely avoided in anyway.
Do we have to change 2 spaces indent to 4 spaces? Uma suggest we keep the 
original 2 spaces style. That makes sense.

Any folks have objections?

Thanks,
Haifeng

-Original Message-
From: Matt Sicker [mailto:boa...@gmail.com] 
Sent: Friday, April 29, 2016 9:00 AM
To: Commons Developers List 
Subject: Re: [crypto] The standard indentation is 4 spaces per indent

If you want to prevent mixed whitespace styles and whatnot, you can use 
EditorConfig .

On 28 April 2016 at 19:06, Gangumalla, Uma  wrote:

> I am ok with a JIRA and type could be task for the reasons Sebb 
> mentioned below.
>
> But I prefer to keep 2 spaces if others also ok who is going to 
> involve in development. I assume most of Hadoop devs would have set 
> their indentation
> 2 already in their IDEs. So, here also most of them would involve with 
> indentation space 2 in their IDEs. If that does not hurt other, how 
> about keeping 2?
>
> It will make easy to identify the default tabs(tab with 4char space) 
> from IDEs like eclipse if code format settings are with 2 spaces. Ex: 
> When some new contributor forgot to modify their IDE setting with 
> spaces, then code will be easily identifiable if that has default 
> setting with tabs. But with 4 spaces, it will look same.
>
> I just read it from Commons site: (Copied from site
> https://commons.apache.org/patches.html)
> Respect The Original Style
> Please respect the style of the orginal file. Make sure that your 
> additions fit in with that style.
> Every component has coding conventions and every contribution is 
> supposed to adhere to them. You might find it a little difficult to 
> discover the conventions used by a particular component but if you 
> stick to the style of the original then that'll be fine.
> If a patch is submitted which doesn't satisfy the component's coding 
> conventions, then either a committer will need to rewrite the 
> submission or it will be rejected. Getting it right in this first 
> place will save you having to rewrite it.
>
> It says that we can continue with original coding format if we want. 
> But anyway we can decide now.
>
>
>
> Regards,
> Uma
>
> On 4/26/16, 3:06 AM, "sebb"  wrote:
>
> >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 history. Or are you just using Jira as a 
> to-do list in the early days of this component in its new home in Apache 
> Commons?
> >> As when we are working in Hadoop projects, we need a JIRA to start 
> >>a work and communicate with the community. I am not sure whether 
> >>Apache Commons allows commit of code without JIRA at this project 
> >>stage. So I just try to do it in a safe way in a new family:)  If 
> >>Apache Commons folks thinks it's OK to do it without JIRA, I am OK 
> >>with it.
> >
> >If a developer spots a typo or missing/unclear Javadoc, I would say 
> >just fix it rather than raising a JIRA.
> >
> >This case is borderline to me since it affects the whole codebase.
> >And the change impacts on how easy it is to see where/when changes 
> >were made.
> >(This is more intrusive than a package name change at least as far as 
> >history is concerned since every line may be changed) Also it ideally 
> >needs to be co-ordinated with other changes.
> >
> >So I think it would be wrong to commit the change without some prior 
> >notification.
> >This can either be a JIRA or agreement on the dev list.
> >
> >> Regards,
> >> Haifeng
> >>
> >> -Original Message-
> >> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> >> Sent: Tuesday, April 26, 2016 9:53 AM
> >> To: Commons Developers List 
> >> Subject: RE: [crypto] The standard indentation is 4 spaces per 
> >> indent
> >>
> >> Hi,
> >>
> >> 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 history. Or are you just using Jira as a 
> >>to-do list in the early days of this component in its new home in Apache 
> >>Commons?
> >>
> >> Gary
> >> On Apr 25, 2016 6:47 PM, "Chen, Haifeng" 
> wrote:
> >>
> In our coding guidelines [1] we say that "The standard indentation 
> is
> 4
> >> spaces per indent - but respect the number of spaces used by the 
> >>original."
> The [crypto] Java code I've seen to far is all 2 spaces per indent.
> I think now is the time to do this, most IDEs can do a one-shot 
> format of
> >> a whole source tree.
> >> 

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

[Matt Sicker]

If you want to prevent mixed whitespace styles and whatnot, you can use
EditorConfig .

On 28 April 2016 at 19:06, Gangumalla, Uma  wrote:

> I am ok with a JIRA and type could be task for the reasons Sebb mentioned
> below.
>
> But I prefer to keep 2 spaces if others also ok who is going to involve in
> development. I assume most of Hadoop devs would have set their indentation
> 2 already in their IDEs. So, here also most of them would involve with
> indentation space 2 in their IDEs. If that does not hurt other, how about
> keeping 2?
>
> It will make easy to identify the default tabs(tab with 4char space) from
> IDEs like eclipse if code format settings are with 2 spaces. Ex: When some
> new contributor forgot to modify their IDE setting with spaces, then code
> will be easily identifiable if that has default setting with tabs. But
> with 4 spaces, it will look same.
>
> I just read it from Commons site: (Copied from site
> https://commons.apache.org/patches.html)
> Respect The Original Style
> Please respect the style of the orginal file. Make sure that your
> additions fit in with that style.
> Every component has coding conventions and every contribution is supposed
> to adhere to them. You might find it a little difficult to discover the
> conventions used by a particular component but if you stick to the style
> of the original then that'll be fine.
> If a patch is submitted which doesn't satisfy the component's coding
> conventions, then either a committer will need to rewrite the submission
> or it will be rejected. Getting it right in this first place will save you
> having to rewrite it.
>
> It says that we can continue with original coding format if we want. But
> anyway we can decide now.
>
>
>
> Regards,
> Uma
>
> On 4/26/16, 3:06 AM, "sebb"  wrote:
>
> >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 history. Or are you just using Jira as a to-do list in
> the early days of this component in its new home in Apache Commons?
> >> As when we are working in Hadoop projects, we need a JIRA to start a
> >>work and communicate with the community. I am not sure whether Apache
> >>Commons allows commit of code without JIRA at this project stage. So I
> >>just try to do it in a safe way in a new family:)
> >> If Apache Commons folks thinks it's OK to do it without JIRA, I am OK
> >>with it.
> >
> >If a developer spots a typo or missing/unclear Javadoc, I would say
> >just fix it rather than raising a JIRA.
> >
> >This case is borderline to me since it affects the whole codebase.
> >And the change impacts on how easy it is to see where/when changes were
> >made.
> >(This is more intrusive than a package name change at least as far as
> >history is concerned since every line may be changed)
> >Also it ideally needs to be co-ordinated with other changes.
> >
> >So I think it would be wrong to commit the change without some prior
> >notification.
> >This can either be a JIRA or agreement on the dev list.
> >
> >> Regards,
> >> Haifeng
> >>
> >> -Original Message-
> >> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> >> Sent: Tuesday, April 26, 2016 9:53 AM
> >> To: Commons Developers List 
> >> Subject: RE: [crypto] The standard indentation is 4 spaces per indent
> >>
> >> Hi,
> >>
> >> 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 history. Or are you just using Jira as a to-do list in the
> >>early days of this component in its new home in Apache Commons?
> >>
> >> Gary
> >> On Apr 25, 2016 6:47 PM, "Chen, Haifeng" 
> wrote:
> >>
> In our coding guidelines [1] we say that "The standard indentation is
> 4
> >> spaces per indent - but respect the number of spaces used by the
> >>original."
> The [crypto] Java code I've seen to far is all 2 spaces per indent.
> I think now is the time to do this, most IDEs can do a one-shot format
> of
> >> a whole source tree.
> >> Good catch, Gary. The original code was based on Hadoop format style
> >>which is 2 spaces indent. I will fire a JIRA to format that.
> >>
> >> Thanks,
> >> Haifeng
> >>
> >> -Original Message-
> >> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> >> Sent: Tuesday, April 26, 2016 6:25 AM
> >> To: Commons Developers List 
> >> Subject: [crypto] The standard indentation is 4 spaces per indent
> >>
> >> Hi all,
> >>
> >> In our coding guidelines [1] we say that "The standard indentation 

Re: [CRYPTO] Switch from JNI to JNA

[Gangumalla, Uma]

This is awesome. Thanks Haifeng for driving towards 1st release.

Regards,
Uma

On 4/26/16, 6:27 PM, "Chen, Haifeng"  wrote:

>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 has different ideas, please free feel to raise up.
>
>Regards,
>Haifeng
>
>-Original Message-
>From: Gary Gregory [mailto:garydgreg...@gmail.com]
>Sent: Tuesday, April 26, 2016 10:50 AM
>To: Commons Developers List 
>Subject: Re: [CRYPTO] Switch from JNI to JNA
>
>I like it. RERO!
>As we plan to have release sooner, marking release ALPHA tagged make
>sense IMO.
>
>Regards,
>Uma
>On 4/25/16, 7:02 PM, "sebb"  wrote:
>
>>On 26 April 2016 at 02:56, Chen, Haifeng  wrote:
> Sounds like a tough time schedule. It's only one week until May.
>>> Yeah, it's a tough time schedule. We will just try moving fast and
>>>see what we can reach at that time. Maybe it's not realistic in one
>>>week.
>>
>>It's expensive to change the public API once released.
>>
>>Given the timescale, maybe it would work to release an ALPHA version on
>>the understanding that the API may change incompatibly.
>>
>>> -Original Message-
>>> From: Benedikt Ritter [mailto:brit...@apache.org]
>>> Sent: Tuesday, April 26, 2016 12:03 AM
>>> To: Commons Developers List 
>>> Subject: Re: [CRYPTO] Switch from JNI to JNA
>>>
>>> Chen, Haifeng  schrieb am Mo., 25. Apr. 2016
>>> um
>>> 08:38 Uhr:
>>>
 >> Maybe its an option to replace JNI by JNA [1]. This would have
 >> IHMO
 several advantages like
 >> * No C code needs to be written, compiled, tested and maintained
 >> * Its easier compared to JNI (this could help attracting more
 >> people to
 contribute)
 >> * Many supported platforms [2], precompiled native binaries
 >> available
 Agree on these advantages.

 >> Disadvantages:
 >> * Introduce a dependency to JNA
 >> * Performance decrease compared to JNI (direct buffers and direct
 mapping helps minimizing this) [3]
 The major concern will be on the performance. Because the major
 value for Crypto is to utilize the performance optimization OpenSSL
provided.
 Need to have an evaluation on how much performance penalty will
 occur when using JNA comparing JNI.

 The Spark community are eager to utilize this library. If we can
have  the first release before May, there is a possibility to include
it in Spark 2.0.

>>>
>>> Sounds like a tough time schedule. It's only one week until May.
>>>
>>>
 Any idea to put JNA evaluation in the second release?
>>>
>>>
>>> Yes, why not.
>>>
>>>

 Thanks,
 Haifeng

 -Original Message-
 From: Hendrik Dev [mailto:hendrikde...@gmail.com]
 Sent: Saturday, April 23, 2016 6:43 PM
 To: Commons Developers List 
 Subject: [CRYPTO] Switch from JNI to JNA

 Hi,

 i just had a brief look into commons crypto today.
 Maybe its an option to replace JNI by JNA [1]. This would have IHMO
 several advantages like

 * No C code needs to be written, compiled, tested and maintained
 * Its easier compared to JNI (this could help attracting more people
 to
 contribute)
 * Many supported platforms [2], precompiled native binaries
 available

 Disadvantages:

 * Introduce a dependency to JNA
 * Performance decrease compared to JNI (direct buffers and direct
 mapping helps minimizing this) [3]

 I prepared a demo [4] to show thats its generally working and how a
 implementation could like (although tests are not working and error
 handling is missing).

 [1] https://github.com/java-native-access/jna
 [2] https://github.com/java-native-access/jna/tree/master/lib/native
 [3] https://s.apache.org/q5Tl
 [4] https://s.apache.org/DQeD

 Wdyt?

 Thanks
 Hendrik

 --
 Hendrik Saly (salyh, hendrikdev22)
 @hendrikdev22
 PGP: 0x22D7F6EC

 
 - 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: [crypto] The standard indentation is 4 spaces per indent

[Gangumalla, Uma]

I am ok with a JIRA and type could be task for the reasons Sebb mentioned
below.

But I prefer to keep 2 spaces if others also ok who is going to involve in
development. I assume most of Hadoop devs would have set their indentation
2 already in their IDEs. So, here also most of them would involve with
indentation space 2 in their IDEs. If that does not hurt other, how about
keeping 2?

It will make easy to identify the default tabs(tab with 4char space) from
IDEs like eclipse if code format settings are with 2 spaces. Ex: When some
new contributor forgot to modify their IDE setting with spaces, then code
will be easily identifiable if that has default setting with tabs. But
with 4 spaces, it will look same.

I just read it from Commons site: (Copied from site
https://commons.apache.org/patches.html)
Respect The Original Style
Please respect the style of the orginal file. Make sure that your
additions fit in with that style.
Every component has coding conventions and every contribution is supposed
to adhere to them. You might find it a little difficult to discover the
conventions used by a particular component but if you stick to the style
of the original then that'll be fine.
If a patch is submitted which doesn't satisfy the component's coding
conventions, then either a committer will need to rewrite the submission
or it will be rejected. Getting it right in this first place will save you
having to rewrite it.

It says that we can continue with original coding format if we want. But
anyway we can decide now.



Regards,
Uma

On 4/26/16, 3:06 AM, "sebb"  wrote:

>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 history. Or are you just using Jira as a to-do list in
the early days of this component in its new home in Apache Commons?
>> As when we are working in Hadoop projects, we need a JIRA to start a
>>work and communicate with the community. I am not sure whether Apache
>>Commons allows commit of code without JIRA at this project stage. So I
>>just try to do it in a safe way in a new family:)
>> If Apache Commons folks thinks it's OK to do it without JIRA, I am OK
>>with it.
>
>If a developer spots a typo or missing/unclear Javadoc, I would say
>just fix it rather than raising a JIRA.
>
>This case is borderline to me since it affects the whole codebase.
>And the change impacts on how easy it is to see where/when changes were
>made.
>(This is more intrusive than a package name change at least as far as
>history is concerned since every line may be changed)
>Also it ideally needs to be co-ordinated with other changes.
>
>So I think it would be wrong to commit the change without some prior
>notification.
>This can either be a JIRA or agreement on the dev list.
>
>> Regards,
>> Haifeng
>>
>> -Original Message-
>> From: Gary Gregory [mailto:garydgreg...@gmail.com]
>> Sent: Tuesday, April 26, 2016 9:53 AM
>> To: Commons Developers List 
>> Subject: RE: [crypto] The standard indentation is 4 spaces per indent
>>
>> Hi,
>>
>> 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 history. Or are you just using Jira as a to-do list in the
>>early days of this component in its new home in Apache Commons?
>>
>> Gary
>> On Apr 25, 2016 6:47 PM, "Chen, Haifeng"  wrote:
>>
In our coding guidelines [1] we say that "The standard indentation is
4
>> spaces per indent - but respect the number of spaces used by the
>>original."
The [crypto] Java code I've seen to far is all 2 spaces per indent.
I think now is the time to do this, most IDEs can do a one-shot format
of
>> a whole source tree.
>> Good catch, Gary. The original code was based on Hadoop format style
>>which is 2 spaces indent. I will fire a JIRA to format that.
>>
>> Thanks,
>> Haifeng
>>
>> -Original Message-
>> From: Gary Gregory [mailto:garydgreg...@gmail.com]
>> Sent: Tuesday, April 26, 2016 6:25 AM
>> To: Commons Developers List 
>> Subject: [crypto] The standard indentation is 4 spaces per indent
>>
>> Hi all,
>>
>> In our coding guidelines [1] we say that "The standard indentation is 4
>>spaces per indent - but respect the number of spaces used by the
>>original."
>>
>> The [crypto] Java code I've seen to far is all 2 spaces per indent.
>>
>> I think now is the time to do this, most IDEs can do a one-shot format
>>of a whole source tree.
>>
>> Gary
>>
>> [1] https://commons.apache.org/patches.html
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence

Re: [VFS] 2.1 Release Plan

[Ralph Goers]

Not to derail the conversation, but my opinion is (and has been for several 
years) that VFS 3.0 should be modified to use java.nio.file.FileSystem and 
FileStore. I don’t think it makes much sense for VFS to have its own constructs 
any more.

Ralph

> On Apr 28, 2016, at 3:41 PM, e...@zusammenkunft.net wrote:
> 
> The components have been updated multiple times. The more we modernize it 
> (including new java version) the less useful the release will be as a drop-in 
> replacement for 2.0. I had the impression some bug reporters would like that. 
> (Just for the record I wondered about having an additional a 2.0.1. Branch 
> but I doubt we find resources for that painful task). It would allow us to 
> release 3.0 (with java 8)...
> 
> If we try to stick to 2.1 I would not do (more) dependency upgrades and Java 
> 7 later (having said that we already switched to java 6 but that offers way 
> more important features than we wohld use in 7 (what java 7 feature you would 
> want to use?)
> 
> But I am fine with both 
> 
> -- 
> http://bernd.eckenfels.net
> 
> -Original Message-
> From: Gary Gregory 
> To: Commons Developers List 
> Cc: Josh Elser 
> Sent: Fr., 29 Apr. 2016 0:16
> Subject: Re: [VFS] 2.1 Release Plan
> 
> Why don't we bring [vfs] 2.1 from Java 6 to 7 and update 3rd party
> components?
> 
> Gary
> 
> On Tue, Apr 26, 2016 at 12:36 PM, Gary Gregory 
> wrote:
> 
>> 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 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 quite happy that you want to
>>> step in as I havent had the time to do the procedure yet.
>>> 
>>> And this is not the actual release procedure (which should be doable as
>>> long as you do not try to use the release-plugin and be careful about
>>> the multi-module+sandbox nature of VFS (as opposed to other commons
>>> projects)). Also be carefull about branch and tag namings (the SVN is a
>>> bit messy in this regard).
>>> 
>>> My main concern I am afraid I would not have enough capacity is because
>>> of the Clirr report and a lot of partially incompatible changes. Most
>>> of them only affect providers if they do not properly use abstract base
>>> classes, but still the list of Clirr violations is long and developers
>>> here have not yet voiced if they would accept a RC with this situation
>>> (or not).
>>> 
>>> Anyway, I do agree that the current critical and blocker bugs are
>>> important but should not stop the 2.1 release (especially if a 2.1.1
>>> release aferwards is much faster to do.) It would be cool to have
>>> VFS-570 (write suport for VFS, but even that could be delivered with
>>> 2.1.1 - it might annoy the HDFS folks a bit)
>>> 
>>> So I can help you in case you need me to sponsor some changes (I hope I
>>> have enough karma now).
>>> 
>>> We could even make a joined RC1, I am just not sure it wont open a big
>>> chunk of additional work.
>>> 
>>> Gruss
>>> Bernd
>>> 
>>> Am Tue, 26 Apr 2016 09:40:01 -0400
>>> schrieb Josh Elser :
>>> 
 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 I
 will have more things to contribute back :)
 
 I'll pull up the thread in the archives and get back to ya'll with
 any questions I have after that.
 
 - Josh
 
 Matt Sicker wrote:
> It's from the thread called "Whatever happened to commons-io 2.5?"
> A few people stepped up to give the necessary permissions and
> committed his GPG key.
> 
> On 25 April 2016 at 17:10, Gary Gregory
> wrote:
> 
>> Hi,
>> 
>> Agreed, VFS 2.1 has been too long in the making. We can release
>> ASAP without fixing more bugs IMO. RERO and all.
>> 
>> As an Apache committer, your are also an Apache Commons committer,
>> so feel free to create JIRAs, fix bugs and so on.
>> 
>> There might be some karma issues with a non-PMC member performing a
>> release, and I think we just went through this (sorry, I'm in
>> settling in a new house, not much time to dig in the ML archives).
>> 
>> Does anyone recall?
>> 
>> Gary
>> 
>> 
>> 
>> On Mon, Apr 25, 2016 at 12:06 PM, Josh 

Re: [VFS] 2.1 Release Plan

[ecki]

The components have been updated multiple times. The more we modernize it 
(including new java version) the less useful the release will be as a drop-in 
replacement for 2.0. I had the impression some bug reporters would like that. 
(Just for the record I wondered about having an additional a 2.0.1. Branch but 
I doubt we find resources for that painful task). It would allow us to release 
3.0 (with java 8)...

If we try to stick to 2.1 I would not do (more) dependency upgrades and Java 7 
later (having said that we already switched to java 6 but that offers way more 
important features than we wohld use in 7 (what java 7 feature you would want 
to use?)

But I am fine with both 

-- 
http://bernd.eckenfels.net

-Original Message-
From: Gary Gregory 
To: Commons Developers List 
Cc: Josh Elser 
Sent: Fr., 29 Apr. 2016 0:16
Subject: Re: [VFS] 2.1 Release Plan

Why don't we bring [vfs] 2.1 from Java 6 to 7 and update 3rd party
components?

Gary

On Tue, Apr 26, 2016 at 12:36 PM, Gary Gregory 
wrote:

> 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 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 quite happy that you want to
>> step in as I havent had the time to do the procedure yet.
>>
>> And this is not the actual release procedure (which should be doable as
>> long as you do not try to use the release-plugin and be careful about
>> the multi-module+sandbox nature of VFS (as opposed to other commons
>> projects)). Also be carefull about branch and tag namings (the SVN is a
>> bit messy in this regard).
>>
>> My main concern I am afraid I would not have enough capacity is because
>> of the Clirr report and a lot of partially incompatible changes. Most
>> of them only affect providers if they do not properly use abstract base
>> classes, but still the list of Clirr violations is long and developers
>> here have not yet voiced if they would accept a RC with this situation
>> (or not).
>>
>> Anyway, I do agree that the current critical and blocker bugs are
>> important but should not stop the 2.1 release (especially if a 2.1.1
>> release aferwards is much faster to do.) It would be cool to have
>> VFS-570 (write suport for VFS, but even that could be delivered with
>> 2.1.1 - it might annoy the HDFS folks a bit)
>>
>> So I can help you in case you need me to sponsor some changes (I hope I
>> have enough karma now).
>>
>> We could even make a joined RC1, I am just not sure it wont open a big
>> chunk of additional work.
>>
>> Gruss
>> Bernd
>>
>>  Am Tue, 26 Apr 2016 09:40:01 -0400
>> schrieb Josh Elser :
>>
>> > 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 I
>> > will have more things to contribute back :)
>> >
>> > I'll pull up the thread in the archives and get back to ya'll with
>> > any questions I have after that.
>> >
>> > - Josh
>> >
>> > Matt Sicker wrote:
>> > > It's from the thread called "Whatever happened to commons-io 2.5?"
>> > > A few people stepped up to give the necessary permissions and
>> > > committed his GPG key.
>> > >
>> > > On 25 April 2016 at 17:10, Gary Gregory
>> > > wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >> Agreed, VFS 2.1 has been too long in the making. We can release
>> > >> ASAP without fixing more bugs IMO. RERO and all.
>> > >>
>> > >> As an Apache committer, your are also an Apache Commons committer,
>> > >> so feel free to create JIRAs, fix bugs and so on.
>> > >>
>> > >> There might be some karma issues with a non-PMC member performing a
>> > >> release, and I think we just went through this (sorry, I'm in
>> > >> settling in a new house, not much time to dig in the ML archives).
>> > >>
>> > >> Does anyone recall?
>> > >>
>> > >> Gary
>> > >>
>> > >>
>> > >>
>> > >> On Mon, Apr 25, 2016 at 12:06 PM, Josh Elser
>> > >> wrote:
>> > >>
>> > >>> Hi all,
>> > >>>
>> > >>> There are presently 171 resolved issues sitting in commons-vfs2
>> > >>> 2.1-SNAPSHOT, with 4 outstanding (none of which look like
>> > >>> blockers to
>> > >> me).
>> > >>> The lack of any release of commons-vfs2 in years has been a big
>> > >>> problem downstream. This past weekend, I was again annoyed by
>> > >>> bugs that have been fixed (but not 

Re: [VFS] 2.1 Release Plan

[Josh Elser]

Because we should make a release of the code that's ready to go now :)

I think it's fine to drop 1.6 support, but if it's going to involve more 
code changes, I don't think it should happen for 2.1. If it's just a 
matter of tweaking the compiler-plugin, that's fine.


I hope to look at this all in earnest tonight.

Gary Gregory wrote:

Why don't we bring [vfs] 2.1 from Java 6 to 7 and update 3rd party
components?

Gary

On Tue, Apr 26, 2016 at 12:36 PM, Gary Gregory > wrote:

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 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 quite happy that you
want to
step in as I havent had the time to do the procedure yet.

And this is not the actual release procedure (which should be
doable as
long as you do not try to use the release-plugin and be careful
about
the multi-module+sandbox nature of VFS (as opposed to other commons
projects)). Also be carefull about branch and tag namings (the
SVN is a
bit messy in this regard).

My main concern I am afraid I would not have enough capacity is
because
of the Clirr report and a lot of partially incompatible changes.
Most
of them only affect providers if they do not properly use
abstract base
classes, but still the list of Clirr violations is long and
developers
here have not yet voiced if they would accept a RC with this
situation
(or not).

Anyway, I do agree that the current critical and blocker bugs are
important but should not stop the 2.1 release (especially if a 2.1.1
release aferwards is much faster to do.) It would be cool to have
VFS-570 (write suport for VFS, but even that could be delivered with
2.1.1 - it might annoy the HDFS folks a bit)

So I can help you in case you need me to sponsor some changes (I
hope I
have enough karma now).

We could even make a joined RC1, I am just not sure it wont open
a big
chunk of additional work.

Gruss
Bernd

  Am Tue, 26 Apr 2016 09:40:01 -0400
schrieb Josh Elser >:

 > 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 I
 > will have more things to contribute back :)
 >
 > I'll pull up the thread in the archives and get back to ya'll
with
 > any questions I have after that.
 >
 > - Josh
 >
 > Matt Sicker wrote:
 > > It's from the thread called "Whatever happened to
commons-io 2.5?"
 > > A few people stepped up to give the necessary permissions and
 > > committed his GPG key.
 > >
 > > On 25 April 2016 at 17:10, Gary
Gregory>
 > > wrote:
 > >
 > >> Hi,
 > >>
 > >> Agreed, VFS 2.1 has been too long in the making. We can
release
 > >> ASAP without fixing more bugs IMO. RERO and all.
 > >>
 > >> As an Apache committer, your are also an Apache Commons
committer,
 > >> so feel free to create JIRAs, fix bugs and so on.
 > >>
 > >> There might be some karma issues with a non-PMC member
performing a
 > >> release, and I think we just went through this (sorry, I'm in
 > >> settling in a new house, not much time to dig in the ML
archives).
 > >>
 > >> Does anyone recall?
 > >>
 > >> Gary
 > >>
 > >>
 > >>
 > >> On Mon, Apr 25, 2016 at 12:06 PM, Josh
Elser>
 > >> wrote:
 > >>
 > >>> Hi all,
 > >>>
 > >>> There are presently 171 resolved issues sitting in
commons-vfs2
 > >>> 2.1-SNAPSHOT, with 4 outstanding (none of which look like
 > >>> blockers to
 > >> me).
 > >>> 

CP 40?

[Gary Gregory]

Did we give up on releasing CP 40?

Gary

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

Re: [VFS] 2.1 Release Plan

[Gary Gregory]

Why don't we bring [vfs] 2.1 from Java 6 to 7 and update 3rd party
components?

Gary

On Tue, Apr 26, 2016 at 12:36 PM, Gary Gregory 
wrote:

> 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 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 quite happy that you want to
>> step in as I havent had the time to do the procedure yet.
>>
>> And this is not the actual release procedure (which should be doable as
>> long as you do not try to use the release-plugin and be careful about
>> the multi-module+sandbox nature of VFS (as opposed to other commons
>> projects)). Also be carefull about branch and tag namings (the SVN is a
>> bit messy in this regard).
>>
>> My main concern I am afraid I would not have enough capacity is because
>> of the Clirr report and a lot of partially incompatible changes. Most
>> of them only affect providers if they do not properly use abstract base
>> classes, but still the list of Clirr violations is long and developers
>> here have not yet voiced if they would accept a RC with this situation
>> (or not).
>>
>> Anyway, I do agree that the current critical and blocker bugs are
>> important but should not stop the 2.1 release (especially if a 2.1.1
>> release aferwards is much faster to do.) It would be cool to have
>> VFS-570 (write suport for VFS, but even that could be delivered with
>> 2.1.1 - it might annoy the HDFS folks a bit)
>>
>> So I can help you in case you need me to sponsor some changes (I hope I
>> have enough karma now).
>>
>> We could even make a joined RC1, I am just not sure it wont open a big
>> chunk of additional work.
>>
>> Gruss
>> Bernd
>>
>>  Am Tue, 26 Apr 2016 09:40:01 -0400
>> schrieb Josh Elser :
>>
>> > 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 I
>> > will have more things to contribute back :)
>> >
>> > I'll pull up the thread in the archives and get back to ya'll with
>> > any questions I have after that.
>> >
>> > - Josh
>> >
>> > Matt Sicker wrote:
>> > > It's from the thread called "Whatever happened to commons-io 2.5?"
>> > > A few people stepped up to give the necessary permissions and
>> > > committed his GPG key.
>> > >
>> > > On 25 April 2016 at 17:10, Gary Gregory
>> > > wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >> Agreed, VFS 2.1 has been too long in the making. We can release
>> > >> ASAP without fixing more bugs IMO. RERO and all.
>> > >>
>> > >> As an Apache committer, your are also an Apache Commons committer,
>> > >> so feel free to create JIRAs, fix bugs and so on.
>> > >>
>> > >> There might be some karma issues with a non-PMC member performing a
>> > >> release, and I think we just went through this (sorry, I'm in
>> > >> settling in a new house, not much time to dig in the ML archives).
>> > >>
>> > >> Does anyone recall?
>> > >>
>> > >> Gary
>> > >>
>> > >>
>> > >>
>> > >> On Mon, Apr 25, 2016 at 12:06 PM, Josh Elser
>> > >> wrote:
>> > >>
>> > >>> Hi all,
>> > >>>
>> > >>> There are presently 171 resolved issues sitting in commons-vfs2
>> > >>> 2.1-SNAPSHOT, with 4 outstanding (none of which look like
>> > >>> blockers to
>> > >> me).
>> > >>> The lack of any release of commons-vfs2 in years has been a big
>> > >>> problem downstream. This past weekend, I was again annoyed by
>> > >>> bugs that have been fixed (but not release) which is spurring me
>> > >>> to take some action. There have been emails reaching back as far
>> > >>> as 2014 asking when the next
>> > >> release
>> > >>> might be, not to mention the fact that vfs-2.0 was released in
>> > >>> 2011 (!).
>> > >>>
>> > >>> History aside, I'm reaching out today to:
>> > >>>
>> > >>> 1) See if anyone on the PMC has the cycles to volunteer as RM.
>> > >>>1a) If not, how can you empower me (or others) to make the
>> > >>> release on your behalf.
>> > >>> 2) Understand, specifically, what (if any) roadblocks exist to
>> > >>> release this version.
>> > >>>
>> > >>> Thanks.
>> > >>>
>> > >>> - Josh
>> > >>>
>> > >>>
>> > >>>
>> -
>> > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > >>> For additional commands, e-mail: dev-h...@commons.apache.org
>> > >>>
>> > >>>
>> > >>
>> > >> --
>> > >> E-Mail: 

Re: [io] Make requirement Java 7?

[Gary Gregory]

trunk is now Java 7 in the POM.

Gary

On Thu, Apr 28, 2016 at 5:44 AM, Benedikt Ritter  wrote:

> Kristian Rosenvold  schrieb am Do., 28. Apr.
> 2016 um 11:59 Uhr:
>
> > 2016-04-26 15:39 GMT+02:00 Emmanuel Bourg :
> >
> > > We are not alone :) RedHat is still maintaining OpenJDK 6 and providing
> > > security fixes for things like critical production systems not meant to
> > > be changed every two years.
> > >
> > >
> > Yes, and they are getting paid for it. If they need extended maintenance
> of
> > an old version they can do it themselves. We really do not need to be
> > backing anyones business model on our volunteer time.
> >
>
> Big +1
>
>
> >
> > I say just move the whole thing forward to jdk7 for the 2.6 release. This
> > is entirely undramatical. And I've been a proponent for relasing 2.5 on
> 1.6
> > :)
> >
> >
> > Kristian
> >
>



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

Re: [VOTE] Release Validator 1.5.1 based on RC2

[Gary Gregory]

Note a blocker: Missing text in @link:

* Note: the {@link #isValid(String)} and {@link } methods strip off any
leading

+1

Release notes, MD5, SHA1, ASC, all OK.

Builds OK from src zip with the expected Slf4j report blow ups with:

Apache Maven *3.3.9* (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T08:41:47-08:00)
Maven home: E:\Java\apache-maven-3.3.9\bin\..
Java version: *1.8.0_91*, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_91\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"

Builds OK as above but with set MAVEN_OPTS=-Xmx2048m -XX:MaxPermSize=128m
in addition to avoid an OOME:

Apache Maven *3.3.9* (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T08:41:47-08:00)
Maven home: E:\Java\apache-maven-3.3.9\bin\..
Java version: *1.7.0_79*, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_79\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

Builds OK with with set MAVEN_OPTS=-Xmx2048m -XX:MaxPermSize=128m:

Apache Maven *3.0.5* (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
05:51:28-0800)
Maven home: E:\Java\apache-maven-3.0.5
Java version: *1.7.0_79*, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_79\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

It builds but I get:

[INFO] Downloading from JIRA at:
http://issues.apache.org/jira/sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?tempMax=100=true=project+%3D+VALIDATOR+AND+status+in+
type+in+%28Bug%2C+%22New+Feature%22%2C+Task%2C+Improvement%2C+Wish%2C+Test%29+ORDER+BY+fixversion+DESC%2C+type+ASC%2C+key+DESC
[ERROR] Error downloading issues from JIRA. Cause is chunked stream ended
unexpectedly
[WARNING]
org.apache.maven.plugin.MojoExecutionException: Failed to parse JIRA XML.
at org.apache.maven.plugin.jira.JiraXML.parse(JiraXML.java:132)
at org.apache.maven.plugin.jira.JiraXML.parseXML(JiraXML.java:108)
at
org.apache.maven.plugin.jira.ClassicJiraDownloader.getIssueList(ClassicJiraDownloader.java:458)
at
org.apache.maven.plugin.jira.AdaptiveJiraDownloader.getIssueList(AdaptiveJiraDownloader.java:89)
at
org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:374)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:255)
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:224)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:311)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:129)
at
org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:182)
at
org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:141)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.xml.sax.SAXParseException; lineNumber: 6998; columnNumber:
52; The element type "customfieldvalue" must be 

Re: [VOTE] Release Validator 1.5.1 based on RC2

[Emmanuel Bourg]

Le 25/04/2016 à 23:24, sebb a écrit :

>   [X] +1 Release these artifacts

Tested on Debian with Maven 3.3.9 and OpenJDK 8. Builds fine from the
tag and from the source archive. The changes look good.

Emmanuel Bourg




signature.asc
Description: OpenPGP digital signature

Re: [ALL] Validator vote - please

[Gary Gregory]

AFK most of the day. I started reviewing and got side tracked on day 1 of
the vote. Will continue tomorrow most likely.

Gary
On Apr 28, 2016 6:23 AM, "sebb"  wrote:

> The Validator vote has been open 3 days now, with no votes or even
> comments.
>
> Please could some other PMC members vote?
>
> Thanks!
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL] Validator vote - please

[Benedikt Ritter]

I'm giving an on site Java Training at one of our customers currently. I'll
have some time this evening and I've already planed to use that time to
verify this release.

Thank you!
Benedikt

sebb  schrieb am Do., 28. Apr. 2016 um 15:23 Uhr:

> The Validator vote has been open 3 days now, with no votes or even
> comments.
>
> Please could some other PMC members vote?
>
> Thanks!
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[ALL] Validator vote - please

[sebb]

The Validator vote has been open 3 days now, with no votes or even comments.

Please could some other PMC members vote?

Thanks!

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

Re: [VOTE] Release Validator 1.5.1 based on RC2

[sebb]

On 25 April 2016 at 22:24, sebb  wrote:
> Second try:
>
> Validator 1.5.1 RC2 is available for review here:
>
> https://dist.apache.org/repos/dist/dev/commons/validator/1.5.1_RC2/
> (revision 13418)
>
> commons-validator-1.5.1-bin.tar.gz.sha1:33a6ffa9b1e9eaa151912312a5ae3df6e996e06f
> commons-validator-1.5.1-bin.zip.sha1:ffa68a2768c4edea00d16ac1f0481c5852aaff05
> commons-validator-1.5.1-src.tar.gz.sha1:48e1cd7504ca2987e403948f46b6c46f136b0ccf
> commons-validator-1.5.1-src.zip.sha1:706ffb941c4f31057d9a4d24e857e07498f971be
>
>   Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1155/commons-validator/commons-validator/1.5.1/
>
> These are the artifacts and their hashes
>
> commons-validator-1.5.1-test-sources.jar
> (SHA1: 41fa99c63b3ff4a65acf3324e9722591e2c7175c)
> commons-validator-1.5.1-sources.jar
> (SHA1: 1779e91e01dc506f388c350a8684f77c43943a08)
> commons-validator-1.5.1.pom
> (SHA1: ab12dc49a49d3ac67bcb949834cb2eed4ed26554)
> commons-validator-1.5.1.jar
> (SHA1: 86d05a46e8f064b300657f751b5a98c62807e2a0)
> commons-validator-1.5.1-javadoc.jar
> (SHA1: 1c5fbdeb20a211050d91366eb1a33d6b8adb3323)
> commons-validator-1.5.1-tests.jar
> (SHA1: 52f05bf0e7b66194e4fd99d9e10692e68fd16450)
>
>   Details of changes since 1.5.0 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/validator/1.5.1_RC2/RELEASE-NOTES.txt
> http://home.apache.org/~sebb/validator-1.5.1-RC2/changes-report.html
>
>
>   The tag is here:
> 
> http://svn.apache.org/repos/asf/commons/proper/validator/tags/VALIDATOR_1_5_1_RC2/
> (revision 1740857)
>
>   Site:
> http://home.apache.org/~sebb/validator-1.5.1-RC2/
>
>(some *relative* links are broken - these will be OK once the site
> is deployed)
>
>   Clirr Report (compared to 1.5.0):
> http://home.apache.org/~sebb/validator-1.5.1-RC2/clirr-report.html
>
>   RAT Report:
> http://home.apache.org/~sebb/validator-1.5.1-RC2/rat-report.html
>
>   KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
>   Please review the release candidate and vote.
>
>   This vote will close no sooner than 72 hours from now,
>   i.e. sometime after 22:00 GMT 28 Apr 2016
>

PROPOSAL.html is missing from the source archives.
However it is not needed for building/testing and is only of
historical interest.
It could probably be removed from SVN now.

Here's my formal vote:

>   [X] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
>   Thanks!

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

[Benedikt Ritter]

Kristian Rosenvold  schrieb am Do., 28. Apr.
2016 um 11:59 Uhr:

> 2016-04-26 15:39 GMT+02:00 Emmanuel Bourg :
>
> > We are not alone :) RedHat is still maintaining OpenJDK 6 and providing
> > security fixes for things like critical production systems not meant to
> > be changed every two years.
> >
> >
> Yes, and they are getting paid for it. If they need extended maintenance of
> an old version they can do it themselves. We really do not need to be
> backing anyones business model on our volunteer time.
>

Big +1


>
> I say just move the whole thing forward to jdk7 for the 2.6 release. This
> is entirely undramatical. And I've been a proponent for relasing 2.5 on 1.6
> :)
>
>
> Kristian
>

Re: [io] Make requirement Java 7?

[Kristian Rosenvold]

2016-04-26 15:39 GMT+02:00 Emmanuel Bourg :

> We are not alone :) RedHat is still maintaining OpenJDK 6 and providing
> security fixes for things like critical production systems not meant to
> be changed every two years.
>
>
Yes, and they are getting paid for it. If they need extended maintenance of
an old version they can do it themselves. We really do not need to be
backing anyones business model on our volunteer time.

I say just move the whole thing forward to jdk7 for the 2.6 release. This
is entirely undramatical. And I've been a proponent for relasing 2.5 on 1.6
:)


Kristian

RE: [jira] [Updated] (CRYPTO-31) Make fields final wherever possible

[Sun, Dapeng]

Hi Gary,

Thank you for pointing it out. I will remove the tag of 'affects version'.

Regards
Dapeng

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Thursday, April 28, 2016 1:03 PM
To: Commons Developers List
Subject: Re: [jira] [Updated] (CRYPTO-31) Make fields final wherever possible

I do not think tickets should be marked as affects 1.0.0 since that version is 
not released.

Gary
On Apr 27, 2016 8:33 PM, "Dapeng Sun (JIRA)"  wrote:

>
>  [
> https://issues.apache.org/jira/browse/CRYPTO-31?page=com.atlassian.jir
> a.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Dapeng Sun updated CRYPTO-31:
> -
> Affects Version/s: 1.0.0
>
> > Make fields final wherever possible
> > ---
> >
> > Key: CRYPTO-31
> > URL: https://issues.apache.org/jira/browse/CRYPTO-31
> > Project: Commons Crypto
> >  Issue Type: Improvement
> >  Components: Stream
> >Affects Versions: 1.0.0
> >Reporter: Sebb
> >Assignee: Ferdinand Xu
> >Priority: Minor
> > Fix For: 1.0.0
> >
> >
> > Final fields are automatically thread safe if the object itself is 
> > not
> modified.
> > Whereas non-final fields are not necessarily thread-safe even if 
> > they
> are not mutated - this is because of the Java memory model.
> > There are several non-final fields that are not mutated once created.
> They should be made final to improve thread-safety. This is 
> particularly important for static fields since they are more likely to 
> be used by multiple threads.
> > Note: such changes will not affect the public API if the fields are
> private or package-protected.
> > The fields include:
> > JavaSecureRandom.instance
> > OpensslSecureRandom.fallback
> > OpensslSecureRandom.nativeEnabled
> > ChannelInput.channel
> > StreamInput.buf - since no point creating an instance if it is not 
> > going
> to be used for reading, might as well create the buffer up front
> > StreamOutput.bufferSize
> > StreamOutput.buf - as for StreamInput StreamOutput.out - should also 
> > be private static NativeCodeLoader.nativeCodeLoaded static 
> > OSInfo.archMapping static ReflectionUtils.classLoader
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>