You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 9, 2017. It is now read-only.
A bundle which provides a web resource should be able to declare requirements to other web resources. The WebresourceServlet should then resolve all these transitive dependencies and provide them over the same .../${bsn}/${BundleVersion}/ path.
I can think of three problems when we are trying to aggregate dependencies which are potentially specified multiple times:
For mismatched String[] resource() values, merge the sets.
For mismatched int priority() values, choose the one nearest in the tree or choose arbitrarily.
For mismatched versions, use the one nearest in the tree or choose the higher version and just hope it works... (It's worth noting this is not an insurmountable problem in javascript, at least not with ES6, just with the merging strategy.)
Following from this, when we aggregate resources we have the opportunity to derive order from the dependency graph rather than manually specifying it as a priority integer. Manual specification is probably still necessary in tricky situations so I'm not suggesting getting rid of it, but for web resources with the same priority it could fall-back to inferred ordering and most of the time I expect that would be sufficient.
Again I'm happy to PR this if you're interested. I think it should be safe wrt leaving both API and behaviour unchanged unless people have some very strange things going on in their bundles.
The text was updated successfully, but these errors were encountered:
I think it is very interesting. One thing, the version resolution should be done by the framework resolver, do not think there is a need for special version handling?
For use cases where javascript dependencies can be isolated by visibility in the same way as bundles, e.g. in ES6/RequireJS environments with module imports, version resolution can indeed be handled by the framework resolver just fine.
But for something like the WebresourceServlet which aggregates resources into a single file I assume it would have to flatten the dependency tree, meaning we have to select a winner between conflicts. Unless there is some other solution I don't see.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
A bundle which provides a web resource should be able to declare requirements to other web resources. The WebresourceServlet should then resolve all these transitive dependencies and provide them over the same
.../${bsn}/${BundleVersion}/
path.I can think of three problems when we are trying to aggregate dependencies which are potentially specified multiple times:
String[] resource()
values, merge the sets.int priority()
values, choose the one nearest in the tree or choose arbitrarily.Following from this, when we aggregate resources we have the opportunity to derive order from the dependency graph rather than manually specifying it as a priority integer. Manual specification is probably still necessary in tricky situations so I'm not suggesting getting rid of it, but for web resources with the same priority it could fall-back to inferred ordering and most of the time I expect that would be sufficient.
Again I'm happy to PR this if you're interested. I think it should be safe wrt leaving both API and behaviour unchanged unless people have some very strange things going on in their bundles.
The text was updated successfully, but these errors were encountered: