ResourceDefinition.SetDependencies doesn't work when it comes to resolving dependencies on scripts defined in a different module

Topics: Core, General, Writing modules
May 2, 2013 at 4:45 PM
Edited May 2, 2013 at 6:04 PM
I have 2 modules. One module defines core java scripts another one uses them. The dependent module specifies dependencies to the scripts defined outside of it using SetDependencies of ResourceDefinition.

When using Script.Require the resulting rendered view in the dependent module has the wrong order of the scripts: the dependent script comes ahead of the script it depends on.

May be it's not the right way of using it, but I could not find anything on how to use ResourceManifest.
// core module

namespace CoreModule
{
    public class ResourceManifest : IResourceManifestProvider
    {
        public void BuildManifests(ResourceManifestBuilder builder)
        {
            var manifest = builder.Add();
            manifest.DefineScript("core.script")
                .SetUrl("core.script.js")
        }
    }
}


// dependent module

namespace DependentModule
{
    public class ResourceManifest : IResourceManifestProvider
    {
        public void BuildManifests(ResourceManifestBuilder builder)
        {
            
            var manifest = builder.Add();

            manifest.DefineScript("dependent.script")
                .SetUrl("dependent.script.js")
                .SetDependencies("core.script");
        }
    }
}
// dependent module.txt

Dependencies: CoreModule

// cshtml

@Script.Require("dependent.script")


// resulting html

<script src="dependent.script.js"></script>
<script src="core.script.js"></script>
May 3, 2013 at 2:18 AM
May 3, 2013 at 2:59 PM
Are you using code from the 1.x branch?
May 3, 2013 at 8:19 PM
I am using the latest (1.6 AFAIK) stable release: "Orchard is currently in version 1.6. "
May 3, 2013 at 8:30 PM
Interesting. And you are able to reliably reproduce this with a clean install of Orchard? If you can, please file a bug.
May 3, 2013 at 9:12 PM
Edited May 3, 2013 at 9:15 PM
All I am saying is that the release that we use has the bug from https://orchard.codeplex.com/workitem/19255 before it was fixed. I checked the revision 3ad6518a57a3 mentioned there and figured out what needs to be done in order to fix it. Now with a recompiled Orchard.Core.dll it seems to work for scripts.

So yes, I think the problem has been solved. You may close it.
May 3, 2013 at 10:31 PM
Great to hear you were able to resolve the issue. Consider this thread closed. :)
May 10, 2013 at 6:48 PM
Edited May 10, 2013 at 7:09 PM
I want to express concern about how bug fixes are getting pushed forward. If you click the "download source" link on the Orchard Project site you still get this bug. Why wasn't it rolled into 1.6.1? Also which branches should we be looking for code fixes, I found this changeset under 1.x, not default, It would be nice to have more clearly named branches. (Like how do I pull down the in development 1.7 branch)
Coordinator
May 28, 2013 at 1:57 AM
If you want to get the latest bug fixes, you must get the source from the 1.x branch (which is the current state of the next version, 1.7 for now). That is what it is for. Deploying a new release is not something we do lightly or every time we fix a bug. The default branch is the latest stable, which coincides with the latest release. 1.6.1 was a necessary release that contained only one fix, for a security issue. This is explained in the documentation: http://docs.orchardproject.net/Documentation/Setting-up-a-source-enlistment#Branches and http://docs.orchardproject.net/Documentation/Developer-FAQ#Whatarethedefaultandxbranches?WhichoneshouldIbeusing?