Re: [VFS] 2.1 clirr report

[sebb]

Has anyone looked at whether the changes really do affect BC?
Note that the Maven Clirr does not distinguish between source compat and BC.
Breaking source compat is not as serious an issue.

For example, the new methds in various interfaces don't affect BC:

https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.5.3-100

Some of the changes clearly do affect BC, but has anyone looked at
whether the old API can be implemented in terms of the new?

It may be a bit tedious to check, but if BC can be achieved then it
reduces the downstream effort needed.


On 30 April 2016 at 00:00, Josh Elser  wrote:
> So, just call 2.1 instead 3.0? Fine by me.
>
> Package name becomes o.a.c.vfs3? ArtifactId becomes (variants of)
> commons-vfs3? Please confirm, Gary.
>
> I don't think we need to expound any more about why compatibility is
> important. No one has even presented any such argument. Let's stick to
> action :)
>
>
> Gary Gregory wrote:
>>
>> Let's look at this from a different POV:
>>
>> 1) If we release 2.1 as is, we are creating a risk. We are strictly
>> speaking breaking BC.
>> 2) If we release trunk as 3.0 with a package and Maven coordinate change,
>> then there is zero risk. If you want to use the new version, you MUST
>> change your imports.
>>
>> The risk, as remote as it may seem, is what I run into regularly dealing
>> with a deep stack: I do not depend on jar Z but I depend on X, I compile
>> against X. X depends on Y depends on Z. If there is BC problem in X, I can
>> deal with it. If it is in Y or Z then I am due for some hacking.
>>
>> For example, here are two BC breaks in maintenance releases I recently
>> found:
>>
>> - https://issues.apache.org/jira/browse/WSS-577 Binary compatibility
>> broken
>> between version<=2.1.3 and>=2.1.4 with
>> org.apache.wss4j.dom.WSSecurityEngineResult
>> - https://issues.apache.org/jira/browse/SANTUARIO-440 Binary compatibility
>> broken between version 2.0.5 and 2.0.4 in
>> org.apache.xml.security.c14n.CanonicalizationException
>>
>> In these two cases, I was very lucky that I could change my source code to
>> match the changes. But these changes should have never been made in a
>> maintenance release.
>>
>> So... the least risky option is (2), which is a 0-risk option.
>>
>> Gary
>>
>> On Fri, Apr 29, 2016 at 3:11 PM, Josh Elser  wrote:
>>
>>> Hah, thanks for the details, Ralph. I will be sure to bring myself up to
>>> speed.
>>>
>>> That being said: I would still like to get some consensus from those who
>>> will be voting from the PMC on what should be done, given the current
>>> report (since my opinion and thus vote are non-binding :D)
>>>
>>> http://home.apache.org/~elserj/commons-vfs/commons-vfs-2.1-site/
>>>
>>>
>>> Ralph Goers wrote:
>>>
 FWIW, these discussions are not new.  You might enjoy reading these
 threads -
 http://www.mail-archive.com/user@commons.apache.org/msg03711.html. But
 maybe not! ;-)

 Ralph


 On Apr 29, 2016, at 12:43 PM, Ralph Goers
>
> wrote:
>
> On Apr 29, 2016, at 10:57 AM, Josh Elser   wrote:
>>
>>
>>
>> Ralph Goers wrote:
>>
>>> On Apr 29, 2016, at 9:27 AM, Josh Elserwrote:

 sebb wrote:

> On 29 April 2016 at 16:19, Josh Elser wrote:
>
>> sebb wrote:
>>
>>> On 29 April 2016 at 15:59, Josh Elser
>>>   wrote:
>>>
 How does changing the package name help? Doesn't that just push
 a
>
> NoClassDefFound error instead of some missing implementation
> for
> a new
> method?
>
 That means we change ALL the package names and the Maven coords.
>>>
>>> Effectively it's a different component, and users have to change
>>> the
>>> import package names.
>>>
>> How is that at all improving *any* level of compatibility? I
>> really
>> don't
>> see how that is providing any service to your users. Now, instead
>> of just
>> updating the version for the artifact and adding the new methods,
>> they
>> *also* have to change the package...
>>
> It's not about compatibility, it's about avoiding jar hell.
>
 Hold up now. We were talking about compatibility. I also don't know
 specifically what you mean by "jar hell", but it sounds like this is
 not
 relevant to the source/binary compatibility discussion (and thus not
 relevant to this thread). Please correct me if I'm wrong.

>>> If a user of VFS drops in the new jar in place of the old one and
>>> their application gets runtime errors then, by definition, binary
>>> compatibility is broken.  This 

Re: [VFS] 2.1 clirr report

[ecki]

Hello,

I will/would vote for releasing 2.1 even when there are some minor problems (if 
it is well documented). Because I do see a large number of bugs for 2.0 and 
those users wont easily profit from a 3.0 (and I dont think backporting or 
removing of all incompatibilities will happen).

Having said that I do have a 2.0 provider which runs fine with 2.1 (source and 
binary).

Maybe some of the clirr violations could be addressed to keep the changes 
strictly on the spi side.

