Re: [ALL] JDK 9 Version String

2016-07-14 Thread Gary Gregory
Thank you, I subscribed and asked a question out of curiosity...

Gary

On Thu, Jul 14, 2016 at 11:08 AM, Paul Benedict 
wrote:

> You can't comment on the tickets, but they do want your feedback on their
> Verona message board:
> http://mail.openjdk.java.net/mailman/listinfo/verona-dev
>
> Cheers,
> Paul
>
> On Thu, Jul 14, 2016 at 1:05 PM, Gary Gregory 
> wrote:
>
> > Am I blind or can someone point out how to comment on a JEP? The JEP is
> > linked to https://bugs.openjdk.java.net/browse/JDK-8061493 but how do
> you
> > get an account on that?
> >
> > I recall hearing a preso on how the comments for Java were locked down
> for
> > fear of too much feedback... or something.
> >
> > Gary
> >
> > On Thu, Jul 14, 2016 at 8:24 AM, Paul Benedict 
> > wrote:
> >
> > > If this issue has been raised in the past, my apologies. I did a search
> > for
> > > "Verona" in the mail archives here and didn't see any hit besides
> > Oracle's
> > > own notification [1]. That was the only hit.
> > >
> > > In JDK 9, the version string is changing from 1.0.X to bigger numbers
> > like
> > > 9.0.0 [2]. Code that has assumed the 1.x pattern for parsing the
> version
> > > string will likely fail or behave strangely. Apache Commons will be one
> > of
> > > these libraries [3]. I already notified the Log4J community that Log4J
> > 1.x
> > > is also affected. So this is just an FYI for any Commons project that
> is
> > > relying on the Version string.
> > >
> > > The slew of Apache Commons sub-projects are likely baked into many
> > > applications. So what does Verona's change mean in practice to all you
> > > here? Any concerns on Verona? This is the time to speak up to Oracle
> with
> > > any feedback you may have.
> > >
> > > [1] http://markmail.org/message/t3l7d73tmqslkele
> > > [2] http://openjdk.java.net/jeps/223
> > > [3]
> > >
> > >
> >
> https://commons.apache.org/proper/commons-lang/javadocs/api-3.4/src-html/org/apache/commons/lang3/SystemUtils.html#line.952
> > >
> > > Cheers,
> > > Paul
> > >
> >
> >
> >
> > --
> > 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
> >
>



-- 
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: [ALL] JDK 9 Version String

2016-07-14 Thread Matt Sicker
I noticed that you can't make an account there, too, when I wanted to
report a javac bug. Plus, it would have been too convenient of a location
to report JDK9 bugs during development apparently.

On 14 July 2016 at 13:08, Paul Benedict  wrote:

> You can't comment on the tickets, but they do want your feedback on their
> Verona message board:
> http://mail.openjdk.java.net/mailman/listinfo/verona-dev
>
> Cheers,
> Paul
>
> On Thu, Jul 14, 2016 at 1:05 PM, Gary Gregory 
> wrote:
>
> > Am I blind or can someone point out how to comment on a JEP? The JEP is
> > linked to https://bugs.openjdk.java.net/browse/JDK-8061493 but how do
> you
> > get an account on that?
> >
> > I recall hearing a preso on how the comments for Java were locked down
> for
> > fear of too much feedback... or something.
> >
> > Gary
> >
> > On Thu, Jul 14, 2016 at 8:24 AM, Paul Benedict 
> > wrote:
> >
> > > If this issue has been raised in the past, my apologies. I did a search
> > for
> > > "Verona" in the mail archives here and didn't see any hit besides
> > Oracle's
> > > own notification [1]. That was the only hit.
> > >
> > > In JDK 9, the version string is changing from 1.0.X to bigger numbers
> > like
> > > 9.0.0 [2]. Code that has assumed the 1.x pattern for parsing the
> version
> > > string will likely fail or behave strangely. Apache Commons will be one
> > of
> > > these libraries [3]. I already notified the Log4J community that Log4J
> > 1.x
> > > is also affected. So this is just an FYI for any Commons project that
> is
> > > relying on the Version string.
> > >
> > > The slew of Apache Commons sub-projects are likely baked into many
> > > applications. So what does Verona's change mean in practice to all you
> > > here? Any concerns on Verona? This is the time to speak up to Oracle
> with
> > > any feedback you may have.
> > >
> > > [1] http://markmail.org/message/t3l7d73tmqslkele
> > > [2] http://openjdk.java.net/jeps/223
> > > [3]
> > >
> > >
> >
> https://commons.apache.org/proper/commons-lang/javadocs/api-3.4/src-html/org/apache/commons/lang3/SystemUtils.html#line.952
> > >
> > > Cheers,
> > > Paul
> > >
> >
> >
> >
> > --
> > 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
> >
>



