RE: [CRYPTO]1.0.0 Release Plan

[Sun, Dapeng]

Hi all,

Please let me know if there is any blocks need to be resolved before the 
release.

Regards
Dapeng

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: Tuesday, June 28, 2016 6:48 PM
To: Commons Developers List
Subject: Re: [CRYPTO]1.0.0 Release Plan

On 28 June 2016 at 07:03, Sun, Dapeng  wrote:
> Thank Sebb for your great work!
>
> About the Properties instance, I have some personal opinions.
>
> I think properties provide a flexible configuration mechanism. Config values 
> could be added and read/written without too much limitation, we also provides 
> default values for each properties, user don't need set value for every 
> properties. They could also give null, if they want to use the default 
> settings.

Agreed they are flexible.

>>> also the way that classes are instantiated is very awkward, as properties 
>>> are not as easy to use as plain variables - String/boolean etc and 
>>> properties don't offer any type validation.
>
> Properties don't offer any type validation, but we can validate the type and 
> value before we using them. For example, stream buffer size, when 
> CryptoStream is creating, it will read the value and convert it to int.
>
>>> Since properties are used in the constructors, it's not enough for 3rd 
>>> parties to just implement the CryptoRandom interface - they also have to 
>>> provide a constructor which takes a Properties instance.
>
> For 3rd parties implementations, they may need to read some configuration 
> when initializing, properties will provide this ability at this time. 
> Otherwise, they need to handle the work such as reading config file, read 
> config value ant etc. For the 3rd parties implementations which don't need 
> the properties, they can leave it null or ignore.
>
> If you have a better configuration mechanism, could you tell me more detail?

On further reflection, I think it's not going to make the API any easier for 
the general case where implementation-specific values are needed.

However, we could perhaps add a convenience method for the case where only the 
classname(s) are needed.
 e.g. add  new methods as below:

CryptoRandom getCryptoRandom(String classids) and CryptoCipher 
getInstance(String transformation, String classids)

These would each create a Property instance and call the existing getInstance 
method

This would not save a lot of code, but it would be simpler for the OpenSSL 
implementations at least.

> Regards
> Dapeng
>
> -Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Sunday, June 26, 2016 7:53 AM
> To: Commons Developers List
> Subject: Re: [CRYPTO]1.0.0 Release Plan
>
> On 24 June 2016 at 11:17, sebb  wrote:
>> On 24 June 2016 at 10:08, Sun, Dapeng  wrote:
>>> Hi all,
>>>
>>> Thank all for helping review CRYPTO from different angles.
>>>
>>> According the number of jira remaining issues, I prefer to start the thread 
>>> for rolling a RC at June 29th(Next Wednesday). Please feel free to let me 
>>> know if you have any concern about it.
>>
>> Yes, I do have some concerns.
>>
>> I think the public API needs to be better documented.
>> There are still a lot of public classes that AFAICT don't really 
>> belong in the API.
>> For example
>> JceCipher
>> OpensslCipher
>> JavaCryptoRandom
>> OpensslCryptoRandom
>> OsCryptoRandom
>> These need to be made private/package protected or moved into an 
>> internal package, or at the very least clearly documented as internal.
>
> I have made them package private.
>
>> Also the way that classes are instantiated is very awkward, as 
>> properties are not as easy to use as plain variables - String/boolean 
>> etc - and properties don't offer any type validation.
>> Since properties are used in the constructors, it's not enough for 
>> 3rd parties to just implement the CryptoRandom interface - they also 
>> have to provide a constructor which takes a Properties instance.
>
> This is still an issue.
>
>> Indeed I wonder why there is a CryptoRandom interface - would it not 
>> be better for JavaCryptoRandom to extend java.util.Random? The other 
>> implementations of CryptoRandom do.
>> Or maybe none of them should extend j.u.Random?
>
> Likewise, this ought to be resolved.
>
>>> Regards
>>> Dapeng
>>>
>>> -Original Message-
>>> From: Sun, Dapeng [mailto:dapeng@intel.com]
>>> Sent: Monday, June 06, 2016 5:14 PM
>>> To: Commons Developers List
>>> Subject: [CRYPTO]1.0.0 Release Plan
>>>
>>> Hello,
>>>
>>> Apache Commons CRYPTO was established at May 9, 2016[1], There are 
>>> presently numbers of resolved issues fix in CRYPTO[2]. Recently, we also 
>>> fixed the legal issue[3].
>>>
>>> With the first release, we can begin to promote CRYPTO to other Apache 
>>> components, like Apache Hadoop, Apache Spark, so that they can benefit the 
>>> higher performance improvement from Apache Commons Crypto.
>>>
>>> We plan the following three opening features to next 