It should not stop us from also releasing a 3.0 shortly afterwards. (Personally 
I would however more work on the 2.x branch as I have the api packages in a 
product where i cannot ask customers to upgrade (but I can ask them to not use 
the incompat classes).

Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: Josh Elser 
To: Commons Developers List 
Sent: Sa., 30 Apr. 2016 0:11
Subject: Re: [VFS] 2.1 clirr report

Hah, thanks for the details, Ralph. I will be sure to bring myself up to 
speed.

That being said: I would still like to get some consensus from those who 
will be voting from the PMC on what should be done, given the current 
report (since my opinion and thus vote are non-binding :D)

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

Ralph Goers wrote:
> FWIW, these discussions are not new.  You might enjoy reading these threads - 
> http://www.mail-archive.com/user@commons.apache.org/msg03711.html. But maybe 
> not! ;-)
>
> Ralph
>
>
>> On Apr 29, 2016, at 12:43 PM, Ralph Goers  wrote:
>>
>>> On Apr 29, 2016, at 10:57 AM, Josh Elser  wrote:
>>>
>>>
>>>
>>> Ralph Goers wrote:
> On Apr 29, 2016, at 9:27 AM, Josh Elser   wrote:
>
> sebb wrote:
>> On 29 April 2016 at 16:19, Josh Elserwrote:
>>> sebb wrote:
 On 29 April 2016 at 15:59, Josh Elser wrote:
>> How does changing the package name help? Doesn't that just push a
>> NoClassDefFound error instead of some missing implementation for a 
>> new
>> method?
 That means we change ALL the package names and the Maven coords.
 Effectively it's a different component, and users have to change the
 import package names.
>>> How is that at all improving *any* level of compatibility? I really 
>>> don't
>>> see how that is providing any service to your users. Now, instead of 
>>> just
>>> updating the version for the artifact and adding the new methods, they
>>> *also* have to change the package...
>> It's not about compatibility, it's about avoiding jar hell.
> Hold up now. We were talking about compatibility. I also don't know 
> specifically what you mean by "jar hell", but it sounds like this is not 
> relevant to the source/binary compatibility discussion (and thus not 
> relevant to this thread). Please correct me if I'm wrong.
 If a user of VFS drops in the new jar in place of the old one and their 
 application gets runtime errors then, by definition, binary compatibility 
 is broken.  This can happen if the user implemented their own FileSystem 
 and are using interfaces that have had new methods added. It can happen if 
 public methods have had signatures change.  If any of these happen then 
 Commons policy is that the package names must change and the artifact id 
 must change, as the jar is no longer compatible with the old one.  This 
 allows the old jar and the new jar to be used side-by-side.
>>> Ok. Can you point me at this documentation? Apparently the issues I take 
>>> with this are more engrained into all of Commons :)
>> I would have to search the dev mailing list but this has been discussed in 
>> the past.  The first link below discusses the versioning policy but does not 
>> explicitly call out changing the package name and artifactid. The second two 
>> links are example of release announcements for incompatible releases.
>>
>> https://commons.apache.org/releases/versioning.html
>>   
>> >
>> http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html
>>   
>> >
>> https://commons.apache.org/proper/commons-collections/release_4_0.html
>>   
>> 

Re: [VFS] 2.1 clirr report

[Josh Elser]

So, just call 2.1 instead 3.0? Fine by me.

Package name becomes o.a.c.vfs3? ArtifactId becomes (variants of) 
commons-vfs3? Please confirm, Gary.


I don't think we need to expound any more about why compatibility is 
important. No one has even presented any such argument. Let's stick to 
action :)


Gary Gregory wrote:

Let's look at this from a different POV:

1) If we release 2.1 as is, we are creating a risk. We are strictly
speaking breaking BC.
2) If we release trunk as 3.0 with a package and Maven coordinate change,
then there is zero risk. If you want to use the new version, you MUST
change your imports.

The risk, as remote as it may seem, is what I run into regularly dealing
with a deep stack: I do not depend on jar Z but I depend on X, I compile
against X. X depends on Y depends on Z. If there is BC problem in X, I can
deal with it. If it is in Y or Z then I am due for some hacking.

For example, here are two BC breaks in maintenance releases I recently
found:

- https://issues.apache.org/jira/browse/WSS-577 Binary compatibility broken
between version<=2.1.3 and>=2.1.4 with
org.apache.wss4j.dom.WSSecurityEngineResult
- https://issues.apache.org/jira/browse/SANTUARIO-440 Binary compatibility
broken between version 2.0.5 and 2.0.4 in
org.apache.xml.security.c14n.CanonicalizationException

In these two cases, I was very lucky that I could change my source code to
match the changes. But these changes should have never been made in a
maintenance release.

So... the least risky option is (2), which is a 0-risk option.

Gary

On Fri, Apr 29, 2016 at 3:11 PM, Josh Elser  wrote:


Hah, thanks for the details, Ralph. I will be sure to bring myself up to
speed.

That being said: I would still like to get some consensus from those who
will be voting from the PMC on what should be done, given the current
report (since my opinion and thus vote are non-binding :D)

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


Ralph Goers wrote:


FWIW, these discussions are not new.  You might enjoy reading these
threads -
http://www.mail-archive.com/user@commons.apache.org/msg03711.html. But
maybe not! ;-)

Ralph


On Apr 29, 2016, at 12:43 PM, Ralph Goers

wrote:

On Apr 29, 2016, at 10:57 AM, Josh Elser   wrote:



Ralph Goers wrote:


On Apr 29, 2016, at 9:27 AM, Josh Elserwrote:

sebb wrote:


On 29 April 2016 at 16:19, Josh Elser wrote:


sebb wrote:


On 29 April 2016 at 15:59, Josh Elser
  wrote:


How does changing the package name help? Doesn't that just push a

NoClassDefFound error instead of some missing implementation for
a new
method?


That means we change ALL the package names and the Maven coords.

Effectively it's a different component, and users have to change
the
import package names.


How is that at all improving *any* level of compatibility? I really
don't
see how that is providing any service to your users. Now, instead
of just
updating the version for the artifact and adding the new methods,
they
*also* have to change the package...


It's not about compatibility, it's about avoiding jar hell.


