Re: [VOTE] Release Commons Email 1.5 Based on RC1
On 30 July 2017 at 16:30, Matt Sicker wrote: > If the build is anything like Log4j's, it probably has a separate rat > config for the release profile than it does by default. If rat and Clirr are run as part of the the site build they use the report settings whereas 'mvn clirr:check' will use the build settings. The build and report section configs need to agree. > On 30 July 2017 at 10:27, Gary Gregory wrote: > >> I always run: >> >> mvn apache-rat:check >> >> And >> >> mvn clirr:check >> >> Gary >> >> On Jul 30, 2017 07:12, "Stefan Bodewig" wrote: >> >> > On 2017-07-30, Gary Gregory wrote: >> > >> > > Branding: The RELEASE-NOTES.txt file should start with "Apache Commons >> > > Email Package" instead of "Commons Email Package". >> > >> > I was under the impression it had been generated by the commons-build >> > plugin. Anyway, will fix it when I publish the release (no reason to >> > vote on that). >> > >> > > RAT check fails with: >> > >> > > Unapproved licenses: >> > >> > > src/test/resources/eml/attachment-only.eml >> > > src/test/resources/eml/html-attachment-content-disposition.eml >> > > src/test/resources/eml/html-attachment-encoded-filename.eml >> > > src/test/resources/eml/html-attachment.eml >> > > src/test/resources/eml/multipart-report.eml >> > > src/test/resources/eml/multipart-text-attachment-only.eml >> > > src/test/resources/eml/multipart-text-attachment.eml >> > > src/test/resources/eml/outofmemory-no-header-seperation.eml >> > > src/test/resources/eml/simple-reply.eml >> > > src/test/resources/eml/simple.eml >> > >> > The pom contains >> > >> > >> > org.apache.rat >> > apache-rat-plugin >> > >> > >> > src/test/resources/eml/*.eml >> > >> > >> > >> > >> > and RAT is prefectly happy inside the site build. How do you execute the >> > rat check? Comparing the POM with the one of Compress I see the plugin >> > is configured inside the section for Email only, while it is >> > inside for Compress. This may explain the difference when >> > running rat checks directly. >> > >> > Stefan >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> > > > > -- > Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Language level, Class files, MRJARs & versioning (was Re: [collections][proposal] Java 7)
On Sun, Jul 30, 2017 at 8:37 AM, Simon Spero wrote: > Class file format is not treated as a breaking change under most versioning > approaches, including the JLS. > > The checkers I looked at that reported on class file format changes > consider it a micro level version change (+0.0.1) > > The past few major version bumps for projects I've worked happened to > coincide with Java version bumps, but they involved major uses of new > features like annotations / try-with-resources / lambda + streams. > > These changes were of necessity Major, since there was no default method > support until 8. > > Now... MRJARs ( http://openjdk.java.net/jeps/238 ) > TL;DR; MRJARs are a mess. Temperature to be determined. > Agreed. For me, for now, PASS. We've dealt with MR-JARs over at Log4j and it makes a mess in tooling and IDEs. Gary > > With Java 9, there is now technically the capability to have multiple > versions of classes, targeting different language levels, in the same jar > file. This was supposed to be back ported to 8, but that got lost along the > way, so currently it's only usable for 9/ <9. > There's only minimal support at the tool level (threads with maven / gradle > samples, with authors' apologies :). > > There's also no easy way to write code with conditional compilation blocks > (e.g. in jdk9 there's a new interface method in added to j.u.zip.Checksum > that is pulled up from CRC32; there's no easy way to write source code to > use the method when compiling for jdk 9 but do instanceof CRC32 / call > virtual if jdk8. Templates or CPP are less than ideal (see ByteBuffer and > friends). > > There are some places in commons where a JDK 9 library addition is > important. For example, codec has a CRC32C implementation, and now so does > jdk 9; both are pure Java slice-by-eight... except the jdk version has > annotations marking critical methods as hotspot intrinsic candidates, which > means that on most major machines the Java code will be ignored in favor of > hardware supported carryless multiplication if available. > > Coding for multi release jars is something that might be worth developing > code & policies for; some of this waiting on maven plugin changes, but > arranging source trees, minimizing copy & paste, and making sure that the > right tests are run in the right environments is more awkward (e.g. do > some/all unit tests now have to run after package, as if they were > integration tests? Are tests multi-versioned? ). > > And returning to the original topic, what should happen to version numbers > if the Java 9 class needs a minor version bump, but the Java < 9 version > doesn't. > > > On Jul 28, 2017 8:41 AM, "Rob Tompkins" wrote: > > > > On Jul 27, 2017, at 12:53 PM, Gary Gregory > wrote: > > > > We have not in the past forced a major version and Maven coordinate > change > > when updating the Java platform. We could do that of course. > > I’m a tad surprised by this. It feels like updating the minimum > accommodated java version would necessitate a major version change. > > -Rob > > > > > Gary > > > > On Jul 27, 2017 06:47, "Jochen Wiedmann" > wrote: > > > >> Wouldn't that make it 5.0? (Binary incompatible change) > >> > >> Note: I am not opposing the change, I just propose an additional > >> change in the version number. > >> > >> Jochen > >> > >> > >> On Wed, Jul 26, 2017 at 12:18 AM, Gary Gregory > >> wrote: > >>> Hi All: > >>> > >>> I propose we make Java 7 the minimum for Commons Collection 4.2. > >>> > >>> Gary > >> > >> > >> > >> -- > >> 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 >
Language level, Class files, MRJARs & versioning (was Re: [collections][proposal] Java 7)
Class file format is not treated as a breaking change under most versioning approaches, including the JLS. The checkers I looked at that reported on class file format changes consider it a micro level version change (+0.0.1) The past few major version bumps for projects I've worked happened to coincide with Java version bumps, but they involved major uses of new features like annotations / try-with-resources / lambda + streams. These changes were of necessity Major, since there was no default method support until 8. Now... MRJARs ( http://openjdk.java.net/jeps/238 ) TL;DR; MRJARs are a mess. Temperature to be determined. With Java 9, there is now technically the capability to have multiple versions of classes, targeting different language levels, in the same jar file. This was supposed to be back ported to 8, but that got lost along the way, so currently it's only usable for 9/ <9. There's only minimal support at the tool level (threads with maven / gradle samples, with authors' apologies :). There's also no easy way to write code with conditional compilation blocks (e.g. in jdk9 there's a new interface method in added to j.u.zip.Checksum that is pulled up from CRC32; there's no easy way to write source code to use the method when compiling for jdk 9 but do instanceof CRC32 / call virtual if jdk8. Templates or CPP are less than ideal (see ByteBuffer and friends). There are some places in commons where a JDK 9 library addition is important. For example, codec has a CRC32C implementation, and now so does jdk 9; both are pure Java slice-by-eight... except the jdk version has annotations marking critical methods as hotspot intrinsic candidates, which means that on most major machines the Java code will be ignored in favor of hardware supported carryless multiplication if available. Coding for multi release jars is something that might be worth developing code & policies for; some of this waiting on maven plugin changes, but arranging source trees, minimizing copy & paste, and making sure that the right tests are run in the right environments is more awkward (e.g. do some/all unit tests now have to run after package, as if they were integration tests? Are tests multi-versioned? ). And returning to the original topic, what should happen to version numbers if the Java 9 class needs a minor version bump, but the Java < 9 version doesn't. On Jul 28, 2017 8:41 AM, "Rob Tompkins" wrote: > On Jul 27, 2017, at 12:53 PM, Gary Gregory wrote: > > We have not in the past forced a major version and Maven coordinate change > when updating the Java platform. We could do that of course. I’m a tad surprised by this. It feels like updating the minimum accommodated java version would necessitate a major version change. -Rob > > Gary > > On Jul 27, 2017 06:47, "Jochen Wiedmann" wrote: > >> Wouldn't that make it 5.0? (Binary incompatible change) >> >> Note: I am not opposing the change, I just propose an additional >> change in the version number. >> >> Jochen >> >> >> On Wed, Jul 26, 2017 at 12:18 AM, Gary Gregory >> wrote: >>> Hi All: >>> >>> I propose we make Java 7 the minimum for Commons Collection 4.2. >>> >>> Gary >> >> >> >> -- >> 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 Commons Email 1.5 Based on RC1
If the build is anything like Log4j's, it probably has a separate rat config for the release profile than it does by default. On 30 July 2017 at 10:27, Gary Gregory wrote: > I always run: > > mvn apache-rat:check > > And > > mvn clirr:check > > Gary > > On Jul 30, 2017 07:12, "Stefan Bodewig" wrote: > > > On 2017-07-30, Gary Gregory wrote: > > > > > Branding: The RELEASE-NOTES.txt file should start with "Apache Commons > > > Email Package" instead of "Commons Email Package". > > > > I was under the impression it had been generated by the commons-build > > plugin. Anyway, will fix it when I publish the release (no reason to > > vote on that). > > > > > RAT check fails with: > > > > > Unapproved licenses: > > > > > src/test/resources/eml/attachment-only.eml > > > src/test/resources/eml/html-attachment-content-disposition.eml > > > src/test/resources/eml/html-attachment-encoded-filename.eml > > > src/test/resources/eml/html-attachment.eml > > > src/test/resources/eml/multipart-report.eml > > > src/test/resources/eml/multipart-text-attachment-only.eml > > > src/test/resources/eml/multipart-text-attachment.eml > > > src/test/resources/eml/outofmemory-no-header-seperation.eml > > > src/test/resources/eml/simple-reply.eml > > > src/test/resources/eml/simple.eml > > > > The pom contains > > > > > > org.apache.rat > > apache-rat-plugin > > > > > > src/test/resources/eml/*.eml > > > > > > > > > > and RAT is prefectly happy inside the site build. How do you execute the > > rat check? Comparing the POM with the one of Compress I see the plugin > > is configured inside the section for Email only, while it is > > inside for Compress. This may explain the difference when > > running rat checks directly. > > > > Stefan > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- Matt Sicker
Re: [VOTE] Release Commons Email 1.5 Based on RC1
I always run: mvn apache-rat:check And mvn clirr:check Gary On Jul 30, 2017 07:12, "Stefan Bodewig" wrote: > On 2017-07-30, Gary Gregory wrote: > > > Branding: The RELEASE-NOTES.txt file should start with "Apache Commons > > Email Package" instead of "Commons Email Package". > > I was under the impression it had been generated by the commons-build > plugin. Anyway, will fix it when I publish the release (no reason to > vote on that). > > > RAT check fails with: > > > Unapproved licenses: > > > src/test/resources/eml/attachment-only.eml > > src/test/resources/eml/html-attachment-content-disposition.eml > > src/test/resources/eml/html-attachment-encoded-filename.eml > > src/test/resources/eml/html-attachment.eml > > src/test/resources/eml/multipart-report.eml > > src/test/resources/eml/multipart-text-attachment-only.eml > > src/test/resources/eml/multipart-text-attachment.eml > > src/test/resources/eml/outofmemory-no-header-seperation.eml > > src/test/resources/eml/simple-reply.eml > > src/test/resources/eml/simple.eml > > The pom contains > > > org.apache.rat > apache-rat-plugin > > > src/test/resources/eml/*.eml > > > > > and RAT is prefectly happy inside the site build. How do you execute the > rat check? Comparing the POM with the one of Compress I see the plugin > is configured inside the section for Email only, while it is > inside for Compress. This may explain the difference when > running rat checks directly. > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [VOTE] Release Commons Email 1.5 Based on RC1
On 2017-07-30, Amey Jadiye wrote: > I have fixed this, and yes reason was though those .eml files was added in > exclusion but in reports and not in build. > I have raised PR and tested it on my local. > https://github.com/apache/commons-email/pull/2 LGTM, but please allow us to get the release out of the door before changung trunk :-) Thanks Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Email 1.5 Based on RC1
Hi, I have fixed this, and yes reason was though those .eml files was added in exclusion but in reports and not in build. I have raised PR and tested it on my local. https://github.com/apache/commons-email/pull/2 Regards, Amey On Sun, Jul 30, 2017 at 7:42 PM, Stefan Bodewig wrote: > On 2017-07-30, Gary Gregory wrote: > > > Branding: The RELEASE-NOTES.txt file should start with "Apache Commons > > Email Package" instead of "Commons Email Package". > > I was under the impression it had been generated by the commons-build > plugin. Anyway, will fix it when I publish the release (no reason to > vote on that). > > > RAT check fails with: > > > Unapproved licenses: > > > src/test/resources/eml/attachment-only.eml > > src/test/resources/eml/html-attachment-content-disposition.eml > > src/test/resources/eml/html-attachment-encoded-filename.eml > > src/test/resources/eml/html-attachment.eml > > src/test/resources/eml/multipart-report.eml > > src/test/resources/eml/multipart-text-attachment-only.eml > > src/test/resources/eml/multipart-text-attachment.eml > > src/test/resources/eml/outofmemory-no-header-seperation.eml > > src/test/resources/eml/simple-reply.eml > > src/test/resources/eml/simple.eml > > The pom contains > > > org.apache.rat > apache-rat-plugin > > > src/test/resources/eml/*.eml > > > > > and RAT is prefectly happy inside the site build. How do you execute the > rat check? Comparing the POM with the one of Compress I see the plugin > is configured inside the section for Email only, while it is > inside for Compress. This may explain the difference when > running rat checks directly. > > Stefan > > - > 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: [email] failing with mvn clean cobertura:cobertura coveralls:report
On 2017-07-30, Amey Jadiye wrote: > while fixing rat issue with commons email I also found that the travis is > failing with the below configurations, thought build is working fine. > seems like we dont have plugin configured in pom.xml > after_success: > - mvn clean cobertura:cobertura coveralls:report coveralls seems to be configured inside the parent POM and has been added there with parent 42. Email still uses parent version 40. I'll update the parent in trunk after the release has been published. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Email 1.5 Based on RC1
On 2017-07-30, Gary Gregory wrote: > Branding: The RELEASE-NOTES.txt file should start with "Apache Commons > Email Package" instead of "Commons Email Package". I was under the impression it had been generated by the commons-build plugin. Anyway, will fix it when I publish the release (no reason to vote on that). > RAT check fails with: > Unapproved licenses: > src/test/resources/eml/attachment-only.eml > src/test/resources/eml/html-attachment-content-disposition.eml > src/test/resources/eml/html-attachment-encoded-filename.eml > src/test/resources/eml/html-attachment.eml > src/test/resources/eml/multipart-report.eml > src/test/resources/eml/multipart-text-attachment-only.eml > src/test/resources/eml/multipart-text-attachment.eml > src/test/resources/eml/outofmemory-no-header-seperation.eml > src/test/resources/eml/simple-reply.eml > src/test/resources/eml/simple.eml The pom contains org.apache.rat apache-rat-plugin src/test/resources/eml/*.eml and RAT is prefectly happy inside the site build. How do you execute the rat check? Comparing the POM with the one of Compress I see the plugin is configured inside the section for Email only, while it is inside for Compress. This may explain the difference when running rat checks directly. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[email] failing with mvn clean cobertura:cobertura coveralls:report
Hi, while fixing rat issue with commons email I also found that the travis is failing with the below configurations, thought build is working fine. seems like we dont have plugin configured in pom.xml after_success: - mvn clean cobertura:cobertura coveralls:report [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 5.066 s [INFO] Finished at: 2017-07-30T13:15:04+00:00 [INFO] Final Memory: 17M/490M [INFO] [ERROR] No plugin found for prefix 'coveralls' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/home/travis/.m2/repository), central (https://repo.maven.apache.org/maven2)] -> [Help 1] [ERROR] Regards, Amey - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Email 1.5 Based on RC1
Checked RC1, and here is my +1 (non-binding). 1. Build and Tests looks good. 2. Clirr looks good. 3. Rat is not good as mentioned by gary, as they are test resources can be put to ignore list. 4. Findbug looks good. 5. There are 302 Checkstyle issues but they are non-blocker to release. 6. Hashes looks good. 7. Site looks good. Checked on :- Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T22:11:47+05:30) Maven home: /opt/apache/maven Java version: 1.8.0_111, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-oracle/jre Default locale: en_IN, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-31-generic", arch: "amd64", family: "unix" On Sat, Jul 29, 2017 at 7:54 PM, Stefan Bodewig wrote: > We have fixed quite a few bugs and added some significant enhancements > since Email 1.4 was released, so I would like to release Email 1.5. > > Email 1.5 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/email/ > (svn revision 20667) > > The tag is here: > http://svn.apache.org/repos/asf/commons/proper/email/tags/ > EMAIL_1_5_RC1/ > (svn revision 1803366) > N.B. the SVN revision is required because SVN tags are not immutable. > > Maven artifacts are here: > https://repository.apache.org/content/repositories/ > orgapachecommons-1255/org/apache/commons/commons-email/1.5/ > > These are the Maven artifacts and their SHA1 hashes > > e8e677c6362eba14ff3c476ba63ccb83132dbd52 commons-email-1.5.jar > 6ccc8b44cb666b849b71ecc6fa32549a6461c099 commons-email-1.5-javadoc.jar > 09d31911480b5148275d8a26c60e355bbcbe9ae3 commons-email-1.5.pom > dbe951d1b89eb9472b4b2c8f618b8bc9783b6623 commons-email-1.5-sources.jar > 15afde52264e316438802b5bd05d34bc424bf659 commons-email-1.5-tests.jar > e157492dfd776839387a6ce4af0d191e0a92a534 commons-email-1.5-test- > sources.jar > > I have tested this with JDK 8 using Maven 3.0.5. > > As usual when I cut a release the site is not the one I'll publish > once the vote has succeeded. I'll recreate the site once the release > date is known. > > I've already copied the javadocs for 1.4 so > http://commons.apache.org/proper/commons-email/javadocs/api-1.4/index.html > already is available. The javadoc links and download page certainly > don't work in the staging site. > > Details of changes since 1.4 are in the release notes: > https://dist.apache.org/repos/dist/dev/commons/email/RELEASE-NOTES.txt > https://stefan.samaflost.de/staging/commons-email-1.5/ > changes-report.html > > Site: > https://stefan.samaflost.de/staging/commons-email-1.5/ > > Clirr Report (compared to 1.4): > https://stefan.samaflost.de/staging/commons-email-1.5/ > clirr-report.html > > RAT Report: > https://stefan.samaflost.de/staging/commons-email-1.5/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 14:30 UTC 1-Aug 2017 > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thanks! > > - > 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
[GitHub] commons-codec pull request #4: commons-codec
Github user asfgit closed the pull request at: https://github.com/apache/commons-codec/pull/4 --- 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 enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-codec pull request #1: More tests
Github user asfgit closed the pull request at: https://github.com/apache/commons-codec/pull/1 --- 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 enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-text pull request #58: Add tests
Github user asfgit closed the pull request at: https://github.com/apache/commons-text/pull/58 --- 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 enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-text issue #58: Add tests
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-text/pull/58 Thanks! :+1: --- 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 enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