-- 
Matt Sicker 


Re: [ALL] JDK 9 Version String

2016-07-14 Thread Paul Benedict
You can't comment on the tickets, but they do want your feedback on their
Verona message board:
http://mail.openjdk.java.net/mailman/listinfo/verona-dev

Cheers,
Paul

On Thu, Jul 14, 2016 at 1:05 PM, Gary Gregory 
wrote:

> Am I blind or can someone point out how to comment on a JEP? The JEP is
> linked to https://bugs.openjdk.java.net/browse/JDK-8061493 but how do you
> get an account on that?
>
> I recall hearing a preso on how the comments for Java were locked down for
> fear of too much feedback... or something.
>
> Gary
>
> On Thu, Jul 14, 2016 at 8:24 AM, Paul Benedict 
> wrote:
>
> > If this issue has been raised in the past, my apologies. I did a search
> for
> > "Verona" in the mail archives here and didn't see any hit besides
> Oracle's
> > own notification [1]. That was the only hit.
> >
> > In JDK 9, the version string is changing from 1.0.X to bigger numbers
> like
> > 9.0.0 [2]. Code that has assumed the 1.x pattern for parsing the version
> > string will likely fail or behave strangely. Apache Commons will be one
> of
> > these libraries [3]. I already notified the Log4J community that Log4J
> 1.x
> > is also affected. So this is just an FYI for any Commons project that is
> > relying on the Version string.
> >
> > The slew of Apache Commons sub-projects are likely baked into many
> > applications. So what does Verona's change mean in practice to all you
> > here? Any concerns on Verona? This is the time to speak up to Oracle with
> > any feedback you may have.
> >
> > [1] http://markmail.org/message/t3l7d73tmqslkele
> > [2] http://openjdk.java.net/jeps/223
> > [3]
> >
> >
> https://commons.apache.org/proper/commons-lang/javadocs/api-3.4/src-html/org/apache/commons/lang3/SystemUtils.html#line.952
> >
> > Cheers,
> > Paul
> >
>
>
>
> --
> 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: [ALL] JDK 9 Version String

2016-07-14 Thread Gary Gregory
Am I blind or can someone point out how to comment on a JEP? The JEP is
linked to https://bugs.openjdk.java.net/browse/JDK-8061493 but how do you
get an account on that?

I recall hearing a preso on how the comments for Java were locked down for
fear of too much feedback... or something.

Gary

On Thu, Jul 14, 2016 at 8:24 AM, Paul Benedict  wrote:

> If this issue has been raised in the past, my apologies. I did a search for
> "Verona" in the mail archives here and didn't see any hit besides Oracle's
> own notification [1]. That was the only hit.
>
> In JDK 9, the version string is changing from 1.0.X to bigger numbers like
> 9.0.0 [2]. Code that has assumed the 1.x pattern for parsing the version
> string will likely fail or behave strangely. Apache Commons will be one of
> these libraries [3]. I already notified the Log4J community that Log4J 1.x
> is also affected. So this is just an FYI for any Commons project that is
> relying on the Version string.
>
> The slew of Apache Commons sub-projects are likely baked into many
> applications. So what does Verona's change mean in practice to all you
> here? Any concerns on Verona? This is the time to speak up to Oracle with
> any feedback you may have.
>
> [1] http://markmail.org/message/t3l7d73tmqslkele
> [2] http://openjdk.java.net/jeps/223
> [3]
>
> https://commons.apache.org/proper/commons-lang/javadocs/api-3.4/src-html/org/apache/commons/lang3/SystemUtils.html#line.952
>
> Cheers,
> Paul
>



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