Hold up now. We were talking about compatibility. I also don't know
specifically what you mean by "jar hell", but it sounds like this is not
relevant to the source/binary compatibility discussion (and thus not
relevant to this thread). Please correct me if I'm wrong.


If a user of VFS drops in the new jar in place of the old one and
their application gets runtime errors then, by definition, binary
compatibility is broken.  This can happen if the user implemented their own
FileSystem and are using interfaces that have had new methods added. It can
happen if public methods have had signatures change.  If any of these
happen then Commons policy is that the package names must change and the
artifact id must change, as the jar is no longer compatible with the old
one.  This allows the old jar and the new jar to be used side-by-side.


Ok. Can you point me at this documentation? Apparently the issues I
take with this are more engrained into all of Commons :)


I would have to search the dev mailing list but this has been discussed
in the past.  The first link below discusses the versioning policy but does
not explicitly call out changing the package name and artifactid. The
second two links are example of release announcements for incompatible
releases.

https://commons.apache.org/releases/versioning.html<
https://commons.apache.org/releases/versioning.html>   <
https://commons.apache.org/releases/versioning.html<
https://commons.apache.org/releases/versioning.html>>

http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html
<
http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html>
<

Re: [VFS] 2.1 clirr report

[Gary Gregory]

Let's look at this from a different POV:

1) If we release 2.1 as is, we are creating a risk. We are strictly
speaking breaking BC.
2) If we release trunk as 3.0 with a package and Maven coordinate change,
then there is zero risk. If you want to use the new version, you MUST
change your imports.

The risk, as remote as it may seem, is what I run into regularly dealing
with a deep stack: I do not depend on jar Z but I depend on X, I compile
against X. X depends on Y depends on Z. If there is BC problem in X, I can
deal with it. If it is in Y or Z then I am due for some hacking.

For example, here are two BC breaks in maintenance releases I recently
found:

- https://issues.apache.org/jira/browse/WSS-577 Binary compatibility broken
between version <=2.1.3 and >=2.1.4 with
org.apache.wss4j.dom.WSSecurityEngineResult
- https://issues.apache.org/jira/browse/SANTUARIO-440 Binary compatibility
broken between version 2.0.5 and 2.0.4 in
org.apache.xml.security.c14n.CanonicalizationException

In these two cases, I was very lucky that I could change my source code to
match the changes. But these changes should have never been made in a
maintenance release.

So... the least risky option is (2), which is a 0-risk option.

Gary

On Fri, Apr 29, 2016 at 3:11 PM, Josh Elser  wrote:

> Hah, thanks for the details, Ralph. I will be sure to bring myself up to
> speed.
>
> That being said: I would still like to get some consensus from those who
> will be voting from the PMC on what should be done, given the current
> report (since my opinion and thus vote are non-binding :D)
>
> http://home.apache.org/~elserj/commons-vfs/commons-vfs-2.1-site/
>
>
> Ralph Goers wrote:
>
>> FWIW, these discussions are not new.  You might enjoy reading these
>> threads -
>> http://www.mail-archive.com/user@commons.apache.org/msg03711.html. But
>> maybe not! ;-)
>>
>> Ralph
>>
>>
>> On Apr 29, 2016, at 12:43 PM, Ralph Goers
>>> wrote:
>>>
>>> On Apr 29, 2016, at 10:57 AM, Josh Elser  wrote:



 Ralph Goers wrote:

> On Apr 29, 2016, at 9:27 AM, Josh Elser   wrote:
>>
>> sebb wrote:
>>
>>> On 29 April 2016 at 16:19, Josh Elserwrote:
>>>
 sebb wrote:

> On 29 April 2016 at 15:59, Josh Elser
>  wrote:
>
>> How does changing the package name help? Doesn't that just push a
>>> NoClassDefFound error instead of some missing implementation for
>>> a new
>>> method?
>>>
>> That means we change ALL the package names and the Maven coords.
> Effectively it's a different component, and users have to change
> the
> import package names.
>
 How is that at all improving *any* level of compatibility? I really
 don't
 see how that is providing any service to your users. Now, instead
 of just
 updating the version for the artifact and adding the new methods,
 they
 *also* have to change the package...

>>> It's not about compatibility, it's about avoiding jar hell.
>>>
>> Hold up now. We were talking about compatibility. I also don't know
>> specifically what you mean by "jar hell", but it sounds like this is not
>> relevant to the source/binary compatibility discussion (and thus not
>> relevant to this thread). Please correct me if I'm wrong.
>>
> If a user of VFS drops in the new jar in place of the old one and
> their application gets runtime errors then, by definition, binary
> compatibility is broken.  This can happen if the user implemented their 
> own
> FileSystem and are using interfaces that have had new methods added. It 
> can
> happen if public methods have had signatures change.  If any of these
> happen then Commons policy is that the package names must change and the
> artifact id must change, as the jar is no longer compatible with the old
> one.  This allows the old jar and the new jar to be used side-by-side.
>
 Ok. Can you point me at this documentation? Apparently the issues I
 take with this are more engrained into all of Commons :)

>>> I would have to search the dev mailing list but this has been discussed
>>> in the past.  The first link below discusses the versioning policy but does
>>> not explicitly call out changing the package name and artifactid. The
>>> second two links are example of release announcements for incompatible
>>> releases.
>>>
>>> https://commons.apache.org/releases/versioning.html<
>>> https://commons.apache.org/releases/versioning.html>  <
>>> https://commons.apache.org/releases/versioning.html<
>>> https://commons.apache.org/releases/versioning.html>>
>>>
>>> http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html
>>> <
>>> 

Re: [RESULT}[VOTE] Release Validator 1.5.1 based on RC2

[Gary Gregory]

And thanks to Sebb for shepherding another release ;-)

Gary

