date:20160619

Hi,

we have failing tests on Jenkins for JCS [1]. Does anybody know what caused
this?

Regards,
Benedikt

[1]
https://builds.apache.org/view/Apache%20Commons/job/commons-jcs/159/org.apache.commons$commons-jcs-core/console

Re: [JCS] Failing Tests in JCS Core

2016-06-19 Thread Romain Manni-Bucau

Can check tomorrow but can it be the ip which is not localhost or ipv4?
Le 19 juin 2016 10:47, "Benedikt Ritter"  a écrit :

> Hi,
>
> we have failing tests on Jenkins for JCS [1]. Does anybody know what caused
> this?
>
> Regards,
> Benedikt
>
> [1]
>
> https://builds.apache.org/view/Apache%20Commons/job/commons-jcs/159/org.apache.commons$commons-jcs-core/console
>

Re: apache, commons, math

2016-06-19 Thread Stian Soiland-Reyes

Thanks Eric for your view and great suggestions!

I agree that more Commons-like codes that are easy enough to understand fit
well here, and that more exotic interpolators etc are harder to get into,
and would fit better in a mathematician-centric community
(Incubator/TLP/Github organisation) with more leverage as to breaking API
changes and different release granularities. I think if we start
categorizing it could be difficult to draw the line, but I think Gilles "I
can (roughly) understand this" is a good criteria to start with.

I think it's OK for Commons Maths +1 to have less features, particularly
here we know Maths have grown too big. It's possible to later re-add your
favourite algorithm, so the documentation would need to clearly show both
the ("unsupported") legacy version and the newer more focused version.

However I still don't understand the reluctance to release "unsupported
code" - we have no support contracts or correctness guarantees. If say
AkimaSpline Interpolator has already been released, then why can't it be
included in future releases? Any bugs from before would be the same later.

I know from experience that it's annoying when repeated updates to open
source software haven't fixed your most annoying bug; but then this itch is
what can trigger a "perhaps I can fix it then?" reaction.

I have not explored the differences, but if it is the case that the master
branch have too much experimental code which has never been released and
which you don't want to commit to "supporting", how about putting them in
an .experimental package? It would be a good indicator that you're on your
own, this might break, please come join us to develop these further.

If someone finds a bug they care enough about, then perhaps we need to
reevaluate why they can't simply contribute a fix (e.g. reluctance to
degrade performance) and lower the barriers for becoming part of Math -
this is important both inside or outside Commons. We don't need to verify
the absolute correctness of the fix; we should rather assume by default the
contributor who needs a fix in a particular specific method knows something
about its algorithm and try to bring in their knowledge (and hopefully
future maintainership).

I think we need to keep calm and avoid rushing off with arguments and he
said/she said; we don't need to fragment the Math community any further and
be realistic with what is a reasonable code base to work with for a
smaller/fresher community. I think it's clear that such a community would
need some liberty to decide for itself on things like release and update
policies and how to structure/modularize it's code, and I think the
Incubator would be a good place to try this out. (If it doesn't work out,
that is also OK)

I think it's also important for us to revisit the assumed requirement of
all classes to remain "supported", I can tell you there are many Apache
projects that have effectively unsupported modules or packages (stagnant
development, lack of knowledge within active committers), but they are part
of the regular releases and therefore still are supported in the sense that
they still compile and can accept patches.
On 19 Jun 2016 12:09 a.m., "Ralph Goers"  wrote:

> Thanks, Eric.
>
> I am OK with Commons Math being split into modules in the Commons Math
> sub-project. I am not OK with Commons Math A, Commons Math B, etc existing
> within Commons. In other words, when a user traverses to Commons Math they
> can then see the modules that make up Commons Math.
>
> I am also OK with code being mothballed if no one knows what it does, how
> it works, why it exists or who may want to use it.  I am not OK with
> retiring code just because a single person doesn’t know what it does or how
> to maintain it.  In other words, I am looking for people like you to
> volunteer to be part of the community that decides what should stay and
> what should go. IMO, that community needs to be of sufficient size that it
> is somewhat representative of the users of Commons Math. That doesn’t mean
> it necessarily needs 10 people, but I would say it needs more than 2.
>
> The side effect of this, is that once you have a community that can start
> making these kinds of decisions you can also make a proposal to go to the
> incubator or become a TLP (there is really no reason a project can’t
> “incubate” here in Commons).
>
> Ralph
>
> > On Jun 18, 2016, at 11:22 AM, Eric Barnhill 
> wrote:
> >
> > I am new to protocols here and not sure which thread to jump on. But I am
> > quite interested in the viability of the math project and hope the
> > following observation is helpful.
> >
> > I think one reason people are talking past each other in this debate is
> > because those outside the commons-math community may be thinking more
> about
> > commons-math classes like Median and those within it may be more
> concerned
> > with commons-math classes like AkimaSplineInterpolator.
> >
> > In the case of Median, the fit to the commons mission i

Re: [CRYPTO] Possible new method for CryptoCipher interface; API evolution

On 19 June 2016 at 01:18, Stian Soiland-Reyes  wrote:
> I am not too keen to grow CryptoCipher to an abstract class (Java 8 or not)
> with additional methods that would not typically be implemented by
> implementing subclasses.
>
> The API of CC is quite low level, yes, but then adding higher level helpers
> there won't really help as it will be quite a confusing API to use, mixed
> with the lower level methods which you then should NOT use.

No, it would be an additional method intended for use alongside the others.

c.f. Writer which as:

void write(String)
and
void write(String,int,int)

> A higher level CryptoUtils (?) could be a better place, it could have
> helpers to de/encrypt a byte[], a String and a Path without requiring the
> multiple steps.

To take the Writer case, it would be confusing to have to use

Writer.write(String,int,int)
and
WriterUtils.write(String).

> On 16 Jun 2016 2:17 p.m., "sebb"  wrote:
>
>> I have been looking at creating examples for Crypto.
>>
>> It occurred to me that a common use case is encryption/decryption of
>> small chunks of data that can readily be stored in a local byte array.
>>
>> For such cases, there is no need to use both update() and doFinal().
>> Having to provide the input array offset/length and the output array
>> offset is tedious.
>>
>> It might therefore be useful to provide a method with the signature:
>>
>> int doFinal(byte[] input, byte[] output)
>>
>> This got me thinking about how the code should be designed to enable
>> evolution of the API in future releases. A method added to an
>> interface breaks compatibility unless one uses Java 8 with its default
>> implementation feature. Whereas if the CryptoCipher interface were
>> turned into an abstract class, changes could be readily implemented
>> without breaking the API.
>>
>> I'm inclined to think that using an abstract base class is better than
>> an interface.
>> - it's easy to extend and to provide helper methods
>> - it works with Java 7 (does not require Java 8)
>> - AFAICT an implementation *is* a CryptoCipher
>>
>> The same applies to the CryptoRandom.
>>
>> I wonder also whether the stream.input.Input and stream.output.Output
>> interfaces should be abstract classes instead.
>> They seem to mirror the java.io.InputStream/OutputStream abstract classes.
>> So maybe they should be dropped in favour of an abstract subclass of
>> InputStream/OutputStream?
>>
>> -
>> 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

[CRYPTO] Defining the public API; are its interfaces supposed to be implemented or just used?

Some work has been done towards defining what is public and what is not.

AFAIK, one aspect that has yet to be considered is whether the
interfaces are designed for public use (or are just internal), and for
public interfaces, are they intended for implementation or just for
use?

Use-only interfaces are much easier to evolve as methods can be added
without affecting client code.

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

Re: [CRYPTO] Defining the public API; are its interfaces supposed to be implemented or just used?

2016-06-19 Thread Jochen Wiedmann

On Sun, Jun 19, 2016 at 12:49 PM, sebb  wrote:

> Use-only interfaces are much easier to evolve as methods can be added
> without affecting client code.

That applies (IMO) only, if there is an abstract base class, and users
are actually deriving from that.

Jochen


-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: [CRYPTO] Defining the public API; are its interfaces supposed to be implemented or just used?

On 19 June 2016 at 12:44, Jochen Wiedmann  wrote:
> On Sun, Jun 19, 2016 at 12:49 PM, sebb  wrote:
>
>> Use-only interfaces are much easier to evolve as methods can be added
>> without affecting client code.
>
> That applies (IMO) only, if there is an abstract base class, and users
> are actually deriving from that.

By a use-only interface, I mean one that is not implemented by user code.
i.e. the code does not derive from the interface, it only uses it to
define fields etc.

This info is taken from
https://wiki.eclipse.org/Evolving_Java-based_APIs#Example_4_-_Adding_an_API_method