[ALL] JDK 9 Version String

2016-07-14 Thread Paul Benedict
If this issue has been raised in the past, my apologies. I did a search for
"Verona" in the mail archives here and didn't see any hit besides Oracle's
own notification [1]. That was the only hit.

In JDK 9, the version string is changing from 1.0.X to bigger numbers like
9.0.0 [2]. Code that has assumed the 1.x pattern for parsing the version
string will likely fail or behave strangely. Apache Commons will be one of
these libraries [3]. I already notified the Log4J community that Log4J 1.x
is also affected. So this is just an FYI for any Commons project that is
relying on the Version string.

The slew of Apache Commons sub-projects are likely baked into many
applications. So what does Verona's change mean in practice to all you
here? Any concerns on Verona? This is the time to speak up to Oracle with
any feedback you may have.

[1] http://markmail.org/message/t3l7d73tmqslkele
[2] http://openjdk.java.net/jeps/223
[3]
https://commons.apache.org/proper/commons-lang/javadocs/api-3.4/src-html/org/apache/commons/lang3/SystemUtils.html#line.952

Cheers,
Paul


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

2016-07-14 Thread Chas Honton
Congratulations!

Chas

> On Jul 14, 2016, at 12:42 AM, Benedikt Ritter  wrote:
> 
> This vote passes (am I dreaming? ;-) The following votes were cast:
> 
> Oliver Heger: +1 (binding)
> Gary Gregory: +1 (binding)
> Mark Roberts: +1
> Oliver Lamy: +1 (binding)
> Jörg Schaible: +1 (binding)
> Emmanuel Bourg: +1 (binding)
> Benedikt Ritter: +1 (binding)
> 
> Thank you for reviewing this RC and the one before.
> 
> Benedikt
> 
> Benedikt Ritter  schrieb am So., 10. Juli 2016 um
> 22:57 Uhr:
> 
>> Hi all,
>> 
>> hopefully the final RC for releasing Apache Commons BCEL 6.0 :-) Changes
>> since RC7:
>> 
>> - fixed failing build on Windows plattforms
>> - corrected fix for BCEL-262
>> 
>> Apache Commons BCEL 6.0 is available for review here:
>>  https://dist.apache.org/repos/dist/dev/commons/bcel (rev 14344)
>> 
>> The tag is here:
>>  https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC8
>> (rev 1752118)
>> 
>> Maven artifacts:
>> 
>> https://repository.apache.org/content/repositories/orgapachecommons-1183/org/apache/bcel/bcel/6.0/
>> 
>> Maven artifact hashes:
>> 
>> bcel-6.0-test-sources.jar
>> (SHA1: 30ba969d603b676929b69228ad0f2a4fc1c9c830)
>> bcel-6.0.pom
>> (SHA1: aff6c560d92df15a207247c5b0293bb734389094)
>> bcel-6.0.jar
>> (SHA1: 7d08bcac4832f81467d3e2ca5bd58ad627288656)
>> bcel-6.0-tests.jar
>> (SHA1: 3536d25398f6f6ac22deb9e446515056191661f7)
>> bcel-6.0-javadoc.jar
>> (SHA1: e47a109aa7416329a9970f0900136cb355af8ac8)
>> bcel-6.0-sources.jar
>> (SHA1: 206dfd32271b9b0150d8211070e5dbbe69cf5154)
>> 
>> I've tested with Java 7 & 8 using Maven 3.3.9
>> 
>> 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-RC8/changes-report.html
>> 
>> Site:
>>  http://home.apache.org/~britter/commons/bcel/6.0-RC8
>> (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-RC8/clirr-report.html
>> 
>> Note that Clirr reports several errors.
>> These are considered OK for the reasons stated below.
>> These exceptions are also noted in the Changes and Release Notes.
>> 
>> Errors reported:
>> - methods added to org.apache.bcel.classfile.Visitor interface: OK
>> because that does not affect binary compatibility.
>> - Removed java.io.Serializable from all classes: OK, because we don't
>> expect anybody to rely on serialization for BCEL classes
>> - Return type of method 'public java.lang.Object getElementAt(int)' has
>> been changed to java.lang.String in class 
>> org.apache.bcel.verifier.VerifierFactoryListModel:
>> OK, because this class is part of an UI application and for this reason
>> should only used by Swing.
>> 
>> RAT Report:
>>  http://home.apache.org/~britter/commons/bcel/6.0-RC8/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 23:00 CEST 13-July 2016
>> 
>> [ ] +1 Release these artifacts
>> [ ] +0 OK, but...
>> [ ] -0 OK, but really should fix...
>> [ ] -1 I oppose this release because...
>> 
>> Thank you!
>> Benedikt
>> 
>> 


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



RE: [CRYPTO]1.0.0 Release Plan

2016-07-14 Thread Dennis E. Hamilton
I don't know if the deployment method for the binaries (.jar, etc.) of these 
releases provides useful download statistics for the Commons project.

If it does, differentiating by the native platforms for which there are native 
shared-libraries that need to also be on the runtime path (e.g., to work with 
JNI) is important.  You will have some evidence for what your users intend to 
run the related classes on.

That might be important to know if you are considering a triage with respect to 
native support.

 - Dennis

> -Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Tuesday, July 12, 2016 09:09
> To: Commons Developers List 
> Subject: Re: [CRYPTO]1.0.0 Release Plan
> 
> On 12 July 2016 at 14:54, sebb  wrote:
> > On 12 July 2016 at 14:20, Sun, Dapeng  wrote:
> >> Separating artifacts for each native library, I think it should be
> same as copying the native binary files. We also need to collect the
> artifacts for unpacking and bundling.
> >
> > Yes.
> >
> >> About using the 'all' artifact, users may be confused about
> downloading the artifacts for all the different platforms, especially
> for the platforms they don't need.
> >
> > I think we could have a separate project that creates a jar containing
> > the Java classes plus all released native builds.
> >
> > AIUI the code can automatically extract the native code from the jar,
> > so it should be easy to use.
> >
> > If we also release the Java classes and native builds as separate
> > jars, then users would have the choice:
> >
> > - download the jar containing the Java classes plus all released
> native builds
> > - download the Java classes jar plus any native builds they need
> >
> > Or maybe when releasing a native build, we could package it with the
> > Java classes.
> 
> It looks like that already happens - the MacOSX installed jar includes
> the jnilib file.
> 
[  ]


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



Jenkins build is back to normal : commons-net #11

2016-07-14 Thread Apache Jenkins Server
See 


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



Build failed in Jenkins: commons-bcel #37

2016-07-14 Thread Apache Jenkins Server
See 

Changes:

[britter] Add dependency tags to pom snippet

[britter] Remove trailing white spaces

--
[...truncated 440 lines...]
AUsrc/main/java/org/apache/bcel/generic/DLOAD.java
AUsrc/main/java/org/apache/bcel/generic/F2L.java
AUsrc/main/java/org/apache/bcel/generic/JSR_W.java
AUsrc/main/java/org/apache/bcel/generic/InstructionListObserver.java
AUsrc/main/java/org/apache/bcel/generic/MONITORENTER.java
AUsrc/main/java/org/apache/bcel/generic/DDIV.java
AUsrc/main/java/org/apache/bcel/generic/CompoundInstruction.java
A src/main/java/org/apache/bcel/util
AUsrc/main/java/org/apache/bcel/util/ClassQueue.java
AUsrc/main/java/org/apache/bcel/util/SyntheticRepository.java
AUsrc/main/java/org/apache/bcel/util/Class2HTML.java
AUsrc/main/java/org/apache/bcel/util/package.html
AUsrc/main/java/org/apache/bcel/util/ConstantHTML.java
AUsrc/main/java/org/apache/bcel/util/Repository.java
AUsrc/main/java/org/apache/bcel/util/ClassSet.java
AUsrc/main/java/org/apache/bcel/util/JavaWrapper.java
AUsrc/main/java/org/apache/bcel/util/ClassPath.java
A src/main/java/org/apache/bcel/util/ClassPathRepository.java
AUsrc/main/java/org/apache/bcel/util/BCELifier.java
AUsrc/main/java/org/apache/bcel/util/AttributeHTML.java
AUsrc/main/java/org/apache/bcel/util/ClassVector.java
AUsrc/main/java/org/apache/bcel/util/ClassStack.java
AUsrc/main/java/org/apache/bcel/util/ByteSequence.java
AUsrc/main/java/org/apache/bcel/util/ClassLoader.java
AUsrc/main/java/org/apache/bcel/util/ClassLoaderRepository.java
AUsrc/main/java/org/apache/bcel/util/BCELComparator.java
AUsrc/main/java/org/apache/bcel/util/BCELFactory.java
AUsrc/main/java/org/apache/bcel/util/CodeHTML.java
A 
src/main/java/org/apache/bcel/util/MemorySensitiveClassPathRepository.java
AUsrc/main/java/org/apache/bcel/util/MethodHTML.java
AUsrc/main/java/org/apache/bcel/util/InstructionFinder.java
AUsrc/main/java/org/apache/bcel/package.html
AUsrc/main/java/org/apache/bcel/Repository.java
AUsrc/main/java/org/apache/bcel/ExceptionConst.java
A src/main/java/org/apache/bcel/classfile
AUsrc/main/java/org/apache/bcel/classfile/ConstantMethodref.java
AUsrc/main/java/org/apache/bcel/classfile/ConstantMethodType.java
AUsrc/main/java/org/apache/bcel/classfile/Unknown.java
AUsrc/main/java/org/apache/bcel/classfile/Visitor.java
AUsrc/main/java/org/apache/bcel/classfile/LocalVariable.java
AUsrc/main/java/org/apache/bcel/classfile/LineNumber.java
AUsrc/main/java/org/apache/bcel/classfile/Signature.java
AUsrc/main/java/org/apache/bcel/classfile/StackMap.java
AUsrc/main/java/org/apache/bcel/classfile/PMGClass.java
AUsrc/main/java/org/apache/bcel/classfile/ClassElementValue.java
AUsrc/main/java/org/apache/bcel/classfile/AccessFlags.java
AUsrc/main/java/org/apache/bcel/classfile/MethodParameter.java
AUsrc/main/java/org/apache/bcel/classfile/AttributeReader.java
AUsrc/main/java/org/apache/bcel/classfile/AnnotationEntry.java
AUsrc/main/java/org/apache/bcel/classfile/Annotations.java
AUsrc/main/java/org/apache/bcel/classfile/SimpleElementValue.java
AUsrc/main/java/org/apache/bcel/classfile/ElementValuePair.java
AUsrc/main/java/org/apache/bcel/classfile/Utility.java
AUsrc/main/java/org/apache/bcel/classfile/Attribute.java
AUsrc/main/java/org/apache/bcel/classfile/MethodParameters.java
AUsrc/main/java/org/apache/bcel/classfile/StackMapType.java
AUsrc/main/java/org/apache/bcel/classfile/ConstantMethodHandle.java
AU
src/main/java/org/apache/bcel/classfile/RuntimeInvisibleParameterAnnotations.java
AUsrc/main/java/org/apache/bcel/classfile/Synthetic.java
AUsrc/main/java/org/apache/bcel/classfile/ConstantCP.java
AUsrc/main/java/org/apache/bcel/classfile/BootstrapMethod.java
AUsrc/main/java/org/apache/bcel/classfile/ConstantFloat.java
AUsrc/main/java/org/apache/bcel/classfile/AnnotationDefault.java
AU
src/main/java/org/apache/bcel/classfile/RuntimeVisibleParameterAnnotations.java
AUsrc/main/java/org/apache/bcel/classfile/Method.java
AUsrc/main/java/org/apache/bcel/classfile/EnclosingMethod.java
AUsrc/main/java/org/apache/bcel/classfile/ClassParser.java
AUsrc/main/java/org/apache/bcel/classfile/Field.java
AUsrc/main/java/org/apache/bcel/classfile/FieldOrMethod.java
AUsrc/main/java/org/apache/bcel/classfile/ElementValue.java
AUsrc/main/java/org/apache/bcel/classfile/ConstantValue.java
AUsrc/main/java/org/apache/bcel/classfile/ParameterAnnotationEntry.java

Build failed in Jenkins: commons-net #10

2016-07-14 Thread Apache Jenkins Server
See 

Changes:

[sebb] Overlong line

--
[...truncated 512 lines...]
Running org.apache.commons.net.ftp.parser.FTPConfigEntryParserTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec - in 
org.apache.commons.net.ftp.parser.FTPConfigEntryParserTest
Running org.apache.commons.net.ftp.parser.DefaultFTPFileEntryParserFactoryTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec - in 
org.apache.commons.net.ftp.parser.DefaultFTPFileEntryParserFactoryTest
Running org.apache.commons.net.ftp.FTPClientTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec - in 
org.apache.commons.net.ftp.FTPClientTest
Running org.apache.commons.net.ftp.FTPCommandTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in 
org.apache.commons.net.ftp.FTPCommandTest
Running org.apache.commons.net.ftp.FTPClientConfigTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.017 sec - in 
org.apache.commons.net.ftp.FTPClientConfigTest
Running org.apache.commons.net.time.TimeTCPClientTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.002 sec - in 
org.apache.commons.net.time.TimeTCPClientTest
Running org.apache.commons.net.SocketClientTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec - in 
org.apache.commons.net.SocketClientTest
Running org.apache.commons.net.SubnetUtilsTest
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec - in 
org.apache.commons.net.SubnetUtilsTest
Running org.apache.commons.net.nntp.TestThreader
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec - in 
org.apache.commons.net.nntp.TestThreader

Results :

Tests run: 274, Failures: 0, Errors: 0, Skipped: 19

[JENKINS] Recording test results
[INFO] 
[INFO] --- maven-jar-plugin:2.6:jar (default-jar) @ commons-net ---
[INFO] Building jar: 

[INFO] 
[INFO] --- maven-site-plugin:3.4:attach-descriptor (attach-descriptor) @ 
commons-net ---
[INFO] 
[INFO] >>> maven-javadoc-plugin:2.10.3:javadoc (create-javadoc-jar) > 
generate-sources @ commons-net >>>
[INFO] 
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-3) @ commons-net 
---
[INFO] 
[INFO] --- build-helper-maven-plugin:1.10:parse-version (parse-version) @ 
commons-net ---
[INFO] 
[INFO] --- maven-antrun-plugin:1.8:run (javadoc.resources) @ commons-net ---
[INFO] Executing tasks