On Fri, Apr 29, 2016 at 12:04 PM, sebb  wrote:

> The 72 hours elapsed some while ago.
>
> The following votes have been seen:
>
> Binding +1:
> Sebastian Bazley
> Emmanuel Bourg
> Gary Gregory
> Jörg Schaible
>
> There were no other votes.
>
> As there were at least 3 binding +1 votes and no -1 votes, the vote passes.
>
>
> Thanks to all who voted and for the feedback.
>
>
>
> -- Forwarded message --
> Date: 25 April 2016 at 22:24
> Subject: [VOTE] Release Validator 1.5.1 based on RC2
> To: CommonsDev 
>
>
> 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
>
>
>   [ ] +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
>
>


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

[Josh Elser]

Hah, thanks for the details, Ralph. I will be sure to bring myself up to 
speed.


That being said: I would still like to get some consensus from those who 
will be voting from the PMC on what should be done, given the current 
report (since my opinion and thus vote are non-binding :D)


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

Ralph Goers wrote:

FWIW, these discussions are not new.  You might enjoy reading these threads - 
http://www.mail-archive.com/user@commons.apache.org/msg03711.html. But maybe 
not! ;-)

Ralph



On Apr 29, 2016, at 12:43 PM, Ralph Goers  wrote:


On Apr 29, 2016, at 10:57 AM, Josh Elser  wrote:



Ralph Goers wrote:

On Apr 29, 2016, at 9:27 AM, Josh Elser   wrote:

sebb wrote:

On 29 April 2016 at 16:19, Josh Elserwrote:

sebb wrote:

On 29 April 2016 at 15:59, Josh Elser wrote:

How does changing the package name help? Doesn't that just push a
NoClassDefFound error instead of some missing implementation for a new
method?

That means we change ALL the package names and the Maven coords.
Effectively it's a different component, and users have to change the
import package names.

How is that at all improving *any* level of compatibility? I really don't
see how that is providing any service to your users. Now, instead of just
updating the version for the artifact and adding the new methods, they
*also* have to change the package...

It's not about compatibility, it's about avoiding jar hell.

Hold up now. We were talking about compatibility. I also don't know specifically what you 
mean by "jar hell", but it sounds like this is not relevant to the 
source/binary compatibility discussion (and thus not relevant to this thread). Please 
correct me if I'm wrong.

If a user of VFS drops in the new jar in place of the old one and their 
application gets runtime errors then, by definition, binary compatibility is 
broken.  This can happen if the user implemented their own FileSystem and are 
using interfaces that have had new methods added. It can happen if public 
methods have had signatures change.  If any of these happen then Commons policy 
is that the package names must change and the artifact id must change, as the 
jar is no longer compatible with the old one.  This allows the old jar and the 
new jar to be used side-by-side.

Ok. Can you point me at this documentation? Apparently the issues I take with 
this are more engrained into all of Commons :)

I would have to search the dev mailing list but this has been discussed in the 
past.  The first link below discusses the versioning policy but does not 
explicitly call out changing the package name and artifactid. The second two 
links are example of release announcements for incompatible releases.

https://commons.apache.org/releases/versioning.html
  
>
http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html
  
>
https://commons.apache.org/proper/commons-collections/release_4_0.html
  
>

Ralph





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

Re: [VFS] 2.1 clirr report

[Ralph Goers]

FWIW, these discussions are not new.  You might enjoy reading these threads - 
http://www.mail-archive.com/user@commons.apache.org/msg03711.html. But maybe 
not! ;-)

Ralph


> On Apr 29, 2016, at 12:43 PM, Ralph Goers  wrote:
> 
>> 
>> On Apr 29, 2016, at 10:57 AM, Josh Elser  wrote:
>> 
>> 
>> 
>> Ralph Goers wrote:
 On Apr 29, 2016, at 9:27 AM, Josh Elser  wrote:
 
 sebb wrote:
> On 29 April 2016 at 16:19, Josh Elser   wrote:
>> sebb wrote:
>>> On 29 April 2016 at 15:59, Josh Elserwrote:
> How does changing the package name help? Doesn't that just push a
> NoClassDefFound error instead of some missing implementation for a new
> method?
>>> That means we change ALL the package names and the Maven coords.
>>> Effectively it's a different component, and users have to change the
>>> import package names.
>> How is that at all improving *any* level of compatibility? I really don't
>> see how that is providing any service to your users. Now, instead of just
>> updating the version for the artifact and adding the new methods, they
>> *also* have to change the package...
> It's not about compatibility, it's about avoiding jar hell.
 Hold up now. We were talking about compatibility. I also don't know 
 specifically what you mean by "jar hell", but it sounds like this is not 
 relevant to the source/binary compatibility discussion (and thus not 
 relevant to this thread). Please correct me if I'm wrong.
>>> 
>>> If a user of VFS drops in the new jar in place of the old one and their 
>>> application gets runtime errors then, by definition, binary compatibility 
>>> is broken.  This can happen if the user implemented their own FileSystem 
>>> and are using interfaces that have had new methods added. It can happen if 
>>> public methods have had signatures change.  If any of these happen then 
>>> Commons policy is that the package names must change and the artifact id 
>>> must change, as the jar is no longer compatible with the old one.  This 
>>> allows the old jar and the new jar to be used side-by-side.
>> 
>> Ok. Can you point me at this documentation? Apparently the issues I take 
>> with this are more engrained into all of Commons :)
> 
> I would have to search the dev mailing list but this has been discussed in 
> the past.  The first link below discusses the versioning policy but does not 
> explicitly call out changing the package name and artifactid. The second two 
> links are example of release announcements for incompatible releases.
> 
> https://commons.apache.org/releases/versioning.html 
>  
>  >
> http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html
>  
> 
>  
>   
> >
> https://commons.apache.org/proper/commons-collections/release_4_0.html 
>  
>  >
> 
> Ralph

