Bug 2223473

Copr build:
https://copr.fedorainfracloud.org/coprs/build/6180738
(failed)

Build log:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2223473-apache-commons-configuration/fedora-rawhide-x86_64/06180738-apache-commons-configuration/builder-live.log.gz

Please make sure the package builds successfully at least for Fedora Rawhide.

- If the build failed for unrelated reasons (e.g. temporary network
  unavailability), please ignore it.
- If the build failed because of missing BuildRequires, please make sure they
  are listed in the "Depends On" field


---
This comment was created by the fedora-review-service
https://github.com/FrostyX/fedora-review-service

If you want to trigger a new Copr build, add a comment containing new
Spec and SRPM URLs or [fedora-review-service-build] string.

fedora-review is broken in rawhide, so here's a manual review:

- package name matches other Apache commons-* projects
- latest version is packaged
- Summary / description are fine and correctly line-wrapped
- source archive contains only source files and no objectionable content
- source archive contains only files under Apache-2.0 license
- License matches upstream specification, license text included
- signature of source file verified with gpg
- Patch to update JEXL dependency to latest version documented and justified (not sure if it's worth upstreaming, Apache Commons is not the easiest project to contribute to)
- BuildRequires look sane (though I could not verify them, xmvn-builddep seems to be broken again)
- docs are built and included in a separate package
- removal of unnecessary maven plugins is fine and justified
- build uses standard mvn_build / mvn_install macros
- disabling tests due to missing dependencies for tests is OK (though you could look into whether you could just drop tests with missing dependencies and run the rest)
- disabling optional features due to missing dependencies is OK (I don't blame you for not wanting to package the Spring framework)
- included %files look sane

===

You can continue the unretirement process with releng after considering the following:

Previously, both apache-commons-configuration and apache-commons-configuration2 existed in Fedora, and commons-configuration2 (which is what we're looking at here) was packaged as apache-ommons-configuration2, while commons-configuration (version 1) was packaged as apache-commons-configuration.

Both have been retired for 5+ releases, but please check whether you want to package this as apache-commons-configuration2 (matches the upstream filename / jar name) or apache-commons-configuration (which was previously only for version 1).

Thank you for the review!

(In reply to Fabio Valentini from comment #2)
> - disabling tests due to missing dependencies for tests is OK (though you could look into whether you could just drop tests with missing dependencies and run the rest)

I gave that a try today.  I had to omit several missing dependencies (e.g., commons-dbcp2, commons-pool2, hsqldb).  Then there was an incompatibility with modern versions of javax.servlet that I had to patch around.  Then the test code refers to jakarta.mail instead of javax.mail, requiring another patch.  Then I found that the Fedora apache-commons-logging package disables log4j support, and the commons-configuration tests assume EVERYWHERE that log4j support is available via commons-logging.  At this point I am giving up.

> Previously, both apache-commons-configuration and
> apache-commons-configuration2 existed in Fedora, and commons-configuration2
> (which is what we're looking at here) was packaged as
> apache-ommons-configuration2, while commons-configuration (version 1) was
> packaged as apache-commons-configuration.

Considering the length of time that has passed, and the fact that nobody has requested the return of commons-configuration version 1, I think I would like to stick with the current naming.  If version 3 is ever released, my preference would be to introduce apache-commons-configuration2 to hold version 2 (if needed), and have apache-commons-configuration move on to version 3.

Sorry if you were waiting on confirmation from me here, I meant to say that whatever you decide is fine with me, I just wanted you to be aware of the history.

Yes, thank you.  I did not wait for you, in fact, but simply forgot to close this bug.  Thanks for the history.  That did help.