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

[Gary Gregory]

Ping for reviews :-)

Gary

On Wed, Jul 17, 2024 at 5:17 PM Rob Tompkins  wrote:
>
> +1, signatures, site, builds, and reports all look good. Send it!
>
> Thanks Gary!
>
> -Rob
>
> > On Jul 13, 2024, at 2:33 PM, Gary Gregory  wrote:
> >
> > We have fixed a few bugs and added enhancements since Apache Commons
> > BCEL 6.9.0 was released, so I would like to release Apache Commons
> > BCEL 6.10.0.
> >
> > Apache Commons BCEL 6.10.0 RC1 is available for review here:
> >https://dist.apache.org/repos/dist/dev/commons/bcel/6.10.0-RC1
> > (svn revision 70288)
> >
> > The Git tag commons-bcel-6.10.0-RC1 commit for this RC is
> > 907c61da34258b8ab70081056443818312e404f6 which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=907c61da34258b8ab70081056443818312e404f6
> > You may checkout this tag using:
> >git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
> > --branch commons-bcel-6.10.0-RC1 commons-bcel-6.10.0-RC1
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1759/org/apache/bcel/bcel/6.10.0/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Sat Jul 13 18:22:56 UTC 2024
> > bcel-6.10.0-bin.tar.gz=ba75885db9c7bec00664ed8eb092a3934090fd638801cf2754eed417748cfb81cf1dd15076891bfc53a3cf50fdb2e05d58cdd37bb30b6229d3a46acdf41921d7
> > bcel-6.10.0-bin.zip=40b666f0464c919d1b850114edbcf56eb651cb8d1893e0f6e3ce3cfb2e93452e919cdeebc3632effd693df56f988219886c98a22651d091dab5509c6ea3812a8
> > bcel-6.10.0-bom.json=aae703dd43bc609ab2a4f0e250a444c08291511f40353a606b05fb5154471302f7c04101189502e4380888d41d92dd9158736634871bbb462078dc08a1b2e183
> > bcel-6.10.0-bom.xml=81ec274c4b3fbdaeb8d97ae665b6497900d361984096231f40c9b5680e44536bab4abec1e080c39fc1a286f74e960ca6e15a353083765953d96a2584eb55fcd7
> > bcel-6.10.0-javadoc.jar=4ef2c43fbcd013d1f5d07558574054e6cbb72e4f56d44486690177f077d895f5c657330998b03b2441c8c733ebe8966715d97987f2c2a8c2ff659d14f8e9faa0
> > bcel-6.10.0-sources.jar=7a39946decb6d52fd0816b2c9bd788e5758e5610187ce78f59f904b64d8bcb472ecd6c10c22c7611130ff4eecd54b09cee09641fc2bd3e5087b3d1be2a489a25
> > bcel-6.10.0-src.tar.gz=7ea129a048bf510ed15212a17680dfa37fe8c4adcc75504fa9a6ff35ef97d25f267547ad019fe146cd2fea9a3ef0eaca432d4c9cac7570ba5e68897f21c29a14
> > bcel-6.10.0-src.zip=31fdbadebd4b57e58489e703db12d2f9b87a7e9e5abf212b15670e04e31a228025e0f28a00a89a0f2bb5ead1929ef0209b8e1bfc051de8ec13d15d7896602deb
> > bcel-6.10.0-test-sources.jar=896c32b7d1dc63154ccff94aef0fc5a4468ccb4ce20a273bd26ef45aa17c202396f9ae01258e2ed6c60ac61d12eff4d0a6ee00e05f9671fa87992a9e71b9bbc4
> > bcel-6.10.0-tests.jar=2cc637c64c5a1a695c2dc72eb283a10f46202b7845a9e0f5235ca6445b130dae74020698ec68f2ae7ac8b23a6bc68723b022ab084cc23783597d865a78f3c888
> > org.apache.bcel_bcel-6.10.0.spdx.json=832586017985e6bfe019d9fa8c797cf2bdf0d2e62fe0c09c1a0acbb7fb22d83891f9127967f719fe23950d11011388636ba3c66da9cad623ae2652276229b248
> >
> >
> >
> > I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy
> > -P jacoco -P japicmp clean package site deploy' using:
> >
> > openjdk version "17.0.11" 2024-04-16
> > OpenJDK Runtime Environment Homebrew (build 17.0.11+0)
> > OpenJDK 64-Bit Server VM Homebrew (build 17.0.11+0, mixed mode, sharing)
> >
> > Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256)
> > Maven home: /usr/local/Cellar/maven/3.9.8/libexec
> > Java version: 17.0.11, vendor: Homebrew, runtime:
> > /usr/local/Cellar/openjdk@17/17.0.11/libexec/openjdk.jdk/Contents/Home
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac"
> >
> > Darwin  23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:09:52
> > PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64
> >
> > Details of changes since 6.9.0 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.10.0-RC1/RELEASE-NOTES.txt
> >
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.10.0-RC1/site/changes-report.html
> >
> > Site:
> >
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.10.0-RC1/site/index.html
> >(note some *relative* links are broken and the 6.10.0 directories
> > are not yet created - these will be OK once the site is deployed.)
> >
> > JApiCmp Report (compared to 6.9.0):
> >
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.10.0-RC1/site/japicmp.html
> >
> > RAT Report:
> >
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.10.0-RC1/site/rat-report.html
> >
> > KEYS:
> >  https://downloads.apache.org/commons/KEYS
> >
> > Please review the release candidate and vote.
> > This vote will close no sooner than 72 hours from now.
> >
> >  [ ] +1 Release these artifacts
> >  [ ] +0 OK, but...
> >  [ ] -0 OK, but really should fix...
> >  [ ] -1 I oppose this release because...
> >
> > Thank you,
> >
> > Gary Gregory,
> > Release Manager (using key 86fdc7e2a11262cb)
> >
> > The foll