Re: [VFS] 2.1 clirr report

[Ralph Goers]

> On Apr 29, 2016, at 10:57 AM, Josh Elser  wrote:
> 
> 
> 
> Ralph Goers wrote:
>>> On Apr 29, 2016, at 9:27 AM, Josh Elser  wrote:
>>> 
>>> sebb wrote:
 On 29 April 2016 at 16:19, Josh Elser   wrote:
> sebb wrote:
>> On 29 April 2016 at 15:59, Josh Elserwrote:
  How does changing the package name help? Doesn't that just push a
  NoClassDefFound error instead of some missing implementation for a new
  method?
>> That means we change ALL the package names and the Maven coords.
>> Effectively it's a different component, and users have to change the
>> import package names.
> How is that at all improving *any* level of compatibility? I really don't
> see how that is providing any service to your users. Now, instead of just
> updating the version for the artifact and adding the new methods, they
> *also* have to change the package...
 It's not about compatibility, it's about avoiding jar hell.
>>> Hold up now. We were talking about compatibility. I also don't know 
>>> specifically what you mean by "jar hell", but it sounds like this is not 
>>> relevant to the source/binary compatibility discussion (and thus not 
>>> relevant to this thread). Please correct me if I'm wrong.
>> 
>> If a user of VFS drops in the new jar in place of the old one and their 
>> application gets runtime errors then, by definition, binary compatibility is 
>> broken.  This can happen if the user implemented their own FileSystem and 
>> are using interfaces that have had new methods added. It can happen if 
>> public methods have had signatures change.  If any of these happen then 
>> Commons policy is that the package names must change and the artifact id 
>> must change, as the jar is no longer compatible with the old one.  This 
>> allows the old jar and the new jar to be used side-by-side.
> 
> Ok. Can you point me at this documentation? Apparently the issues I take with 
> this are more engrained into all of Commons :)

I would have to search the dev mailing list but this has been discussed in the 
past.  The first link below discusses the versioning policy but does not 
explicitly call out changing the package name and artifactid. The second two 
links are example of release announcements for incompatible releases.

https://commons.apache.org/releases/versioning.html 

http://www.h-online.com/open/news/item/Apache-Commons-Lang-3-0-makes-a-break-with-the-past-1283761.html
 

https://commons.apache.org/proper/commons-collections/release_4_0.html 


Ralph

[RESULT][VOTE][ALL] (lazy consensus) Commons Parent 40 based on RC3

[sebb]

72 hours has elapsed without any negative votes so the lazy vote passes.

I will publish the sources and send the announce shortly.

On 25 April 2016 at 18:00, sebb  wrote:
> Third try:
>
> The Apache Commons Parent POM provides common settings for all Apache
> Commons components.
>
>
> This is a VOTE to release Commons Parent 40 based on RC3
>
>
> This VOTE by LAZY-CONSENSUS is open for at least 72 hours
> It will close after April 29 17:00 UTC
>
>
> Changes in this version include:
>
> - Update Apache parent: 16 -> 17
> - COMMONSSITE-87 - ensure assembly plugin runs after all package phase plugins
> - Require minimum of Maven 3.0.5
> - maven-release-plugin 2.5.2 -> 2.5.3
> - buildnumber-maven-plugin 1.3 -> 1.4 (supports git SCM now)
> - maven-assembly-plugin 2.5.5 -> 2.6
> - maven-surefire-plugin 2.18.1 -> 2.19.1
> - maven-compiler-plugin : 3.3 -> 3.5.1
> - maven-changes-plugin : 2.11 -> 2.12
> - commons-build-plugin : 1.4 -> 1.6
> - felix:maven-bundle-plugin : 2.5.3 -> 3.0.1
> - maven-enforcer-plugin : 1.3.1 -> 1.4.1
> - maven-project-info-reports-plugin : 2.8 -> 2.9
> - maven-source-plugin : 2.4 -> 3.0.0
> - animal-sniffer-maven-plugin : 1.11 -> 1.15
> - build-helper-maven-plugin : 1.9.1 -> 1.10
> - clirr-maven-plugin : 2.6.1 -> 2.7
> - jacoco-maven-plugin : 0.7.5.201505241946 -> 0.7.6.201602180812
> - maven-clean-plugin : 2.6.1 -> 3.0.0
>
>
> The files (staged):
>   
> https://repository.apache.org/content/repositories/orgapachecommons-1154/org/apache/commons/commons-parent/40/
>
> commons-parent-40.pom
> (SHA1: cfdedc8c2ed763c836ca0f317ac106e17a699f36)
> commons-parent-40-site.xml
> (SHA1: 33fe63b18e0790f6f1d773784dcac0518e01ed8c)
>
> The source archives:
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/40-RC3/ (r13415)
> commons-parent-40-src.tar.gz.sha1: 0bfa38fa057cad592011ad4b03d330e479014af5
> commons-parent-40-src.zip.sha1: 038837ad05662639bfe18eabc8fa7adc6d0c6555
> commons-parent-40-src.tar.gz.md5: f39848d3daa743e7f1206dc44810a85e
> commons-parent-40-src.zip.md5: 50ed7b1a34555abcf06e8e94e1ec2cfc
>
>
> The tag:
> https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent_40_RC3
> (r1740855)
>
> The site: None; the page http://commons.apache.org/commons-parent-pom.html
> will be updated once the POM has been released

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

[RESULT}[VOTE] Release Validator 1.5.1 based on RC2

[sebb]

The 72 hours elapsed some while ago.

The following votes have been seen:

