Flow: github.javaparser libraries are not OSGi compatible

[denis-anisimov]

There are a number of libraries which are introduced by fusion team :
com.github.javaparser: javaparser-core,javaparser-symbol-xxxx`

At least javaparser-symbol-solver-core is not an OSGi bundle.
I haven't checked the others but I'm pretty sure the same situation is for other dependencies as well.

As a result OSGi support is impossible for non-OSGI bundles.

These dependencies should be either removed, replaced with some OSGi compatible deps or they have to be repackaged so that they have OSGi compatible manifest (in the same way as it has been done with gentyref library).

[pleku]

Since Fusion depends on Spring Boot anyway, which is not OSGi compliant, the OSGi support for Fusion views is outside of scope for the current OSGi support.

But the question is that will those ^ non-OSGi compliant dependencies need to be excluded or something or is it just fine ?
It probably would be much easier, we've now learned, if the code for Fusion would not be shared in the flow-server artifact.

[knoobie]

It probably would be much easier, we've now learned, if the code for Fusion would not be shared in the flow-server artifact.

That would fix some other problems I saw with the dependencies introduced by fusion as well. https://github.com/vaadin/flow/issues/8588 and of course spring as a whole.

[stbischof]

I made a PR to fix this: https://github.com/javaparser/javaparser/pull/2824 (javaparser-core is a bundle,javaparser-symbol-solver-core not)

But it would be much better if the code for Fusion would not be shared in the flow-server artifact.
To import this dependencies just optional would be also a way. But not the cleanest.

[MysterAitch]

These dependencies should be either removed, replaced with some OSGi compatible deps or they have to be repackaged so that they have OSGi compatible manifest

Happy to help out on the JavaParser front with this, though I don't have any meaningful knowledge of the OSGi side of things.

Hopefully yourselves (with @stbischof 's PR) will be able to provide some guidance. I see that javaparser-core has a bnd.bnd file that we generate. Would providing a bnd.bnd file for javaparser-symbol-solver-core be enough to meet your needs? :)

[denis-anisimov]

But it would be much better if the code for Fusion would not be shared in the flow-server artifact.

That's for sure.

[denis-anisimov]

These dependencies should be either removed, replaced with some OSGi compatible deps or they have to be repackaged so that they have OSGi compatible manifest

Happy to help out on the JavaParser front with this, though I don't have any meaningful knowledge of the OSGi side of things.

Hopefully yourselves (with @stbischof 's PR) will be able to provide some guidance. I see that javaparser-core has a bnd.bnd file that we generate. Would providing a bnd.bnd file for javaparser-symbol-solver-core be enough to meet your needs? :)

bnd file is not the only file which is required. It's used by the maven plugin (see the pom file modification made by Stefan).
There can be also another ways to do the same : it's possible to inline OSGi manifest into pom file as a configuration and use another maven plugin.
But the provided PR should be enough at least for javaparser-symbol-solver-core.

[denis-anisimov]

It seems this library is used only either in maven plugin or in dev mode DevModeInitializer.
Since we explicitly exclude DevModeInitializer for OSGi it may be set as optional without any issue.
So this is the same situation as with http-client .

Proper fix for this should be :

• extract dev mode module from flow-server : long-requested thing.
• modularize Fusion functionality so that it works only if it's available (in the classpath). It will require dependency inversion which can be done via introduced Lookup in the 6.0 .

[stbischof]

@Maho7791, @juergen-albert

her is the other , we discussed

[haijian-vaadin]

The endpoint code has been moved to fusion-endpoint module in https://github.com/vaadin/flow/pull/9499, so this ticket can now be closed.