Compilation error in resolving a package in site/pom.xml, during v12.6.9 to v13.4.2 upgrade

Hello! I’m currently trying to upgrade brxp from 12.6.9 to 13.4.3. I’ve followed the upgrade steps listed here https://documentation.bloomreach.com/13/about/upgrade/introduction.html and I’m unable to compile the project. I have a custom class inside site module that extends “AbstractAsynchronousComponentWindowRenderer” from hst-core.jar . The jar is also available in 13.4.2 and I added the right dependency to the site/pom.xml

When I try to import with the package “import org.hippoecm.hst.core.container.*”, where this class is located - the project is importing classes from “hst-api.jar” instead of “hst-core.jar” and this is leading to a compilation error. More than bloomreach, seems to be a simple dependency resolution issue.

Would really appreciate any ideas or help to resolve this, if others have experienced anything similar!

@Tom_Roelfsema
Apologies for troubling you bro.
Would really appreciate any help to resolve this issue.
Thanks in advance.

As AbstractAsynchronousComponentWindowRenderer just implements AsynchronousComponentWindowRenderer interface in hst-api with a minimal implementation (only the simple #createAsyncComponentRenderingURL()), I’d change the custom code to directly implement the interface and copy the method to the custom class, dropping the dependency on AbstractAsynchronousComponentWindowRenderer.

Regards,

Woonsan

HTH
Thank you for the quick response @woonsanko

@woonsanko
We also have a similar issue where we have added “hst-core” dependency in our site/pom.xml and added import statement to our java class.

import org.hippoecm.hst.site.request.ResolvedSiteMapItemImpl;

But it results in compilation failure. PFB error details.

[ERROR] C:\Workspace\xxxx\site\src\main\java\xxxx\common\request\xxxxxxx.java:[182,19] error: cannot find symbol
[ERROR] symbol: class ResolvedSiteMapItemImpl
[ERROR] location: class xxxxxxxxxxxxxxxx

Note that you shouldn’t be adding hst-core to the site application starting from v13. If you relied on it before, find a way to refactor the code so you don’t rely on the jar anymore