Binding +1:
Sebastian Bazley
Emmanuel Bourg
Gary Gregory
Jörg Schaible

There were no other votes.

As there were at least 3 binding +1 votes and no -1 votes, the vote passes.


Thanks to all who voted and for the feedback.



-- Forwarded message --
Date: 25 April 2016 at 22:24
Subject: [VOTE] Release Validator 1.5.1 based on RC2
To: CommonsDev 


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


  [ ] +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: [VFS] 2.1 clirr report

[Josh Elser]

Ralph Goers wrote:

On Apr 29, 2016, at 9:27 AM, Josh Elser  wrote:

sebb wrote:

On 29 April 2016 at 16:19, Josh Elser   wrote:

sebb wrote:

On 29 April 2016 at 15:59, Josh Elserwrote:

  How does changing the package name help? Doesn't that just push a
  NoClassDefFound error instead of some missing implementation for a new
  method?

That means we change ALL the package names and the Maven coords.
Effectively it's a different component, and users have to change the
import package names.

How is that at all improving *any* level of compatibility? I really don't
see how that is providing any service to your users. Now, instead of just
updating the version for the artifact and adding the new methods, they
*also* have to change the package...

It's not about compatibility, it's about avoiding jar hell.

Hold up now. We were talking about compatibility. I also don't know specifically what you 
mean by "jar hell", but it sounds like this is not relevant to the 
source/binary compatibility discussion (and thus not relevant to this thread). Please 
correct me if I'm wrong.


If a user of VFS drops in the new jar in place of the old one and their 
application gets runtime errors then, by definition, binary compatibility is 
broken.  This can happen if the user implemented their own FileSystem and are 
using interfaces that have had new methods added. It can happen if public 
methods have had signatures change.  If any of these happen then Commons policy 
is that the package names must change and the artifact id must change, as the 
jar is no longer compatible with the old one.  This allows the old jar and the 
new jar to be used side-by-side.


Ok. Can you point me at this documentation? Apparently the issues I take 
with this are more engrained into all of Commons :)


If it's not yet clear, I do not have any confusion about what source and 
binary compatibility is. My confusion is around Commons' application of 
"compatibility", specifically, my current understanding of what is done 
for compatibility would make me unhappy as a user. However, that is a 
completely separate discussion that can be had at a later time.


My goal here is to find out what the Commons PMC considers to be 
blockers to a release so I can avoid wasting time in cutting RCs that 
will just be immediately -1'ed. That's why I keep asking for 
documentation on your policies :)


I still don't have a clear understanding of what *needs* to be done to 
cut 2.1 which is why I keep poking at this all, trying to get an answer 
by understanding your policies.



What matters is what the expectation is as to how users are going to use VFS in 
their projects.  Most will use the providers that we have created. Some may 
implement their own.  We may say that most users can just drop in the jar but 
if you are doing a), b) and/or c) (whatever those are defined to be) that you 
must recompile your code.


Is this an indirect way of asking me as release manager to enumerate 
this "matrix" for you then as a part of the release process or are you 
just stating your view of how you would like it work?


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

Re: [VFS] 2.1 clirr report

[Ralph Goers]

> On Apr 29, 2016, at 9:27 AM, Josh Elser  wrote:
> 
> sebb wrote:
>> On 29 April 2016 at 16:19, Josh Elser  wrote:
>>> sebb wrote:
 On 29 April 2016 at 15:59, Josh Elser   wrote:
>>  How does changing the package name help? Doesn't that just push a
>>  NoClassDefFound error instead of some missing implementation for a new
>>  method?
 
 That means we change ALL the package names and the Maven coords.
 Effectively it's a different component, and users have to change the
 import package names.
>>> 
>>> How is that at all improving *any* level of compatibility? I really don't
>>> see how that is providing any service to your users. Now, instead of just
>>> updating the version for the artifact and adding the new methods, they
>>> *also* have to change the package...
>> 
>> It's not about compatibility, it's about avoiding jar hell.
> 
> Hold up now. We were talking about compatibility. I also don't know 
> specifically what you mean by "jar hell", but it sounds like this is not 
> relevant to the source/binary compatibility discussion (and thus not relevant 
> to this thread). Please correct me if I'm wrong.

If a user of VFS drops in the new jar in place of the old one and their 
application gets runtime errors then, by definition, binary compatibility is 
broken.  This can happen if the user implemented their own FileSystem and are 
using interfaces that have had new methods added. It can happen if public 
methods have had signatures change.  If any of these happen then Commons policy 
is that the package names must change and the artifact id must change, as the 
jar is no longer compatible with the old one.  This allows the old jar and the 
new jar to be used side-by-side.

What matters is what the expectation is as to how users are going to use VFS in 
their projects.  Most will use the providers that we have created. Some may 
implement their own.  We may say that most users can just drop in the jar but 
if you are doing a), b) and/or c) (whatever those are defined to be) that you 
must recompile your code. 

Ralph

Re: [VFS] 2.1 clirr report

[Josh Elser]

sebb wrote:

On 29 April 2016 at 16:19, Josh Elser  wrote:

sebb wrote:

On 29 April 2016 at 15:59, Josh Elser   wrote:

  How does changing the package name help? Doesn't that just push a
  NoClassDefFound error instead of some missing implementation for a new
  method?


That means we change ALL the package names and the Maven coords.
Effectively it's a different component, and users have to change the
import package names.


How is that at all improving *any* level of compatibility? I really don't
see how that is providing any service to your users. Now, instead of just
updating the version for the artifact and adding the new methods, they
*also* have to change the package...


It's not about compatibility, it's about avoiding jar hell.


