Open eliasvasylenko opened 7 years ago
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.
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.