[GitHub] commons-bcel pull request #13: BCEL-289: iterate through parameter annotatio...

Github user asfgit closed the pull request at: https://github.com/apache/commons-bcel/pull/13 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

Re: [IMAGING] Why don't we just release it?

Am 19.05.2017 um 08:17 schrieb Jörg Schaible: We failed to release for years and the current SNAPSHOT is the de facto API now. So qwe better make this official releasing 1.0 and move on immediately with 2.0 to adjust any stuff that has to be corrected. +1 --

Re: [IMAGING] Why don't we just release it?

Gary Gregory wrote: > If you dig through the mailing list, you will find a few proposal for a > road map out of "0.97" land. IIRC, the code was deemed in flux and BC > breaking changes planned. > > For me, It's fine to cut 1.0 and to NOT be shy about releasing a 2.0 with > BC breaks. +1 - Jörg

Re: [IMAGING] Why don't we just release it?

Hi, sebb wrote: > On 18 May 2017 at 19:22, Benedikt Ritter wrote: >> >>> Am 18.05.2017 um 12:54 schrieb sebb : >>> >>> I think the release should be marked as ALPHA. >>> This is because: >>> - there are many unresolved issues >> >> Yes, but I don’t think we could push out 1.0 anyway. >> >>> - it

Re: [FUNCTOR] How do we move on?

I'd like to have more time to work on [functor], but I think it more likely that I will jump to work on [text] and [jelly] in the next months. If I remember well, there were a few utility classes that even now with Java 8 are still missing from the language. These could either be ported to Lang

RE: [CRYPTO] Suggestion from ApacheCON: Have a look at Amazon s2n

Hi Benedikt, I've took a glance at s2n. It is not a full replacement for OpenSSL, its crypto is a wrapper of OpenSSL. It doesn't support all the algorithms that OpenSSL supports. For instance, s2n does not support AES-CTR algorithm. Regards, Xianda -Original Message- From: Benedikt

Re: svn commit: r1795551 - /commons/proper/commons-parent/trunk/pom.xml

Since the current version of maven-site-plugin is 3.6, it would be nice to note what happens for that version as well. Gary On Thu, May 18, 2017 at 12:04 PM, wrote: > Author: britter > Date: Thu May 18 19:04:38 2017 > New Revision: 1795551 > > URL: http://svn.apache.org/viewvc?rev=1795551&view=

Re: [FUNCTOR] How do we move on?

TBH I cleaned up more than I implemented, but okay. What happened was we changed the nomenclature to better mesh with Java 8 and that pretty much killed the momentum on the project, despite having been the right thing to do. I wouldn't mind seeing a redefined component such as you have suggested, b

Re: [IMAGING] Why don't we just release it?

On 18 May 2017 at 19:22, Benedikt Ritter wrote: > >> Am 18.05.2017 um 12:54 schrieb sebb : >> >> I think the release should be marked as ALPHA. >> This is because: >> - there are many unresolved issues > > Yes, but I don’t think we could push out 1.0 anyway. > >> - it's highly likely that the next

Re: [VOTE][LAZY] Move commons-imaging to git

+1 Gary On May 18, 2017 10:22 AM, "Rob Tompkins" wrote: > Hello all, > > I would like to propose that we move commons-imaging to git in hopes of > doing that before the potential of releasing a 1.0. I figure that it would > be an easier migration with only a trunk to manage in getting it over t

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

On May 18, 2017 12:09 PM, "Benedikt Ritter" wrote: Hi, here is my proposal on how to get the Automatic-Module-Name entry into our MANIFEST files. This change has to be made only in commons parent. This is the change: Index: pom.xml ===

[PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

Hi, here is my proposal on how to get the Automatic-Module-Name entry into our MANIFEST files. This change has to be made only in commons parent. This is the change: Index: pom.xml === --- pom.xml (revision 1795551) +++ pom.xml

Re: [IMAGING] Why don't we just release it?

> Am 18.05.2017 um 12:54 schrieb sebb : > > I think the release should be marked as ALPHA. > This is because: > - there are many unresolved issues Yes, but I don’t think we could push out 1.0 anyway. > - it's highly likely that the next release will break compatibility Why do you think this is

Re: [FUNCTOR] How do we move on?

> Am 17.05.2017 um 19:38 schrieb Gary Gregory : > > On Wed, May 17, 2017 at 1:39 PM, Benedikt Ritter > wrote: > >> Hello Gary, >> >>> Am 17.05.2017 um 15:01 schrieb Gary Gregory >> >: >>> >>> On Wed, May 17, 2017 at 11:17 AM, Benedikt

Re: [IMAGING] Why don't we just release it?

On Thu, May 18, 2017 at 9:54 AM, sebb wrote: > I think the release should be marked as ALPHA. > This is because: > - there are many unresolved issues > - it's highly likely that the next release will break compatibility > > This should also be highlighted in the release notes. > The seems like t

[VOTE][LAZY] Move commons-imaging to git

Hello all, I would like to propose that we move commons-imaging to git in hopes of doing that before the potential of releasing a 1.0. I figure that it would be an easier migration with only a trunk to manage in getting it over there. For this reason I’m calling a vote by lazy consensus for mov

Re: [IMAGING] Why don't we just release it?

I think the release should be marked as ALPHA. This is because: - there are many unresolved issues - it's highly likely that the next release will break compatibility This should also be highlighted in the release notes. On 18 May 2017 at 17:09, Rob Tompkins wrote: > >> On May 18, 2017, at 9:20

Re: [IMAGING] Why don't we just release it?

> On May 18, 2017, at 9:20 AM, Benedikt Ritter wrote: > > Hi Damjan, > >> Am 18.05.2017 um 08:16 schrieb Damjan Jovanovic : >> >> Imaging is in quite a sad state compared to javax.imageio, with very >> limited JPEG support that is hard to improve without major research, and >> doesn't add that

Re: [ALL] Build Javadoc with Java 9

Speaking of javadoc checks, maybe I'll considering enabling them when OpenJDK does. On 18 May 2017 at 03:10, Stian Soiland-Reyes wrote: > Agree to wait for Java 9 GA before it's general practice. Would not -1 a > release candidate with nicer Java 9 javadoc though! > > With Java 8 there were many

[RESULT][VOTE][LAZY] Move Apache Commons Jelly to dormant

> Am 17.05.2017 um 14:26 schrieb Benedikt Ritter : > > Hi, > > I think we should move Apache Commons Jelly to dormant for the following > reasons: > > - Jelly hasn’t seen any activity in a while. There haven’t been any relevant > commits since 2010 (I didn’t search the history further than th

[JELLY] State of the project (Was: [VOTE][LAZY] Move Apache Commons Jelly to dormant)

Hi, > Am 17.05.2017 um 19:38 schrieb Gary Gregory : > > I think that we could, as a community test of interest, say something like, > if Oliver wants to push out what is in trunk in the next 30 days or so (or > 60 or 90), we will help. I would help with odds and ends. Aside from that, > if no one

[commons-text] Regarding code consolidation.

Hello all, Over the last year or so we in Commons have been working towards a newly released component “commons-text,”, and we were wondering if folks wanted to begin consuming commons-text so that we can consolidate the maintenance of the code performing edit distances and similarity scores (for

Re: [IMAGING] Why don't we just release it?

Hi Damjan, > Am 18.05.2017 um 08:16 schrieb Damjan Jovanovic : > > Imaging is in quite a sad state compared to javax.imageio, with very > limited JPEG support that is hard to improve without major research, and > doesn't add that much value. People seem to mostly use it for extracting > image met

Re: [IMAGING] Why don't we just release it?

Imaging is in quite a sad state compared to javax.imageio, with very limited JPEG support that is hard to improve without major research, and doesn't add that much value. People seem to mostly use it for extracting image metadata. I would like to see most of the following in 1.0: * Proper support

Re: [text] Thoughts on cutting a 1.1 release?

+1 for 1.1 release On Thu, May 18, 2017, 12:33 AM Gary Gregory wrote: > Go for it. > > Gary > > On Wed, May 17, 2017 at 7:45 AM, Rob Tompkins wrote: > > > Hello all, > > > > Now that we have WordUtils and the RandomStringGenerator in the [text] > > codebase, it feels like we could cut a 1.1 rel

[CRYPTO] Suggestion from ApacheCON: Have a look at Amazon s2n

Hi folks, Somebody at Dapeng’s talk about commons crypto suggested us to have a look at Amazon s2n [1]. I’m not sure it is a full replacement for OpenSSL, but if it is, it may be interesting to have it as an alternative native backend for crypto. Cheers, Benedikt [1] https://github.com/awslab

Re: [IMAGING] Why don't we just release it?

> Am 17.05.2017 um 19:46 schrieb Gary Gregory : > > If you dig through the mailing list, you will find a few proposal for a > road map out of "0.97" land. IIRC, the code was deemed in flux and BC > breaking changes planned. > > For me, It's fine to cut 1.0 and to NOT be shy about releasing a 2.0

Re: [bcel] Any reviewer for my BCEL-289 pull request?

+1 On 05/18/2017 05:57 AM, Bruno P. Kinoshita wrote: Hi all, Found a solution for BCEL-289 [1], and submitted as a pull request [2], but not really sure if the old behaviour was intentional for any reason, or just really a bug. Never used BCEL, nor read much of its code base before. So happy

[bcel] Any reviewer for my BCEL-289 pull request?

Hi all, Found a solution for BCEL-289 [1], and submitted as a pull request [2], but not really sure if the old behaviour was intentional for any reason, or just really a bug. Never used BCEL, nor read much of its code base before. So happy to have someone else reviewing it if possible before it

[GitHub] commons-bcel pull request #13: BCEL-289: iterate through parameter annotatio...

GitHub user kinow opened a pull request: https://github.com/apache/commons-bcel/pull/13 BCEL-289: iterate through parameter annotation entries using the right limit The code was iterating through the number of parameters (3 in this case, the Bar parent class, and the two annotated p

Re: [ALL] Build Javadoc with Java 9

Agree to wait for Java 9 GA before it's general practice. Would not -1 a release candidate with nicer Java 9 javadoc though! With Java 8 there were many issues with javadoc checks and options incompatible with Java 7. I I don't know if anything changes here for Java 9, but trying to comply both