revAPI breaking for an xwiki depedency evolution (10.11)

Development
, ,
#1

Hello fellow XWikiers,

I am developping an app for XWiki 10.11 and I encounter an annoying issue: My app is moving from 9.x to 10.x and I have already made some release candidates. Now, however, I get a revapi error because :

[INFO] java.class.nonFinalClassInheritsFromNewClass: class org.xwiki.model.reference.DocumentReference: Non-final class now inherits from ‘org.xwiki.model.reference.AbstractLocalizedEntityReference’. [org.xwiki.platform:xwiki-platform-model:jar:10.11]

This definitely seems like. change at XWiki dependencies side… And I have tried to, thus, avoid the revapi check of the XWiki dependencies.

The pom.xml of xwiki-platform-master sounds ike the best idea. But tthat failed. I also tried changing failCriticality but, again, the build keeps breaking unless I use -Drevapi.checkDependencies=false in the command-line.

What is the proper way to ignore revapi for which we trust there’s a team already checking?

thanks in advance.

Paul

#2

Dependency check is already disabled. The reason why revapi complains in your case is that you expose DocumentReference in one of your API thus making it part of it.

I would just add revapi ignores for this breakage (you should get a proposed configuration in the revapi error message).

See OIDC-76: Upgrade to oauth2-oidc-sdk 6.23 and nimbus-jose-jwt 8.6 · xwiki-contrib/oidc@9888874 · GitHub for an example (same situation).

#3

Thanks Thomas,

So that’s interesting. From the error message, you’d believe you can formulate some XML for the configuration and I did so in this commit but changing to JSON as OIDC-76 shows did work, see here.

thanks. Solved!

Paul

#4

Hello Thomas,
Actually, considering that the DocumentReference reference is only in the internal package, this should not fire, or?
paul

#5

@polx we looked at method return types but can you also check if you have a public API (not inside internal package) that has DocumentReference as parameter? If there’s no API method that receives as input or that returns DocumentReference then I find the revapi error strange.

#6

I did try it and can confirm that DocumentReference only appears within the internal package. I have added the necessary escapes… but clearly revapi is doing something incorrect.

paul

identity-oauth % git remote -v
origin	git@github.com:xwikisas/identity-oauth.git (fetch)
origin	git@github.com:xwikisas/identity-oauth.git (push)
identity-oauth % git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
identity-oauth % grep -r DocumentReference `find . -name "*.java" | grep -v target ` | wc -l
      19
identity-oauth % grep -r DocumentReference `find . -name "*.java" | grep -v target | grep -v intern` | wc -l
       0
#7

Maybe you only checked direct access to DocumentReference in your API, but it could be indirect like a class from a dependency that you expose in your API which itself expose DocumentReference, etc. DocumentReference is used quite a lot in various XWiki APIs.

#8

Hello @tmortagne,

I’m rewaking this thread, since it is blocking me to release: How could I check recursively?

The things revapi is bragging about now include:

  • [ERROR] java.class.defaultSerializationChanged: class com.xpn.xwiki.doc.XWikiLink: The default serialization ID for the class has changed. This means that the new version of the class is not deserializable from the byte stream of a serialized old class. [org.xwiki.platform:xwiki-platform-oldcore:jar:11.10]
  • [ERROR] java.method.addedToInterface: method java.net.URL com.xpn.xwiki.web.XWikiURLFactory::createSkinURL(java.lang.String, java.lang.String, java.lang.String, java.lang.String, com.xpn.xwiki.XWikiContext, java.util.Map<java.lang.String, java.lang.Object>): Method was added to an interface. [org.xwiki.platform:xwiki-platform-oldcore:jar:11.10]
  • [ERROR] java.method.parameterTypeChanged: parameter java.util.List com.xpn.xwiki.store.XWikiHibernateStore::search(===org.hibernate.query.Query===, int, int, com.xpn.xwiki.XWikiContext) throws com.xpn.xwiki.XWikiException: The type of the parameter changed from 'org.hibernate.Query' to 'org.hibernate.query.Query'. [org.xwiki.platform:xwiki-platform-oldcore:jar:11.10]

How can I search to grasp if something I have called has evolved in an incompatible manner?
Neither createSkinURL nor XWikiLink are words found in my source.
There are called to createQuery immediately followed by execute so that a change of type is completely irrelevant to me.

Maybe it would be simpler to also indicate how to skip revapi when invoking mvn release:prepare, adding -Dmaven.revapi.skip=true was not enough.

paul

#9

AFAIR you also need -Darguments="-Dmaven.revapi.skip=true", -Darguments can take all the skipping arguments you need for the release. Don’t forget to use the same arguments for release:perform

#10

Unfortunately not. The output extract above was obtained with mvn release:prepare -U -DautoVersionSubmodules=true -Pquality -DskipTests=true -Dmaven.revapi.skip=true -Darguments="-Dmaven.revapi.skip=true -DskipTests=true" (JDK 8 or 11).
paul

#11

That’s because it’s the wrong argument I think :slight_smile: Apparently I have in my scripts -Dxwiki.revapi.skip=true

#12

Thank you. That has worked!
One day there will be a way to remember how to properly prefix a skip :->…
paul

#13

The rule is:

  • any system property introduced by the xwiki dev team is prefixed with xwiki.

The harder part is knowing the prefix for properties not introduced by the XWiki dev team. You need to check the plugin doc for that. For the Revapi plugin it’s Revapi Maven Plugin – revapi:check , i.e. -Drevapi.skip=true

We’ve introduced -Dxwiki.revapi.skip=true but -Drevapi.skip=true should work just as fine normally (unless I’m wrong ofc :slight_smile: ).