-1 There are some blocking issues needing resolved, and the version itself seems off, both of which I'll elaborate on below. Beyond these I verified the assemblies as usual in terms of running the build, verifying checksums, licences etc and all seemed well other than the issues noted.
First, the version itself. Considering the JIRAs listed and related changes in them from just a quick skim, the 9.0.1 version doesn't actually seem appropriate given some of the very significant non-bugfix changes that have been made in the ~9 months since 9.0.0, various of which have at least some scope for breaking existing things people might be doing with 9.0.0. Seems like at minimum a 9.1.0 release at this point if not more. E.g: - Updating from Jetty 9 to Jetty 11, itself significant but even more so in that it is also a switch from using javax to jakarta API packages. - SLF4J switched from 1.x to 2.x, which though API compatible, has an incompatible logging impl registration system and so can actually 'break' things applications do. - Significant 'clean up' that while hopefully non-impacting/behavioural, is significant churn and certainly doesnt seem suited to what appears named like a bug-fix release. - Swapping the tests from JUnit 4 to JUnit 5, though clearly that's mainly internal, would still seem unusual like the above. Beyond the version seeming off, there are some actual problems with the code/build/packages also needing addressed. The broker assembly is defaulting to DEBUG (or higher) level output to the console unlike previously. It is still only doing INFO to the log file. Perhaps related to the SLF4J change, though it would be quite odd given a recent Logback is being used, so maybe it's more likely the Logback change itself which is the issue. Or maybe just a wayward testing config change was committed. Who knows. There are some licence related changes around the updates that are also needed. Skimming the diff I noticed an unsuitable licenceMerge config addition for the licence plugin: https://github.com/apache/qpid-broker-j/blob/2f99658e57b0cb3b2cad9c354aaf73f304dee870/pom.xml#L1675 The 'GPL2 w/ CPE' ID on its own is definitely not a merge candidate with the dual-licensed CDDL entries. We are allowed to ship CDDL bits which is why those are there, but are not allowed to ship GPL-only bits. That config should be removed. Since this was added as part of https://github.com/apache/qpid-broker-j/commit/2f99658e57b0cb3b2cad9c354aaf73f304dee870 to update Jetty it also seemed unnecessary anyway, as Jetty is ASLv2 or EPL 2.0 licenced overall. If there was something tripping up on a dual-licensed thing then it may be a candidate for exclusion from the check instead (noticing the Logback one in the config above that). But definitely not merging 'GPL2 w/ CPE' into the CDDL entries. Actually, digging further I notice the same commit added a couple of jakarta spec deps (based on the DEPENDENCIES_REFERENCE file [1] changes shown) which did reference 'GPL2 w/ CPE' so it may have been something around those...though they were also EPL 2.0 licensed, and so that would be what we select as we can actually ship that. I see those spec deps have since been removed as unnecessary, however the incorrect licenceMerge config remains. Also, no entry was added for them in the binary assembly LICENCE [2] file which there should have been, but clearly thats no longer an issue now as they were later removed again. Looking at the wider changes from 9.0.0 to now though for the DEPENDENCIES_REFERENCE [1] file for the assembly, and indeed the actual binary assembly contents themselves, another change to the reference that should have flagged a potential change to the LICENCE [2] file was the addition of multiple Bouncy Castle deps (bcpkix-jdk18on, bcprov-jdk18on, bcutil-jdk18on) [3]. An entry for those should have been, but wasnt, added to the binary assembly LICENCE file since they are MIT licensed (the noted Bouncy Castle Licence https://www.bouncycastle.org/licence.html is just the MIT licence, as it mentions and a read confirms). [1] https://github.com/apache/qpid-broker-j/blob/main/apache-qpid-broker-j/src/main/assembly/dependency-verification/DEPENDENCIES_REFERENCE [2] https://github.com/apache/qpid-broker-j/blob/main/apache-qpid-broker-j/src/main/assembly/LICENSE [3] https://github.com/apache/qpid-broker-j/blob/f3703502e16e75c1df8c1f84e9de1afde6781e5f/apache-qpid-broker-j/src/main/assembly/dependency-verification/DEPENDENCIES_REFERENCE#L53-L60 Robbie On Wed, 9 Aug 2023 at 14:26, Tomas Vavricka <vavr...@apache.org> wrote: > > Hi all, > > I built release artifacts for Qpid Broker-J version 9.0.1 RC1. > Please, give them a test out and vote accordingly. > > The source and binary archives can be found at: > https://dist.apache.org/repos/dist/dev/qpid/broker-j/9.0.1-rc1/ > > The maven artifacts are also staged at: > https://repository.apache.org/content/repositories/orgapacheqpid-1265/ > > The new version brings a number of improvements and bug fixes. > You can find the full list of JIRAs included in the release here: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520&version=12352584 > > Regards, > Tomas > > P.S. For testing of maven broker staging repo artefacts, please add > into to your project pom the staging repo as below: > > <repositories> > <repository> > <id>staging</id> > > <url>https://repository.apache.org/content/repositories/orgapacheqpid-1265/</url> > </repository> > </repositories> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
