BUG: XML contains local project name

I have an image on the wireframe which is taken from the same project's images folder. The resource is defined in the *.screen file as

/resource/ngssui_john_localcopy/WebContent/images/logo_de_173x33.gif

The CVS module ngss was checked out as project ngssui_john_localcopy (I also have the same project checked out in a few branches -- under a different names -- for task reviews).

Now, when I try to checkout the same project under it's canonical name (ngssui) with original folder removed, the screen refuses to open:

Could not open the editor: Unable to create resource URLImageDescriptor(platform:/resource/ngssui_john_localcopy/WebContent/images/logo_de_173x33.gif)

Resources taken from the same project should only have relative path within the project, NOT including the project name.

So the xml should have: /resource/WebContent/images/logo_de_173x33.gif

Vladimir,

Can you give me the steps to reproduce the problem?

Normally references within the same project are stored using relative paths. However when you use resources from other projects then paths are absolute.

The only way I can think to achieve your result is like this:

1. Create the screen in some other project
2. Add the image from the ngssui_john_localcopy project
3. Move the screen to the ngssui_john_localcopy project.

Does it look like something you could have done?

I agree however that WireframeSketcher should be able to open the screen in all cases. So this is definitely a bug.

Reproduce, hmm... OK! :D

Create project AAA. Place an image there. Create a wireframe with that image.

Commit to CVS.

Delete project AAA.

Checkout AAA from CVS as AAA_TEST.

Open the wireframe.

Enjoy a message like this one: Could not open the editor: Unable to create resource URLImageDescriptor(platform:/resource/ngssui/WebContent/images/logo_de_173x33.gif)

Vladimir,

Can you describe the layout of your project? What's the location of the screen file? What's the location of the image file? I'll try to recreate this layout locally.

As I was saying, normally, resource withing the same projects are referred to using relative paths. So your steps actually work for me. The relative path does not contain the name of the project thus renaming the project doesn't break anything.

Ha! You know what? I cannot reproduce it either! The only explanation I see is that I've made that screen before I've updated to the latest version of WFS, so may be the bug was actually in the old code?

Vladimir,

Things were working this way from the very beginning. I see only one way to reproduce this problem. It implies the use of a second project and the creation of a cross-project image reference. Otherwise, if you always work within the same project you should have no problems with paths.

For the time being I've fixed the error. Now you'll always be able to open the screen. The image won't be displayed but you'll be able to correct it from within the screen editor.

Nay, there was no second project. And as you can see in my original posting, the image references to the same project name -- "local_copy"...

The one interesting thing about this project is that it is used by two "perpectives" -- Java and Javascript. Everytime I use some operation (e.g. Sync to CVS) it always shows me two trees, like it would be two projects (despite it's one). I wonder if I somehow create the wireframe in "zone of responsibility" of Java perspective, but with image from under Javascript "zone", would it (mistakenly) consider it an outside reference?

I need to try to reproduce it.

Anyway, good we can now open the wireframe even when some image is unavailable. After all, the image can be missed for a variety of reasons.

Thanks!