Re: Bug spot in commons-net-3.5

[sebb]

I just tried downloading a file using the FTPClientExample and it worked fine.

Remember to set the binary transfer mode if necessary.

2016-07-07 20:45 GMT+01:00 MBCRAFT :
> Hi! I spot a bug in commons-net-3.5  it seems that the ftp client misses
> the last bytes on large downloaded files.
> I did some tests with a 7 MB file, and it always missed the last kb.
> I've tried some quick fix, but i wasn't able to solve my problem.
>
> Kind regards
>
> -Marco B.
>
> --
> [---
> [MBCRAFT di Marco Bagnaresi - Software development services
> [Via ca' del vento, 11
> [CAP 48012 - Bagnacavallo(RA)
> [C.F. : BGNMRC82H03E730O
> [P.IVA/VAT N. : 02475790396
> [Website : http://www.mbcraft.it
> [Standard mail : i...@mbcraft.it
> [PEC : mbcr...@pec.it
> [---
> [
> [
> [Informativa ai sensi del codice della privacy (D.Lgs 196-30/06/2003)
> [Questo messaggio è destinato unicamente ai soggetti indicati
> nell'intestazione.
> [In caso di ricezione erronea si prega di informare il mittente e di
> eliminare
> [il messaggio secondo le norme relative al trattamento dei dati personali.
> [La diffusione impropria in qualsiasi forma delle informazioni contenute in
> questo messaggio sono proibite
> [dalla legge. Questo messaggio può contenere informazioni non corrette.
> [Può rivolgersi alla nostra azienda per richiedere informazioni su titolare
> e responsabili del trattamento e
> [per esercitare i diritti previsti dall'Art.7 del D.lg.196/2003
> [inviando una mail con oggetto “Privacy”.
> [
>
>
>
> -
> 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: Bug spot in commons-net-3.5

[Gary Gregory]

Hi Marco,

Could you please provide unit test that demonstrates the problem?

Gary

2016-07-07 12:45 GMT-07:00 MBCRAFT :

> Hi! I spot a bug in commons-net-3.5  it seems that the ftp client
> misses the last bytes on large downloaded files.
> I did some tests with a 7 MB file, and it always missed the last kb.
> I've tried some quick fix, but i wasn't able to solve my problem.
>
> Kind regards
>
> -Marco B.
>
> --
> [---
> [MBCRAFT di Marco Bagnaresi - Software development services
> [Via ca' del vento, 11
> [CAP 48012 - Bagnacavallo(RA)
> [C.F. : BGNMRC82H03E730O
> [P.IVA/VAT N. : 02475790396
> [Website : http://www.mbcraft.it
> [Standard mail : i...@mbcraft.it
> [PEC : mbcr...@pec.it
> [---
> [
> [
> [Informativa ai sensi del codice della privacy (D.Lgs 196-30/06/2003)
> [Questo messaggio è destinato unicamente ai soggetti indicati
> nell'intestazione.
> [In caso di ricezione erronea si prega di informare il mittente e di
> eliminare
> [il messaggio secondo le norme relative al trattamento dei dati personali.
> [La diffusione impropria in qualsiasi forma delle informazioni contenute
> in questo messaggio sono proibite
> [dalla legge. Questo messaggio può contenere informazioni non corrette.
> [Può rivolgersi alla nostra azienda per richiedere informazioni su
> titolare e responsabili del trattamento e
> [per esercitare i diritti previsti dall'Art.7 del D.lg.196/2003
> [inviando una mail con oggetto “Privacy”.
> [
>
>
>
> -
> 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

Bug spot in commons-net-3.5

[MBCRAFT]

Hi! I spot a bug in commons-net-3.5  it seems that the ftp client 
misses the last bytes on large downloaded files.

I did some tests with a 7 MB file, and it always missed the last kb.
I've tried some quick fix, but i wasn't able to solve my problem.

Kind regards

-Marco B.

--
[---
[MBCRAFT di Marco Bagnaresi - Software development services
[Via ca' del vento, 11
[CAP 48012 - Bagnacavallo(RA)
[C.F. : BGNMRC82H03E730O
[P.IVA/VAT N. : 02475790396
[Website : http://www.mbcraft.it
[Standard mail : i...@mbcraft.it
[PEC : mbcr...@pec.it
[---
[
[
[Informativa ai sensi del codice della privacy (D.Lgs 196-30/06/2003)
[Questo messaggio è destinato unicamente ai soggetti indicati nell'intestazione.
[In caso di ricezione erronea si prega di informare il mittente e di eliminare
[il messaggio secondo le norme relative al trattamento dei dati personali.
[La diffusione impropria in qualsiasi forma delle informazioni contenute in 
questo messaggio sono proibite
[dalla legge. Questo messaggio può contenere informazioni non corrette.
[Può rivolgersi alla nostra azienda per richiedere informazioni su titolare e 
responsabili del trattamento e
[per esercitare i diritti previsti dall'Art.7 del D.lg.196/2003
[inviando una mail con oggetto “Privacy”.
[
  




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

Re: [VOTE] Release Apache Commons BCEL 6.0 based on RC7

[Benedikt Ritter]

Thank you Mark, I'll have a look ASAP.

Mark Roberts  schrieb am Do., 7. Juli 2016 um
18:41:

> Unit test attached to BCEL-262.
>
> Mark
>
> > -Original Message-
> > From: Gary Gregory [mailto:garydgreg...@gmail.com]
> > Sent: Wednesday, July 06, 2016 2:26 PM
> > To: Commons Developers List
> > Subject: Re: [VOTE] Release Apache Commons BCEL 6.0 based on RC7
> >
> > I think we should wait for your unit test before we cut another (and
> final I
> > hope) RC.
> >
> > Gary
> >
> > On Wed, Jul 6, 2016 at 10:51 AM, Mark Roberts
> > 
> > wrote:
> >
> > > The patch that (was) attached to bcel-262 was correct, it just looks
> > > like it was never applied.  The line numbers are a little off now so I
> > > have just updated the patch - the new version is relative to RC7.
> > >
> > > The example failure shown in the bug report requires running Daikon to
> > > repro.  I will see if I can produce a reduced test case, but it will
> > > take a little time.
> > >
> > > I just noticed that the package coordinates change (from commons/bcel6
> > > back to bcel) was applied to the trunk as well as the RC candidates.
> > > It this change permanent?  I really don't want to edit my sources back
> > > only to have to change them again at some point in the future.
> > >
> > > And here is some good (!) news:  I took the current RC7 sources,
> > > applied my InvokeInstruction patch, built the system, used shade52.xml
> > > to get the correct :-) names and inserted the resulting bcel.jar into
> > > the Daikon system.  It built correctly and passed all the regression
> tests. Ta-
> > da!
> > >
> > > Thank you,
> > > Mark
> > >
> > > > -Original Message-
> > > > From: Benedikt Ritter [mailto:brit...@apache.org]
> > > > Sent: Wednesday, July 06, 2016 9:47 AM
> > > > To: Commons Developers List
> > > > Subject: Re: [VOTE] Release Apache Commons BCEL 6.0 based on RC7
> > > >
> > > > Gary Gregory  schrieb am Mi., 6. Juli 2016
> > > > um
> > > > 18:37 Uhr:
> > > >
> > > > > Can you craft a unit test that makes sure the proper behavior is
> > > > > in
> > > place?
> > > > >
> > > >
> > > > That would be awesome. Furthermore you will have to attach the patch
> > > > to jira or create a GitHub PR, since the ML moes not allow file
> > attachments.
> > > >
> > > > Benedikt
> > > >
> > > >
> > > > > Gary
> > > > >
> > > > > On Wed, Jul 6, 2016 at 9:16 AM, Mark Roberts
> > > > > 
> > > > > wrote:
> > > > >
> > > > > > Hmm - now I'm thinking the code for InvokeInstruction is not
> correct.
> > > > > The
> > > > > > override method getClassName was added, but my patch was not
> > > > applied
> > > > > > to
> > > > > the
> > > > > > added code.  I have attached the diff.
> > > > > >
> > > > > > Sorry for not catching this the first time.
> > > > > >
> > > > > > Thank you,
> > > > > > Mark
> > > > > >
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Mark Roberts [mailto:mar...@cs.washington.edu]
> > > > > > > Sent: Wednesday, July 06, 2016 6:57 AM
> > > > > > > To: 'Commons Developers List'
> > > > > > > Subject: RE: [VOTE] Release Apache Commons BCEL 6.0 based on
> > > > > > > RC7
> > > > > > >
> > > > > > > The RELEASE-NOTES.txt entry for BCEL-262 is incorrect.  It
> > > > > > > should be
> > > > > > exactly
> > > > > > > the opposite.  The override was added to InvokeInstruction
> > > > > > > because an
> > > > > > array
> > > > > > > IS a legal operand.  The code is correct, the throw has been
> > > removed.
> > > > > > >
> > > > > > > Mark
> > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: Benedikt Ritter [mailto:brit...@apache.org]
> > > > > > > > Sent: Tuesday, July 05, 2016 2:17 AM
> > > > > > > > To: Commons Developers List
> > > > > > > > Subject: Re: [VOTE] Release Apache Commons BCEL 6.0 based on
> > > > > > > > RC7
> > > > > > > >
> > > > > > > > This vote is still pending and nobody has voted so far.
> > > > > > > > Please review this RC and cast your votes!
> > > > > > > >
> > > > > > > > Thank you!
> > > > > > > > Benedikt
> > > > > > > >
> > > > > > > > Benedikt Ritter  schrieb am Sa., 2. Juli
> > > > > > > > 2016 um
> > > > > > > > 20:52 Uhr:
> > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I'd like to release Apache Commons BCEL 6.0 based on RC7.
> > > > > > > > > Changes compared to RC6 are:
> > > > > > > > >
> > > > > > > > > - restored binary compatibility to a greater degree
> > > > > > > > > - fixed issue BCEL-262
> > > > > > > > >
> > > > > > > > > BCEL 6.0 RC7 is available for review here:
> > > > > > > > > https://dist.apache.org/repos/dist/dev/commons/bcel/ (svn
> > > > > > > > > revision
> > > > > > > > > 14251)
> > > > > > > > >
> > > > > > > > > The tag is here:
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > >
> > http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_
> > > > > > > RC
> > 

RE: [VOTE] Release Apache Commons BCEL 6.0 based on RC7

[Mark Roberts]

Unit test attached to BCEL-262.

Mark

> -Original Message-
> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> Sent: Wednesday, July 06, 2016 2:26 PM
> To: Commons Developers List
> Subject: Re: [VOTE] Release Apache Commons BCEL 6.0 based on RC7
> 
> I think we should wait for your unit test before we cut another (and final I
> hope) RC.
> 
> Gary
> 
> On Wed, Jul 6, 2016 at 10:51 AM, Mark Roberts
> 
> wrote:
> 
> > The patch that (was) attached to bcel-262 was correct, it just looks
> > like it was never applied.  The line numbers are a little off now so I
> > have just updated the patch - the new version is relative to RC7.
> >
> > The example failure shown in the bug report requires running Daikon to
> > repro.  I will see if I can produce a reduced test case, but it will
> > take a little time.
> >
> > I just noticed that the package coordinates change (from commons/bcel6
> > back to bcel) was applied to the trunk as well as the RC candidates.
> > It this change permanent?  I really don't want to edit my sources back
> > only to have to change them again at some point in the future.
> >
> > And here is some good (!) news:  I took the current RC7 sources,
> > applied my InvokeInstruction patch, built the system, used shade52.xml
> > to get the correct :-) names and inserted the resulting bcel.jar into
> > the Daikon system.  It built correctly and passed all the regression tests. 
> > Ta-
> da!
> >
> > Thank you,
> > Mark
> >
> > > -Original Message-
> > > From: Benedikt Ritter [mailto:brit...@apache.org]
> > > Sent: Wednesday, July 06, 2016 9:47 AM
> > > To: Commons Developers List
> > > Subject: Re: [VOTE] Release Apache Commons BCEL 6.0 based on RC7
> > >
> > > Gary Gregory  schrieb am Mi., 6. Juli 2016
> > > um
> > > 18:37 Uhr:
> > >
> > > > Can you craft a unit test that makes sure the proper behavior is
> > > > in
> > place?
> > > >
> > >
> > > That would be awesome. Furthermore you will have to attach the patch
> > > to jira or create a GitHub PR, since the ML moes not allow file
> attachments.
> > >
> > > Benedikt
> > >
> > >
> > > > Gary
> > > >
> > > > On Wed, Jul 6, 2016 at 9:16 AM, Mark Roberts
> > > > 
> > > > wrote:
> > > >
> > > > > Hmm - now I'm thinking the code for InvokeInstruction is not correct.
> > > > The
> > > > > override method getClassName was added, but my patch was not
> > > applied
> > > > > to
> > > > the
> > > > > added code.  I have attached the diff.
> > > > >
> > > > > Sorry for not catching this the first time.
> > > > >
> > > > > Thank you,
> > > > > Mark
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Mark Roberts [mailto:mar...@cs.washington.edu]
> > > > > > Sent: Wednesday, July 06, 2016 6:57 AM
> > > > > > To: 'Commons Developers List'
> > > > > > Subject: RE: [VOTE] Release Apache Commons BCEL 6.0 based on
> > > > > > RC7
> > > > > >
> > > > > > The RELEASE-NOTES.txt entry for BCEL-262 is incorrect.  It
> > > > > > should be
> > > > > exactly
> > > > > > the opposite.  The override was added to InvokeInstruction
> > > > > > because an
> > > > > array
> > > > > > IS a legal operand.  The code is correct, the throw has been
> > removed.
> > > > > >
> > > > > > Mark
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Benedikt Ritter [mailto:brit...@apache.org]
> > > > > > > Sent: Tuesday, July 05, 2016 2:17 AM
> > > > > > > To: Commons Developers List
> > > > > > > Subject: Re: [VOTE] Release Apache Commons BCEL 6.0 based on
> > > > > > > RC7
> > > > > > >
> > > > > > > This vote is still pending and nobody has voted so far.
> > > > > > > Please review this RC and cast your votes!
> > > > > > >
> > > > > > > Thank you!
> > > > > > > Benedikt
> > > > > > >
> > > > > > > Benedikt Ritter  schrieb am Sa., 2. Juli
> > > > > > > 2016 um
> > > > > > > 20:52 Uhr:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I'd like to release Apache Commons BCEL 6.0 based on RC7.
> > > > > > > > Changes compared to RC6 are:
> > > > > > > >
> > > > > > > > - restored binary compatibility to a greater degree
> > > > > > > > - fixed issue BCEL-262
> > > > > > > >
> > > > > > > > BCEL 6.0 RC7 is available for review here:
> > > > > > > > https://dist.apache.org/repos/dist/dev/commons/bcel/ (svn
> > > > > > > > revision
> > > > > > > > 14251)
> > > > > > > >
> > > > > > > > The tag is here:
> > > > > > > >
> > > > > > >
> > > > > >
> > >
> http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_
> > > > > > RC
> > > > > > > 7/
> > > > > > > > (svn revision 1751084)
> > > > > > > >
> > > > > > > > Maven artifacts are here:
> > > > > > > >
> > > > > >
> > > https://repository.apache.org/content/repositories/orgapachecommon
> > > > > > s-
> > > > > > > 11
> > > > > > > > 81/org/apache/bcel/bcel/6.0/
> > > > > > > >
> > > > > > > > These are the Maven artifacts and their hashes
> > > > > > > >
> > > > 

[Compress] Apple FOSS its new codec

[Gary Gregory]

http://www.appleworld.today/blog/2016/7/6/apples-lzfse-compression-algorithm-goes-open-source

Could be interesting to port to Java.

The C source is in GitHub but no unit test AFAIK, I don't get that. Their
tests must rely on some infra code they do not want to clean up and FOSS.

Gary

Re: [Math] Getting things done

[Jörg Schaible]

Hello Mike,

michael.brzustow...@gmail.com wrote:

> Hi Math3 devs,
> 
> Is there a consensus on the future of Math3?

Definately. Not necessarily as Math3 for mid-term, since the plan was to 
establish a Math TLP with the code base of Math 3/4 minus the code for the 
three new components.

> I rely on the Linear Algebra
> package and also Stats.
> Is there major changes planned for those? I have heard some mentions of
> refactoring going on,
> but not sure how much would change to the API ... or if it's just
> implementation details.

Actually I have no knowledge about the current state of the code, esp. what 
happened between Math 3 and 4 for the areas you've mentioned here.
 
> I do hope to contribute some code (probably in linalg, stats,
> machine-learning) when some current
> side projects clear up and I have time to dedicate.

Any help is welcome. The future of Math needs an active community caring for 
the individual parts of the code.

Cheers.
Jörg


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