Users deriving from an abstract base class do not have to change code
to implement new methods.
But if their class happens to define a method with a name that is
subsequently used by the Crypto abstract class, there will be a clash
which will require them to recode.

> Jochen
>
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [CRYPTO] Defining the public API; are its interfaces supposed to be implemented or just used?

My unterstanding of crypto is that those interfaces are not to be
implemented by Clients.

sebb  schrieb am So., 19. Juni 2016 um 14:02:

> On 19 June 2016 at 12:44, Jochen Wiedmann 
> wrote:
> > On Sun, Jun 19, 2016 at 12:49 PM, sebb  wrote:
> >
> >> Use-only interfaces are much easier to evolve as methods can be added
> >> without affecting client code.
> >
> > That applies (IMO) only, if there is an abstract base class, and users
> > are actually deriving from that.
>
> By a use-only interface, I mean one that is not implemented by user code.
> i.e. the code does not derive from the interface, it only uses it to
> define fields etc.
>
> This info is taken from
>
> https://wiki.eclipse.org/Evolving_Java-based_APIs#Example_4_-_Adding_an_API_method
>
> Users deriving from an abstract base class do not have to change code
> to implement new methods.
> But if their class happens to define a method with a name that is
> subsequently used by the Crypto abstract class, there will be a clash
> which will require them to recode.
>
> > Jochen
> >
> >
> > --
> > The next time you hear: "Don't reinvent the wheel!"
> >
> >
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

2016-06-19 Thread Oliver Heger

Build works fine with Java 1.7 on Windows 10. Artifacts and site look
good (there are a number of PMD and findbugs warnings, but I think this
is acceptable).

However, I was not able to build the site locally because of:

[ERROR] Could not find resource
'c:\data\dev\projects\OpenSource\bcel\bcel-6.0-src/findbugs-exclude-filter.xml'.
-> [Help 1]

This file is missing from the source distribution. This prevents me from
voting +1.

Note: I did a rather technical check of the artifacts and cannot judge
if the content is really what the users desire.

Thanks
Oliver

Am 18.06.2016 um 16:54 schrieb Benedikt Ritter:
> Hi,
> 
> more then 10 years have passed since we've released BCEL 5.2. Users are
> waiting for us to release a new version capable of handling Java 6, 7 and 8
> byte code. There have already been 4 release candidates for BCEL 6.0 but
> they have not made it for various reasons. Most importantly BC has been
> broken. Package and Maven coordinates have been changed according to our
> release guidelines. However our users have asked us to provide a binary
> compatible release and here we are...
> 
> I'd like to call a vote for releasing Apache Commons BCEL 6.0 based on RC5.
> 
> BCEL 6.0 RC1 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/bcel (rev 14039)
> 
> The tag is here:
>   https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC5 (rev
> 1749058)
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1177/org/apache/bcel/bcel/6.0/
> 
> These are the Maven artifacts and their hashes:
> 
> bcel-6.0-javadoc.jar
> (SHA1: 79b5fd315f5f949580268e55c0baa85e18df4740)
> bcel-6.0-sources.jar
> (SHA1: f4ab6e682465471084e601c49e03a1385c610343)
> bcel-6.0-test-sources.jar
> (SHA1: 9aabf73fd9680336000f54a29fc234eaf474fc85)
> bcel-6.0-tests.jar
> (SHA1: f34db9121dd7b2dd198754416d29258a96549789)
> bcel-6.0.jar
> (SHA1: e6546a05530e8ed64b07cb917a8dca7912a16404)
> bcel-6.0.pom
> (SHA1: 76c9509859b13c74ff082e489b247708c48e59cb)
> 
> I have tested this with Java 7 and 8 using Maven 3.3.9 on Mac OS 10.11.5.
> 
> Details of changes since 5.2 are in the release notes:
>   https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-NOTES.txt
>   http://home.apache.org/~britter/commons/bcel/6.0-RC5/changes-report.html
> 
> Site:
>   http://home.apache.org/~britter/commons/bcel/6.0-RC5/
> (note some *relative* links are broken and the 6.0 directories are not yet
> created - these will be OK once the site is deployed)
> 
> Clirr Report (compared to 5.2):
>   http://home.apache.org/~britter/commons/bcel/6.0-RC5/clirr-report.html
> 
> Note that Clirr reports several errors. These have been discussed on the ML
> already and I uploaded the site a while ago giving everybody the
> opportunity to raise objections against these changes. These changes are
> also explicitly noted in the Release notes.
> 
> Furthermore java.io.Serializable has been dropped from all BCEL classes. An
> extended Clirr report including this change can be reviewed here:
> 
> http://home.apache.org/~britter/commons/bcel/6.0-RC5/bcel5-bcel6-clirr-report.html
> 
> We don't consider this to be a problem because we don't see a reason for
> users to serialize BCEL classes.
> 
> RAT Report:
> http://home.apache.org/~britter/commons/bcel/6.0-RC5/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. sometime after 17:00 CEST 21-June 2016
> 
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
> 
> Thanks!
> Benedikt
> 

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

Re: Resign from PMC...

2016-06-19 Thread Oliver Heger

James,

Am 19.06.2016 um 01:36 schrieb James Carman:
> I wish to resign from the Apache Commons PMC. Thank you.
> 

sorry to hear this. Would you mind telling us something about your
reasons? - Of course, you don't have to if you don't want.

Regards
Oliver

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

Re: [VOTE] Release Compress 1.12 based on RC2

Hello Stefan,

- checked signs and hashes
- compared archives
- compared tag with src archive
- build with
  Java 6 using Maven 3.2.5
  Java 7 and 8 using Maven 3.3.9

Everything worked fine.

+1

Benedikt

Stefan Bodewig  schrieb am Sa., 18. Juni 2016 um
18:12 Uhr:

> Hi all
>
> as promised I've cut a RC for Compress 1.12.
>
> The Release Candidate is available for review at:
>   https://dist.apache.org/repos/dist/dev/commons/compress/
>   (svn revision 14040)
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1178/org/apache/commons/commons-compress/1.12/
>
> These are the Maven artifacts and their hashes
>
> d4ba952b054eef846e7255cc3ac6d4ca76ead72c  commons-compress-1.12.pom
> 84caa68576e345eb5e7ae61a0e5a9229eb100d7b  commons-compress-1.12.jar
> 3f11c15206fe1658cb09793f551d4777edc3ac99  commons-compress-1.12-javadoc.jar
> 1fdd1a2fed15cdf08780ed564279c0ddbff46419  commons-compress-1.12-sources.jar
> 2e03ca468fbfb7c5b09bd8b626261f4dffc4ffcc  commons-compress-1.12-tests.jar
> 2b970a766b502f15170e75b9bc7cc7d880e53e2d
> commons-compress-1.12-test-sources.jar
>
> Details of changes since 1.11 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt
>   http://stefan.samaflost.de/staging/COMPRESS-1.12/changes-report.html
>
> The tag is here:
>
> https://git-wip-us.apache.org/repos/asf?p=commons-compress.git;a=commit;h=3623ee7dad07c74722baeeffcec6770015f915cf
>
> Site:
>   http://stefan.samaflost.de/staging/COMPRESS-1.12
>
>   as usual when I cut releases this is *not* the site that I'm going to
>   publish after the relase. I'll update changes.xml when I know the
>   release date. Also the javadocs for 1.12 are missing for now (they are
>   identical to the "GIT latest" ones) and the download page doesn't work
>   on my server.
>
> Clirr Report (compared to 1.11):
>   http://stefan.samaflost.de/staging/COMPRESS-1.12/clirr-report.html
>
> RAT Report:
>   http://stefan.samaflost.de/staging/COMPRESS-1.12/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. sometime after 16:00 UTC 21-June 2016
>
>   [ ] +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
>
>

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

Hello Oliver,

Oliver Heger  schrieb am So., 19. Juni 2016
um 17:43 Uhr:

> Build works fine with Java 1.7 on Windows 10. Artifacts and site look
> good (there are a number of PMD and findbugs warnings, but I think this
> is acceptable).
>
> However, I was not able to build the site locally because of:
>
> [ERROR] Could not find resource
>
> 'c:\data\dev\projects\OpenSource\bcel\bcel-6.0-src/findbugs-exclude-filter.xml'.
> -> [Help 1]
>
> This file is missing from the source distribution. This prevents me from
> voting +1.
>
> Note: I did a rather technical check of the artifacts and cannot judge
> if the content is really what the users desire.
>

To make it easier for me to tally up votes in the end, does this mean your
vote is -1?

Benedikt


