Re: [VOTE] Release Compress 1.10 Based on RC1

[Kristian Rosenvold]

Done in r1654980.

This whole incident is a confirmation of murphys law; I must've run
that test 500 times on my machine without failure =:)

K


2015-01-27 0:10 GMT+01:00 Gary Gregory :
> I see you changed the test but the code could benefit from a comment to
> avoid a future regression back to this problem.
>
> Gary
>
> On Mon, Jan 26, 2015 at 4:52 PM, Kristian Rosenvold 
> wrote:
>
>> Testcase fixed in r1654901
>>
>> Kristian
>>
>>
>> 2015-01-26 22:37 GMT+01:00 Kristian Rosenvold <
>> kristian.rosenv...@gmail.com>:
>> > 2015-01-26 22:27 GMT+01:00 Gary Gregory :
>> >> Tests:
>> >>
>> >> Running: 'mvn clean site' gave me
>> >>
>> >> Failed tests:
>> >>
>>  ZipTestCase.testCopyRawZip64EntryFromFile:361->assertSameFileContents:414
>> >> arrays first differed at element [10]; expected:<-16> but was:<-15>
>> >
>> > The problem appears to be that time does not stand still, and every
>> > now and then you can make "expected" and "actual" get different time
>> > stamps (with the 2 second granularity of zip it takes a bit of "luck"
>> > to hit the problem)
>> >
>> > The problem is within the testcase itself, and I'll fix this on trunk.
>> >
>> > Kristian
>>
>> -
>> 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

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

RE: [bcel] PLSE changes to BCEL

[Mark Roberts]

In our opinion, the fix is worse than the disease.  Here are the comments
from our version:

  The following piece of code is new since our 5.2 based version.
   It was added in revision 524610 on 2007-04-01, more information is at:
   http://issues.apache.org/bugzilla/show_bug.cgi?id=39695 (now BCEL-79)
   However, it seems quite wrong to me and I have no idea how it solved the
bug.
   There is no requirement for there to be as many LocalVariableTypeTable
entries
   as there are LocalVariables.  In fact, there will almost always be fewer.
So
   deleting the local variables and reconstructing them from types makes no
sense.
   Was it a bad cut and paste job from above and meant to reconstruct the
types
   table?  Then how did it fix the bug?  More likely, the test case had the
same
   number of vars and types.  If so, the correct code would seem to be only
modify
   those local vars that have a matching type.  I cannot figure out what was
intended
   so I'm just going to comment the whole thing out.   (markro)

To repeat - constructing the local variables from the local variable types
is totally bogus.   I have no idea how that fixed the original problem but
it is clearly incorrect.

Mark

> -Original Message-
> From: Emmanuel Bourg [mailto:emmanuel.bo...@gmail.com] On 
> Behalf Of Emmanuel Bourg
>
> Isn't BCEL-79 already fixed?
> 
> 

RE: [bcel] PLSE changes to BCEL

[Mark Roberts]

I understand the goal of trying to reuse instructions - an 'iadd' is the
same as any other 'iadd'.  However,  one 'goto 50' is not the same as
another 'goto 50' due to the way Targeters are implemented.  If branch
instructions are reused, then only one entry gets put on the Targeter list.
So when some api is used to modify the instruction list and location 50
becomes location 52 ONLY ONE of the branches gets updated. A very bad thing.
So unless you modify the hash to special case branch instructions (and there
might be other instructions needing special treatment as well) its broken.
We fixed it by simply commenting the hash out to make things like they used
to be and all works great.

Which takes us to another question I was going to ask - is there a BCEL test
suite?  'mvn verify' is ok for build verification - but it doesn't begin to
cover the bases of what the api can do - especially in the area of code
modification.

Mark

> -Original Message-
> From: Emmanuel Bourg [mailto:emmanuel.bo...@gmail.com] On 
> Behalf Of Emmanuel Bourg
> Sent: Monday, January 26, 2015 4:14 PM
> 
> > I was surprised by 'U' as that change had a huge side 
> effect, possibly due to a design flaw in how Targeters work; 
> I was unable to find any discussion in your archives.
> 
> Could you elaborate a bit on this change?
> 


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

Re: [bcel] PLSE changes to BCEL

[Emmanuel Bourg]

Thank you for the detailed summary Mark.


Le 26/01/2015 19:02, Mark Roberts a écrit :
> I'm currently not familiar with your release process and, hence, not sure 
> what sorts of changes you are willing to consider at this time.  I thought I 
> would start with a rough outline of all of our changes and then the group 
> could suggest which ones I should open in JIRA.

An important rule that drives many design decisions is that we never
break the binary compatibility. And if we really have to, well... we
don't :) Instead we roll out a new version under a new package name.

Considering that we would like to publish BCEL 6.0 soon we will probably
not merge involved changes now, but smalls fixes are welcome.


> We cloned a version of the BCEL sources at Revision 1514334.
> We updated to Revision 1646789 (2014-12-19) week of January 19-23, 2015.

I don't know if you are familiar with Git but BCEL also has a mirror on
Github. You may find it useful to rebase your changes as the trunk evolves.

https://github.com/apache/commons-bcel


> I was surprised by 'U' as that change had a huge side effect, possibly due to 
> a design flaw in how Targeters work; I was unable to find any discussion in 
> your archives.

Could you elaborate a bit on this change?


> During the past year, both the Apache Commons BCEL team and our group here at 
> UW independently completed the support for InvokeDynamic .  Some things we 
> chose to do the same way, but there are a few items that are quite different. 
>  Trying not to be too biased, I believe our method is better.  One of the 
> larger differences is your decision to add the abstract class 
> NameSignatureMethod between FieldOrMethod and CPInstruction and then have 
> InvokeDynamic extend from that instead of from InvokeInstruction.  To me this 
> seems wrong.   In addition to forcing InvokeDynamic to duplicate all the 
> methods from InvokeInstruction and FieldOrMethod, it is awkward that it is 
> the only form of the Invoke Instruction that doesn't derive from 
> InvokeInstruction. (‘ID’ and ‘BM’ as well.)

Good point, this should be investigated.


> ‘B’, ‘H’, and ‘LV’ are important bug fixes.

Isn't BCEL-79 already fixed?


> I not sure why you chose not to complete the change from DataInputStream to 
> DataInput (‘I’).  This was another item we did here at PLSE independent of 
> your work.  Going all the way is nice, because tools that use BCEL can then 
> backup and reprocess the input class file.

I stopped because some changes touched the public API. I reviewed that
again today and managed to replace more occurrences, but the one in the
AttributeReader interface can't be changed without breaking the binary
compatibility and this affects some other classes.


> A lot of the ‘TS’ changes were to make the BCEL output look more like the 
> ‘javap’ output; you may not care, but this was useful to some of our clients.

This is a good idea.


> Sorry for length of post and amount of information.  We can divide into 
> separate threads If you wish.

That's fine. These changes sound excellent, could you open one JIRA
issue per change please?

Thank you,

Emmanuel Bourg


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

Re: [VOTE] Release Compress 1.10 Based on RC1

[Gary Gregory]

I see you changed the test but the code could benefit from a comment to
avoid a future regression back to this problem.

Gary

On Mon, Jan 26, 2015 at 4:52 PM, Kristian Rosenvold 
wrote:

> Testcase fixed in r1654901
>
> Kristian
>
>
> 2015-01-26 22:37 GMT+01:00 Kristian Rosenvold <
> kristian.rosenv...@gmail.com>:
> > 2015-01-26 22:27 GMT+01:00 Gary Gregory :
> >> Tests:
> >>
> >> Running: 'mvn clean site' gave me
> >>
> >> Failed tests:
> >>
>  ZipTestCase.testCopyRawZip64EntryFromFile:361->assertSameFileContents:414
> >> arrays first differed at element [10]; expected:<-16> but was:<-15>
> >
> > The problem appears to be that time does not stand still, and every
> > now and then you can make "expected" and "actual" get different time
> > stamps (with the 2 second granularity of zip it takes a bit of "luck"
> > to hit the problem)
> >
> > The problem is within the testcase itself, and I'll fix this on trunk.
> >
> > Kristian
>
> -
> 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

[Commons Wiki] Update of "VfsReleaseState" by BerndEckenfels

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Commons Wiki" for 
change notification.

The "VfsReleaseState" page has been changed by BerndEckenfels:
https://wiki.apache.org/commons/VfsReleaseState?action=diff&rev1=10&rev2=11

  
   * Preview of Site: http://people.apache.org/~ecki/commons-vfs/
   * Decided: will use manual not release-plugin process
