Re: [All][Math] New component: "Commons Geometry"?

2017-12-02 Thread Gilles
Hi. On Sat, 2 Dec 2017 20:40:38 +, Martijn Verburg wrote: Has the PMC and the active developers met over a video call to try and hash this out? The ML archive is replete with discussions. A few PMC members voiced their agreement with the Apache mantra. A few oppose trying an approach that

Re: [all] Preventing assembly archives from being deployed to nexus.

2017-12-02 Thread Rob Tompkins
> On Dec 2, 2017, at 4:42 PM, Charles Honton wrote: > > I’ve been down this path about a year ago. We’re relying on the side effect > of these assemblies being artifacts for the GPG plugin to sign them. There > is an outstanding JIRA (https://issues.apache.org/jira/browse/MGPG-43 >

Re: [all] Preventing assembly archives from being deployed to nexus.

2017-12-02 Thread Matt Sicker
I mean from here: MD5 is a base requirement like the GPG signature is. Additional sha hashes are useful, though. I usually generate SHA-256 or SHA-512 with a release if I'm handling it manually. On 2 December 2017 at 17:50, Gary Gregory wrot

Re: [all] Preventing assembly archives from being deployed to nexus.

2017-12-02 Thread Gary Gregory
MD5 is just a kind of hash, as is SHA-1. SHA-512 should reduces the odds of collisions. IMO what matters is that we provide a hash for each file. Gary On Sat, Dec 2, 2017 at 4:26 PM, Matt Sicker wrote: > I thought md5 files were required? Unless that's project-specific (or Maven > Central requi

Re: [all] Preventing assembly archives from being deployed to nexus.

2017-12-02 Thread Matt Sicker
I thought md5 files were required? Unless that's project-specific (or Maven Central required?). On 2 December 2017 at 17:07, Gary Gregory wrote: > On Sat, Dec 2, 2017 at 3:51 PM, Rob Tompkins wrote: > > > > > > > > On Dec 2, 2017, at 4:22 PM, Gary Gregory > wrote: > > > > > > Hi Rob, > > > > >

Re: [all] Preventing assembly archives from being deployed to nexus.

2017-12-02 Thread Gary Gregory
On Sat, Dec 2, 2017 at 3:51 PM, Rob Tompkins wrote: > > > > On Dec 2, 2017, at 4:22 PM, Gary Gregory wrote: > > > > Hi Rob, > > > > Note that for Commons Daemon we do want to deploy the bin zip that > contains > > the Windows DLL/EXEs. > > Indeed, this would need to be done at a component level

Re: [all] Preventing assembly archives from being deployed to nexus.

2017-12-02 Thread Rob Tompkins
> On Dec 2, 2017, at 4:22 PM, Gary Gregory wrote: > > Hi Rob, > > Note that for Commons Daemon we do want to deploy the bin zip that contains > the Windows DLL/EXEs. Indeed, this would need to be done at a component level to accommodate just that. But, with Chas’ last email about signatures

RE: [VOTE] Release Apache Commons BCEL based on RC1

2017-12-02 Thread Mark Roberts
I will give it a try - but might take a couple of days -Original Message- From: Gary Gregory [mailto:garydgreg...@gmail.com] Sent: Saturday, December 02, 2017 1:04 PM To: Commons Developers List Subject: Re: [VOTE] Release Apache Commons BCEL based on RC1 Well, you you try this RC and se

Re: [all] Preventing assembly archives from being deployed to nexus.

2017-12-02 Thread Charles Honton
I’ve been down this path about a year ago. We’re relying on the side effect of these assemblies being artifacts for the GPG plugin to sign them. There is an outstanding JIRA (https://issues.apache.org/jira/browse/MGPG-43 ) to support signing un-at

Re: [all] Preventing assembly archives from being deployed to nexus.

2017-12-02 Thread Gary Gregory
Hi Rob, Note that for Commons Daemon we do want to deploy the bin zip that contains the Windows DLL/EXEs. Some folks, like me, depend on it in order to include the Windows EXE/DLLs in builds. Gary On Sat, Dec 2, 2017 at 2:06 PM, Rob Tompkins wrote: > Hello all, > > In my work on the [build-pl

[all] Preventing assembly archives from being deployed to nexus.

2017-12-02 Thread Rob Tompkins
Hello all, In my work on the [build-plugin], I’ve come across the following mechanism to prevent the [maven-assembly-plugin] from deploying the artifacts to nexus. If in the configuration section of the plugin, you put “false” the archives that the [maven-assembly-plugin] creates will not get p

Re: [VOTE] Release Apache Commons BCEL based on RC1

2017-12-02 Thread Gary Gregory
Well, you you try this RC and see if it can replace your custom build? Gary On Sat, Dec 2, 2017 at 1:27 PM, Mark Roberts wrote: > As far as the Daikon tool set is concerned, 295 is not a regression, it is > a newly discovered fatal flaw. We have already had to release a private > version of BC

Re: [All][Math] New component: "Commons Geometry"?

2017-12-02 Thread Martijn Verburg
Has the PMC and the active developers met over a video call to try and hash this out? It would be a shame to see this library fall into disuse. I'd also argue with Jigsaw being the heart of Java 9+ that more modular libs now make sense. Cheers, Martijn On 1 December 2017 at 14:56, Gilles wrote

RE: [VOTE] Release Apache Commons BCEL based on RC1

2017-12-02 Thread Mark Roberts
As far as the Daikon tool set is concerned, 295 is not a regression, it is a newly discovered fatal flaw. We have already had to release a private version of BCEL, we were hoping that the next version would fix that. -Original Message- From: Gary Gregory [mailto:garydgreg...@gmail.com]

Re: [VOTE] Release Apache Commons BCEL based on RC1

2017-12-02 Thread Gary Gregory
Looking at the release notes https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-NOTES.txt, you will see BCEL-295 is in this RC. Gary On Sat, Dec 2, 2017 at 1:24 PM, Gary Gregory wrote: > Also note that my prime motivation here is to get a version out of the > door that does not blow up

Re: [VOTE] Release Apache Commons BCEL based on RC1

2017-12-02 Thread Gary Gregory
Also note that my prime motivation here is to get a version out of the door that does not blow up violently when Java 9 bytes codes are scanned. Gary On Sat, Dec 2, 2017 at 1:14 PM, Gary Gregory wrote: > Mark, > > Unless BCEL-295 is a > regressio

Re: [VOTE] Release Apache Commons BCEL based on RC1

2017-12-02 Thread Gary Gregory
Mark, Unless BCEL-295 is a regression, I see no technical reason for a -1. What am I missing? Gary On Sat, Dec 2, 2017 at 12:35 PM, Mark Roberts wrote: > I have to vote -1 until 295 is fixed - this will force us to have a > private version of bc

RE: [VOTE] Release Apache Commons BCEL based on RC1

2017-12-02 Thread Mark Roberts
I have to vote -1 until 295 is fixed - this will force us to have a private version of bcel. https://issues.apache.org/jira/browse/BCEL-295 Mark -Original Message- From: Gary Gregory [mailto:ggreg...@apache.org] Sent: Thursday, November 30, 2017 8:18 PM To: Commons Developers List Sub

Re: [VOTE] Release Apache Commons BCEL based on RC1

2017-12-02 Thread Gary Gregory
+1 from me and a request to the PMC to have a look ;-) Thank you! Gary On Thu, Nov 30, 2017 at 9:17 PM, Gary Gregory wrote: > We fixed a few bugs and added some enhancements since we released Apache > Commons BCEL 6.1, so I would like to release Commons BCEL 6.2. > > Commons BCEL 6.2 RC1 is ava