Webjars are not OSGi compatible

[denis-anisimov]

Templates require polymer webjar at least.

This webjar has no any manifest and it's absolutely invisible for OSGi. As a result at the moment only plain WAR can be used within some OSGi server bundle if it allows it (which has no any relation to OSGi since it's just plain WAR file which should work in the same way as in any Servlet container). E.g. Jetty OSGi boot allows WAR file deployment (but this has no any relation to OSGi as I said).

I don't even know what to do here since webjars are not bundles and cannot be deployed to OSGI. So issue resolution looks impossible.

[denis-anisimov]

For the reference: https://github.com/webjars/webjars/issues/1307

[denis-anisimov]

A couple thing to note:

• at the moment webars are totally OSGi incompatible : there is no ANY manifest file inside the jar
• having only manifest file inside the jar file is not enough to make webjar work in OSGi: the resources are only inside Bundle and they are not visible outside the bundle. So we should be aware of that and somehow make them available via HTTP.

One way of making them available: register resource via HTTP service . It means we will need a bundle activator (or another way) which registers the resources via HttpService: so this is additional Java code.

Another way (which I'm not sure) : scan all bundles (and listen their registration) and register them inside Flow code somehow using the Bundle::getResource method. But I'm not sure whether openConnection() for the resulting URL will work outside the bundle where resource is located.

[denis-anisimov]

Issue for tests: #4421

[Sandared]

Maybe this issue can be solved. Webjars should soon be OSGi bundles with a proper manifest thanks to a new maven plugin.

Each webjar bundle will have a manifest based on maven information like this:

Bundle-SymbolicName: ${project.groupId}.${project.artifactId}
Bundle-Version: ${version.osgi} 
WebJars-Resource:\ 
    /META-INF/resources/webjars/${project.artifactId}/${project.version},\ 
    /webjars-requirejs.js 
Provide-Capability: org.webjars.osgi.dep;projectId:List<String>=${project.groupId},artifactId:List<String>=${project.artifactId},version:List<String>=${version.osgi}
Require-Capability: ${dependencies.osgi}

version.osgi is a version that is compliant to the description of OSGi versions

dependencies.osgi are the dependencies defined in the maven dependencies section, but expressed as proper Require-Capability filters so that those can be resolved by the OSGi resolver.

The contract of webjars' Provide-/Require-Capabilites looks like this:

Provide-Capability: org.webjars.osgi.deps;projectId:List<String>=${project.groupId},artifactId:List<String>=${project.artifactId},version:List<String>=${version.osgi} </br>
Require-Capability: org.webjars.osgi.deps;filter:="(&(groupId=${project.groupId})(artifactId=${project.artifactId})(version=${version.osgi}))", .... , ....

Additionally, all webjars bundles will provide a header, so that they can be filtered by a BundleTracker

WebJars-Resource:\ 
    /META-INF/resources/webjars/${project.artifactId}/${project.version},\ 
    /webjars-requirejs.js

This header points to all relevant resources within the bundle, which should easen the registration of those resources via the http whiteboard in OSGi

[denis-anisimov]

There still may be an issue with Servlet context.

We are parsing HTML files at least for PolymerTemplates and want them be available via Servlet context. Resources in the separate bundles won't be available via Servlet context.

I'm not sure about all places where we request the files from the servlet context.

[zhsc]

Hi denis, I would think we should be able to use the extender pattern and basically listen for bundles activating with the WebJars-Resource header and then register its resources to be known to Vaadin directly or to the HttpService which should then be available to vaadin. I believe Liferay does something similar for including javascript.

https://github.com/liferay/com-liferay-frontend-js/tree/master/frontend-js-top-head-extender

https://community.liferay.com/blogs/-/blogs/meet-the-extenders

I'm not familiar with the exact need Vaadin 10+ has in regard to parsing html. Is having a reference to the stream of the script enough? If so I believe this pattern should work.

Thanks!

[denis-anisimov]

Sure, we can find a solution for webjars once they become OSGi compatible.

There is still an open question about their availability via the Servlet context. We will need investigate this question. We parse a template file and it needs to be available via servlet context but this is a custom file and not a webjar. But I think there are other cases where we also parse HTML imports which may be webjars. This is a task for investigation for us. Hopefully the code which access to the servlet context is localized somewhere in the VaadinService.

About OSGi compatible webjars. This solution is very limited for now since there almost no any OSGi compatible webjars. So it requires some work from web component developer.

We may implement a way of handling OSGi compatible webjars later on. For now let's go with the repackaging way which always works even though it's a bit hacky way. This way will work also for those webjars that don't care about OSGi even though it's possible to make them OSGI compatible.

The "proper way" will be just an addition to the repackaging. But it's not a high priority since there are almost no OSGi webjars.

We will create a starter project for OSGi which will repackage resource to make them working properly. This starter may be used by the developers when they need to make OSGi project.

[pleku]

Just as an update here too - we decided to not to keep on waiting/pushing for making all webjars OSGi compatible, but instead we made a solution for unpacking all webjars for the project and then having those available in OSGi as static resources. This solution works well also with using npm for fetching the frontend dependencies for the project.

So this issue still exists, but it is not a blocker for having OSGi support in Flow.

[pleku]

As the focus has shifted from webjars to using other means (npm/pnpm & webpack) for the frontend resources, this issue will no longer be a priority for us. Contributions are welcome, but as I don't believe there will be any effort for this from our side, I'm closing the issue.

For Vaadin 14 and OSGi support, #5671 is the priority.