- 
+  * JIRA report does not include more than 100 fixes and changes-plugin cant 
page (http://jira.codehaus.org/browse/MCHANGES-351). As INFRA cant raise the 
limit, I plan to not create a JIRA report for the release (as all of them are 
in the chnages.xml anyway).
  
  This is a list of things to do for the (upcoming) next release of VFS 2.1
  
   * update testing/test-server site: some protocols are tested now, hdfs with 
windows profile
-  * JIRA report does not include more than 100 fixed, there are 141 in this 
release. What to do? (http://jira.codehaus.org/browse/MCHANGES-351 
https://issues.apache.org/jira/browse/INFRA-9069)
-  * OSGI imports are not optional 
(https://issues.apache.org/jira/browse/VFS-498) - pending CP release
+  * OSGI imports are not optional 
(https://issues.apache.org/jira/browse/VFS-498) - pending commons-parent release
   * only show aggregate checkstyle report toplevel
  
   * announce Java 1.6 in release-notes

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

[Commons Wiki] Update of "VfsReleaseState" by BerndEckenfels

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Commons Wiki" for 
change notification.

The "VfsReleaseState" page has been changed by BerndEckenfels:
https://wiki.apache.org/commons/VfsReleaseState?action=diff&rev1=9&rev2=10

Comment:
Opened INFRA ticket

  This is a list of things to do for the (upcoming) next release of VFS 2.1
  
   * update testing/test-server site: some protocols are tested now, hdfs with 
windows profile
-  * JIRA report does not include more than 100 fixed, there are 141 in this 
release. What to do? (http://jira.codehaus.org/browse/MCHANGES-351)
+  * JIRA report does not include more than 100 fixed, there are 141 in this 
release. What to do? (http://jira.codehaus.org/browse/MCHANGES-351 
https://issues.apache.org/jira/browse/INFRA-9069)
   * OSGI imports are not optional 
(https://issues.apache.org/jira/browse/VFS-498) - pending CP release
   * only show aggregate checkstyle report toplevel
  

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

RE: [bcel] PLSE changes to BCEL

[Mark Roberts]

The InvokeDynamic and BootstrapMethod changes move some class members around.  
So any app that writes a serialized version of the BCEL internal data 
structures and re-reads later would have to regenerate those files.  Our tools 
do not do this; I have no idea if this is common.  On the other hand, these 
changes are the largest single set of diffs so if you are close to release this 
would probably mean starting the test/verification cycle from the top.

Mark

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Monday, January 26, 2015 1:32 PM
To: Commons Developers List
Subject: Re: [bcel] PLSE changes to BCEL

The only caveat here, since we are going for a major version bump is whether 
you have some proposal for changes that would be binary incompatible with 5.x, 
which we should therefore consider for 6.0.

Gary



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

Re: [VOTE] Release Compress 1.10 Based on RC1

[Kristian Rosenvold]

Testcase fixed in r1654901

Kristian


2015-01-26 22:37 GMT+01:00 Kristian Rosenvold :
> 2015-01-26 22:27 GMT+01:00 Gary Gregory :
>> Tests:
>>
>> Running: 'mvn clean site' gave me
>>
>> Failed tests:
>>   ZipTestCase.testCopyRawZip64EntryFromFile:361->assertSameFileContents:414
>> arrays first differed at element [10]; expected:<-16> but was:<-15>
>
> The problem appears to be that time does not stand still, and every
> now and then you can make "expected" and "actual" get different time
> stamps (with the 2 second granularity of zip it takes a bit of "luck"
> to hit the problem)
>
> The problem is within the testcase itself, and I'll fix this on trunk.
>
> Kristian

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

Re: [VOTE][JCS] release [jcs] 2.0-beta-1 (take 3)

[Romain Manni-Bucau]

@sebb: I read this doc when you mentionned it previously and
intentionnaly kept it cause it makes things clearer for me and it is
not mandatory to remove it, just better. I thought more code was from
xerox - why I wanted to keep it. Anyway this is not a blocker at all
and we have to fix it, just waiting Thomas feedback before deleting
some files.


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-26 22:24 GMT+01:00 sebb :
> On 26 January 2015 at 17:38, Mark Struberg  wrote:
>> Sebb, this is nowhere stated in the bylaws. There is just no ground for 
>> totally blasting a release!
>
> This has come up several times, and the rules are still at:
>
> http://www.apache.org/dev/licensing-howto.html#mod-notice
>
>> It's superfluous and not 100% perfect but it is NOT wrong. The sources 
>> _currenty_ contain this file, so we have it.
>
> The NOTICE file is still wrong, because it contains stuff that should
> not be there.
>
>> For how long is this now in the codebase? 2 years? even longer?
>
> Irrelevant.
>
> Besides, I already noted the problem during the vote for RC2.
> I should not have to argue the case again.
>
>> Be glad that Romain finally cleans this up.
>> It's not perfect but it's also not a show stopper. And instead of ranting 
>> you could have easily fixed it in SVN in the meantime.
>
> Some of it I could have fixed and could still fix.
>
> But I do not have the information needed to determine if a Xerox
> license is still required, so could not complete the work.
>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>>
>>> On Monday, 26 January 2015, 17:59, sebb  wrote:
>>> > On 26 January 2015 at 16:47, Romain Manni-Bucau 
>>> wrote:
  2015-01-26 17:41 GMT+01:00 sebb :
>  On 26 January 2015 at 12:20, Romain Manni-Bucau
>>>  wrote:
>>  Ok so you only speak about dist src bundle?
>
>  No, it also affects the binary bundle, and it affects the SVN tag
>  (which is also a distribution, though not a release)
>

  Not the bundle since aspectj files are not here and keeping xerox
  reference is not an issue just something we should avoid if possible
  nor the tag since the tag is fine (the tag uses module license and
  global one - bundle - doesnt make any sense). So it only affects
  sources one.
>>>
>>> The NOTICE file is wrong, whether or not the xerox file is included.
>>> NOTICE files must not contain spurious text.
>>>
>>> This affects the source and binary bundles and the jars (binary and source)
>>>
>>  Not sure it does need to cancel the vote, this is not a major issue
>>  IMO and can be fixed for next one
>
>  Given how infrequently releases are made, I don't think that is a
>>> good idea.
>
>>
>>
>>
>>  Romain Manni-Bucau
>>  @rmannibucau
>>  http://www.tomitribe.com
>>  http://rmannibucau.wordpress.com
>>  https://github.com/rmannibucau
>>
>>
>>  2015-01-26 12:39 GMT+01:00 sebb :
>>>  On 26 January 2015 at 11:30, Romain Manni-Bucau
>>>  wrote:
  @sebb: not sure I get it right, it references LICENSE.txt
>>> correctly for me
>>>
>>>  Not sure what you mean by "it" above.
>>>
>>>  As I already wrote:
>>>  The NOTICE file should not reference LICENSE.txt
>>>  Nor should it reference LICENSE.xerox, because the Xerox
>>> license does
>>>  not require attribution.
>>>
>>>  However LICENSE.txt must include - or point to as separate
>>> file(s) -
>>>  any 3rd party licenses for bundled code.
>>>  It does not reference xerox currently, so there is a problem
>>> which
>>>  arises because of the source file.
>>>
>>>  The user must be able to determine the licensing requirements
>>> from
>>>  LICENSE and NOTICE without having to look around for other
>>> license
>>>  files.
>>>  And the NOTICE file must not contain anything that is not
>>> required.
>>>

  Romain Manni-Bucau
  @rmannibucau
  http://www.tomitribe.com
  http://rmannibucau.wordpress.com
  https://github.com/rmannibucau


  2015-01-26 12:27 GMT+01:00 sebb :
>  On 26 January 2015 at 11:19, Romain Manni-Bucau
>>>  wrote:
>>  if that's the case +1 but anyway it doesnt hurt
>
>  But it does have some consequences, because of the
>>> license issues.
>
>>  @Thomas: before dropping it can you confirm it a
>>> last time please?
>>
>>
>>  Romain Manni-Bucau
>>  @rmannibucau
>>  http://www.tomitribe.com
>>  http://rmannibucau.wordpress.com
>>  https://github.com/rmannibucau
>>
>>
>>  2015-01-26 12:18 GMT+01:00 sebb
>>> :
>>>  Why not just drop it entirely?
>>>
>>>  If that is the only Xerox-licensed file, it is
>>> not essential to the
>>>  operation of JCS, so why ke

Re: [VOTE] Release Compress 1.10 Based on RC1

[Kristian Rosenvold]

2015-01-26 22:27 GMT+01:00 Gary Gregory :
> Tests:
>
> Running: 'mvn clean site' gave me
>
> Failed tests:
>   ZipTestCase.testCopyRawZip64EntryFromFile:361->assertSameFileContents:414
> arrays first differed at element [10]; expected:<-16> but was:<-15>

The problem appears to be that time does not stand still, and every
now and then you can make "expected" and "actual" get different time
stamps (with the 2 second granularity of zip it takes a bit of "luck"
to hit the problem)

The problem is within the testcase itself, and I'll fix this on trunk.

Kristian

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

Re: [bcel] PLSE changes to BCEL

[Gary Gregory]

Mark,

This is awesome info. Thank you for taking the time to compile it.

My preference would be to finalize and cut 6.0 ASAP, then start a new
cycle. I am a RERO proponent.

The only caveat here, since we are going for a major version bump is
whether you have some proposal for changes that would be binary
incompatible with 5.x, which we should therefore consider for 6.0.

Gary

On Mon, Jan 26, 2015 at 1:02 PM, Mark Roberts 
wrote:

> I'm currently not familiar with your release process and, hence, not sure
> what sorts of changes you are willing to consider at this time.  I thought
> I would start with a rough outline of all of our changes and then the group
> could suggest which ones I should open in JIRA.
>
> We cloned a version of the BCEL sources at Revision 1514334.
> We updated to Revision 1646789 (2014-12-19) week of January 19-23, 2015.
>
> Here is a list of files and reasons we differ from standard BCEL:
> (The 'reason' codes in left hand column are enumerated below the file
> list.)
>
> C /bcel/classfile/AnnotationDefault.java
> I /bcel/classfile/AnnotationEntry.java
> D,I   /bcel/classfile/Attribute.java
> I /bcel/classfile/AttributeReader.java
> BM,JD /bcel/classfile/BootstrapMethod.java
> BM,JD /bcel/classfile/BootstrapMethods.java
> I /bcel/classfile/ClassParser.java
> I /bcel/classfile/Code.java
> BM,ID,TS  /bcel/classfile/ConstantCP.java
> ID/bcel/classfile/ConstantInvokeDynamic.java
> P /bcel/classfile/Constant.java
> T /bcel/classfile/ConstantLong.java
> BM,ID,TS  /bcel/classfile/ConstantPool.java
> BM,ID /bcel/classfile/DescendingVisitor.java
> BM,ID /bcel/classfile/EmptyVisitor.java
> C /bcel/classfile/EnclosingMethod.java
> I /bcel/classfile/Field.java
> I /bcel/classfile/FieldOrMethod.java
> TS/bcel/classfile/InnerClasses.java
> TS/bcel/classfile/InnerClass.java
> T /bcel/classfile/JavaClass.java
> JD/bcel/classfile/LineNumber.java
> JD/bcel/classfile/LineNumberTable.java
> TS/bcel/classfile/LocalVariable.java
> TS/bcel/classfile/LocalVariableTypeTable.java
> I /bcel/classfile/Method.java
> T /bcel/classfile/RuntimeInvisibleParameterAnnotations.java
> T /bcel/classfile/RuntimeVisibleParameterAnnotations.java
> TS/bcel/classfile/SourceFile.java
> S,I   /bcel/classfile/StackMapTableEntry.java
> I /bcel/classfile/StackMapTable.java
> V,I,ID/bcel/classfile/Utility.java
> BM,ID /bcel/classfile/Visitor.java
> T /bcel/Constants.java
> TS/bcel/generic/BranchInstruction.java
> ID/bcel/generic/ConstantPoolGen.java
> ID/bcel/generic/EmptyVisitor.java
> P,ID  /bcel/generic/FieldOrMethod.java
> ID/bcel/generic/GETFIELD.java
> ID/bcel/generic/GETSTATIC.java
> ID/bcel/generic/InstructionFactory.java
> P,U   /bcel/generic/Instruction.java
> ID/bcel/generic/INVOKEDYNAMIC.java
> ID/bcel/generic/INVOKEINTERFACE.java
> ID/bcel/generic/INVOKESPECIAL.java
> ID/bcel/generic/INVOKESTATIC.java
> ID/bcel/generic/INVOKEVIRTUAL.java
> ID/bcel/generic/InvokeInstruction.java
> D /bcel/generic/LineNumberGen.java
> H /bcel/generic/LocalVariableGen.java
> B,LV,TS   /bcel/generic/MethodGen.java
> ID/bcel/generic/PUTFIELD.java
> ID/bcel/generic/PUTSTATIC.java
> ID/bcel/generic/Visitor.java
> M /bcel/PLSEMarker.java (new file)
> P,TS  /bcel/util/BCELifier.java
> ID/bcel/util/CodeHTML.java
> ID/bcel/util/InstructionFinder.java
> D /bcel/util/SyntheticRepository.java
> D /bcel/verifier/statics/Pass1Verifier.java
> ID/bcel/verifier/statics/Pass3aVerifier.java
> ID/bcel/verifier/structurals/ExecutionVisitor.java
> P /bcel/verifier/structurals/Frame.java
> D,ID,UT   /bcel/verifier/structurals/InstConstraintVisitor.java
> C,P,ML/bcel/verifier/structurals/LocalVariables.java
> P /bcel/verifier/structurals/OperandStack.java
> RS/bcel/verifier/structurals/Subroutines.java
>
>
> B  - BCEL bug #39695 (and #44083) (now BCEL-79)
> BM - add support for BootstrapMethod(s)
> C  - better support for clone/copy methods
> D  - add some debugging code
> H  - fix problem with hash function
> I  - finish/complete change from DataInputStream to DataInput
> ID - add/improve support for InvokeDynamic
> JD - javadoc additions
> LV - correct problem with missing local vars to anonymous init methods
> M  - marked class to identify our version of BCEL
> ML - deal with superclass of type Object in merge of local variables
> P  - make some methods public (or not deprecated) for our use
> RS - reduce JustIce restrictions on subroutines
> S  - improve StackMap support
> T  - fix typo, source formatting or cut/paste error
> TS - improve toString or other output formatting
> U  - we need instructions to b

Re: [VOTE] Release Compress 1.10 Based on RC1

[Gary Gregory]

Thank you for preparing this RC Stefan.

Using with src zip from binary dist folder:

MD5 OK.
ASC OK.

Tests:

Running: 'mvn clean site' gave me

Failed tests:
  ZipTestCase.testCopyRawZip64EntryFromFile:361->assertSameFileContents:414
arrays first differed at element [10]; expected:<-16> but was:<-15>

The HEAD of trunk passes this test in Eclipse (Java 7).

Running 'mvn test' solo was OK.

Running 'mvn clean test' again was OK.

Running 'mvn clean site' again was OK.

Can anyone shed some light on this 'random' error? My PC might have been
super busy at the time.

I am on:

Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
2014-12-14T12:29:23-05:00)
Maven home: C:\Java\apache-maven-3.2.5
Java version: 1.7.0_75, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_75\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

Site:

Typo: What's new in 1.10? "the old" -> "The old".

Changes report says "Release 1.10 – not released, yet". I like to use the
RC date here so you do not have to change the site post vote. But that's
just my process...

Other reports look good. Clirr shows expected errors due to internal
package name change.

Should be fixed, not a blocker: PMDs for "Avoid unused private methods".

Abstaining for now until RM addresses 'random' test failure.

Gary

On Mon, Jan 26, 2015 at 1:05 AM, Stefan Bodewig  wrote:

> As inidcated last week, here is the first RC for Compress 1.10.
>
> Compress 1.10 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/
> (svn revision 7828)
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1080/org/apache/commons/commons-compress/1.10/
>
> Details of changes since 1.9 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt
>
> http://people.apache.org/~bodewig/compress-1.10-RC1/changes-report.html
>
> The tag is here:
>
> http://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.10-RC1
> (svn revision 1654723)
>
> Site:
> http://people.apache.org/~bodewig/compress-1.10-RC1/
>
> Clirr Report (compared to 1.9):
> http://people.apache.org/~bodewig/compress-1.10-RC1/clirr-report.html
>
> RAT Report:
> http://people.apache.org/~bodewig/compress-1.10-RC1/rat-report.html
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
>   This vote will close no sooner that 72 hours from now, i.e. after
>   0600 GMT 29-January 2015
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thanks!
>
> Stefan
>
> -
> 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: [VOTE][JCS] release [jcs] 2.0-beta-1 (take 3)

[sebb]

On 26 January 2015 at 17:38, Mark Struberg  wrote:
> Sebb, this is nowhere stated in the bylaws. There is just no ground for 
> totally blasting a release!

This has come up several times, and the rules are still at:

http://www.apache.org/dev/licensing-howto.html#mod-notice

> It's superfluous and not 100% perfect but it is NOT wrong. The sources 
> _currenty_ contain this file, so we have it.

The NOTICE file is still wrong, because it contains stuff that should
not be there.

> For how long is this now in the codebase? 2 years? even longer?

Irrelevant.

Besides, I already noted the problem during the vote for RC2.
I should not have to argue the case again.

> Be glad that Romain finally cleans this up.
> It's not perfect but it's also not a show stopper. And instead of ranting you 
> could have easily fixed it in SVN in the meantime.

Some of it I could have fixed and could still fix.

But I do not have the information needed to determine if a Xerox
license is still required, so could not complete the work.

> LieGrue,
> strub
>
>
>
>
>
>
>> On Monday, 26 January 2015, 17:59, sebb  wrote:
>> > On 26 January 2015 at 16:47, Romain Manni-Bucau 
>> wrote:
>>>  2015-01-26 17:41 GMT+01:00 sebb :
  On 26 January 2015 at 12:20, Romain Manni-Bucau
>>  wrote:
>  Ok so you only speak about dist src bundle?

  No, it also affects the binary bundle, and it affects the SVN tag
  (which is also a distribution, though not a release)

>>>
>>>  Not the bundle since aspectj files are not here and keeping xerox
>>>  reference is not an issue just something we should avoid if possible
>>>  nor the tag since the tag is fine (the tag uses module license and
>>>  global one - bundle - doesnt make any sense). So it only affects
>>>  sources one.
>>
>> The NOTICE file is wrong, whether or not the xerox file is included.
>> NOTICE files must not contain spurious text.
>>
>> This affects the source and binary bundles and the jars (binary and source)
>>
>  Not sure it does need to cancel the vote, this is not a major issue
>  IMO and can be fixed for next one

  Given how infrequently releases are made, I don't think that is a
>> good idea.

>
>
>
>  Romain Manni-Bucau
>  @rmannibucau
>  http://www.tomitribe.com
>  http://rmannibucau.wordpress.com
>  https://github.com/rmannibucau
>
>
>  2015-01-26 12:39 GMT+01:00 sebb :
>>  On 26 January 2015 at 11:30, Romain Manni-Bucau
>>  wrote:
>>>  @sebb: not sure I get it right, it references LICENSE.txt
>> correctly for me
>>
>>  Not sure what you mean by "it" above.
>>
>>  As I already wrote:
>>  The NOTICE file should not reference LICENSE.txt
>>  Nor should it reference LICENSE.xerox, because the Xerox
>> license does
>>  not require attribution.
>>
>>  However LICENSE.txt must include - or point to as separate
>> file(s) -
>>  any 3rd party licenses for bundled code.
>>  It does not reference xerox currently, so there is a problem
>> which
>>  arises because of the source file.
>>
>>  The user must be able to determine the licensing requirements
>> from
>>  LICENSE and NOTICE without having to look around for other
>> license
>>  files.
>>  And the NOTICE file must not contain anything that is not
>> required.
>>
>>>
>>>  Romain Manni-Bucau
>>>  @rmannibucau
>>>  http://www.tomitribe.com
>>>  http://rmannibucau.wordpress.com
>>>  https://github.com/rmannibucau
>>>
>>>
>>>  2015-01-26 12:27 GMT+01:00 sebb :
  On 26 January 2015 at 11:19, Romain Manni-Bucau
>>  wrote:
>  if that's the case +1 but anyway it doesnt hurt

  But it does have some consequences, because of the
>> license issues.

>  @Thomas: before dropping it can you confirm it a
>> last time please?
>
>
>  Romain Manni-Bucau
>  @rmannibucau
>  http://www.tomitribe.com
>  http://rmannibucau.wordpress.com
>  https://github.com/rmannibucau
>
>
>  2015-01-26 12:18 GMT+01:00 sebb
>> :
>>  Why not just drop it entirely?
>>
>>  If that is the only Xerox-licensed file, it is
>> not essential to the
>>  operation of JCS, so why keep it?
>>
>>  On 25 January 2015 at 21:44, Romain Manni-Bucau
>>  wrote:
>>>  Hi Mark,
>>>
>>>  this is not packaged AFAIK, just here as a
>> sample I guess.
>>>
>>>
>>>  Romain Manni-Bucau
>>>  @rmannibucau
>>>  http://www.tomitribe.com
>>>  http://rmannibucau.wordpress.com
>>>  https://github.com/rmannibucau
>>>
>>>
>>>  2015-01-25 22:35 GMT+01:00 Mark Struberg
>> :
  is that all?

>> https://svn.apache.org/repos/asf/commons/proper/jcs/trunk/commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>>>

RE: [bcel] PLSE changes to BCEL

[Mark Roberts]

Good question.  When I started work here (at PLSE) in Jan 2013, we had been 
using BCEL for some time.  We had not released a version of our product in 
about three years and one of my tasks was to get back to making regular 
releases of the Daikon toolset.  So in about May of 2013 I picked up the latest 
Revision of BCEL.  I got it working and noticed we had a few existing 
differences from the mainline that had apparently been there for quite some 
time.  As time went on,  I found and fixed a couple of problems with BCEL.  I 
noticed that after several months there had been no activity on the product at 
all.  I sent email to one of the developers and was told that the project was 
in limbo and 5.2 might be the last release.  I promised to send what changes I 
had, but never got around to it.  Over the next year I noticed a few checkins, 
but no signs of a release.  Recently, I was encouraged by my supervisor 
(Professor Michael Ernst) to make a better effort at sharing our work.  I was 
quite taken by surprise by the amount of work in the last 6 months or so on the 
project.  So I got the latest version of BCEL, went through the integration 
process and here we are.

So, if the intention is to start making regular releases of BCEL again, I'm all 
for it and more than willing to help. 

Mark

-Original Message-
From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On 
Behalf Of James Carman
Sent: Monday, January 26, 2015 10:20 AM
To: Commons Developers List
Subject: Re: [bcel] PLSE changes to BCEL

Out of curiosity, what was the reason you rolled your own as opposed to 
engaging with the community on these changes?


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

Re: [bcel] PLSE changes to BCEL

[James Carman]

Attaching a patch (or pull request) to a JIRA would be a great way for
one of us to take a look at what you have.  This is great stuff, man!
We are always glad to have new folks come in and provide patches.

Out of curiosity, what was the reason you rolled your own as opposed
to engaging with the community on these changes?

On Mon, Jan 26, 2015 at 1:02 PM, Mark Roberts  wrote:
> I'm currently not familiar with your release process and, hence, not sure 
> what sorts of changes you are willing to consider at this time.  I thought I 
> would start with a rough outline of all of our changes and then the group 
> could suggest which ones I should open in JIRA.
>
> We cloned a version of the BCEL sources at Revision 1514334.
> We updated to Revision 1646789 (2014-12-19) week of January 19-23, 2015.
>
> Here is a list of files and reasons we differ from standard BCEL:
> (The 'reason' codes in left hand column are enumerated below the file list.)
>
> C /bcel/classfile/AnnotationDefault.java
> I /bcel/classfile/AnnotationEntry.java
> D,I   /bcel/classfile/Attribute.java
> I /bcel/classfile/AttributeReader.java
> BM,JD /bcel/classfile/BootstrapMethod.java
> BM,JD /bcel/classfile/BootstrapMethods.java
> I /bcel/classfile/ClassParser.java
> I /bcel/classfile/Code.java
> BM,ID,TS  /bcel/classfile/ConstantCP.java
> ID/bcel/classfile/ConstantInvokeDynamic.java
> P /bcel/classfile/Constant.java
> T /bcel/classfile/ConstantLong.java
> BM,ID,TS  /bcel/classfile/ConstantPool.java
> BM,ID /bcel/classfile/DescendingVisitor.java
> BM,ID /bcel/classfile/EmptyVisitor.java
> C /bcel/classfile/EnclosingMethod.java
> I /bcel/classfile/Field.java
> I /bcel/classfile/FieldOrMethod.java
> TS/bcel/classfile/InnerClasses.java
> TS/bcel/classfile/InnerClass.java
> T /bcel/classfile/JavaClass.java
> JD/bcel/classfile/LineNumber.java
> JD/bcel/classfile/LineNumberTable.java
> TS/bcel/classfile/LocalVariable.java
> TS/bcel/classfile/LocalVariableTypeTable.java
> I /bcel/classfile/Method.java
> T /bcel/classfile/RuntimeInvisibleParameterAnnotations.java
> T /bcel/classfile/RuntimeVisibleParameterAnnotations.java
> TS/bcel/classfile/SourceFile.java
> S,I   /bcel/classfile/StackMapTableEntry.java
> I /bcel/classfile/StackMapTable.java
> V,I,ID/bcel/classfile/Utility.java
> BM,ID /bcel/classfile/Visitor.java
> T /bcel/Constants.java
> TS/bcel/generic/BranchInstruction.java
> ID/bcel/generic/ConstantPoolGen.java
> ID/bcel/generic/EmptyVisitor.java
> P,ID  /bcel/generic/FieldOrMethod.java
> ID/bcel/generic/GETFIELD.java
> ID/bcel/generic/GETSTATIC.java
> ID/bcel/generic/InstructionFactory.java
> P,U   /bcel/generic/Instruction.java
> ID/bcel/generic/INVOKEDYNAMIC.java
> ID/bcel/generic/INVOKEINTERFACE.java
> ID/bcel/generic/INVOKESPECIAL.java
> ID/bcel/generic/INVOKESTATIC.java
> ID/bcel/generic/INVOKEVIRTUAL.java
> ID/bcel/generic/InvokeInstruction.java
> D /bcel/generic/LineNumberGen.java
> H /bcel/generic/LocalVariableGen.java
> B,LV,TS   /bcel/generic/MethodGen.java
> ID/bcel/generic/PUTFIELD.java
> ID/bcel/generic/PUTSTATIC.java
> ID/bcel/generic/Visitor.java
> M /bcel/PLSEMarker.java (new file)
> P,TS  /bcel/util/BCELifier.java
> ID/bcel/util/CodeHTML.java
> ID/bcel/util/InstructionFinder.java
> D /bcel/util/SyntheticRepository.java
> D /bcel/verifier/statics/Pass1Verifier.java
> ID/bcel/verifier/statics/Pass3aVerifier.java
> ID/bcel/verifier/structurals/ExecutionVisitor.java
> P /bcel/verifier/structurals/Frame.java
> D,ID,UT   /bcel/verifier/structurals/InstConstraintVisitor.java
> C,P,ML/bcel/verifier/structurals/LocalVariables.java
> P /bcel/verifier/structurals/OperandStack.java
> RS/bcel/verifier/structurals/Subroutines.java
>
>
> B  - BCEL bug #39695 (and #44083) (now BCEL-79)
> BM - add support for BootstrapMethod(s)
> C  - better support for clone/copy methods
> D  - add some debugging code
> H  - fix problem with hash function
> I  - finish/complete change from DataInputStream to DataInput
> ID - add/improve support for InvokeDynamic
> JD - javadoc additions
> LV - correct problem with missing local vars to anonymous init methods
> M  - marked class to identify our version of BCEL
> ML - deal with superclass of type Object in merge of local variables
> P  - make some methods public (or not deprecated) for our use
> RS - reduce JustIce restrictions on subroutines
> S  - improve StackMap support
> T  - fix typo, source formatting or cut/paste error
> TS - improve toString or other output formatting
> U  - we need instructions to be unique
> UT - allow unitialized types in PUTFIELD (can

[bcel] PLSE changes to BCEL

[Mark Roberts]

I'm currently not familiar with your release process and, hence, not sure what 
sorts of changes you are willing to consider at this time.  I thought I would 
start with a rough outline of all of our changes and then the group could 
suggest which ones I should open in JIRA.

We cloned a version of the BCEL sources at Revision 1514334.
We updated to Revision 1646789 (2014-12-19) week of January 19-23, 2015.

Here is a list of files and reasons we differ from standard BCEL:
(The 'reason' codes in left hand column are enumerated below the file list.)

C /bcel/classfile/AnnotationDefault.java
I /bcel/classfile/AnnotationEntry.java
D,I   /bcel/classfile/Attribute.java
I /bcel/classfile/AttributeReader.java
BM,JD /bcel/classfile/BootstrapMethod.java
BM,JD /bcel/classfile/BootstrapMethods.java
I /bcel/classfile/ClassParser.java
I /bcel/classfile/Code.java
BM,ID,TS  /bcel/classfile/ConstantCP.java
ID/bcel/classfile/ConstantInvokeDynamic.java
P /bcel/classfile/Constant.java
T /bcel/classfile/ConstantLong.java
BM,ID,TS  /bcel/classfile/ConstantPool.java
BM,ID /bcel/classfile/DescendingVisitor.java
BM,ID /bcel/classfile/EmptyVisitor.java
C /bcel/classfile/EnclosingMethod.java
I /bcel/classfile/Field.java
I /bcel/classfile/FieldOrMethod.java
TS/bcel/classfile/InnerClasses.java
TS/bcel/classfile/InnerClass.java
T /bcel/classfile/JavaClass.java
JD/bcel/classfile/LineNumber.java
JD/bcel/classfile/LineNumberTable.java
TS/bcel/classfile/LocalVariable.java
TS/bcel/classfile/LocalVariableTypeTable.java
I /bcel/classfile/Method.java
T /bcel/classfile/RuntimeInvisibleParameterAnnotations.java
T /bcel/classfile/RuntimeVisibleParameterAnnotations.java
TS/bcel/classfile/SourceFile.java
S,I   /bcel/classfile/StackMapTableEntry.java
I /bcel/classfile/StackMapTable.java
V,I,ID/bcel/classfile/Utility.java
BM,ID /bcel/classfile/Visitor.java
T /bcel/Constants.java
TS/bcel/generic/BranchInstruction.java
ID/bcel/generic/ConstantPoolGen.java
ID/bcel/generic/EmptyVisitor.java
P,ID  /bcel/generic/FieldOrMethod.java
ID/bcel/generic/GETFIELD.java
ID/bcel/generic/GETSTATIC.java
ID/bcel/generic/InstructionFactory.java
P,U   /bcel/generic/Instruction.java
ID/bcel/generic/INVOKEDYNAMIC.java
ID/bcel/generic/INVOKEINTERFACE.java
ID/bcel/generic/INVOKESPECIAL.java
ID/bcel/generic/INVOKESTATIC.java
ID/bcel/generic/INVOKEVIRTUAL.java
ID/bcel/generic/InvokeInstruction.java
D /bcel/generic/LineNumberGen.java
H /bcel/generic/LocalVariableGen.java
B,LV,TS   /bcel/generic/MethodGen.java
ID/bcel/generic/PUTFIELD.java
ID/bcel/generic/PUTSTATIC.java
ID/bcel/generic/Visitor.java
M /bcel/PLSEMarker.java (new file)
P,TS  /bcel/util/BCELifier.java
ID/bcel/util/CodeHTML.java
ID/bcel/util/InstructionFinder.java
D /bcel/util/SyntheticRepository.java
D /bcel/verifier/statics/Pass1Verifier.java
ID/bcel/verifier/statics/Pass3aVerifier.java
ID/bcel/verifier/structurals/ExecutionVisitor.java
P /bcel/verifier/structurals/Frame.java
D,ID,UT   /bcel/verifier/structurals/InstConstraintVisitor.java
C,P,ML/bcel/verifier/structurals/LocalVariables.java
P /bcel/verifier/structurals/OperandStack.java
RS/bcel/verifier/structurals/Subroutines.java


B  - BCEL bug #39695 (and #44083) (now BCEL-79)
BM - add support for BootstrapMethod(s)
C  - better support for clone/copy methods
D  - add some debugging code
H  - fix problem with hash function
I  - finish/complete change from DataInputStream to DataInput
ID - add/improve support for InvokeDynamic
JD - javadoc additions
LV - correct problem with missing local vars to anonymous init methods
M  - marked class to identify our version of BCEL
ML - deal with superclass of type Object in merge of local variables
P  - make some methods public (or not deprecated) for our use
RS - reduce JustIce restrictions on subroutines
S  - improve StackMap support
T  - fix typo, source formatting or cut/paste error
TS - improve toString or other output formatting
U  - we need instructions to be unique
UT - allow unitialized types in PUTFIELD (can happen in a constructor)
V  - add support for TypeVariable Signature


A few additional thoughts:

You will definitely not want change 'M', probably not change 'P' either.  

I was surprised by 'U' as that change had a huge side effect, possibly due to a 
design flaw in how Targeters work; I was unable to find any discussion in your 
archives.

During the past year, both the Apache Commons BCEL team and our group here at 
UW independently completed the support for InvokeDynamic .  Some things we 
chose to do the same way, but there are a few items that are quite di

Re: [VOTE][JCS] release [jcs] 2.0-beta-1 (take 3)

[Mark Struberg]

Sebb, this is nowhere stated in the bylaws. There is just no ground for totally 
blasting a release!

It's superfluous and not 100% perfect but it is NOT wrong. The sources 
_currenty_ contain this file, so we have it.

For how long is this now in the codebase? 2 years? even longer?
Be glad that Romain finally cleans this up.
It's not perfect but it's also not a show stopper. And instead of ranting you 
could have easily fixed it in SVN in the meantime.

LieGrue,
strub






> On Monday, 26 January 2015, 17:59, sebb  wrote:
> > On 26 January 2015 at 16:47, Romain Manni-Bucau  
> wrote:
>>  2015-01-26 17:41 GMT+01:00 sebb :
>>>  On 26 January 2015 at 12:20, Romain Manni-Bucau 
>  wrote:
  Ok so you only speak about dist src bundle?
>>> 
>>>  No, it also affects the binary bundle, and it affects the SVN tag
>>>  (which is also a distribution, though not a release)
>>> 
>> 
>>  Not the bundle since aspectj files are not here and keeping xerox
>>  reference is not an issue just something we should avoid if possible
>>  nor the tag since the tag is fine (the tag uses module license and
>>  global one - bundle - doesnt make any sense). So it only affects
>>  sources one.
> 
> The NOTICE file is wrong, whether or not the xerox file is included.
> NOTICE files must not contain spurious text.
> 
> This affects the source and binary bundles and the jars (binary and source)
> 
  Not sure it does need to cancel the vote, this is not a major issue
  IMO and can be fixed for next one
>>> 
>>>  Given how infrequently releases are made, I don't think that is a 
> good idea.
>>> 
 
 
 
  Romain Manni-Bucau
  @rmannibucau
  http://www.tomitribe.com
  http://rmannibucau.wordpress.com
  https://github.com/rmannibucau
 
 
  2015-01-26 12:39 GMT+01:00 sebb :
>  On 26 January 2015 at 11:30, Romain Manni-Bucau 
>  wrote:
>>  @sebb: not sure I get it right, it references LICENSE.txt 
> correctly for me
> 
>  Not sure what you mean by "it" above.
> 
>  As I already wrote:
>  The NOTICE file should not reference LICENSE.txt
>  Nor should it reference LICENSE.xerox, because the Xerox 
> license does
>  not require attribution.
> 
>  However LICENSE.txt must include - or point to as separate 
> file(s) -
>  any 3rd party licenses for bundled code.
>  It does not reference xerox currently, so there is a problem 
> which
>  arises because of the source file.
> 
>  The user must be able to determine the licensing requirements 
> from
>  LICENSE and NOTICE without having to look around for other 
> license
>  files.
>  And the NOTICE file must not contain anything that is not 
> required.
> 
>> 
>>  Romain Manni-Bucau
>>  @rmannibucau
>>  http://www.tomitribe.com
>>  http://rmannibucau.wordpress.com
>>  https://github.com/rmannibucau
>> 
>> 
>>  2015-01-26 12:27 GMT+01:00 sebb :
>>>  On 26 January 2015 at 11:19, Romain Manni-Bucau 
>  wrote:
  if that's the case +1 but anyway it doesnt hurt
>>> 
>>>  But it does have some consequences, because of the 
> license issues.
>>> 
  @Thomas: before dropping it can you confirm it a 
> last time please?
 
 
  Romain Manni-Bucau
  @rmannibucau
  http://www.tomitribe.com
  http://rmannibucau.wordpress.com
  https://github.com/rmannibucau
 
 
  2015-01-26 12:18 GMT+01:00 sebb 
> :
>  Why not just drop it entirely?
> 
>  If that is the only Xerox-licensed file, it is 
> not essential to the
>  operation of JCS, so why keep it?
> 
>  On 25 January 2015 at 21:44, Romain Manni-Bucau 
>  wrote:
>>  Hi Mark,
>> 
>>  this is not packaged AFAIK, just here as a 
> sample I guess.
>> 
>> 
>>  Romain Manni-Bucau
>>  @rmannibucau
>>  http://www.tomitribe.com
>>  http://rmannibucau.wordpress.com
>>  https://github.com/rmannibucau
>> 
>> 
>>  2015-01-25 22:35 GMT+01:00 Mark Struberg 
> :
>>>  is that all?
>>> 
> https://svn.apache.org/repos/asf/commons/proper/jcs/trunk/commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>>> 
>>>  Wouldn't it be actually quite easy 
> to replace this?
>>> 
>>> 
>>> 
>>>  LieGrue,
>>>  strub
>>> 
>>> 
>>> 
>>> 
>>> 
  On Sunday, 25 January 2015, 19:30, 
> Thomas Vandahl  wrote:
  > On 25.01.15 17:00, Romain 
> Manni-Bucau wrote:
>   It does AFAIK - was not here 
> and just propagated existing legal text - and
>   that is why it is referenced 
> in core and not all artifacts.
>Le 25 janv. 2015 16:55, 
> "sebb"  a écrit
  :
 
  The XEROX license

Re: [VOTE][JCS] release [jcs] 2.0-beta-1 (take 3)

[James Carman]

On Mon, Jan 26, 2015 at 11:48 AM, sebb  wrote:
>
> Strictly speaking that is true, but when an issue is found, the RM
> should take any vetos into account.
>

They are NOT vetoes.

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

Re: [VOTE][JCS] release [jcs] 2.0-beta-1 (take 3)

[Romain Manni-Bucau]

but this is not a blocker and actually can even be considered right
since optional doesn't mean shouldn't be mentioned (in particular I
think it is better to mention it even if optional to avoid ambiguities
and keep the origin explicit)


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-26 17:58 GMT+01:00 sebb :
> On 26 January 2015 at 16:47, Romain Manni-Bucau  wrote:
>> 2015-01-26 17:41 GMT+01:00 sebb :
>>> On 26 January 2015 at 12:20, Romain Manni-Bucau  
>>> wrote:
 Ok so you only speak about dist src bundle?
>>>
>>> No, it also affects the binary bundle, and it affects the SVN tag
>>> (which is also a distribution, though not a release)
>>>
>>
>> Not the bundle since aspectj files are not here and keeping xerox
>> reference is not an issue just something we should avoid if possible
>> nor the tag since the tag is fine (the tag uses module license and
>> global one - bundle - doesnt make any sense). So it only affects
>> sources one.
>
> The NOTICE file is wrong, whether or not the xerox file is included.
> NOTICE files must not contain spurious text.
>
> This affects the source and binary bundles and the jars (binary and source)
>
 Not sure it does need to cancel the vote, this is not a major issue
 IMO and can be fixed for next one
>>>
>>> Given how infrequently releases are made, I don't think that is a good idea.
>>>



 Romain Manni-Bucau
 @rmannibucau
 http://www.tomitribe.com
 http://rmannibucau.wordpress.com
 https://github.com/rmannibucau


 2015-01-26 12:39 GMT+01:00 sebb :
> On 26 January 2015 at 11:30, Romain Manni-Bucau  
> wrote:
>> @sebb: not sure I get it right, it references LICENSE.txt correctly for 
>> me
>
> Not sure what you mean by "it" above.
>
> As I already wrote:
> The NOTICE file should not reference LICENSE.txt
> Nor should it reference LICENSE.xerox, because the Xerox license does
> not require attribution.
>
> However LICENSE.txt must include - or point to as separate file(s) -
> any 3rd party licenses for bundled code.
> It does not reference xerox currently, so there is a problem which
> arises because of the source file.
>
> The user must be able to determine the licensing requirements from
> LICENSE and NOTICE without having to look around for other license
> files.
> And the NOTICE file must not contain anything that is not required.
>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-26 12:27 GMT+01:00 sebb :
>>> On 26 January 2015 at 11:19, Romain Manni-Bucau  
>>> wrote:
 if that's the case +1 but anyway it doesnt hurt
>>>
>>> But it does have some consequences, because of the license issues.
>>>
 @Thomas: before dropping it can you confirm it a last time please?


 Romain Manni-Bucau
 @rmannibucau
 http://www.tomitribe.com
 http://rmannibucau.wordpress.com
 https://github.com/rmannibucau


 2015-01-26 12:18 GMT+01:00 sebb :
> Why not just drop it entirely?
>
> If that is the only Xerox-licensed file, it is not essential to the
> operation of JCS, so why keep it?
>
> On 25 January 2015 at 21:44, Romain Manni-Bucau 
>  wrote:
>> Hi Mark,
>>
>> this is not packaged AFAIK, just here as a sample I guess.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-25 22:35 GMT+01:00 Mark Struberg :
>>> is that all?
>>> https://svn.apache.org/repos/asf/commons/proper/jcs/trunk/commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>>>
>>> Wouldn't it be actually quite easy to replace this?
>>>
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>
>>>
 On Sunday, 25 January 2015, 19:30, Thomas Vandahl 
  wrote:
 > On 25.01.15 17:00, Romain Manni-Bucau wrote:
>  It does AFAIK - was not here and just propagated existing legal 
> text - and
>  that is why it is referenced in core and not all artifacts.
>   Le 25 janv. 2015 16:55, "sebb"  a écrit
 :

 The XEROX license relates to the file
 /commons-jcs-core/src/aspect/org/apache/commons/Trace.aj

 If the file continues to be part of the distribution, the license 
 file
 must be present, at least that is my understand

Re: [VOTE][JCS] release [jcs] 2.0-beta-1 (take 3)

[sebb]

On 26 January 2015 at 16:47, Romain Manni-Bucau  wrote:
> 2015-01-26 17:41 GMT+01:00 sebb :
>> On 26 January 2015 at 12:20, Romain Manni-Bucau  
>> wrote:
>>> Ok so you only speak about dist src bundle?
>>
>> No, it also affects the binary bundle, and it affects the SVN tag
>> (which is also a distribution, though not a release)
>>
>
> Not the bundle since aspectj files are not here and keeping xerox
> reference is not an issue just something we should avoid if possible
> nor the tag since the tag is fine (the tag uses module license and
> global one - bundle - doesnt make any sense). So it only affects
> sources one.

The NOTICE file is wrong, whether or not the xerox file is included.
NOTICE files must not contain spurious text.

This affects the source and binary bundles and the jars (binary and source)

>>> Not sure it does need to cancel the vote, this is not a major issue
>>> IMO and can be fixed for next one
>>
>> Given how infrequently releases are made, I don't think that is a good idea.
>>
>>>
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-26 12:39 GMT+01:00 sebb :
 On 26 January 2015 at 11:30, Romain Manni-Bucau  
 wrote:
> @sebb: not sure I get it right, it references LICENSE.txt correctly for me

 Not sure what you mean by "it" above.

 As I already wrote:
 The NOTICE file should not reference LICENSE.txt
 Nor should it reference LICENSE.xerox, because the Xerox license does
 not require attribution.

 However LICENSE.txt must include - or point to as separate file(s) -
 any 3rd party licenses for bundled code.
 It does not reference xerox currently, so there is a problem which
 arises because of the source file.

 The user must be able to determine the licensing requirements from
 LICENSE and NOTICE without having to look around for other license
 files.
 And the NOTICE file must not contain anything that is not required.

>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-26 12:27 GMT+01:00 sebb :
>> On 26 January 2015 at 11:19, Romain Manni-Bucau  
>> wrote:
>>> if that's the case +1 but anyway it doesnt hurt
>>
>> But it does have some consequences, because of the license issues.
>>
>>> @Thomas: before dropping it can you confirm it a last time please?
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-26 12:18 GMT+01:00 sebb :
 Why not just drop it entirely?

 If that is the only Xerox-licensed file, it is not essential to the
 operation of JCS, so why keep it?

 On 25 January 2015 at 21:44, Romain Manni-Bucau 
  wrote:
> Hi Mark,
>
> this is not packaged AFAIK, just here as a sample I guess.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-25 22:35 GMT+01:00 Mark Struberg :
>> is that all?
>> https://svn.apache.org/repos/asf/commons/proper/jcs/trunk/commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>>
>> Wouldn't it be actually quite easy to replace this?
>>
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>>> On Sunday, 25 January 2015, 19:30, Thomas Vandahl  
>>> wrote:
>>> > On 25.01.15 17:00, Romain Manni-Bucau wrote:
  It does AFAIK - was not here and just propagated existing legal 
 text - and
  that is why it is referenced in core and not all artifacts.
   Le 25 janv. 2015 16:55, "sebb"  a écrit
>>> :
>>>
>>> The XEROX license relates to the file
>>> /commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>>>
>>> If the file continues to be part of the distribution, the license 
>>> file
>>> must be present, at least that is my understanding of the Apache
>>> requirements.
>>>
>>> This was discussed at length when JCS 1.3 was released.
>>>
>>> Bye, Thomas.
>>>
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>> -
>>

Re: [VOTE][JCS] release [jcs] 2.0-beta-1 (take 3)

[Romain Manni-Bucau]

2015-01-26 17:48 GMT+01:00 sebb :
> On 26 January 2015 at 13:45, James Carman  wrote:
>> Release votes cannot be vetoed, so it's just a vote against.  If you
>
> The problem here is that there does not appear to be a specific commit
> that can be vetoed which can be said to be the cause of the problem.
>
>> have more +1's than -1's and you have at least 3 PMC folks saying +1,
>> then you can release.
>
> Strictly speaking that is true, but when an issue is found, the RM
> should take any vetos into account.

Sure but I'm really not sure it is a blocking issue, licensing is fine
just not super clean from my understanding.

>
>> However, if we do have an opportunity to clean
>> something up here, we should take it.  If we can just remove this file
>> and move on without the cruft, I'd say let's do it.  That way we don't
>> have to have this conversation again, the next time we try to release
>> this component.
>
> +1, please let's fix it now
>

@Thomas: since you are surely the one knowing the most about these
.aj, is it ok to remove these files? not sure we need any aspect BTW,
we should surely study their replacement by sirona if still needed. If
it is ok I'll remove them (the aspecj folder and the xerox references)

>>
>> On Mon, Jan 26, 2015 at 7:20 AM, Romain Manni-Bucau
>>  wrote:
>>> Ok so you only speak about dist src bundle?
>>>
>>> Not sure it does need to cancel the vote, this is not a major issue
>>> IMO and can be fixed for next one
>>>
>>>
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-26 12:39 GMT+01:00 sebb :
 On 26 January 2015 at 11:30, Romain Manni-Bucau  
 wrote:
> @sebb: not sure I get it right, it references LICENSE.txt correctly for me

 Not sure what you mean by "it" above.

 As I already wrote:
 The NOTICE file should not reference LICENSE.txt
 Nor should it reference LICENSE.xerox, because the Xerox license does
 not require attribution.

 However LICENSE.txt must include - or point to as separate file(s) -
 any 3rd party licenses for bundled code.
 It does not reference xerox currently, so there is a problem which
 arises because of the source file.

 The user must be able to determine the licensing requirements from
 LICENSE and NOTICE without having to look around for other license
 files.
 And the NOTICE file must not contain anything that is not required.

>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-26 12:27 GMT+01:00 sebb :
>> On 26 January 2015 at 11:19, Romain Manni-Bucau  
>> wrote:
>>> if that's the case +1 but anyway it doesnt hurt
>>
>> But it does have some consequences, because of the license issues.
>>
>>> @Thomas: before dropping it can you confirm it a last time please?
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-26 12:18 GMT+01:00 sebb :
 Why not just drop it entirely?

 If that is the only Xerox-licensed file, it is not essential to the
 operation of JCS, so why keep it?

 On 25 January 2015 at 21:44, Romain Manni-Bucau 
  wrote:
> Hi Mark,
>
> this is not packaged AFAIK, just here as a sample I guess.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-25 22:35 GMT+01:00 Mark Struberg :
>> is that all?
>> https://svn.apache.org/repos/asf/commons/proper/jcs/trunk/commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>>
>> Wouldn't it be actually quite easy to replace this?
>>
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>>> On Sunday, 25 January 2015, 19:30, Thomas Vandahl  
>>> wrote:
>>> > On 25.01.15 17:00, Romain Manni-Bucau wrote:
  It does AFAIK - was not here and just propagated existing legal 
 text - and
  that is why it is referenced in core and not all artifacts.
   Le 25 janv. 2015 16:55, "sebb"  a écrit
>>> :
>>>
>>> The XEROX license relates to the file
>>> /commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>>>
>>> If the file continues to be part of the distribution, the license 
>>> file
>>> must be present, at least that is my understanding of the Apache
>>> requirements.
>>>
>>> This was discuss

Re: [VOTE][JCS] release [jcs] 2.0-beta-1 (take 3)

[sebb]

On 26 January 2015 at 13:45, James Carman  wrote:
> Release votes cannot be vetoed, so it's just a vote against.  If you

The problem here is that there does not appear to be a specific commit
that can be vetoed which can be said to be the cause of the problem.

> have more +1's than -1's and you have at least 3 PMC folks saying +1,
> then you can release.

Strictly speaking that is true, but when an issue is found, the RM
should take any vetos into account.

> However, if we do have an opportunity to clean
> something up here, we should take it.  If we can just remove this file
> and move on without the cruft, I'd say let's do it.  That way we don't
> have to have this conversation again, the next time we try to release
> this component.

+1, please let's fix it now

>
> On Mon, Jan 26, 2015 at 7:20 AM, Romain Manni-Bucau
>  wrote:
>> Ok so you only speak about dist src bundle?
>>
>> Not sure it does need to cancel the vote, this is not a major issue
>> IMO and can be fixed for next one
>>
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-26 12:39 GMT+01:00 sebb :
>>> On 26 January 2015 at 11:30, Romain Manni-Bucau  
>>> wrote:
 @sebb: not sure I get it right, it references LICENSE.txt correctly for me
>>>
>>> Not sure what you mean by "it" above.
>>>
>>> As I already wrote:
>>> The NOTICE file should not reference LICENSE.txt
>>> Nor should it reference LICENSE.xerox, because the Xerox license does
>>> not require attribution.
>>>
>>> However LICENSE.txt must include - or point to as separate file(s) -
>>> any 3rd party licenses for bundled code.
>>> It does not reference xerox currently, so there is a problem which
>>> arises because of the source file.
>>>
>>> The user must be able to determine the licensing requirements from
>>> LICENSE and NOTICE without having to look around for other license
>>> files.
>>> And the NOTICE file must not contain anything that is not required.
>>>

 Romain Manni-Bucau
 @rmannibucau
 http://www.tomitribe.com
 http://rmannibucau.wordpress.com
 https://github.com/rmannibucau


 2015-01-26 12:27 GMT+01:00 sebb :
> On 26 January 2015 at 11:19, Romain Manni-Bucau  
> wrote:
>> if that's the case +1 but anyway it doesnt hurt
>
> But it does have some consequences, because of the license issues.
>
>> @Thomas: before dropping it can you confirm it a last time please?
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-26 12:18 GMT+01:00 sebb :
>>> Why not just drop it entirely?
>>>
>>> If that is the only Xerox-licensed file, it is not essential to the
>>> operation of JCS, so why keep it?
>>>
>>> On 25 January 2015 at 21:44, Romain Manni-Bucau  
>>> wrote:
 Hi Mark,

 this is not packaged AFAIK, just here as a sample I guess.


 Romain Manni-Bucau
 @rmannibucau
 http://www.tomitribe.com
 http://rmannibucau.wordpress.com
 https://github.com/rmannibucau


 2015-01-25 22:35 GMT+01:00 Mark Struberg :
> is that all?
> https://svn.apache.org/repos/asf/commons/proper/jcs/trunk/commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>
> Wouldn't it be actually quite easy to replace this?
>
>
>
> LieGrue,
> strub
>
>
>
>
>
>> On Sunday, 25 January 2015, 19:30, Thomas Vandahl  
>> wrote:
>> > On 25.01.15 17:00, Romain Manni-Bucau wrote:
>>>  It does AFAIK - was not here and just propagated existing legal 
>>> text - and
>>>  that is why it is referenced in core and not all artifacts.
>>>   Le 25 janv. 2015 16:55, "sebb"  a écrit
>> :
>>
>> The XEROX license relates to the file
>> /commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>>
>> If the file continues to be part of the distribution, the license 
>> file
>> must be present, at least that is my understanding of the Apache
>> requirements.
>>
>> This was discussed at length when JCS 1.3 was released.
>>
>> Bye, Thomas.
>>
>>
>>
>>
>> -
>> 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.apac

Re: [VOTE][JCS] release [jcs] 2.0-beta-1 (take 3)

[Romain Manni-Bucau]

2015-01-26 17:41 GMT+01:00 sebb :
> On 26 January 2015 at 12:20, Romain Manni-Bucau  wrote:
>> Ok so you only speak about dist src bundle?
>
> No, it also affects the binary bundle, and it affects the SVN tag
> (which is also a distribution, though not a release)
>

Not the bundle since aspectj files are not here and keeping xerox
reference is not an issue just something we should avoid if possible
nor the tag since the tag is fine (the tag uses module license and
global one - bundle - doesnt make any sense). So it only affects
sources one.

>> Not sure it does need to cancel the vote, this is not a major issue
>> IMO and can be fixed for next one
>
> Given how infrequently releases are made, I don't think that is a good idea.
>
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-26 12:39 GMT+01:00 sebb :
>>> On 26 January 2015 at 11:30, Romain Manni-Bucau  
>>> wrote:
 @sebb: not sure I get it right, it references LICENSE.txt correctly for me
>>>
>>> Not sure what you mean by "it" above.
>>>
>>> As I already wrote:
>>> The NOTICE file should not reference LICENSE.txt
>>> Nor should it reference LICENSE.xerox, because the Xerox license does
>>> not require attribution.
>>>
>>> However LICENSE.txt must include - or point to as separate file(s) -
>>> any 3rd party licenses for bundled code.
>>> It does not reference xerox currently, so there is a problem which
>>> arises because of the source file.
>>>
>>> The user must be able to determine the licensing requirements from
>>> LICENSE and NOTICE without having to look around for other license
>>> files.
>>> And the NOTICE file must not contain anything that is not required.
>>>

 Romain Manni-Bucau
 @rmannibucau
 http://www.tomitribe.com
 http://rmannibucau.wordpress.com
 https://github.com/rmannibucau


 2015-01-26 12:27 GMT+01:00 sebb :
> On 26 January 2015 at 11:19, Romain Manni-Bucau  
> wrote:
>> if that's the case +1 but anyway it doesnt hurt
>
> But it does have some consequences, because of the license issues.
>
>> @Thomas: before dropping it can you confirm it a last time please?
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-26 12:18 GMT+01:00 sebb :
>>> Why not just drop it entirely?
>>>
>>> If that is the only Xerox-licensed file, it is not essential to the
>>> operation of JCS, so why keep it?
>>>
>>> On 25 January 2015 at 21:44, Romain Manni-Bucau  
>>> wrote:
 Hi Mark,

 this is not packaged AFAIK, just here as a sample I guess.


 Romain Manni-Bucau
 @rmannibucau
 http://www.tomitribe.com
 http://rmannibucau.wordpress.com
 https://github.com/rmannibucau


 2015-01-25 22:35 GMT+01:00 Mark Struberg :
> is that all?
> https://svn.apache.org/repos/asf/commons/proper/jcs/trunk/commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>
> Wouldn't it be actually quite easy to replace this?
>
>
>
> LieGrue,
> strub
>
>
>
>
>
>> On Sunday, 25 January 2015, 19:30, Thomas Vandahl  
>> wrote:
>> > On 25.01.15 17:00, Romain Manni-Bucau wrote:
>>>  It does AFAIK - was not here and just propagated existing legal 
>>> text - and
>>>  that is why it is referenced in core and not all artifacts.
>>>   Le 25 janv. 2015 16:55, "sebb"  a écrit
>> :
>>
>> The XEROX license relates to the file
>> /commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>>
>> If the file continues to be part of the distribution, the license 
>> file
>> must be present, at least that is my understanding of the Apache
>> requirements.
>>
>> This was discussed at length when JCS 1.3 was released.
>>
>> Bye, Thomas.
>>
>>
>>
>>
>> -
>> 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: [VOTE][JCS] release [jcs] 2.0-beta-1 (take 3)

[sebb]

On 26 January 2015 at 12:20, Romain Manni-Bucau  wrote:
> Ok so you only speak about dist src bundle?

No, it also affects the binary bundle, and it affects the SVN tag
(which is also a distribution, though not a release)

> Not sure it does need to cancel the vote, this is not a major issue
> IMO and can be fixed for next one

Given how infrequently releases are made, I don't think that is a good idea.

>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-26 12:39 GMT+01:00 sebb :
>> On 26 January 2015 at 11:30, Romain Manni-Bucau  
>> wrote:
>>> @sebb: not sure I get it right, it references LICENSE.txt correctly for me
>>
>> Not sure what you mean by "it" above.
>>
>> As I already wrote:
>> The NOTICE file should not reference LICENSE.txt
>> Nor should it reference LICENSE.xerox, because the Xerox license does
>> not require attribution.
>>
>> However LICENSE.txt must include - or point to as separate file(s) -
>> any 3rd party licenses for bundled code.
>> It does not reference xerox currently, so there is a problem which
>> arises because of the source file.
>>
>> The user must be able to determine the licensing requirements from
>> LICENSE and NOTICE without having to look around for other license
>> files.
>> And the NOTICE file must not contain anything that is not required.
>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-26 12:27 GMT+01:00 sebb :
 On 26 January 2015 at 11:19, Romain Manni-Bucau  
 wrote:
> if that's the case +1 but anyway it doesnt hurt

 But it does have some consequences, because of the license issues.

> @Thomas: before dropping it can you confirm it a last time please?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-26 12:18 GMT+01:00 sebb :
>> Why not just drop it entirely?
>>
>> If that is the only Xerox-licensed file, it is not essential to the
>> operation of JCS, so why keep it?
>>
>> On 25 January 2015 at 21:44, Romain Manni-Bucau  
>> wrote:
>>> Hi Mark,
>>>
>>> this is not packaged AFAIK, just here as a sample I guess.
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-25 22:35 GMT+01:00 Mark Struberg :
 is that all?
 https://svn.apache.org/repos/asf/commons/proper/jcs/trunk/commons-jcs-core/src/aspect/org/apache/commons/Trace.aj

 Wouldn't it be actually quite easy to replace this?



 LieGrue,
 strub





> On Sunday, 25 January 2015, 19:30, Thomas Vandahl  
> wrote:
> > On 25.01.15 17:00, Romain Manni-Bucau wrote:
>>  It does AFAIK - was not here and just propagated existing legal 
>> text - and
>>  that is why it is referenced in core and not all artifacts.
>>   Le 25 janv. 2015 16:55, "sebb"  a écrit
> :
>
> The XEROX license relates to the file
> /commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>
> If the file continues to be part of the distribution, the license file
> must be present, at least that is my understanding of the Apache
> requirements.
>
> This was discussed at length when JCS 1.3 was released.
>
> Bye, Thomas.
>
>
>
>
> -
> 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
>>>
>>
>> -
>> 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: svn commit: r1654500 - in /commons/proper/validator/trunk/src: changes/ main/java/org/apache/commons/validator/routines/ test/java/org/apache/commons/validator/routines/

[sebb]

On 26 January 2015 at 11:47, Benedikt Ritter  wrote:
> 2015-01-26 12:25 GMT+01:00 sebb :
>
>> On 26 January 2015 at 07:30, Benedikt Ritter  wrote:
>> > Hello sebb,
>> >
>> > 2015-01-25 12:55 GMT+01:00 sebb :
>> >
>> >> On 25 January 2015 at 11:12, sebb  wrote:
>> >> > On 25 January 2015 at 10:58, Benedikt Ritter 
>> wrote:
>> >> >> Hello sebb,
>> >> >>
>> >> >> 2015-01-24 13:16 GMT+01:00 sebb :
>> >> >>
>> >> >>> On 24 January 2015 at 12:01,   wrote:
>> >> >>> > Author: britter
>> >> >>> > Date: Sat Jan 24 12:01:20 2015
>> >> >>> > New Revision: 1654500
>> >> >>> >
>> >> >>> > URL: http://svn.apache.org/r1654500
>> >> >>> > Log:
>> >> >>> > VALIDATOR-358: Underscores in domain names are not supported. This
>> >> fixes
>> >> >>> #3 from github. Thanks to Nykolas Laurentino de Lima.
>> >> >>>
>> >> >>> -1
>> >> >>>
>> >> >>> This is not supported by the RFCs I have seen.
>> >> >>>
>> >> >>> AFAICT underscore is supported in DNS labels.
>> >> >>>
>> >> >>
>> >> >> I've looked at RCF2181 [1] - Clarifications to the DNS Specification,
>> >> >> section 11 - Name syntax:
>> >> >>
>> >> >> "The DNS itself places only one restriction on the particular labels
>> >> that
>> >> >> can be used to identify resource records. That one restriction
>> relates
>> >> to
>> >> >> the length of the label and the full name. [...] Implementations of
>> the
>> >> DNS
>> >> >> protocols must not place any restrictions on the labels that can be
>> >> used.
>> >> >> In particular, DNS servers must not refuse to serve a zone because it
>> >> >> contains labels that might not be acceptable to some DNS client
>> >> programs."
>> >> >>
>> >> >> What am I missing?
>> >> >
>> >> > What I wrote below.
>> >> >
>> >> >> Benedikt
>> >> >>
>> >> >> [1] http://www.ietf.org/rfc/rfc2181.txt
>> >> >>
>> >> >>
>> >> >>>
>> >> >>> However that does not imply they are supported in hostnames and
>> URLs.
>> >> >
>> >> > i.e. DNS is a lot more permissive than hostnames allow.
>> >> > DNS is used for more than just hostname resolution.
>> >> >
>> >> >
>> http://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_host_names
>> >>
>> >> RFC 1123 extends RFC 952 to allow a leading numeric:
>> >>
>> >> http://tools.ietf.org/html/rfc1123#page-13
>> >>
>> >> so the syntax now allows letter-or-digit in first and last characters
>> >> of a label.
>> >> hyphens are additionally allowed in other positions
>> >> [TLDs are not allowed to start with a digit; this means 1.2.3.4 must
>> >> be a numeric IP address]
>> >>
>> >> I'm not aware of an RFC that relaxes the hostname syntax further, but
>> >> I've not done an exhaustive search.
>> >>
>> >
>> > I've reverted the commit.
>>
>> Thanks!
>>
>> > The initial PR on github [1] was about AWS host
>> > names, which can contain underscores (but are not considered valid bei
>> > validator). Maybe there is a different way we can fix that?
>>
>> If there really is a use case for this (and it seems there is) then it
>> should be easy enough to add underscore as an _option_ when performing
>> validation.
>> Perhaps the OP can provide an updated patch?
>>
>> We need to be careful not to change the validation without considering
>> the relevant RFCs.
>> We should fix bugs where the code does not agree with the RFCs, but we
>> should not deliberately allow forbidden syntax.
>> Other users may be expecting strict adherence to the RFCs.
>>
>
> Because of this I'm not sure whether DomainValidator is the correct place
> for this at all. The github issue looks more like it needs a
> "HostnameValidator" or "DnsValidator" or something like that.
>

That really depends on what "Domain" means in this context.
I'm fairly sure it does not actually mean Domain as in DNS, because:
- the rules are too restrictive for DNS
- DNS entry validation seems out of scope for VALIDATOR, which is more
focussed on validating URIs.

We need to look again at the RFCs for the validation classes that
depend on DomainValidator and check that the usage is correct.
And update the Javadocs where necessary to clarify the processing.

>>
>> > Benedikt
>> >
>> > [1] https://github.com/apache/commons-validator/pull/2
>> >
>> >
>> >>
>> >> >>>
>> >> >>> Unless a relevant RFC shows otherwise, this commit needs to be
>> >> reworked.
>> >> >>>
>> >> >>> Either reverted entirely, or allowing underscore must be optional,
>> and
>> >> >>> not allowed by default.
>> >> >>>
>> >> >>> > Modified:
>> >> >>> > commons/proper/validator/trunk/src/changes/changes.xml
>> >> >>> >
>> >> >>>
>> >>
>> commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/DomainValidator.java
>> >> >>> >
>> >> >>>
>> >>
>> commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/UrlValidator.java
>> >> >>> >
>> >> >>>
>> >>
>> commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/EmailValidatorTest.java
>> >> >>> >
>> >> >>>
>> >>
>> commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/

Re: [VOTE][JCS] release [jcs] 2.0-beta-1 (take 3)

[James Carman]

Release votes cannot be vetoed, so it's just a vote against.  If you
have more +1's than -1's and you have at least 3 PMC folks saying +1,
then you can release.  However, if we do have an opportunity to clean
something up here, we should take it.  If we can just remove this file
and move on without the cruft, I'd say let's do it.  That way we don't
have to have this conversation again, the next time we try to release
this component.


On Mon, Jan 26, 2015 at 7:20 AM, Romain Manni-Bucau
 wrote:
> Ok so you only speak about dist src bundle?
>
> Not sure it does need to cancel the vote, this is not a major issue
> IMO and can be fixed for next one
>
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-26 12:39 GMT+01:00 sebb :
>> On 26 January 2015 at 11:30, Romain Manni-Bucau  
>> wrote:
>>> @sebb: not sure I get it right, it references LICENSE.txt correctly for me
>>
>> Not sure what you mean by "it" above.
>>
>> As I already wrote:
>> The NOTICE file should not reference LICENSE.txt
>> Nor should it reference LICENSE.xerox, because the Xerox license does
>> not require attribution.
>>
>> However LICENSE.txt must include - or point to as separate file(s) -
>> any 3rd party licenses for bundled code.
>> It does not reference xerox currently, so there is a problem which
>> arises because of the source file.
>>
>> The user must be able to determine the licensing requirements from
>> LICENSE and NOTICE without having to look around for other license
>> files.
>> And the NOTICE file must not contain anything that is not required.
>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-26 12:27 GMT+01:00 sebb :
 On 26 January 2015 at 11:19, Romain Manni-Bucau  
 wrote:
> if that's the case +1 but anyway it doesnt hurt

 But it does have some consequences, because of the license issues.

> @Thomas: before dropping it can you confirm it a last time please?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-26 12:18 GMT+01:00 sebb :
>> Why not just drop it entirely?
>>
>> If that is the only Xerox-licensed file, it is not essential to the
>> operation of JCS, so why keep it?
>>
>> On 25 January 2015 at 21:44, Romain Manni-Bucau  
>> wrote:
>>> Hi Mark,
>>>
>>> this is not packaged AFAIK, just here as a sample I guess.
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-25 22:35 GMT+01:00 Mark Struberg :
 is that all?
 https://svn.apache.org/repos/asf/commons/proper/jcs/trunk/commons-jcs-core/src/aspect/org/apache/commons/Trace.aj

 Wouldn't it be actually quite easy to replace this?



 LieGrue,
 strub





> On Sunday, 25 January 2015, 19:30, Thomas Vandahl  
> wrote:
> > On 25.01.15 17:00, Romain Manni-Bucau wrote:
>>  It does AFAIK - was not here and just propagated existing legal 
>> text - and
>>  that is why it is referenced in core and not all artifacts.
>>   Le 25 janv. 2015 16:55, "sebb"  a écrit
> :
>
> The XEROX license relates to the file
> /commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>
> If the file continues to be part of the distribution, the license file
> must be present, at least that is my understanding of the Apache
> requirements.
>
> This was discussed at length when JCS 1.3 was released.
>
> Bye, Thomas.
>
>
>
>
> -
> 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
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> ---

Re: [collections] Revert a performance related fix in 4.1

[James Carman]

On Mon, Jan 26, 2015 at 7:03 AM, Benedikt Ritter  wrote:
> Hello Adrian
>
> 2015-01-24 19:43 GMT+01:00 Adrian Crum :
>
>> Slightly off-topic but somewhat related...
>>
>> I saw a recent commit where a "performance improvement" went something
>> like this:
>>
>> StringBuilder sb = new StringBuilder();
>> sb.append("foo");
>>
>> was replaced with
>>
>> StringBuilder sb = new StringBuilder("foo");
>>
>> The change reduced the code by one line, but there was no "performance
>> improvement" - because the StringBuilder constructor calls append().
>>
>
> All methods on StringBuffer are synchronized, so there a slight overhead of
> acquiring the lock. This is usually the argument for using StringBuilder
> over StringBuffer.
>

But, there was no StringBuffer referenced in the above code snippet,
right, so the sync vs. non-sync doesn't apply.

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

Re: [collections] Revert a performance related fix in 4.1

[Benedikt Ritter]

2015-01-26 14:05 GMT+01:00 Gary Gregory :

> On Mon, Jan 26, 2015 at 7:03 AM, Benedikt Ritter 
> wrote:
>
> > Hello Adrian
> >
> > 2015-01-24 19:43 GMT+01:00 Adrian Crum <
> adrian.c...@sandglass-software.com
> > >:
> >
> > > Slightly off-topic but somewhat related...
> > >
> > > I saw a recent commit where a "performance improvement" went something
> > > like this:
> > >
> > > StringBuilder sb = new StringBuilder();
> > > sb.append("foo");
> > >
> > > was replaced with
> > >
> > > StringBuilder sb = new StringBuilder("foo");
> > >
> > > The change reduced the code by one line, but there was no "performance
> > > improvement" - because the StringBuilder constructor calls append().
> > >
> >
> > All methods on StringBuffer are synchronized, so there a slight overhead
> of
> > acquiring the lock. This is usually the argument for using StringBuilder
> > over StringBuffer.
> >
>
> Woa, going from builder to buffer sounds wrong unless synchronization is
> required.
>

D'oh, meant it the other way around ;-) sorry for the confusion!


>
> Gary
>
> >
> >
> > >
> > > So, I agree that suggested performance improvements should be met with
> a
> > > great deal of skepticism and they should be closely scrutinized.
> > >
> > > Adrian Crum
> > > Sandglass Software
> > > www.sandglass-software.com
> > >
> > >
> > > On 1/24/2015 10:21 AM, Thomas Neidhart wrote:
> > >
> > >> Hi,
> > >>
> > >> from time to time some researchers trying to find performance bugs in
> > >> open-source software create issues for collections.
> > >>
> > >> One of the easy targets is the Collection#retainAll(Collection) method
> > >> as the default implementation in AbstractCollection calls contains on
> > >> the provided collection.
> > >>
> > >> Now, in the worst-case this may lead to a runtime complexity of
> O(n^2),
> > >> i.e. when the collection has a contains implementation with O(n)
> > >> complexity.
> > >>
> > >> The proposed solution is usually to create an intermediate set and use
> > >> it to speed up the contains calls.
> > >>
> > >> My position was always that a given Collection class shall not
> overwrite
> > >> this method trying to optimize its runtime behavior for any possible
> > >> input by creating such intermediate data structures as this will just
> > >> increase the space complexity (in many cases unnecessarily). Instead,
> > >> the runtime complexity was documented (one can even question this as
> the
> > >> Collection framework should be well-known by java users).
> > >>
> > >> It looks like that at 2 occasions these "performance bugs" got fixed:
> > >>
> > >>   * https://issues.apache.org/jira/browse/COLLECTIONS-426
> > >>   * https://issues.apache.org/jira/browse/COLLECTIONS-427
> > >>
> > >> and I would like to revert these fixes as they are wrong imho and just
> > >> create a precedent for further tickets.
> > >>
> > >> Does anybody challenge my rationale behind this or can I go ahead with
> > it?
> > >>
> > >> Thomas
> > >>
> > >> -
> > >> 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
> > >
> > >
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
> >
>
>
>
> --
> 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
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [collections] Revert a performance related fix in 4.1

[Gary Gregory]

On Mon, Jan 26, 2015 at 7:03 AM, Benedikt Ritter  wrote:

> Hello Adrian
>
> 2015-01-24 19:43 GMT+01:00 Adrian Crum  >:
>
> > Slightly off-topic but somewhat related...
> >
> > I saw a recent commit where a "performance improvement" went something
> > like this:
> >
> > StringBuilder sb = new StringBuilder();
> > sb.append("foo");
> >
> > was replaced with
> >
> > StringBuilder sb = new StringBuilder("foo");
> >
> > The change reduced the code by one line, but there was no "performance
> > improvement" - because the StringBuilder constructor calls append().
> >
>
> All methods on StringBuffer are synchronized, so there a slight overhead of
> acquiring the lock. This is usually the argument for using StringBuilder
> over StringBuffer.
>

Woa, going from builder to buffer sounds wrong unless synchronization is
required.

Gary

>
>
> >
> > So, I agree that suggested performance improvements should be met with a
> > great deal of skepticism and they should be closely scrutinized.
> >
> > Adrian Crum
> > Sandglass Software
> > www.sandglass-software.com
> >
> >
> > On 1/24/2015 10:21 AM, Thomas Neidhart wrote:
> >
> >> Hi,
> >>
> >> from time to time some researchers trying to find performance bugs in
> >> open-source software create issues for collections.
> >>
> >> One of the easy targets is the Collection#retainAll(Collection) method
> >> as the default implementation in AbstractCollection calls contains on
> >> the provided collection.
> >>
> >> Now, in the worst-case this may lead to a runtime complexity of O(n^2),
> >> i.e. when the collection has a contains implementation with O(n)
> >> complexity.
> >>
> >> The proposed solution is usually to create an intermediate set and use
> >> it to speed up the contains calls.
> >>
> >> My position was always that a given Collection class shall not overwrite
> >> this method trying to optimize its runtime behavior for any possible
> >> input by creating such intermediate data structures as this will just
> >> increase the space complexity (in many cases unnecessarily). Instead,
> >> the runtime complexity was documented (one can even question this as the
> >> Collection framework should be well-known by java users).
> >>
> >> It looks like that at 2 occasions these "performance bugs" got fixed:
> >>
> >>   * https://issues.apache.org/jira/browse/COLLECTIONS-426
> >>   * https://issues.apache.org/jira/browse/COLLECTIONS-427
> >>
> >> and I would like to revert these fixes as they are wrong imho and just
> >> create a precedent for further tickets.
> >>
> >> Does anybody challenge my rationale behind this or can I go ahead with
> it?
> >>
> >> Thomas
> >>
> >> -
> >> 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
> >
> >
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>



-- 
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][JCS] release [jcs] 2.0-beta-1 (take 3)

[Romain Manni-Bucau]

Ok so you only speak about dist src bundle?

Not sure it does need to cancel the vote, this is not a major issue
IMO and can be fixed for next one




Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-26 12:39 GMT+01:00 sebb :
> On 26 January 2015 at 11:30, Romain Manni-Bucau  wrote:
>> @sebb: not sure I get it right, it references LICENSE.txt correctly for me
>
> Not sure what you mean by "it" above.
>
> As I already wrote:
> The NOTICE file should not reference LICENSE.txt
> Nor should it reference LICENSE.xerox, because the Xerox license does
> not require attribution.
>
> However LICENSE.txt must include - or point to as separate file(s) -
> any 3rd party licenses for bundled code.
> It does not reference xerox currently, so there is a problem which
> arises because of the source file.
>
> The user must be able to determine the licensing requirements from
> LICENSE and NOTICE without having to look around for other license
> files.
> And the NOTICE file must not contain anything that is not required.
>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-26 12:27 GMT+01:00 sebb :
>>> On 26 January 2015 at 11:19, Romain Manni-Bucau  
>>> wrote:
 if that's the case +1 but anyway it doesnt hurt
>>>
>>> But it does have some consequences, because of the license issues.
>>>
 @Thomas: before dropping it can you confirm it a last time please?


 Romain Manni-Bucau
 @rmannibucau
 http://www.tomitribe.com
 http://rmannibucau.wordpress.com
 https://github.com/rmannibucau


 2015-01-26 12:18 GMT+01:00 sebb :
> Why not just drop it entirely?
>
> If that is the only Xerox-licensed file, it is not essential to the
> operation of JCS, so why keep it?
>
> On 25 January 2015 at 21:44, Romain Manni-Bucau  
> wrote:
>> Hi Mark,
>>
>> this is not packaged AFAIK, just here as a sample I guess.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-25 22:35 GMT+01:00 Mark Struberg :
>>> is that all?
>>> https://svn.apache.org/repos/asf/commons/proper/jcs/trunk/commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>>>
>>> Wouldn't it be actually quite easy to replace this?
>>>
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>
>>>
 On Sunday, 25 January 2015, 19:30, Thomas Vandahl  
 wrote:
 > On 25.01.15 17:00, Romain Manni-Bucau wrote:
>  It does AFAIK - was not here and just propagated existing legal text 
> - and
>  that is why it is referenced in core and not all artifacts.
>   Le 25 janv. 2015 16:55, "sebb"  a écrit
 :

 The XEROX license relates to the file
 /commons-jcs-core/src/aspect/org/apache/commons/Trace.aj

 If the file continues to be part of the distribution, the license file
 must be present, at least that is my understanding of the Apache
 requirements.

 This was discussed at length when JCS 1.3 was released.

 Bye, Thomas.




 -
 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
>>
>
> -
> 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
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> ---

Re: [collections] Revert a performance related fix in 4.1

[Benedikt Ritter]

Hello Adrian

2015-01-24 19:43 GMT+01:00 Adrian Crum :

> Slightly off-topic but somewhat related...
>
> I saw a recent commit where a "performance improvement" went something
> like this:
>
> StringBuilder sb = new StringBuilder();
> sb.append("foo");
>
> was replaced with
>
> StringBuilder sb = new StringBuilder("foo");
>
> The change reduced the code by one line, but there was no "performance
> improvement" - because the StringBuilder constructor calls append().
>

All methods on StringBuffer are synchronized, so there a slight overhead of
acquiring the lock. This is usually the argument for using StringBuilder
over StringBuffer.


>
> So, I agree that suggested performance improvements should be met with a
> great deal of skepticism and they should be closely scrutinized.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
>
> On 1/24/2015 10:21 AM, Thomas Neidhart wrote:
>
>> Hi,
>>
>> from time to time some researchers trying to find performance bugs in
>> open-source software create issues for collections.
>>
>> One of the easy targets is the Collection#retainAll(Collection) method
>> as the default implementation in AbstractCollection calls contains on
>> the provided collection.
>>
>> Now, in the worst-case this may lead to a runtime complexity of O(n^2),
>> i.e. when the collection has a contains implementation with O(n)
>> complexity.
>>
>> The proposed solution is usually to create an intermediate set and use
>> it to speed up the contains calls.
>>
>> My position was always that a given Collection class shall not overwrite
>> this method trying to optimize its runtime behavior for any possible
>> input by creating such intermediate data structures as this will just
>> increase the space complexity (in many cases unnecessarily). Instead,
>> the runtime complexity was documented (one can even question this as the
>> Collection framework should be well-known by java users).
>>
>> It looks like that at 2 occasions these "performance bugs" got fixed:
>>
>>   * https://issues.apache.org/jira/browse/COLLECTIONS-426
>>   * https://issues.apache.org/jira/browse/COLLECTIONS-427
>>
>> and I would like to revert these fixes as they are wrong imho and just
>> create a precedent for further tickets.
>>
>> Does anybody challenge my rationale behind this or can I go ahead with it?
>>
>> Thomas
>>
>> -
>> 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
>
>


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: svn commit: r1654500 - in /commons/proper/validator/trunk/src: changes/ main/java/org/apache/commons/validator/routines/ test/java/org/apache/commons/validator/routines/

[Benedikt Ritter]

2015-01-26 12:47 GMT+01:00 Benedikt Ritter :

>
>
> 2015-01-26 12:25 GMT+01:00 sebb :
>
>> On 26 January 2015 at 07:30, Benedikt Ritter  wrote:
>> > Hello sebb,
>> >
>> > 2015-01-25 12:55 GMT+01:00 sebb :
>> >
>> >> On 25 January 2015 at 11:12, sebb  wrote:
>> >> > On 25 January 2015 at 10:58, Benedikt Ritter 
>> wrote:
>> >> >> Hello sebb,
>> >> >>
>> >> >> 2015-01-24 13:16 GMT+01:00 sebb :
>> >> >>
>> >> >>> On 24 January 2015 at 12:01,   wrote:
>> >> >>> > Author: britter
>> >> >>> > Date: Sat Jan 24 12:01:20 2015
>> >> >>> > New Revision: 1654500
>> >> >>> >
>> >> >>> > URL: http://svn.apache.org/r1654500
>> >> >>> > Log:
>> >> >>> > VALIDATOR-358: Underscores in domain names are not supported.
>> This
>> >> fixes
>> >> >>> #3 from github. Thanks to Nykolas Laurentino de Lima.
>> >> >>>
>> >> >>> -1
>> >> >>>
>> >> >>> This is not supported by the RFCs I have seen.
>> >> >>>
>> >> >>> AFAICT underscore is supported in DNS labels.
>> >> >>>
>> >> >>
>> >> >> I've looked at RCF2181 [1] - Clarifications to the DNS
>> Specification,
>> >> >> section 11 - Name syntax:
>> >> >>
>> >> >> "The DNS itself places only one restriction on the particular labels
>> >> that
>> >> >> can be used to identify resource records. That one restriction
>> relates
>> >> to
>> >> >> the length of the label and the full name. [...] Implementations of
>> the
>> >> DNS
>> >> >> protocols must not place any restrictions on the labels that can be
>> >> used.
>> >> >> In particular, DNS servers must not refuse to serve a zone because
>> it
>> >> >> contains labels that might not be acceptable to some DNS client
>> >> programs."
>> >> >>
>> >> >> What am I missing?
>> >> >
>> >> > What I wrote below.
>> >> >
>> >> >> Benedikt
>> >> >>
>> >> >> [1] http://www.ietf.org/rfc/rfc2181.txt
>> >> >>
>> >> >>
>> >> >>>
>> >> >>> However that does not imply they are supported in hostnames and
>> URLs.
>> >> >
>> >> > i.e. DNS is a lot more permissive than hostnames allow.
>> >> > DNS is used for more than just hostname resolution.
>> >> >
>> >> >
>> http://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_host_names
>> >>
>> >> RFC 1123 extends RFC 952 to allow a leading numeric:
>> >>
>> >> http://tools.ietf.org/html/rfc1123#page-13
>> >>
>> >> so the syntax now allows letter-or-digit in first and last characters
>> >> of a label.
>> >> hyphens are additionally allowed in other positions
>> >> [TLDs are not allowed to start with a digit; this means 1.2.3.4 must
>> >> be a numeric IP address]
>> >>
>> >> I'm not aware of an RFC that relaxes the hostname syntax further, but
>> >> I've not done an exhaustive search.
>> >>
>> >
>> > I've reverted the commit.
>>
>> Thanks!
>>
>> > The initial PR on github [1] was about AWS host
>> > names, which can contain underscores (but are not considered valid bei
>> > validator). Maybe there is a different way we can fix that?
>>
>> If there really is a use case for this (and it seems there is) then it
>> should be easy enough to add underscore as an _option_ when performing
>> validation.
>> Perhaps the OP can provide an updated patch?
>>
>> We need to be careful not to change the validation without considering
>> the relevant RFCs.
>> We should fix bugs where the code does not agree with the RFCs, but we
>> should not deliberately allow forbidden syntax.
>> Other users may be expecting strict adherence to the RFCs.
>>
>
> Because of this I'm not sure whether DomainValidator is the correct place
> for this at all. The github issue looks more like it needs a
> "HostnameValidator" or "DnsValidator" or something like that.
>

To make this clear :-) I agree with you, our routines should not violate
rules defined in RFCs, not even optionally.


>
>
>>
>> > Benedikt
>> >
>> > [1] https://github.com/apache/commons-validator/pull/2
>> >
>> >
>> >>
>> >> >>>
>> >> >>> Unless a relevant RFC shows otherwise, this commit needs to be
>> >> reworked.
>> >> >>>
>> >> >>> Either reverted entirely, or allowing underscore must be optional,
>> and
>> >> >>> not allowed by default.
>> >> >>>
>> >> >>> > Modified:
>> >> >>> > commons/proper/validator/trunk/src/changes/changes.xml
>> >> >>> >
>> >> >>>
>> >>
>> commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/DomainValidator.java
>> >> >>> >
>> >> >>>
>> >>
>> commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/UrlValidator.java
>> >> >>> >
>> >> >>>
>> >>
>> commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/EmailValidatorTest.java
>> >> >>> >
>> >> >>>
>> >>
>> commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/UrlValidatorTest.java
>> >> >>> >
>> >> >>> > Modified: commons/proper/validator/trunk/src/changes/changes.xml
>> >> >>> > URL:
>> >> >>>
>> >>
>> http://svn.apache.org/viewvc/commons/proper/validator/trunk/src/changes/changes.xml?rev=1654500&r1=1654499&r2=1654500&view=diff
>> >> >>> >
>> >> >>>
>> >>
>> 

Re: svn commit: r1654500 - in /commons/proper/validator/trunk/src: changes/ main/java/org/apache/commons/validator/routines/ test/java/org/apache/commons/validator/routines/

[Benedikt Ritter]

2015-01-26 12:25 GMT+01:00 sebb :

> On 26 January 2015 at 07:30, Benedikt Ritter  wrote:
> > Hello sebb,
> >
> > 2015-01-25 12:55 GMT+01:00 sebb :
> >
> >> On 25 January 2015 at 11:12, sebb  wrote:
> >> > On 25 January 2015 at 10:58, Benedikt Ritter 
> wrote:
> >> >> Hello sebb,
> >> >>
> >> >> 2015-01-24 13:16 GMT+01:00 sebb :
> >> >>
> >> >>> On 24 January 2015 at 12:01,   wrote:
> >> >>> > Author: britter
> >> >>> > Date: Sat Jan 24 12:01:20 2015
> >> >>> > New Revision: 1654500
> >> >>> >
> >> >>> > URL: http://svn.apache.org/r1654500
> >> >>> > Log:
> >> >>> > VALIDATOR-358: Underscores in domain names are not supported. This
> >> fixes
> >> >>> #3 from github. Thanks to Nykolas Laurentino de Lima.
> >> >>>
> >> >>> -1
> >> >>>
> >> >>> This is not supported by the RFCs I have seen.
> >> >>>
> >> >>> AFAICT underscore is supported in DNS labels.
> >> >>>
> >> >>
> >> >> I've looked at RCF2181 [1] - Clarifications to the DNS Specification,
> >> >> section 11 - Name syntax:
> >> >>
> >> >> "The DNS itself places only one restriction on the particular labels
> >> that
> >> >> can be used to identify resource records. That one restriction
> relates
> >> to
> >> >> the length of the label and the full name. [...] Implementations of
> the
> >> DNS
> >> >> protocols must not place any restrictions on the labels that can be
> >> used.
> >> >> In particular, DNS servers must not refuse to serve a zone because it
> >> >> contains labels that might not be acceptable to some DNS client
> >> programs."
> >> >>
> >> >> What am I missing?
> >> >
> >> > What I wrote below.
> >> >
> >> >> Benedikt
> >> >>
> >> >> [1] http://www.ietf.org/rfc/rfc2181.txt
> >> >>
> >> >>
> >> >>>
> >> >>> However that does not imply they are supported in hostnames and
> URLs.
> >> >
> >> > i.e. DNS is a lot more permissive than hostnames allow.
> >> > DNS is used for more than just hostname resolution.
> >> >
> >> >
> http://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_host_names
> >>
> >> RFC 1123 extends RFC 952 to allow a leading numeric:
> >>
> >> http://tools.ietf.org/html/rfc1123#page-13
> >>
> >> so the syntax now allows letter-or-digit in first and last characters
> >> of a label.
> >> hyphens are additionally allowed in other positions
> >> [TLDs are not allowed to start with a digit; this means 1.2.3.4 must
> >> be a numeric IP address]
> >>
> >> I'm not aware of an RFC that relaxes the hostname syntax further, but
> >> I've not done an exhaustive search.
> >>
> >
> > I've reverted the commit.
>
> Thanks!
>
> > The initial PR on github [1] was about AWS host
> > names, which can contain underscores (but are not considered valid bei
> > validator). Maybe there is a different way we can fix that?
>
> If there really is a use case for this (and it seems there is) then it
> should be easy enough to add underscore as an _option_ when performing
> validation.
> Perhaps the OP can provide an updated patch?
>
> We need to be careful not to change the validation without considering
> the relevant RFCs.
> We should fix bugs where the code does not agree with the RFCs, but we
> should not deliberately allow forbidden syntax.
> Other users may be expecting strict adherence to the RFCs.
>

Because of this I'm not sure whether DomainValidator is the correct place
for this at all. The github issue looks more like it needs a
"HostnameValidator" or "DnsValidator" or something like that.


>
> > Benedikt
> >
> > [1] https://github.com/apache/commons-validator/pull/2
> >
> >
> >>
> >> >>>
> >> >>> Unless a relevant RFC shows otherwise, this commit needs to be
> >> reworked.
> >> >>>
> >> >>> Either reverted entirely, or allowing underscore must be optional,
> and
> >> >>> not allowed by default.
> >> >>>
> >> >>> > Modified:
> >> >>> > commons/proper/validator/trunk/src/changes/changes.xml
> >> >>> >
> >> >>>
> >>
> commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/DomainValidator.java
> >> >>> >
> >> >>>
> >>
> commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/UrlValidator.java
> >> >>> >
> >> >>>
> >>
> commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/EmailValidatorTest.java
> >> >>> >
> >> >>>
> >>
> commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/UrlValidatorTest.java
> >> >>> >
> >> >>> > Modified: commons/proper/validator/trunk/src/changes/changes.xml
> >> >>> > URL:
> >> >>>
> >>
> http://svn.apache.org/viewvc/commons/proper/validator/trunk/src/changes/changes.xml?rev=1654500&r1=1654499&r2=1654500&view=diff
> >> >>> >
> >> >>>
> >>
> ==
> >> >>> > --- commons/proper/validator/trunk/src/changes/changes.xml
> (original)
> >> >>> > +++ commons/proper/validator/trunk/src/changes/changes.xml Sat
> Jan 24
> >> >>> 12:01:20 2015
> >> >>> > @@ -43,6 +43,9 @@ The  type attribute can be add,u
> >> >>> >
> >> >>> >
> >> >>> > 

Re: [VOTE][JCS] release [jcs] 2.0-beta-1 (take 3)

[sebb]

On 26 January 2015 at 11:30, Romain Manni-Bucau  wrote:
> @sebb: not sure I get it right, it references LICENSE.txt correctly for me

Not sure what you mean by "it" above.

As I already wrote:
The NOTICE file should not reference LICENSE.txt
Nor should it reference LICENSE.xerox, because the Xerox license does
not require attribution.

However LICENSE.txt must include - or point to as separate file(s) -
any 3rd party licenses for bundled code.
It does not reference xerox currently, so there is a problem which
arises because of the source file.

The user must be able to determine the licensing requirements from
LICENSE and NOTICE without having to look around for other license
files.
And the NOTICE file must not contain anything that is not required.

>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-26 12:27 GMT+01:00 sebb :
>> On 26 January 2015 at 11:19, Romain Manni-Bucau  
>> wrote:
>>> if that's the case +1 but anyway it doesnt hurt
>>
>> But it does have some consequences, because of the license issues.
>>
>>> @Thomas: before dropping it can you confirm it a last time please?
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-26 12:18 GMT+01:00 sebb :
 Why not just drop it entirely?

 If that is the only Xerox-licensed file, it is not essential to the
 operation of JCS, so why keep it?

 On 25 January 2015 at 21:44, Romain Manni-Bucau  
 wrote:
> Hi Mark,
>
> this is not packaged AFAIK, just here as a sample I guess.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-25 22:35 GMT+01:00 Mark Struberg :
>> is that all?
>> https://svn.apache.org/repos/asf/commons/proper/jcs/trunk/commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>>
>> Wouldn't it be actually quite easy to replace this?
>>
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>>> On Sunday, 25 January 2015, 19:30, Thomas Vandahl  
>>> wrote:
>>> > On 25.01.15 17:00, Romain Manni-Bucau wrote:
  It does AFAIK - was not here and just propagated existing legal text 
 - and
  that is why it is referenced in core and not all artifacts.
   Le 25 janv. 2015 16:55, "sebb"  a écrit
>>> :
>>>
>>> The XEROX license relates to the file
>>> /commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>>>
>>> If the file continues to be part of the distribution, the license file
>>> must be present, at least that is my understanding of the Apache
>>> requirements.
>>>
>>> This was discussed at length when JCS 1.3 was released.
>>>
>>> Bye, Thomas.
>>>
>>>
>>>
>>>
>>> -
>>> 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
>

 -
 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
>>
>
> -
> 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][JCS] release [jcs] 2.0-beta-1 (take 3)

[Romain Manni-Bucau]

@sebb: not sure I get it right, it references LICENSE.txt correctly for me


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-26 12:27 GMT+01:00 sebb :
> On 26 January 2015 at 11:19, Romain Manni-Bucau  wrote:
>> if that's the case +1 but anyway it doesnt hurt
>
> But it does have some consequences, because of the license issues.
>
>> @Thomas: before dropping it can you confirm it a last time please?
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-26 12:18 GMT+01:00 sebb :
>>> Why not just drop it entirely?
>>>
>>> If that is the only Xerox-licensed file, it is not essential to the
>>> operation of JCS, so why keep it?
>>>
>>> On 25 January 2015 at 21:44, Romain Manni-Bucau  
>>> wrote:
 Hi Mark,

 this is not packaged AFAIK, just here as a sample I guess.


 Romain Manni-Bucau
 @rmannibucau
 http://www.tomitribe.com
 http://rmannibucau.wordpress.com
 https://github.com/rmannibucau


 2015-01-25 22:35 GMT+01:00 Mark Struberg :
> is that all?
> https://svn.apache.org/repos/asf/commons/proper/jcs/trunk/commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>
> Wouldn't it be actually quite easy to replace this?
>
>
>
> LieGrue,
> strub
>
>
>
>
>
>> On Sunday, 25 January 2015, 19:30, Thomas Vandahl  
>> wrote:
>> > On 25.01.15 17:00, Romain Manni-Bucau wrote:
>>>  It does AFAIK - was not here and just propagated existing legal text - 
>>> and
>>>  that is why it is referenced in core and not all artifacts.
>>>   Le 25 janv. 2015 16:55, "sebb"  a écrit
>> :
>>
>> The XEROX license relates to the file
>> /commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>>
>> If the file continues to be part of the distribution, the license file
>> must be present, at least that is my understanding of the Apache
>> requirements.
>>
>> This was discussed at length when JCS 1.3 was released.
>>
>> Bye, Thomas.
>>
>>
>>
>>
>> -
>> 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

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

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

Re: [VOTE][JCS] release [jcs] 2.0-beta-1 (take 3)

[sebb]

On 26 January 2015 at 11:19, Romain Manni-Bucau  wrote:
> if that's the case +1 but anyway it doesnt hurt

But it does have some consequences, because of the license issues.

> @Thomas: before dropping it can you confirm it a last time please?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-26 12:18 GMT+01:00 sebb :
>> Why not just drop it entirely?
>>
>> If that is the only Xerox-licensed file, it is not essential to the
>> operation of JCS, so why keep it?
>>
>> On 25 January 2015 at 21:44, Romain Manni-Bucau  
>> wrote:
>>> Hi Mark,
>>>
>>> this is not packaged AFAIK, just here as a sample I guess.
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-25 22:35 GMT+01:00 Mark Struberg :
 is that all?
 https://svn.apache.org/repos/asf/commons/proper/jcs/trunk/commons-jcs-core/src/aspect/org/apache/commons/Trace.aj

 Wouldn't it be actually quite easy to replace this?



 LieGrue,
 strub





> On Sunday, 25 January 2015, 19:30, Thomas Vandahl  wrote:
> > On 25.01.15 17:00, Romain Manni-Bucau wrote:
>>  It does AFAIK - was not here and just propagated existing legal text - 
>> and
>>  that is why it is referenced in core and not all artifacts.
>>   Le 25 janv. 2015 16:55, "sebb"  a écrit
> :
>
> The XEROX license relates to the file
> /commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>
> If the file continues to be part of the distribution, the license file
> must be present, at least that is my understanding of the Apache
> requirements.
>
> This was discussed at length when JCS 1.3 was released.
>
> Bye, Thomas.
>
>
>
>
> -
> 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
>>>
>>
>> -
>> 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: svn commit: r1654500 - in /commons/proper/validator/trunk/src: changes/ main/java/org/apache/commons/validator/routines/ test/java/org/apache/commons/validator/routines/

[sebb]

On 26 January 2015 at 07:30, Benedikt Ritter  wrote:
> Hello sebb,
>
> 2015-01-25 12:55 GMT+01:00 sebb :
>
>> On 25 January 2015 at 11:12, sebb  wrote:
>> > On 25 January 2015 at 10:58, Benedikt Ritter  wrote:
>> >> Hello sebb,
>> >>
>> >> 2015-01-24 13:16 GMT+01:00 sebb :
>> >>
>> >>> On 24 January 2015 at 12:01,   wrote:
>> >>> > Author: britter
>> >>> > Date: Sat Jan 24 12:01:20 2015
>> >>> > New Revision: 1654500
>> >>> >
>> >>> > URL: http://svn.apache.org/r1654500
>> >>> > Log:
>> >>> > VALIDATOR-358: Underscores in domain names are not supported. This
>> fixes
>> >>> #3 from github. Thanks to Nykolas Laurentino de Lima.
>> >>>
>> >>> -1
>> >>>
>> >>> This is not supported by the RFCs I have seen.
>> >>>
>> >>> AFAICT underscore is supported in DNS labels.
>> >>>
>> >>
>> >> I've looked at RCF2181 [1] - Clarifications to the DNS Specification,
>> >> section 11 - Name syntax:
>> >>
>> >> "The DNS itself places only one restriction on the particular labels
>> that
>> >> can be used to identify resource records. That one restriction relates
>> to
>> >> the length of the label and the full name. [...] Implementations of the
>> DNS
>> >> protocols must not place any restrictions on the labels that can be
>> used.
>> >> In particular, DNS servers must not refuse to serve a zone because it
>> >> contains labels that might not be acceptable to some DNS client
>> programs."
>> >>
>> >> What am I missing?
>> >
>> > What I wrote below.
>> >
>> >> Benedikt
>> >>
>> >> [1] http://www.ietf.org/rfc/rfc2181.txt
>> >>
>> >>
>> >>>
>> >>> However that does not imply they are supported in hostnames and URLs.
>> >
>> > i.e. DNS is a lot more permissive than hostnames allow.
>> > DNS is used for more than just hostname resolution.
>> >
>> > http://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_host_names
>>
>> RFC 1123 extends RFC 952 to allow a leading numeric:
>>
>> http://tools.ietf.org/html/rfc1123#page-13
>>
>> so the syntax now allows letter-or-digit in first and last characters
>> of a label.
>> hyphens are additionally allowed in other positions
>> [TLDs are not allowed to start with a digit; this means 1.2.3.4 must
>> be a numeric IP address]
>>
>> I'm not aware of an RFC that relaxes the hostname syntax further, but
>> I've not done an exhaustive search.
>>
>
> I've reverted the commit.

Thanks!

> The initial PR on github [1] was about AWS host
> names, which can contain underscores (but are not considered valid bei
> validator). Maybe there is a different way we can fix that?

If there really is a use case for this (and it seems there is) then it
should be easy enough to add underscore as an _option_ when performing
validation.
Perhaps the OP can provide an updated patch?

We need to be careful not to change the validation without considering
the relevant RFCs.
We should fix bugs where the code does not agree with the RFCs, but we
should not deliberately allow forbidden syntax.
Other users may be expecting strict adherence to the RFCs.

> Benedikt
>
> [1] https://github.com/apache/commons-validator/pull/2
>
>
>>
>> >>>
>> >>> Unless a relevant RFC shows otherwise, this commit needs to be
>> reworked.
>> >>>
>> >>> Either reverted entirely, or allowing underscore must be optional, and
>> >>> not allowed by default.
>> >>>
>> >>> > Modified:
>> >>> > commons/proper/validator/trunk/src/changes/changes.xml
>> >>> >
>> >>>
>> commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/DomainValidator.java
>> >>> >
>> >>>
>> commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/UrlValidator.java
>> >>> >
>> >>>
>> commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/EmailValidatorTest.java
>> >>> >
>> >>>
>> commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/UrlValidatorTest.java
>> >>> >
>> >>> > Modified: commons/proper/validator/trunk/src/changes/changes.xml
>> >>> > URL:
>> >>>
>> http://svn.apache.org/viewvc/commons/proper/validator/trunk/src/changes/changes.xml?rev=1654500&r1=1654499&r2=1654500&view=diff
>> >>> >
>> >>>
>> ==
>> >>> > --- commons/proper/validator/trunk/src/changes/changes.xml (original)
>> >>> > +++ commons/proper/validator/trunk/src/changes/changes.xml Sat Jan 24
>> >>> 12:01:20 2015
>> >>> > @@ -43,6 +43,9 @@ The  type attribute can be add,u
>> >>> >
>> >>> >
>> >>> >
>> >>> > +> >>> due-to="Nykolas Laurentino de Lima">
>> >>> > +  Underscores in domain names are not supported
>> >>> > +
>> >>> >  
>> >>> >IDN.toASCII drops trailing dot in Java 6 & 7
>> >>> >  
>> >>> >
>> >>> > Modified:
>> >>>
>> commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/DomainValidator.java
>> >>> > URL:
>> >>>
>> http://svn.apache.org/viewvc/commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/DomainValidator.java?rev=

Re: [VOTE][JCS] release [jcs] 2.0-beta-1 (take 3)

[Romain Manni-Bucau]

if that's the case +1 but anyway it doesnt hurt

@Thomas: before dropping it can you confirm it a last time please?


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-26 12:18 GMT+01:00 sebb :
> Why not just drop it entirely?
>
> If that is the only Xerox-licensed file, it is not essential to the
> operation of JCS, so why keep it?
>
> On 25 January 2015 at 21:44, Romain Manni-Bucau  wrote:
>> Hi Mark,
>>
>> this is not packaged AFAIK, just here as a sample I guess.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-25 22:35 GMT+01:00 Mark Struberg :
>>> is that all?
>>> https://svn.apache.org/repos/asf/commons/proper/jcs/trunk/commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>>>
>>> Wouldn't it be actually quite easy to replace this?
>>>
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>
>>>
 On Sunday, 25 January 2015, 19:30, Thomas Vandahl  wrote:
 > On 25.01.15 17:00, Romain Manni-Bucau wrote:
>  It does AFAIK - was not here and just propagated existing legal text - 
> and
>  that is why it is referenced in core and not all artifacts.
>   Le 25 janv. 2015 16:55, "sebb"  a écrit
 :

 The XEROX license relates to the file
 /commons-jcs-core/src/aspect/org/apache/commons/Trace.aj

 If the file continues to be part of the distribution, the license file
 must be present, at least that is my understanding of the Apache
 requirements.

 This was discussed at length when JCS 1.3 was released.

 Bye, Thomas.




 -
 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
>>
>
> -
> 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][JCS] release [jcs] 2.0-beta-1 (take 3)

[sebb]

Why not just drop it entirely?

If that is the only Xerox-licensed file, it is not essential to the
operation of JCS, so why keep it?

On 25 January 2015 at 21:44, Romain Manni-Bucau  wrote:
> Hi Mark,
>
> this is not packaged AFAIK, just here as a sample I guess.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-25 22:35 GMT+01:00 Mark Struberg :
>> is that all?
>> https://svn.apache.org/repos/asf/commons/proper/jcs/trunk/commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>>
>> Wouldn't it be actually quite easy to replace this?
>>
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>>> On Sunday, 25 January 2015, 19:30, Thomas Vandahl  wrote:
>>> > On 25.01.15 17:00, Romain Manni-Bucau wrote:
  It does AFAIK - was not here and just propagated existing legal text - and
  that is why it is referenced in core and not all artifacts.
   Le 25 janv. 2015 16:55, "sebb"  a écrit
>>> :
>>>
>>> The XEROX license relates to the file
>>> /commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
>>>
>>> If the file continues to be part of the distribution, the license file
>>> must be present, at least that is my understanding of the Apache
>>> requirements.
>>>
>>> This was discussed at length when JCS 1.3 was released.
>>>
>>> Bye, Thomas.
>>>
>>>
>>>
>>>
>>> -
>>> 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
>

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