Hold up now. We were talking about compatibility. I also don't know 
specifically what you mean by "jar hell", but it sounds like this is not 
relevant to the source/binary compatibility discussion (and thus not 
relevant to this thread). Please correct me if I'm wrong.



  Where do you all define what is public API (and thus what is stated to
be
  stable)?



That's the big question...


So, let me give some personal opinions here: you cannot claim to have any
level of compatibility if you do not prominently define what is subject to
compatibility. Just take a look at the introduction on semver[1]: "For this
system to work, you first need to declare a public API".

It is my strong opinion that any attempt to "improve compatibility" is
pointless if you haven't actually put forth the effort to define what you're
keeping compatible.

The feeling I'm getting is that this is not defined. As such, I feel this is
going the same way as the "we should upgrade min JDK" and "we should upgrade
dependencies" -- it's not ready to go and should be addressed in a future
release.

I don't want to come across as dismissive, but I've had this conversation
with more than one other project in the past. If there are concerns, let's
state them, discuss how they be addressed, and move on so we can avoid
unclear worries.


I agree that we are not very good at defining what is public API.

Or rather, we are not very good at defining what is *not* intended to be public.

This is a general problem with Java projects that have more than one
level of package.
Methods and fields often have to be made public or protected to
satisfy internal use.

So in the end it may come down to a judgement call as to which parts
of the otherwise public API are unlikely to be used externally.


A common approach is to define artifacts or specifics packages in an 
artifact which is guaranteed to be stable. Yes, as you say this is hard.


