Wicket
  1. Wicket
  2. WICKET-902

Multi-project js library dependency resolution

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.0.0-beta1
    • Component/s: wicket
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        Eelco Hillenius added a comment -

        bulk set issues to next version. I only did a quick check (and filtered some out for 1.3.1), but we can always bump em again.

        Show
        Eelco Hillenius added a comment - bulk set issues to next version. I only did a quick check (and filtered some out for 1.3.1), but we can always bump em again.
        Hide
        Jeremy Thomerson added a comment -

        I started a Wicket Stuff project meant for housing JS libraries and giving a common way of referring to them. I did it before looking at this jira issue, and with only a brief recollection of that thread, so I am sure there are many things raised on that thread that it does not address. I simply did it for my other WS projects to stop having to bundle JS within themselves, etc.

        https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/jslibraries/

        I'll try to look at this more later to see if I can address some of the concerns from that thread.

        Show
        Jeremy Thomerson added a comment - I started a Wicket Stuff project meant for housing JS libraries and giving a common way of referring to them. I did it before looking at this jira issue, and with only a brief recollection of that thread, so I am sure there are many things raised on that thread that it does not address. I simply did it for my other WS projects to stop having to bundle JS within themselves, etc. https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/jslibraries/ I'll try to look at this more later to see if I can address some of the concerns from that thread.
        Hide
        Martijn Dashorst added a comment -

        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.

        Show
        Martijn Dashorst added a comment - 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.

          People

          • Assignee:
            Unassigned
            Reporter:
            Jim McLaughlin
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development