> Thanks
> Oliver
>
> Am 18.06.2016 um 16:54 schrieb Benedikt Ritter:
> > Hi,
> >
> > more then 10 years have passed since we've released BCEL 5.2. Users are
> > waiting for us to release a new version capable of handling Java 6, 7
> and 8
> > byte code. There have already been 4 release candidates for BCEL 6.0 but
> > they have not made it for various reasons. Most importantly BC has been
> > broken. Package and Maven coordinates have been changed according to our
> > release guidelines. However our users have asked us to provide a binary
> > compatible release and here we are...
> >
> > I'd like to call a vote for releasing Apache Commons BCEL 6.0 based on
> RC5.
> >
> > BCEL 6.0 RC1 is available for review here:
> >   https://dist.apache.org/repos/dist/dev/commons/bcel (rev 14039)
> >
> > The tag is here:
> >   https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC5
> (rev
> > 1749058)
> >
> > Maven artifacts are here:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1177/org/apache/bcel/bcel/6.0/
> >
> > These are the Maven artifacts and their hashes:
> >
> > bcel-6.0-javadoc.jar
> > (SHA1: 79b5fd315f5f949580268e55c0baa85e18df4740)
> > bcel-6.0-sources.jar
> > (SHA1: f4ab6e682465471084e601c49e03a1385c610343)
> > bcel-6.0-test-sources.jar
> > (SHA1: 9aabf73fd9680336000f54a29fc234eaf474fc85)
> > bcel-6.0-tests.jar
> > (SHA1: f34db9121dd7b2dd198754416d29258a96549789)
> > bcel-6.0.jar
> > (SHA1: e6546a05530e8ed64b07cb917a8dca7912a16404)
> > bcel-6.0.pom
> > (SHA1: 76c9509859b13c74ff082e489b247708c48e59cb)
> >
> > I have tested this with Java 7 and 8 using Maven 3.3.9 on Mac OS 10.11.5.
> >
> > Details of changes since 5.2 are in the release notes:
> >   https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-NOTES.txt
> >
> http://home.apache.org/~britter/commons/bcel/6.0-RC5/changes-report.html
> >
> > Site:
> >   http://home.apache.org/~britter/commons/bcel/6.0-RC5/
> > (note some *relative* links are broken and the 6.0 directories are not
> yet
> > created - these will be OK once the site is deployed)
> >
> > Clirr Report (compared to 5.2):
> >   http://home.apache.org/~britter/commons/bcel/6.0-RC5/clirr-report.html
> >
> > Note that Clirr reports several errors. These have been discussed on the
> ML
> > already and I uploaded the site a while ago giving everybody the
> > opportunity to raise objections against these changes. These changes are
> > also explicitly noted in the Release notes.
> >
> > Furthermore java.io.Serializable has been dropped from all BCEL classes.
> An
> > extended Clirr report including this change can be reviewed here:
> >
> >
> http://home.apache.org/~britter/commons/bcel/6.0-RC5/bcel5-bcel6-clirr-report.html
> >
> > We don't consider this to be a problem because we don't see a reason for
> > users to serialize BCEL classes.
> >
> > RAT Report:
> > http://home.apache.org/~britter/commons/bcel/6.0-RC5/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. sometime after 17:00 CEST 21-June 2016
> >
> > [ ] +1 Release these artifacts
> > [ ] +0 OK, but...
> > [ ] -0 OK, but really should fix...
> > [ ] -1 I oppose this release because...
> >
> > Thanks!
> > Benedikt
> >
>
> -
> 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 RC5

2016-06-19 Thread Oliver Heger



Am 19.06.2016 um 17:56 schrieb Benedikt Ritter:
> Hello Oliver,
> 
> Oliver Heger  schrieb am So., 19. Juni 2016
> um 17:43 Uhr:
> 
>> Build works fine with Java 1.7 on Windows 10. Artifacts and site look
>> good (there are a number of PMD and findbugs warnings, but I think this
>> is acceptable).
>>
>> However, I was not able to build the site locally because of:
>>
>> [ERROR] Could not find resource
>>
>> 'c:\data\dev\projects\OpenSource\bcel\bcel-6.0-src/findbugs-exclude-filter.xml'.
>> -> [Help 1]
>>
>> This file is missing from the source distribution. This prevents me from
>> voting +1.
>>
>> Note: I did a rather technical check of the artifacts and cannot judge
>> if the content is really what the users desire.
>>
> 
> To make it easier for me to tally up votes in the end, does this mean your
> vote is -1?

I have an interest to see the release coming out, so it is a -0.

Oliver

> 
> Benedikt
> 
> 
>> Thanks
>> Oliver
>>
>> Am 18.06.2016 um 16:54 schrieb Benedikt Ritter:
>>> Hi,
>>>
>>> more then 10 years have passed since we've released BCEL 5.2. Users are
>>> waiting for us to release a new version capable of handling Java 6, 7
>> and 8
>>> byte code. There have already been 4 release candidates for BCEL 6.0 but
>>> they have not made it for various reasons. Most importantly BC has been
>>> broken. Package and Maven coordinates have been changed according to our
>>> release guidelines. However our users have asked us to provide a binary
>>> compatible release and here we are...
>>>
>>> I'd like to call a vote for releasing Apache Commons BCEL 6.0 based on
>> RC5.
>>>
>>> BCEL 6.0 RC1 is available for review here:
>>>   https://dist.apache.org/repos/dist/dev/commons/bcel (rev 14039)
>>>
>>> The tag is here:
>>>   https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC5
>> (rev
>>> 1749058)
>>>
>>> Maven artifacts are here:
>>>
>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1177/org/apache/bcel/bcel/6.0/
>>>
>>> These are the Maven artifacts and their hashes:
>>>
>>> bcel-6.0-javadoc.jar
>>> (SHA1: 79b5fd315f5f949580268e55c0baa85e18df4740)
>>> bcel-6.0-sources.jar
>>> (SHA1: f4ab6e682465471084e601c49e03a1385c610343)
>>> bcel-6.0-test-sources.jar
>>> (SHA1: 9aabf73fd9680336000f54a29fc234eaf474fc85)
>>> bcel-6.0-tests.jar
>>> (SHA1: f34db9121dd7b2dd198754416d29258a96549789)
>>> bcel-6.0.jar
>>> (SHA1: e6546a05530e8ed64b07cb917a8dca7912a16404)
>>> bcel-6.0.pom
>>> (SHA1: 76c9509859b13c74ff082e489b247708c48e59cb)
>>>
>>> I have tested this with Java 7 and 8 using Maven 3.3.9 on Mac OS 10.11.5.
>>>
>>> Details of changes since 5.2 are in the release notes:
>>>   https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-NOTES.txt
>>>
>> http://home.apache.org/~britter/commons/bcel/6.0-RC5/changes-report.html
>>>
>>> Site:
>>>   http://home.apache.org/~britter/commons/bcel/6.0-RC5/
>>> (note some *relative* links are broken and the 6.0 directories are not
>> yet
>>> created - these will be OK once the site is deployed)
>>>
>>> Clirr Report (compared to 5.2):
>>>   http://home.apache.org/~britter/commons/bcel/6.0-RC5/clirr-report.html
>>>
>>> Note that Clirr reports several errors. These have been discussed on the
>> ML
>>> already and I uploaded the site a while ago giving everybody the
>>> opportunity to raise objections against these changes. These changes are
>>> also explicitly noted in the Release notes.
>>>
>>> Furthermore java.io.Serializable has been dropped from all BCEL classes.
>> An
>>> extended Clirr report including this change can be reviewed here:
>>>
>>>
>> http://home.apache.org/~britter/commons/bcel/6.0-RC5/bcel5-bcel6-clirr-report.html
>>>
>>> We don't consider this to be a problem because we don't see a reason for
>>> users to serialize BCEL classes.
>>>
>>> RAT Report:
>>> http://home.apache.org/~britter/commons/bcel/6.0-RC5/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. sometime after 17:00 CEST 21-June 2016
>>>
>>> [ ] +1 Release these artifacts
>>> [ ] +0 OK, but...
>>> [ ] -0 OK, but really should fix...
>>> [ ] -1 I oppose this release because...
>>>
>>> Thanks!
>>> Benedikt
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
> 

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

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

2016-06-19 Thread Andrey Loskutov

Hi,

Thanks & congratulations to BCEL team!

With this BCEL version all FB regression tests on both Java 8 and Java 9 (as 
runtime) pass. Well done!

If I could vote, I would vote +1.

