What are the nature of the complaints?

Packages that do something like "build-classpath javax.activation" (e.g. sometimes ant-based packages) can be fixed by adding a compatibility symlink with "%mvn_file" to the jakarta-activation package

Compilation failures (esp. in maven-based packages) could be because they assumed the presence of activation in the JDK and probably just need "%pom_add_dep jakarta-activation-whatever" to the failing package

Right, I think the compat symlink is missing, which should fix some packages.

I found some projects where this is a problem, including geronimo-saaj:

[ERROR] /builddir/build/BUILD/geronimo-saaj_1.3_spec-1.1/src/main/java/javax/xml/soap/AttachmentPart.java:[22,24] package javax.activation does not exist
[ERROR] /builddir/build/BUILD/geronimo-saaj_1.3_spec-1.1/src/main/java/javax/xml/soap/AttachmentPart.java:[155,21] cannot find symbol
  symbol:   class DataHandler
  location: class javax.xml.soap.AttachmentPart
[ERROR] /builddir/build/BUILD/geronimo-saaj_1.3_spec-1.1/src/main/java/javax/xml/soap/AttachmentPart.java:[168,41] cannot find symbol
  symbol:   class DataHandler
  location: class javax.xml.soap.AttachmentPart
[ERROR] /builddir/build/BUILD/geronimo-saaj_1.3_spec-1.1/src/main/java/javax/xml/soap/SOAPMessage.java:[21,24] package javax.activation does not exist
[ERROR] /builddir/build/BUILD/geronimo-saaj_1.3_spec-1.1/src/main/java/javax/xml/soap/SOAPMessage.java:[177,48] cannot find symbol
  symbol:   class DataHandler
  location: class javax.xml.soap.SOAPMessage

This also occurrs in httpunit, istack-commons, log4j, openas2, xmlunit.

I will try if %pom_add_dep foo will help.

Update:

Adding %pom_add_dep com.sun.activation:jakarta.activation and BuildRequires: mvn(%pom_add_dep com.sun.activation:jakarta.activation) to the packages fixed most of them.

istack-commons fails somewhere in the test suite with cryptic errors, and xmlunit complains about missing jaxb 2.3.0 dependencies on Java 11.

Update:
Adding %pom_add_dep com.sun.activation:jakarta.activation and BuildRequires: mvn(%pom_add_dep com.sun.activation:jakarta.activation) to the packages fixed most of them.
istack-commons fails somewhere in the test suite with cryptic errors, and xmlunit complains about missing jaxb 2.3.0 dependencies on Java 11.

Yeah, jaxb and activation often come hand-in-hand. See for example my fix for "stax-ex" package: https://src.fedoraproject.org/rpms/stax-ex/c/97577a92d561f36ce769213e505bce33151591fe

@mbooth whoa I have no idea what magic you did there :D

Would it be too much to ask to look at these packages and see if they need a similar fix?

• glassfixh-jax-rs-api
• jboss-jaxrs-2.0-api
• jgroups
• jmock
• xmlunit

Sure I can take a quick look

Hi, the following are leaf packages that do not seem to be required by anything:

• glassfixh-jax-rs-api
• jgroups
• jmock

How about retiring them instead?

@mbooth sadly, not true, at least for two packages:

glassfish-jax-rs-api:

BuildRequired-By: jackson-jaxrs-providers
BuildRequired-By: jsonp
BuildRequired-By: osgi-compendium

jgroups: seems to really be a leaf

jmock:

Required-By: jmock-example
Required-By: jmock-junit3
Required-By: jmock-junit4
Required-By: jmock-legacy

jmock-junit3:

Required-By: jmock-example

jmock-junit4:

Required-By: jmock-example
BuildRequired-By: disruptor

jmock-legacy:

BuildRequired-By: disruptor

jmock-testjar:

Required-By: jmock

Looks like you either didn't include all subpackages in your query, or didn't include the source repo. :)

But I'm fine with letting jgroups die.

How are you querying??

Here I'm querying all subpackages of jmock, against both binary and source repos, and it does not yield disruptor:

$ for p in jmock-junit3 jmock-junit4 jmock-legacy ; do echo $p ; sudo dnf repoquery --alldeps --whatrequires $p ; sudo dnf repoquery --disablerepo=* --enablerepo=*-source --arch=src --alldeps --whatrequires $p ; echo ; done

jmock-junit3
Last metadata expiration check: 0:10:24 ago on Mon 20 Jul 2020 20:30:49 BST.
jmock-example-0:2.8.2-10.fc32.noarch
Last metadata expiration check: 0:12:30 ago on Mon 20 Jul 2020 20:28:45 BST.

jmock-junit4
Last metadata expiration check: 0:10:27 ago on Mon 20 Jul 2020 20:30:49 BST.
jmock-example-0:2.8.2-10.fc32.noarch
Last metadata expiration check: 0:12:33 ago on Mon 20 Jul 2020 20:28:45 BST.

jmock-legacy
Last metadata expiration check: 0:10:31 ago on Mon 20 Jul 2020 20:30:49 BST.
Last metadata expiration check: 0:12:37 ago on Mon 20 Jul 2020 20:28:45 BST.

I'm making the only magic invocation that I found to yield complete results :frowning:

dnf --installroot /tmp/dnf --releasever rawhide --repo rawhide --repo rawhide-source repoquery --whatrequires jmock-junit4
Last metadata expiration check: 0:19:39 ago on Mon 20 Jul 2020 21:30:22 CEST.
disruptor-0:3.4.2-1.fc33.src
jmock-example-0:2.8.2-10.fc32.noarch

Errr, come in dnf, what the fuck, over.

The problem with sudo dnf repoquery --disablerepo=* --enablerepo=*-source --arch=src --alldeps --whatrequires $p is that no src arch package depends on any other src arch dep.

Yeah, repoquery is not user friendly.

Which is why I did this in my bashrc:

alias dnfraw='dnf --installroot=/tmp/dnf/ --repo rawhide --repo rawhide-source --releasever rawhide'

so I only have to do dnfraw repoquery --foo and don't have to remember the correct command line :(