[
https://issues.apache.org/jira/browse/WICKET-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Dashorst resolved WICKET-902.
-------------------------------------
Resolution: Fixed
Fix Version/s: 6.0.0-beta1
Not completely fixed, but the duplicates filtering has been resolved in 1.5.x
and with 6.0 you are able to combine multiple JS libraries into one packed
resource.
> Multi-project js library dependency resolution
> ----------------------------------------------
>
> Key: WICKET-902
> URL: https://issues.apache.org/jira/browse/WICKET-902
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
> Reporter: Jim McLaughlin
> Fix For: 6.0.0-beta1
>
>
> see http://www.nabble.com/Multiple-JS-libraray-inclusions-tf4285036.html
> No doubt this is a complicated issue, so maybe we should start small and see
> what shakes out. Currently, the only real conflict is wicket-datetime and
> wicket-contrib-yui loading duplicate or incompatible versions from different
> locations, resulting in multiple script refs in a page.
> A lot of good ideas were tossed around in the above thread, and the only one
> I really didn't like is the shared jar (eg, wicket-yui). I realize that it
> solves the problem, but i would like to see more developer control. Also, say
> there is no one maintaining wicket-contrib-yui. Then it will become the
> responsibility of a core dev to upgrade the wicket-stuff project. An upgrade
> to the yui libs will also require a much higher degree of coordination
> between stuff and core then there has been historically. I think ultimately
> this will be a source of frustration. It will also hinder the stuff project
> from being more experimental, which is one of its missions. Also, there might
> be libs that wicket can not host because of license incompatibilities.
> I liked igor's idea of having a JavascriptLibraryReference with a common id,
> and Eelco's idea of having some sort of registry. The Application class can
> have a JavascriptLibrarySettings object that will maintain a mapping of
> common id (regex) to class which will be the root for loading the library.
> The JavascriptLibraryReference can access this when generating the url. This
> leaves the problem of how to resolve priority when both wicket-datetime and
> wicket-contrib-yui want to register different roots for the same common id.
> This will probably require some kind of PriorityResolverStrategy with a
> sensible default, like defering to the wicket-core project.
> Hopefully these mumblings will inspire some comments postive and negative. If
> the idea is given any kind of nod, I will try to find some time to work up a
> patch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