P.S:
Since we had this weekend also an official ASM 6 alpha release (see 
http://mail.ow2.org/wws/arc/asm/2016-06/msg5.html), I've also updated our 
ASM version and merged FindBugs java9 branch to master now.
I've created 3.1.0 preview2 release for FindBugs, see 
https://github.com/findbugsproject/findbugs/releases/tag/3.1.0_preview2.

On Saturday 18 June 2016 14:54 Benedikt Ritter wrote:
> Hi,
> 
> more then 10 years have passed since we've released BCEL 5.2. Users are
> waiting for us to release a new version capable of handling Java 6, 7 and 8
> byte code. There have already been 4 release candidates for BCEL 6.0 but
> they have not made it for various reasons. Most importantly BC has been
> broken. Package and Maven coordinates have been changed according to our
> release guidelines. However our users have asked us to provide a binary
> compatible release and here we are...
> 
> I'd like to call a vote for releasing Apache Commons BCEL 6.0 based on RC5.
> [...]

-- 
Kind regards,
google.com/+AndreyLoskutov

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

Hello Andrey,

Andrey Loskutov  schrieb am So., 19. Juni 2016 um
18:30 Uhr:

> Hi,
>
> Thanks & congratulations to BCEL team!
>
> With this BCEL version all FB regression tests on both Java 8 and Java 9
> (as runtime) pass. Well done!
>

Thank you!


>
> If I could vote, I would vote +1.
>

You can vote and we appreciate votes from the community. I'll add your +1
when I tally up the votes.

Benedikt


>
> P.S:
> Since we had this weekend also an official ASM 6 alpha release (see
> http://mail.ow2.org/wws/arc/asm/2016-06/msg5.html), I've also updated
> our ASM version and merged FindBugs java9 branch to master now.
> I've created 3.1.0 preview2 release for FindBugs, see
> https://github.com/findbugsproject/findbugs/releases/tag/3.1.0_preview2.
>
> On Saturday 18 June 2016 14:54 Benedikt Ritter wrote:
> > Hi,
> >
> > more then 10 years have passed since we've released BCEL 5.2. Users are
> > waiting for us to release a new version capable of handling Java 6, 7
> and 8
> > byte code. There have already been 4 release candidates for BCEL 6.0 but
> > they have not made it for various reasons. Most importantly BC has been
> > broken. Package and Maven coordinates have been changed according to our
> > release guidelines. However our users have asked us to provide a binary
> > compatible release and here we are...
> >
> > I'd like to call a vote for releasing Apache Commons BCEL 6.0 based on
> RC5.
> > [...]
>
> --
> Kind regards,
> google.com/+AndreyLoskutov
>

Re: [ALL] Volunteers for a Math IPMC?

2016-06-19 Thread Jörg Schaible

Hi Gilles,

Gilles wrote:

> On Sun, 19 Jun 2016 01:55:12 +0200, Jörg Schaible wrote:
>> Hi Gilles,
>>
>>
>> Gilles wrote:
>>
>>> On Sat, 18 Jun 2016 11:00:34 -0700, Ted Dunning wrote:
 On Sat, Jun 18, 2016 at 4:29 AM, Gilles
>>
>> [snip]
>>
 You can never go home. No project stays the same.
>>>
>>> Well, some people in CM for years did their best to avoid change.
>>> I didn't like that view and argue with them because they were
>>> important contributors to CM.
>>>
>>> I still have to argue, but now with non-contributors.
>>> *This* makes no sense.
>>
>> [snip]
>>
 This was your assertion in the long email thread. It seemed that
 there was
 significant counter-positions.
>>>
>>> By non-contributors, using arguments that do not fit the CM history.
>>
>>
>> Since this is now the second time in two weeks that you indirectly
>> state
>> that I should keep my mouth, I simply refer here a mail of Phil in
>> January
>> 2015 on the PMC list about the "PMC member responsibilities".
>>
>> As such a Commons PMC member you are responsible for *all* of the
>> components, all its users and the health of the ecosystem these
>> components
>> live.
> 
> This is a pretext.
> 
> Don't pretend that you don't know how unrealistic it is to expect that
> anyone will be able to care for all the components.


It *not* unrealistic. But it seems that we have a totally different view of 
what it means to "care". It you pretend "care" as support any of the 
components into detail, then you're right. But as said before, nobody 
expects that.


> You didn't move when the situation required it (when I explicitly asked
> for the PMC to intervene), so please don't try to teach me a lesson
> now!


I do this as long as you disqualify other views based on contributions and 
therefore disrespecting the role of the Commons PMC. And I let it 
uncommented the first time.


>> You seem to care currently for 20% of the code of one component only
>> ignoring any impact on the ecosystem your action with the other 80%
>> may
>> have.
> 
> I'm fed up with the smearing.
> 
> My "action" has ZERO impact on Commons Math.
> It is dead because people (who wanted it to be what it is) have left.
> 
> "Commons Math" will stay 100% clean of any interaction with me.


You mean, there's suddenly no CM 4.0? Now I am confused.


> I advocated for a reboot of the codebase, with the long-term goal to
> provide a sustainable service to a community of users potentially
> interested in a (modern) Java scientific library.
> 
> Of course, I'm not going to veto people who'd like to commit fixes
> in the "3.x" line.  I repeated that several times now.
> However, have I the right to not want to do it myself?


Absolutely. Again, nobody expects from you that you bug fix code you're not 
interested in.


> I'm OK to go through the incubator to do that; but I don't see
> that
> it
> is an easier path.  Surely it looks longer.  And it seems that
> even
> the
> incubator people doubt that it will lead anywhere.
>

 The incubator is for building community and adapting to Apache. If
 you
 don't have a seed community, then incubator is the wrong place. You
 need to
 have more than just you.
>>>
>>> That's fair, but there are a few others; that was mentioned.
>>
>>
>> Right. And therefore incubation is a good way to build an own
>> community for
>> this one component only (although it is big).
> 
> Ted Dunning said that this is not a job for the Incubator, because the
> problem is not the missing community.  It is the Commons PMC not
> willing
> to let go of the code.


Well, he had now two votes for Math TLP. Actually I don't know either, why 
it does not proceed. Main concern seems to that the community is currently 
still too small. But see Niall's response. At least the TLP will give you a 
chance to reboot the code base completely.

[snip]


>> Just because the way *you* like to act with CM is no option for a
>> Commons
>> component.
> 
> No, because of the way *you* acted in response to my wish to work
> on what I deem feasible.


And again, I am not the only one here who has no problem with releasing 
again already released code independently if someone can currently support 
it (they way you define "support") or if it has know bugs. It's just that 
you refuse to act with such a handicap.


> And you didn't come up with something
> better than "let's wait and see", which is not an option anymore
> (because I've *already* done that, for 6 months, and saw that it
> didn't work).


I would not say that, it is just now that this topic has attention. And new 
people stepped up now.


- Jörg


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

Hello Oliver,

Oliver Heger  schrieb am So., 19. Juni 2016
um 18:00 Uhr:

>
>
> Am 19.06.2016 um 17:56 schrieb Benedikt Ritter:
> > Hello Oliver,
> >
> > Oliver Heger  schrieb am So., 19. Juni
> 2016
> > um 17:43 Uhr:
> >
> >> Build works fine with Java 1.7 on Windows 10. Artifacts and site look
> >> good (there are a number of PMD and findbugs warnings, but I think this
> >> is acceptable).
> >>
> >> However, I was not able to build the site locally because of:
> >>
> >> [ERROR] Could not find resource
> >>
> >>
> 'c:\data\dev\projects\OpenSource\bcel\bcel-6.0-src/findbugs-exclude-filter.xml'.
> >> -> [Help 1]
> >>
> >> This file is missing from the source distribution. This prevents me from
> >> voting +1.
> >>
> >> Note: I did a rather technical check of the artifacts and cannot judge
> >> if the content is really what the users desire.
> >>
> >
> > To make it easier for me to tally up votes in the end, does this mean
> your
> > vote is -1?
>
> I have an interest to see the release coming out, so it is a -0.
>

Thank you for the clarification.

We release sources, not websites. For this reason I do not consider this
blocking. I have fixed the problem in rev 1749187 [1]. So if there is
another RC it will be fixed. Let's see what others think.

Benedikt

[1] http://svn.apache.org/viewvc?rev=1749187&view=rev


>
> Oliver
>
> >
> > Benedikt
> >
> >
> >> Thanks
> >> Oliver
> >>
> >> Am 18.06.2016 um 16:54 schrieb Benedikt Ritter:
> >>> Hi,
> >>>
> >>> more then 10 years have passed since we've released BCEL 5.2. Users are
> >>> waiting for us to release a new version capable of handling Java 6, 7
> >> and 8
> >>> byte code. There have already been 4 release candidates for BCEL 6.0
> but
> >>> they have not made it for various reasons. Most importantly BC has been
> >>> broken. Package and Maven coordinates have been changed according to
> our
> >>> release guidelines. However our users have asked us to provide a binary
> >>> compatible release and here we are...
> >>>
> >>> I'd like to call a vote for releasing Apache Commons BCEL 6.0 based on
> >> RC5.
> >>>
> >>> BCEL 6.0 RC1 is available for review here:
> >>>   https://dist.apache.org/repos/dist/dev/commons/bcel (rev 14039)
> >>>
> >>> The tag is here:
> >>>
> https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC5
> >> (rev
> >>> 1749058)
> >>>
> >>> Maven artifacts are here:
> >>>
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1177/org/apache/bcel/bcel/6.0/
> >>>
> >>> These are the Maven artifacts and their hashes:
> >>>
> >>> bcel-6.0-javadoc.jar
> >>> (SHA1: 79b5fd315f5f949580268e55c0baa85e18df4740)
> >>> bcel-6.0-sources.jar
> >>> (SHA1: f4ab6e682465471084e601c49e03a1385c610343)
> >>> bcel-6.0-test-sources.jar
> >>> (SHA1: 9aabf73fd9680336000f54a29fc234eaf474fc85)
> >>> bcel-6.0-tests.jar
> >>> (SHA1: f34db9121dd7b2dd198754416d29258a96549789)
> >>> bcel-6.0.jar
> >>> (SHA1: e6546a05530e8ed64b07cb917a8dca7912a16404)
> >>> bcel-6.0.pom
> >>> (SHA1: 76c9509859b13c74ff082e489b247708c48e59cb)
> >>>
> >>> I have tested this with Java 7 and 8 using Maven 3.3.9 on Mac OS
> 10.11.5.
> >>>
> >>> Details of changes since 5.2 are in the release notes:
> >>>
> https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-NOTES.txt
> >>>
> >>
> http://home.apache.org/~britter/commons/bcel/6.0-RC5/changes-report.html
> >>>
> >>> Site:
> >>>   http://home.apache.org/~britter/commons/bcel/6.0-RC5/
> >>> (note some *relative* links are broken and the 6.0 directories are not
> >> yet
> >>> created - these will be OK once the site is deployed)
> >>>
> >>> Clirr Report (compared to 5.2):
> >>>
> http://home.apache.org/~britter/commons/bcel/6.0-RC5/clirr-report.html
> >>>
> >>> Note that Clirr reports several errors. These have been discussed on
> the
> >> ML
> >>> already and I uploaded the site a while ago giving everybody the
> >>> opportunity to raise objections against these changes. These changes
> are
> >>> also explicitly noted in the Release notes.
> >>>
> >>> Furthermore java.io.Serializable has been dropped from all BCEL
> classes.
> >> An
> >>> extended Clirr report including this change can be reviewed here:
> >>>
> >>>
> >>
> http://home.apache.org/~britter/commons/bcel/6.0-RC5/bcel5-bcel6-clirr-report.html
> >>>
> >>> We don't consider this to be a problem because we don't see a reason
> for
> >>> users to serialize BCEL classes.
> >>>
> >>> RAT Report:
> >>>
> http://home.apache.org/~britter/commons/bcel/6.0-RC5/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. sometime after 17:00 CEST 21-June 2016
> >>>
> >>> [ ] +1 Release these artifacts
> >>> [ ] +0 OK, but...
> >>> [ ] -0 OK, but really should fix...
> >>> [ ] -1 I oppose this release because...
> >>>
> >>> Thanks!
> >>> Benedikt
> >>>
> >>
> >> ---

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

2016-06-19 Thread Dave Brosius

Am 18.06.2016 um 16:54 schrieb Benedikt Ritter:

Hi,

more then 10 years have passed since we've released BCEL 5.2. Users are
waiting for us to release a new version capable of handling Java 6, 7 and 8
byte code. There have already been 4 release candidates for BCEL 6.0 but
they have not made it for various reasons. Most importantly BC has been
broken. Package and Maven coordinates have been changed according to our
release guidelines. However our users have asked us to provide a binary
compatible release and here we are...

I'd like to call a vote for releasing Apache Commons BCEL 6.0 based on RC5.

BCEL 6.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/bcel (rev 14039)

The tag is here:
https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC5 (rev
1749058)

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1177/org/apache/bcel/bcel/6.0/

These are the Maven artifacts and their hashes:

bcel-6.0-javadoc.jar
(SHA1: 79b5fd315f5f949580268e55c0baa85e18df4740)
bcel-6.0-sources.jar
(SHA1: f4ab6e682465471084e601c49e03a1385c610343)
bcel-6.0-test-sources.jar
(SHA1: 9aabf73fd9680336000f54a29fc234eaf474fc85)
bcel-6.0-tests.jar
(SHA1: f34db9121dd7b2dd198754416d29258a96549789)
bcel-6.0.jar
(SHA1: e6546a05530e8ed64b07cb917a8dca7912a16404)
bcel-6.0.pom
(SHA1: 76c9509859b13c74ff082e489b247708c48e59cb)

I have tested this with Java 7 and 8 using Maven 3.3.9 on Mac OS 10.11.5.

Details of changes since 5.2 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-NOTES.txt
http://home.apache.org/~britter/commons/bcel/6.0-RC5/changes-report.html

Site:
http://home.apache.org/~britter/commons/bcel/6.0-RC5/
(note some *relative* links are broken and the 6.0 directories are not yet
created - these will be OK once the site is deployed)

Clirr Report (compared to 5.2):
http://home.apache.org/~britter/commons/bcel/6.0-RC5/clirr-report.html

Note that Clirr reports several errors. These have been discussed on the ML
already and I uploaded the site a while ago giving everybody the
opportunity to raise objections against these changes. These changes are
also explicitly noted in the Release notes.

Furthermore java.io.Serializable has been dropped from all BCEL classes. An
extended Clirr report including this change can be reviewed here:

http://home.apache.org/~britter/commons/bcel/6.0-RC5/bcel5-bcel6-clirr-report.html

We don't consider this to be a problem because we don't see a reason for
users to serialize BCEL classes.

RAT Report:
http://home.apache.org/~britter/commons/bcel/6.0-RC5/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. sometime after 17:00 CEST 21-June 2016

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

Thanks!
Benedikt

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

Re: Resign from PMC...

2016-06-19 Thread Ralph Goers

I am not sure if Gary saw this since it wasn’t sent to the PMC list.

Ralph

> On Jun 19, 2016, at 8:53 AM, Oliver Heger  
> wrote:
> 
> James,
> 
> Am 19.06.2016 um 01:36 schrieb James Carman:
>> I wish to resign from the Apache Commons PMC. Thank you.
>> 
> 
> sorry to hear this. Would you mind telling us something about your
> reasons? - Of course, you don't have to if you don't want.
> 
> Regards
> Oliver
> 
> -
> 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: apache, commons, math

2016-06-19 Thread Jörg Schaible

Hi Ralph,

Ralph Goers wrote:

> Thanks, Eric.
> 
> I am OK with Commons Math being split into modules in the Commons Math
> sub-project.

That was my first idea too. But if the collection of all submodules will in 
the end nevertheless only contain 20% of the code, we gained nothing.

> I am not OK with Commons Math A, Commons Math B, etc existing
> within Commons. In other words, when a user traverses to Commons Math they
> can then see the modules that make up Commons Math.

The main problem seems to be that CM was a dumping ground for all kind of 
stuff that have at least the slightest relation to a mathematical base.

Gilles never expressed it directly, but in its consequence he proposed to 
move the current CM into dormant/attic and extract single parts of the old 
code base as new components.

Some of those components can be:
- Commons RNG (Random Number Generators)
- Commons Complex (Complex Numbers)
- Commons Matrix (Matrix Algebra)

Those components might have an own life, those algorithms have a wide 
audience and can be used in a lot of stuff on its own. The question is what 
happens with:
- Commons Genetics (Genetic Algorithms)
- Commons ML (Machine Learning)

Or other stuff requiring deep mathematical background. I don't have the 
impression this belongs as own components into Commons. Moving CM as whole 
into a new TLP at least provides a place for all of it.

The question is, what do we want as PMC members?

> I am also OK with code being mothballed if no one knows what it does, how
> it works, why it exists or who may want to use it.  I am not OK with
> retiring code just because a single person doesn’t know what it does or
> how to maintain it.  In other words, I am looking for people like you to
> volunteer to be part of the community that decides what should stay and
> what should go.

And this does not require that the code base is separated now before the 
decisions are made.

> IMO, that community needs to be of sufficient size that it
> is somewhat representative of the users of Commons Math. That doesn’t mean
> it necessarily needs 10 people, but I would say it needs more than 2.

Otherwise a TLP will never be accepted.

> The side effect of this, is that once you have a community that can start
> making these kinds of decisions you can also make a proposal to go to the
> incubator or become a TLP (there is really no reason a project can’t
> “incubate” here in Commons).

+1

Thanks for your thoughts, Eric + Ralph!

- Jörg

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

RE: [CRYPTO] Defining the public API; are its interfaces supposed to be implemented or just used?

2016-06-19 Thread Dennis E. Hamilton

Being keen about API architectures ...

> -Original Message-
> From: Benedikt Ritter [mailto:brit...@apache.org]
> Sent: Sunday, June 19, 2016 07:08
> To: Commons Developers List 
> Subject: Re: [CRYPTO] Defining the public API; are its interfaces
> supposed to be implemented or just used?
> 
> My unterstanding of crypto is that those interfaces are not to be
> implemented by Clients.
> 
> sebb  schrieb am So., 19. Juni 2016 um 14:02:
> 
[ ... ]
> > Users deriving from an abstract base class do not have to change code
> > to implement new methods.
> > But if their class happens to define a method with a name that is
> > subsequently used by the Crypto abstract class, there will be a clash
> > which will require them to recode.
[orcmid] 

It is my understanding that this difficulty is one that Interfaces can be used 
to overcome.

It also does not compel all implementations being off the same [abstract] base 
class.

 - Dennis
> >
> > > Jochen
> > >
> > >
> > > --
> > > The next time you hear: "Don't reinvent the wheel!"
> > >
> > >
> > http://www.keystonedevelopment.co.uk/wp-
> content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> > >
> > > 
> -
> > > 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: apache, commons, math

2016-06-19 Thread Gilles


On Sun, 19 Jun 2016 19:40:34 +0200, Jörg Schaible wrote:

Hi Ralph,

Ralph Goers wrote:


Thanks, Eric.

I am OK with Commons Math being split into modules in the Commons 
Math

sub-project.



That was my first idea too. But if the collection of all submodules 
will in

the end nevertheless only contain 20% of the code, we gained nothing.



I am not OK with Commons Math A, Commons Math B, etc existing
within Commons. In other words, when a user traverses to Commons 
Math they

can then see the modules that make up Commons Math.



The main problem seems to be that CM was a dumping ground for all 
kind of
stuff that have at least the slightest relation to a mathematical 
base.


Gilles never expressed it directly, but in its consequence he 
proposed to
move the current CM into dormant/attic and extract single parts of 
the old

code base as new components.


Really?

I have a hard time figuring out what could have been more direct than
the initial post of that thread:
  http://markmail.org/message/ye6wvqvlvnqe4qrp



Some of those components can be:
- Commons RNG (Random Number Generators)
- Commons Complex (Complex Numbers)
- Commons Matrix (Matrix Algebra)

Those components might have an own life, those algorithms have a wide
audience and can be used in a lot of stuff on its own. The question 
is what

happens with:
- Commons Genetics (Genetic Algorithms)
- Commons ML (Machine Learning)

Or other stuff requiring deep mathematical background. I don't have 
the
impression this belongs as own components into Commons. Moving CM as 
whole

into a new TLP at least provides a place for all of it.

The question is, what do we want as PMC members?


I am also OK with code being mothballed if no one knows what it 
does, how

it works, why it exists or who may want to use it.  I am not OK with
retiring code just because a single person doesn’t know what it does 
or
how to maintain it.  In other words, I am looking for people like 
you to
volunteer to be part of the community that decides what should stay 
and

what should go.



And this does not require that the code base is separated now before 
the

decisions are made.



IMO, that community needs to be of sufficient size that it
is somewhat representative of the users of Commons Math. That 
doesn’t mean
it necessarily needs 10 people, but I would say it needs more than 
2.



Otherwise a TLP will never be accepted.


The side effect of this, is that once you have a community that can 
start
making these kinds of decisions you can also make a proposal to go 
to the

incubator or become a TLP (there is really no reason a project can’t
“incubate” here in Commons).



+1

Thanks for your thoughts, Eric + Ralph!

- Jörg


-
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: apache, commons, math

2016-06-19 Thread Ralph Goers


> On Jun 19, 2016, at 10:40 AM, Jörg Schaible  wrote:
> 
> Hi Ralph,
> 
> Ralph Goers wrote:
> 
>> Thanks, Eric.
>> 
>> I am OK with Commons Math being split into modules in the Commons Math
>> sub-project.
> 
> 
> That was my first idea too. But if the collection of all submodules will in 
> the end nevertheless only contain 20% of the code, we gained nothing.
> 
> 
>> I am not OK with Commons Math A, Commons Math B, etc existing
>> within Commons. In other words, when a user traverses to Commons Math they
>> can then see the modules that make up Commons Math.
> 
> 
> The main problem seems to be that CM was a dumping ground for all kind of 
> stuff that have at least the slightest relation to a mathematical base.
> 
> Gilles never expressed it directly, but in its consequence he proposed to 
> move the current CM into dormant/attic and extract single parts of the old 
> code base as new components.

Personally, I don’t think moving it to the attic is appropriate. Projects go to 
the attic, not components.  The Math project (or sub-project) is free to add or 
drop components as the see fit, so long as it is a community decision.

> 
> Some of those components can be:
> - Commons RNG (Random Number Generators)
> - Commons Complex (Complex Numbers)
> - Commons Matrix (Matrix Algebra)
> 
> Those components might have an own life, those algorithms have a wide 
> audience and can be used in a lot of stuff on its own. The question is what 
> happens with:
> - Commons Genetics (Genetic Algorithms)
> - Commons ML (Machine Learning)

If there is a case to be made to move components out of Commons Math to become 
individual Commons components then those proposals should be made individually 
so the merits can be discussed. For example, just by its name I am not sure why 
Machine Learning belongs in Math unless it really is just a bunch of machine 
learning algorithms. 


> 
> Or other stuff requiring deep mathematical background. I don't have the 
> impression this belongs as own components into Commons. Moving CM as whole 
> into a new TLP at least provides a place for all of it.
> 
> The question is, what do we want as PMC members?

I’m not sure I understand the question. Once there are enough active committers 
then I would think they would become Math TLP PMC members when it is 
appropriate.

Ralph



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

Re: Resign from PMC...

Yep, I'm here. Father's day, preping a work demo for tomorrow... I'll
follow up.

Gary

On Sun, Jun 19, 2016 at 10:39 AM, Ralph Goers 
wrote:

> I am not sure if Gary saw this since it wasn’t sent to the PMC list.
>
> Ralph
>
> > On Jun 19, 2016, at 8:53 AM, Oliver Heger 
> wrote:
> >
> > James,
> >
> > Am 19.06.2016 um 01:36 schrieb James Carman:
> >> I wish to resign from the Apache Commons PMC. Thank you.
> >>
> >
> > sorry to hear this. Would you mind telling us something about your
> > reasons? - Of course, you don't have to if you don't want.
> >
> > Regards
> > Oliver
> >
> > -
> > 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
>
>


-- 
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: Resign from PMC...

ACK. Per https://www.apache.org/dev/pmc.html#emeritus, James has 72 hours
to withdraw his resignation before I process it.

Gary

On Sat, Jun 18, 2016 at 4:36 PM, James Carman 
wrote:

> I wish to resign from the Apache Commons PMC. Thank you.
>

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

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

On Sun, Jun 19, 2016 at 10:28 AM, Benedikt Ritter 
wrote:

> Hello Oliver,
>
> Oliver Heger  schrieb am So., 19. Juni 2016
> um 18:00 Uhr:
>
> >
> >
> > Am 19.06.2016 um 17:56 schrieb Benedikt Ritter:
> > > Hello Oliver,
> > >
> > > Oliver Heger  schrieb am So., 19. Juni
> > 2016
> > > um 17:43 Uhr:
> > >
> > >> Build works fine with Java 1.7 on Windows 10. Artifacts and site look
> > >> good (there are a number of PMD and findbugs warnings, but I think
> this
> > >> is acceptable).
> > >>
> > >> However, I was not able to build the site locally because of:
> > >>
> > >> [ERROR] Could not find resource
> > >>
> > >>
> >
> 'c:\data\dev\projects\OpenSource\bcel\bcel-6.0-src/findbugs-exclude-filter.xml'.
> > >> -> [Help 1]
> > >>
> > >> This file is missing from the source distribution. This prevents me
> from
> > >> voting +1.
> > >>
> > >> Note: I did a rather technical check of the artifacts and cannot judge
> > >> if the content is really what the users desire.
> > >>
> > >
> > > To make it easier for me to tally up votes in the end, does this mean
> > your
> > > vote is -1?
> >
> > I have an interest to see the release coming out, so it is a -0.
> >
>
> Thank you for the clarification.
>
> We release sources, not websites.


[X] +0 OK, but... IMO I should be able everything from sources. If the
website has bugs in it that would be one thing, but you cannot even built
it. This is a problem I claim for use cases like, I download the sources
and I want to create a patch. I would want to use the site to see the
result of the whole thing I did, reports and all, and for that I would rely
on the site to see it all.

Gary


> For this reason I do not consider this
> blocking. I have fixed the problem in rev 1749187 [1]. So if there is
> another RC it will be fixed. Let's see what others think.
>
> Benedikt
>
> [1] http://svn.apache.org/viewvc?rev=1749187&view=rev
>
>
> >
> > Oliver
> >
> > >
> > > Benedikt
> > >
> > >
> > >> Thanks
> > >> Oliver
> > >>
> > >> Am 18.06.2016 um 16:54 schrieb Benedikt Ritter:
> > >>> Hi,
> > >>>
> > >>> more then 10 years have passed since we've released BCEL 5.2. Users
> are
> > >>> waiting for us to release a new version capable of handling Java 6, 7
> > >> and 8
> > >>> byte code. There have already been 4 release candidates for BCEL 6.0
> > but
> > >>> they have not made it for various reasons. Most importantly BC has
> been
> > >>> broken. Package and Maven coordinates have been changed according to
> > our
> > >>> release guidelines. However our users have asked us to provide a
> binary
> > >>> compatible release and here we are...
> > >>>
> > >>> I'd like to call a vote for releasing Apache Commons BCEL 6.0 based
> on
> > >> RC5.
> > >>>
> > >>> BCEL 6.0 RC1 is available for review here:
> > >>>   https://dist.apache.org/repos/dist/dev/commons/bcel (rev 14039)
> > >>>
> > >>> The tag is here:
> > >>>
> > https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC5
> > >> (rev
> > >>> 1749058)
> > >>>
> > >>> Maven artifacts are here:
> > >>>
> > >>>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1177/org/apache/bcel/bcel/6.0/
> > >>>
> > >>> These are the Maven artifacts and their hashes:
> > >>>
> > >>> bcel-6.0-javadoc.jar
> > >>> (SHA1: 79b5fd315f5f949580268e55c0baa85e18df4740)
> > >>> bcel-6.0-sources.jar
> > >>> (SHA1: f4ab6e682465471084e601c49e03a1385c610343)
> > >>> bcel-6.0-test-sources.jar
> > >>> (SHA1: 9aabf73fd9680336000f54a29fc234eaf474fc85)
> > >>> bcel-6.0-tests.jar
> > >>> (SHA1: f34db9121dd7b2dd198754416d29258a96549789)
> > >>> bcel-6.0.jar
> > >>> (SHA1: e6546a05530e8ed64b07cb917a8dca7912a16404)
> > >>> bcel-6.0.pom
> > >>> (SHA1: 76c9509859b13c74ff082e489b247708c48e59cb)
> > >>>
> > >>> I have tested this with Java 7 and 8 using Maven 3.3.9 on Mac OS
> > 10.11.5.
> > >>>
> > >>> Details of changes since 5.2 are in the release notes:
> > >>>
> > https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-NOTES.txt
> > >>>
> > >>
> > http://home.apache.org/~britter/commons/bcel/6.0-RC5/changes-report.html
> > >>>
> > >>> Site:
> > >>>   http://home.apache.org/~britter/commons/bcel/6.0-RC5/
> > >>> (note some *relative* links are broken and the 6.0 directories are
> not
> > >> yet
> > >>> created - these will be OK once the site is deployed)
> > >>>
> > >>> Clirr Report (compared to 5.2):
> > >>>
> > http://home.apache.org/~britter/commons/bcel/6.0-RC5/clirr-report.html
> > >>>
> > >>> Note that Clirr reports several errors. These have been discussed on
> > the
> > >> ML
> > >>> already and I uploaded the site a while ago giving everybody the
> > >>> opportunity to raise objections against these changes. These changes
> > are
> > >>> also explicitly noted in the Release notes.
> > >>>
> > >>> Furthermore java.io.Serializable has been dropped from all BCEL
> > classes.
> > >> An
> > >>> extended Clirr report including this change can be reviewed here:
> > >>>
> > >>>
> > >>
> >
> http://home.apache.org/~britter/commo

Jenkins build is back to stable : commons-jcs » Apache Commons JCS :: Core #160

2016-06-19 Thread Apache Jenkins Server

See 



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

Jenkins build is back to stable : commons-jcs #160

2016-06-19 Thread Apache Jenkins Server

See 


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

Re: [VOTE] Release Compress 1.12 based on RC2

Release notes typo: "Commons Compress 1.12 is the first version to require
Java6 at runtime."

"Java6" -> "Java 6"

TODO:
On file:///E:/temp/rc/commons-compress-1.12-src/target/site/limitations.html,
you should remove the section on limitation for "Z". The "7Z" section also
talks about old versions of Commons Compress and XZ, not sure that is
needed.

Tested from src zip: MD5, SHA1, SHA512, ASC OK.

Reports OK.

+1

Tested 'mvn clean site'  with:

Apache Maven 3.4.0-SNAPSHOT (644ac9c40ad41bf61e3b099918af33b8eb950621;
2016-06-11T12:17:57-07:00)
Maven home: E:\Java\apache-maven-3.4.0-SNAPSHOT\bin\..
Java version: 1.7.0_79, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_79\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "Windows 7", version: "6.1", arch: "amd64", family: "Windows"

Gary

On Sat, Jun 18, 2016 at 9:12 AM, Stefan Bodewig  wrote:

> Hi all
>
> as promised I've cut a RC for Compress 1.12.
>
> The Release Candidate is available for review at:
>   https://dist.apache.org/repos/dist/dev/commons/compress/
>   (svn revision 14040)
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1178/org/apache/commons/commons-compress/1.12/
>
> These are the Maven artifacts and their hashes
>
> d4ba952b054eef846e7255cc3ac6d4ca76ead72c  commons-compress-1.12.pom
> 84caa68576e345eb5e7ae61a0e5a9229eb100d7b  commons-compress-1.12.jar
> 3f11c15206fe1658cb09793f551d4777edc3ac99  commons-compress-1.12-javadoc.jar
> 1fdd1a2fed15cdf08780ed564279c0ddbff46419  commons-compress-1.12-sources.jar
> 2e03ca468fbfb7c5b09bd8b626261f4dffc4ffcc  commons-compress-1.12-tests.jar
> 2b970a766b502f15170e75b9bc7cc7d880e53e2d
> commons-compress-1.12-test-sources.jar
>
> Details of changes since 1.11 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt
>   http://stefan.samaflost.de/staging/COMPRESS-1.12/changes-report.html
>
> The tag is here:
>
> https://git-wip-us.apache.org/repos/asf?p=commons-compress.git;a=commit;h=3623ee7dad07c74722baeeffcec6770015f915cf
>
> Site:
>   http://stefan.samaflost.de/staging/COMPRESS-1.12
>
>   as usual when I cut releases this is *not* the site that I'm going to
>   publish after the relase. I'll update changes.xml when I know the
>   release date. Also the javadocs for 1.12 are missing for now (they are
>   identical to the "GIT latest" ones) and the download page doesn't work
>   on my server.
>
> Clirr Report (compared to 1.11):
>   http://stefan.samaflost.de/staging/COMPRESS-1.12/clirr-report.html
>
> RAT Report:
>   http://stefan.samaflost.de/staging/COMPRESS-1.12/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. sometime after 16:00 UTC 21-June 2016
>
>   [ ] +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

[CANCEL][VOTE] Release Apache Commons BCEL 6.0 based on RC5

Hi,

this vote is canceled because of problems with the build. The RC can not be
build from the source archive and this is blocker. The necessary fixes have
already been applied to trunk, so I'm planning to create RC6 tomorrow.

Thank you for reviewing!
Benedikt

Benedikt Ritter  schrieb am Sa., 18. Juni 2016 um 16:54:

> Hi,
>
> more then 10 years have passed since we've released BCEL 5.2. Users are
> waiting for us to release a new version capable of handling Java 6, 7 and 8
> byte code. There have already been 4 release candidates for BCEL 6.0 but
> they have not made it for various reasons. Most importantly BC has been
> broken. Package and Maven coordinates have been changed according to our
> release guidelines. However our users have asked us to provide a binary
> compatible release and here we are...
>
> I'd like to call a vote for releasing Apache Commons BCEL 6.0 based on RC5.
>
> BCEL 6.0 RC1 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/bcel (rev 14039)
>
> The tag is here:
>   https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC5 (rev
> 1749058)
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1177/org/apache/bcel/bcel/6.0/
>
> These are the Maven artifacts and their hashes:
>
> bcel-6.0-javadoc.jar
> (SHA1: 79b5fd315f5f949580268e55c0baa85e18df4740)
> bcel-6.0-sources.jar
> (SHA1: f4ab6e682465471084e601c49e03a1385c610343)
> bcel-6.0-test-sources.jar
> (SHA1: 9aabf73fd9680336000f54a29fc234eaf474fc85)
> bcel-6.0-tests.jar
> (SHA1: f34db9121dd7b2dd198754416d29258a96549789)
> bcel-6.0.jar
> (SHA1: e6546a05530e8ed64b07cb917a8dca7912a16404)
> bcel-6.0.pom
> (SHA1: 76c9509859b13c74ff082e489b247708c48e59cb)
>
> I have tested this with Java 7 and 8 using Maven 3.3.9 on Mac OS 10.11.5.
>
> Details of changes since 5.2 are in the release notes:
>   https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-NOTES.txt
>   http://home.apache.org/~britter/commons/bcel/6.0-RC5/changes-report.html
>
> Site:
>   http://home.apache.org/~britter/commons/bcel/6.0-RC5/
> (note some *relative* links are broken and the 6.0 directories are not yet
> created - these will be OK once the site is deployed)
>
> Clirr Report (compared to 5.2):
>   http://home.apache.org/~britter/commons/bcel/6.0-RC5/clirr-report.html
>
> Note that Clirr reports several errors. These have been discussed on the
> ML already and I uploaded the site a while ago giving everybody the
> opportunity to raise objections against these changes. These changes are
> also explicitly noted in the Release notes.
>
> Furthermore java.io.Serializable has been dropped from all BCEL classes.
> An extended Clirr report including this change can be reviewed here:
>
> http://home.apache.org/~britter/commons/bcel/6.0-RC5/bcel5-bcel6-clirr-report.html
>
> We don't consider this to be a problem because we don't see a reason for
> users to serialize BCEL classes.
>
> RAT Report:
> http://home.apache.org/~britter/commons/bcel/6.0-RC5/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. sometime after 17:00 CEST 21-June 2016
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thanks!
> Benedikt
>

Re: [JCS] Failing Tests in JCS Core

Now it's working again 8-)

Romain Manni-Bucau  schrieb am So., 19. Juni 2016 um
10:57:

> Can check tomorrow but can it be the ip which is not localhost or ipv4?
> Le 19 juin 2016 10:47, "Benedikt Ritter"  a écrit :
>
> > Hi,
> >
> > we have failing tests on Jenkins for JCS [1]. Does anybody know what
> caused
> > this?
> >
> > Regards,
> > Benedikt
> >
> > [1]
> >
> >
> https://builds.apache.org/view/Apache%20Commons/job/commons-jcs/159/org.apache.commons$commons-jcs-core/console
> >
>

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

On Sun, Jun 19, 2016 at 1:42 PM, Benedikt Ritter  wrote:

> Hi,
>
> this vote is canceled because of problems with the build. The RC can not be
> build from the source archive and this is blocker. The necessary fixes have
> already been applied to trunk, so I'm planning to create RC6 tomorrow.
>

Awesome, thank you for preparing this RC and the upcoming one!

Gary


>
> Thank you for reviewing!

Benedikt
>
> Benedikt Ritter  schrieb am Sa., 18. Juni 2016 um
> 16:54:
>
> > Hi,
> >
> > more then 10 years have passed since we've released BCEL 5.2. Users are
> > waiting for us to release a new version capable of handling Java 6, 7
> and 8
> > byte code. There have already been 4 release candidates for BCEL 6.0 but
> > they have not made it for various reasons. Most importantly BC has been
> > broken. Package and Maven coordinates have been changed according to our
> > release guidelines. However our users have asked us to provide a binary
> > compatible release and here we are...
> >
> > I'd like to call a vote for releasing Apache Commons BCEL 6.0 based on
> RC5.
> >
> > BCEL 6.0 RC1 is available for review here:
> >   https://dist.apache.org/repos/dist/dev/commons/bcel (rev 14039)
> >
> > The tag is here:
> >   https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC5
> (rev
> > 1749058)
> >
> > Maven artifacts are here:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1177/org/apache/bcel/bcel/6.0/
> >
> > These are the Maven artifacts and their hashes:
> >
> > bcel-6.0-javadoc.jar
> > (SHA1: 79b5fd315f5f949580268e55c0baa85e18df4740)
> > bcel-6.0-sources.jar
> > (SHA1: f4ab6e682465471084e601c49e03a1385c610343)
> > bcel-6.0-test-sources.jar
> > (SHA1: 9aabf73fd9680336000f54a29fc234eaf474fc85)
> > bcel-6.0-tests.jar
> > (SHA1: f34db9121dd7b2dd198754416d29258a96549789)
> > bcel-6.0.jar
> > (SHA1: e6546a05530e8ed64b07cb917a8dca7912a16404)
> > bcel-6.0.pom
> > (SHA1: 76c9509859b13c74ff082e489b247708c48e59cb)
> >
> > I have tested this with Java 7 and 8 using Maven 3.3.9 on Mac OS 10.11.5.
> >
> > Details of changes since 5.2 are in the release notes:
> >   https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-NOTES.txt
> >
> http://home.apache.org/~britter/commons/bcel/6.0-RC5/changes-report.html
> >
> > Site:
> >   http://home.apache.org/~britter/commons/bcel/6.0-RC5/
> > (note some *relative* links are broken and the 6.0 directories are not
> yet
> > created - these will be OK once the site is deployed)
> >
> > Clirr Report (compared to 5.2):
> >   http://home.apache.org/~britter/commons/bcel/6.0-RC5/clirr-report.html
> >
> > Note that Clirr reports several errors. These have been discussed on the
> > ML already and I uploaded the site a while ago giving everybody the
> > opportunity to raise objections against these changes. These changes are
> > also explicitly noted in the Release notes.
> >
> > Furthermore java.io.Serializable has been dropped from all BCEL classes.
> > An extended Clirr report including this change can be reviewed here:
> >
> >
> http://home.apache.org/~britter/commons/bcel/6.0-RC5/bcel5-bcel6-clirr-report.html
> >
> > We don't consider this to be a problem because we don't see a reason for
> > users to serialize BCEL classes.
> >
> > RAT Report:
> > http://home.apache.org/~britter/commons/bcel/6.0-RC5/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. sometime after 17:00 CEST 21-June 2016
> >
> > [ ] +1 Release these artifacts
> > [ ] +0 OK, but...
> > [ ] -0 OK, but really should fix...
> > [ ] -1 I oppose this release because...
> >
> > Thanks!
> > Benedikt
> >
>



-- 
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: [CRYPTO] Defining the public API; are its interfaces supposed to be implemented or just used?

On 19 June 2016 at 18:57, Dennis E. Hamilton  wrote:
> Being keen about API architectures ...
>
>> -Original Message-
>> From: Benedikt Ritter [mailto:brit...@apache.org]
>> Sent: Sunday, June 19, 2016 07:08
>> To: Commons Developers List 
>> Subject: Re: [CRYPTO] Defining the public API; are its interfaces
>> supposed to be implemented or just used?
>>
>> My unterstanding of crypto is that those interfaces are not to be
>> implemented by Clients.
>>
>> sebb  schrieb am So., 19. Juni 2016 um 14:02:
>>
> [ ... ]
>> > Users deriving from an abstract base class do not have to change code
>> > to implement new methods.
>> > But if their class happens to define a method with a name that is
>> > subsequently used by the Crypto abstract class, there will be a clash
>> > which will require them to recode.
> [orcmid]
>
> It is my understanding that this difficulty is one that Interfaces can be 
> used to overcome.

Sorry, but that's not the case.

If client code defines a method that is not currently in a superclass
or an interface that it implements, there is no problem.

If in a subsequent release, the superclass or interface happens to
define a method with the same parameters and return type as the one in
the client class, the client method will override/implement it.
However since the original client method was defined before the
superclass/interface method was added, it may well serve a completely
different purpose.

And if the client method has the same parameters but a different
return type, the compiler will complain.

Interfaces and super-classes behave identically in this particular respect.

> It also does not compel all implementations being off the same [abstract] 
> base class.

That much is true.

However if all implementations of the interface *are* the instances of
the defined functionality then it's generally better to use
subclassing.
For example Writer is an abstract class, not an interface.

>  - Dennis
>> >
>> > > Jochen
>> > >
>> > >
>> > > --
>> > > The next time you hear: "Don't reinvent the wheel!"
>> > >
>> > >
>> > http://www.keystonedevelopment.co.uk/wp-
>> content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>> > >
>> > > 
>> -
>> > > 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: [CRYPTO] Defining the public API; are its interfaces supposed to be implemented or just used?