main:
[INFO] Executed tasks
[WARNING] Failed to getClass for org.apache.maven.plugin.javadoc.JavadocReport
[INFO] 
[INFO] <<< maven-javadoc-plugin:2.10.3:javadoc (create-javadoc-jar) < 
generate-sources @ commons-net <<<
[INFO] 
[INFO] --- maven-javadoc-plugin:2.10.3:javadoc (create-javadoc-jar) @ 
commons-net ---
[INFO] 
1 warning
[WARNING] Javadoc Warnings
[WARNING] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
[JENKINS] Archiving  javadoc
[INFO] 
[INFO] --- maven-javadoc-plugin:2.10.3:jar (create-javadoc-jar) @ commons-net 
---
[INFO] 
1 warning
[WARNING] Javadoc Warnings
[WARNING] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
[INFO] Building jar: 

[INFO] 
[INFO] --- maven-antrun-plugin:1.8:run (default) @ commons-net ---
[INFO] Executing tasks

main:
  [jar] Building jar: 

  [jar] Building jar: 

[INFO] Executed tasks
[INFO] 
[INFO] >>> maven-source-plugin:3.0.0:jar (create-source-jar) > generate-sources 
@ commons-net >>>
[INFO] 
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-3) @ commons-net 
---
[INFO] 
[INFO] --- build-helper-maven-plugin:1.10:parse-version (parse-version) @ 
commons-net ---
[INFO] 
[INFO] --- maven-antrun-plugin:1.8:run (javadoc.resources) @ commons-net ---
[INFO] Executing tasks

