[
https://issues.apache.org/jira/browse/WICKET-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Bille Jensen updated WICKET-902:
--------------------------------------
Fix Version/s: (was: 1.4-M2)
1.4-M3
> 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: 1.4-M3
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