Issue: Tagged server response in IMAPReply / org.apache.commons.net.imap

[Andreas Lemke]

Hello,

I have found a possible issue is the IMAPReply class of 
org.apache.commons.net.imap.
Starting from Version 3.11.0 the length of the TAGGED_RESPONSE pattern was 
limited to 80 chars. In conjunction with m.matches() request at line 107 of 
the class, this leads to a MalformedServerReplyException, if the server 
reply exceeds 80 chars. This is because the matches() method returns "true 
if, and only if, the entire region sequence matches this matcher's pattern" 
(from JDK API documentation).

I found this issus using OpenJDK 21.0.4.
Maybe it is an option to use lookingAt() instead of matches() because it 
does not require the match of the entire region.


In my case the IMAP server answered to a LOGIN with the following line, 
longer than 80 chars:


 OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT 
SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT 
MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS 
LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN 
CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY PREVIEW=FUZZY PREVIEW 
STATUS=SIZE SAVEDATE XLIST LITERAL+ NOTIFY SPECIAL-USE] Logged in


Kind regards,

Andreas

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

Re: Issue: Tagged server response in IMAPReply / org.apache.commons.net.imap

[Gary Gregory]

Hi Andreas,

Thank for your reply.

I can bump up the limit for the next release and also (maybe) make it
configurable. We definitely want to keep a limit though.

In the meantime, if you make the change locally with a local build, what is
the longest string you see IRL?

Gary

On Sat, Jul 20, 2024, 12:21 PM Andreas Lemke <
i...@systementwicklung-lemke.de> wrote:

> Hello,
>
> I have found a possible issue is the IMAPReply class of
> org.apache.commons.net.imap.
> Starting from Version 3.11.0 the length of the TAGGED_RESPONSE pattern was
> limited to 80 chars. In conjunction with m.matches() request at line 107
> of
> the class, this leads to a MalformedServerReplyException, if the server
> reply exceeds 80 chars. This is because the matches() method returns "true
> if, and only if, the entire region sequence matches this matcher's
> pattern"
> (from JDK API documentation).
> I found this issus using OpenJDK 21.0.4.
> Maybe it is an option to use lookingAt() instead of matches() because it
> does not require the match of the entire region.
>
> In my case the IMAP server answered to a LOGIN with the following line,
> longer than 80 chars:
>
>  OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT
> SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT
> MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS
> LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN
> CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY PREVIEW=FUZZY PREVIEW
> STATUS=SIZE SAVEDATE XLIST LITERAL+ NOTIFY SPECIAL-USE] Logged in
>
> Kind regards,
>
> Andreas
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>