main:
[INFO] Executed tasks
[WARNING] Failed to getClass for org.apache.maven.plugins.source.SourceJarMojo
[INFO] 
[INFO] <<< maven-source-plugin:3.0.0:jar (create-source-jar) < generate-sources 
@ commons-net <<<
[INFO] 
[INFO] --- maven-source-plugin:3.0.0:jar (create-source-jar) @ commons-net ---
[INFO] Building jar: 

[INFO] 
[INFO] >>> maven-source-plugin:3.0.0:test-jar (create-source-jar) > 
generate-sources @ commons-net >>>
[INFO] 
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-3) @ commons-net 
---
[INFO] 
[INFO] --- build-helper-maven-plugin:1.10:parse-version (parse-version) @ 
commons-net ---
[INFO] 
[INFO] --- maven-antrun-plugin:1.8:run (javadoc.resources) @ commons-net ---
[INFO] 

[RESULT][VOTE] Release Apache Commons BCEL 6.0 based on RC8

2016-07-14 Thread Benedikt Ritter
This vote passes (am I dreaming? ;-) The following votes were cast:

Oliver Heger: +1 (binding)
Gary Gregory: +1 (binding)
Mark Roberts: +1
Oliver Lamy: +1 (binding)
Jörg Schaible: +1 (binding)
Emmanuel Bourg: +1 (binding)
Benedikt Ritter: +1 (binding)

