Opened 12 years ago

Closed 7 years ago

#5189 closed defect (invalid)

Discard layers with same name as a dependency causes problems?

Reported by: James Burke Owned by: Rawld Gill
Priority: high Milestone: future
Component: BuildSystem Version: 0.9
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by James Burke)

Reported in the forums.

May be two issues: 1) discard layer still shows up in the build output? 2) the dojo.require call for the dependency is stripped out of dependent layers.

It could be related to having the layer name the same name as a module resource.

Change History (7)

comment:1 Changed 12 years ago by guest

This is Lance who originally reported on the issue in the forum.

I went back to the profile and renamed the name and resourceName for the discard layer to "dojomino.session.discard" and rebuilt the project.

Build.txt does not include dojomino.session - good.

In the dojomino.js.uncompressed.js file, in the NamePickerSingle? class, the dojo.require('dojomino.session') has been removed - bad. (Still the same issue.)

So I think the issue is global to the build process, and not related strictly to the name and resourceName being the same as the underlying module to be discarded.

Hope this helps.

comment:2 Changed 12 years ago by James Burke

Milestone: 1.0.21.1

This is going to be a larger code change than what I feel comfortable for 1.0.2. This ties into the logic where the require calls that are satisfied in other layers are stripped out of dependent layers since it is assumed that is layer dependencies will be loaded before it. I'll give this more thought for the 1.1 release.

In the meantime, you can get around the problem by not doing a discard layer, but specifying your dependency like so:

dojorequire?("my.module.name");

That syntax is not picked up by the build's regexp dependency parsing, so it should give you the desired effect. Unfortunately it means changing code instead of changing a build profile.

(For future reference, the issue is in buildUtil.getDependencyList() around line 390: the currentProvideList array needs to be trimmed for things that are in a dependent discard layer. Trick is, everything that is required by the discard layer would be trimmed out, which might not be wise since another layer may be loading that dependency. I think it works out, but there needs to be care to make sure the right sort of list is compared when doing the provideList trimming.)

comment:3 Changed 11 years ago by James Burke

Milestone: 1.11.2

comment:4 Changed 11 years ago by James Burke

Description: modified (diff)
Milestone: 1.2future

comment:5 Changed 8 years ago by ben hockey

Status: newpending

is this ticket still relevant? it will automatically close in 14 days if there is no response.

comment:6 Changed 8 years ago by bill

Owner: changed from James Burke to Rawld Gill

Bulk update to assign BuildSystem? tickets to Rawld. Many of these are probably already fixed in 1.7.

comment:7 Changed 7 years ago by trac-o-bot

Resolution: invalid
Status: pendingclosed

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

Note: See TracTickets for help on using tickets.