It sounds to me like compatibility is not something commons-vfs is 
anywhere close to guaranteeing presently (as it's presently undefined) 
and it should not hold up a release of 2.1 (my two cents).


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

Re: [VFS] 2.1 clirr report

[sebb]

On 29 April 2016 at 16:19, Josh Elser  wrote:
> sebb wrote:
>>
>> On 29 April 2016 at 15:59, Josh Elser  wrote:
>>>
>>> >  How does changing the package name help? Doesn't that just push a
>>> >  NoClassDefFound error instead of some missing implementation for a new
>>> >  method?
>>
>>
>> That means we change ALL the package names and the Maven coords.
>> Effectively it's a different component, and users have to change the
>> import package names.
>
>
> How is that at all improving *any* level of compatibility? I really don't
> see how that is providing any service to your users. Now, instead of just
> updating the version for the artifact and adding the new methods, they
> *also* have to change the package...

It's not about compatibility, it's about avoiding jar hell.

>>> >  Where do you all define what is public API (and thus what is stated to
>>> > be
>>> >  stable)?
>>> >
>>
>>
>> That's the big question...
>>
>
> So, let me give some personal opinions here: you cannot claim to have any
> level of compatibility if you do not prominently define what is subject to
> compatibility. Just take a look at the introduction on semver[1]: "For this
> system to work, you first need to declare a public API".
>
> It is my strong opinion that any attempt to "improve compatibility" is
> pointless if you haven't actually put forth the effort to define what you're
> keeping compatible.
>
> The feeling I'm getting is that this is not defined. As such, I feel this is
> going the same way as the "we should upgrade min JDK" and "we should upgrade
> dependencies" -- it's not ready to go and should be addressed in a future
> release.
>
> I don't want to come across as dismissive, but I've had this conversation
> with more than one other project in the past. If there are concerns, let's
> state them, discuss how they be addressed, and move on so we can avoid
> unclear worries.

I agree that we are not very good at defining what is public API.

Or rather, we are not very good at defining what is *not* intended to be public.

This is a general problem with Java projects that have more than one
level of package.
Methods and fields often have to be made public or protected to
satisfy internal use.

So in the end it may come down to a judgement call as to which parts
of the otherwise public API are unlikely to be used externally.

> [1] http://semver.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: [VFS] 2.1 clirr report

[Josh Elser]

sebb wrote:

On 29 April 2016 at 15:59, Josh Elser  wrote:

>  How does changing the package name help? Doesn't that just push a
>  NoClassDefFound error instead of some missing implementation for a new
>  method?


That means we change ALL the package names and the Maven coords.
Effectively it's a different component, and users have to change the
import package names.


How is that at all improving *any* level of compatibility? I really 
don't see how that is providing any service to your users. Now, instead 
of just updating the version for the artifact and adding the new 
methods, they *also* have to change the package...



>  Where do you all define what is public API (and thus what is stated to be
>  stable)?
>


That's the big question...



So, let me give some personal opinions here: you cannot claim to have 
any level of compatibility if you do not prominently define what is 
subject to compatibility. Just take a look at the introduction on 
semver[1]: "For this system to work, you first need to declare a public 
API".


It is my strong opinion that any attempt to "improve compatibility" is 
pointless if you haven't actually put forth the effort to define what 
you're keeping compatible.


The feeling I'm getting is that this is not defined. As such, I feel 
this is going the same way as the "we should upgrade min JDK" and "we 
should upgrade dependencies" -- it's not ready to go and should be 
addressed in a future release.


I don't want to come across as dismissive, but I've had this 
conversation with more than one other project in the past. If there are 
concerns, let's state them, discuss how they be addressed, and move on 
so we can avoid unclear worries.


[1] http://semver.org/

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

Re: [VFS] 2.1 clirr report

[sebb]

On 29 April 2016 at 15:59, Josh Elser  wrote:
> How does changing the package name help? Doesn't that just push a
> NoClassDefFound error instead of some missing implementation for a new
> method?

That means we change ALL the package names and the Maven coords.
Effectively it's a different component, and users have to change the
import package names.

> Where do you all define what is public API (and thus what is stated to be
> stable)?
>

That's the big question...

> Gary Gregory wrote:
>>
>> We have 2 choices IMO: document breaks or change package name. The later
>> is
>> safer from a jar hell POV.
>>
>> The question is how likely are the changes going to break BC IRL? There
>> are
>> two main use cases: user like call sites and implementors of providers.
>>
>> Thoughts?
>>
>> Gary
>> 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
>>
>
> -
> 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: [patch] Add elserj to KEYS

[Josh Elser]

Thanks, sebb. That did the trick.

sebb wrote:

Try again.

I added you to the commons unix group

On 29 April 2016 at 05:03, Josh Elser  wrote:

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


-
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: [VFS] 2.1 clirr report

[Josh Elser]

How does changing the package name help? Doesn't that just push a 
NoClassDefFound error instead of some missing implementation for a new 
method?


Where do you all define what is public API (and thus what is stated to 
be stable)?


Gary Gregory wrote:

We have 2 choices IMO: document breaks or change package name. The later is
safer from a jar hell POV.

The question is how likely are the changes going to break BC IRL? There are
two main use cases: user like call sites and implementors of providers.

Thoughts?

Gary
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



-
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

[Jörg Schaible]

+1

Built from source using tarball with my complete compiler zoo.

However, tests fail for JDK 9 (tested even with latest from today):

= %< 
Failed tests: 
  CalendarValidatorTest.testDateTimeStyle:197 validate(A) default
  CalendarValidatorTest.testFormat:215 default expected:<31/12/[]05> but 
was:<31/12/[20]05>
  CurrencyValidatorTest.testIntegerValid:142 US negative expected:<-1234.00> 
but was:
  CurrencyValidatorTest.testInvalid:121 US wrong negative
  CurrencyValidatorTest.testValid:93 US negative expected:<-1234.56> but 
was:
  DateValidatorTest.testDateValidatorMethods:69 validate(A) both 
expected: but was:
  TimeValidatorTest.testLocaleValid:157 compare 0 value=[23:59] failed  
expected: but was:
  TimeValidatorTest.testPatternValid:131 compare 0 value=[23-59-59] failed  
expected: but was:
  TimeValidatorTest.testTimeZone:219 pattern result
Tests in error: 
  CalendarValidatorTest.testCalendarValidatorMethods:70 NullPointer
= %< 

Not critical for this release, but a heads-up.

Cheers,
Jörg


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
> 
> 
>   [ ] +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: [VFS] 2.1 clirr report

[Gary Gregory]

We have 2 choices IMO: document breaks or change package name. The later is
safer from a jar hell POV.

The question is how likely are the changes going to break BC IRL? There are
two main use cases: user like call sites and implementors of providers.

Thoughts?

Gary
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

Re: [VOTE] Release Validator 1.5.1 based on RC2

[Gary Gregory]

On Apr 29, 2016 2:38 AM, "sebb"  wrote:
>
> On 28 April 2016 at 18:34, Gary Gregory  wrote:
> > Note a blocker: Missing text in @link:
>
> I assume you mean "Not a blocker" above?

Yes, not a blocker.

>
> > * 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:
>
> What was the Maven command-line here?

IIRC: mvn clean site

Gary
>
> > [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]
>
> I think that's a Maven issue.
> It can be noted in BUILDING.txt
>
> > 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
> >

Early Access builds of JDK 9 b116 & JDK 9 with Project Jigsaw b115 (#4909) are available on java.net

[Rory O'Donnell]

Hi Benedikt,

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


Early Access b115  (#4909) for JDK 9 with 
Project Jigsaw is available on java.net.


Recent changes:

 * in b114
 o Replace
   –com.apple.eawt
   –com.apple.eio
   With platform independent alternatives in java.awt
 * in b115
 o As per JEP 260, all non-Critical types/members should be moved
   out of
   sun/reflect and placed into a non-exported package. Only
   critical APIs
   should remain in sun.reflect.

We are very interested in hearing your experiences in testing any Early 
Access builds. Have you have begun testing against
JDK 9 and or JDK 9 with Project Jigsaw EA builds, have you uncovered 
showstopper issues that you would like to discuss?
We would really like to hear your findings so far, either reply to me or 
via the mailing lists [1], [2].


Rgds,Rory

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/
[2] http://mail.openjdk.java.net/pipermail/jdk9-dev/

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

Re: [patch] Add elserj to KEYS

[sebb]

Try again.

I added you to the commons unix group

On 29 April 2016 at 05:03, Josh Elser  wrote:
> 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
>
>
> -
> 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: CP 40?

[sebb]

"It will close after April 29 17:00 UTC"

I made a mistake with the date calculation; it should have been Apr 28.
But I thought I would honour the date in mail.

On 28 April 2016 at 23:23, Gary Gregory  wrote:
> 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

-
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 28 April 2016 at 18:34, Gary Gregory  wrote:
> Note a blocker: Missing text in @link:

I assume you mean "Not a blocker" above?

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

What was the Maven command-line here?

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

I think that's a Maven issue.
It can be noted in BUILDING.txt

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

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

[Gangumalla, Uma]

>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...
[Uma] Thanks Gary for your opinion on this. I think I confused on the part
respect "original code". Since we got original code from Hadoop (Chimera
pulled the code from Hadoop), I brought this point. My proposal also says
that, original source of code is from Hadoop. I realized that, point says
about the component coding style for new contributions. BTW, Yes, its not
worth discussing too much on this point :-). I am ok either way.

Regards,
Uma

On 4/28/16, 10:17 PM, "Gary Gregory"  wrote:

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


-
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

[Chen, Haifeng]

OK. Let's use 4 spaces indent. Thanks folks for sharing your opinion.

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Friday, April 29, 2016 1:18 PM
To: Commons Developers List 
Subject: Re: [crypto] The standard indentation is 4 spaces per indent

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