Thank you for reviewing this RC and the one before.

Benedikt

Benedikt Ritter  schrieb am So., 10. Juli 2016 um
22:57 Uhr:

> Hi all,
>
> hopefully the final RC for releasing Apache Commons BCEL 6.0 :-) Changes
> since RC7:
>
> - fixed failing build on Windows plattforms
> - corrected fix for BCEL-262
>
> Apache Commons BCEL 6.0 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/bcel (rev 14344)
>
> The tag is here:
>   https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC8
>  (rev 1752118)
>
> Maven artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1183/org/apache/bcel/bcel/6.0/
>
> Maven artifact hashes:
>
> bcel-6.0-test-sources.jar
> (SHA1: 30ba969d603b676929b69228ad0f2a4fc1c9c830)
> bcel-6.0.pom
> (SHA1: aff6c560d92df15a207247c5b0293bb734389094)
> bcel-6.0.jar
> (SHA1: 7d08bcac4832f81467d3e2ca5bd58ad627288656)
> bcel-6.0-tests.jar
> (SHA1: 3536d25398f6f6ac22deb9e446515056191661f7)
> bcel-6.0-javadoc.jar
> (SHA1: e47a109aa7416329a9970f0900136cb355af8ac8)
> bcel-6.0-sources.jar
> (SHA1: 206dfd32271b9b0150d8211070e5dbbe69cf5154)
>
> I've tested with Java 7 & 8 using Maven 3.3.9
>
> 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-RC8/changes-report.html
>
> Site:
>   http://home.apache.org/~britter/commons/bcel/6.0-RC8
> (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-RC8/clirr-report.html
>
> Note that Clirr reports several errors.
> These are considered OK for the reasons stated below.
> These exceptions are also noted in the Changes and Release Notes.
>
> Errors reported:
> - methods added to org.apache.bcel.classfile.Visitor interface: OK
> because that does not affect binary compatibility.
> - Removed java.io.Serializable from all classes: OK, because we don't
> expect anybody to rely on serialization for BCEL classes
> - Return type of method 'public java.lang.Object getElementAt(int)' has
> been changed to java.lang.String in class 
> org.apache.bcel.verifier.VerifierFactoryListModel:
> OK, because this class is part of an UI application and for this reason
> should only used by Swing.
>
> RAT Report:
>   http://home.apache.org/~britter/commons/bcel/6.0-RC8/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 23:00 CEST 13-July 2016
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thank you!
> Benedikt
>
>