I have modified the code to check the resource oracle (patch is attached). If the way i did it is correct - one more problem arose - The path is not reconstructed correctly. I get the error is
Scanning for additional dependencies:
file:/D:/Devel/open-source/gwt-distributed-compiler/agent/0002/src/hr/tkd/orka/client/panels/MainPanel.java
Computing all possible rebind results for
'hr.tkd.orka.client.panels.MainPanel.MainPanelUiBinder'
Rebinding hr.tkd.orka.client.panels.MainPanel.MainPanelUiBinder
Invoking generator
com.google.gwt.uibinder.rebind.UiBinderGenerator
[ERROR] Generator
'com.google.gwt.uibinder.rebind.UiBinderGenerator' threw an exception while
rebinding 'hr.tkd.orka.client.panels.MainPanel.MainPanelUiBinder'
java.lang.RuntimeException: java.io.FileNotFoundException:
D:\Devel\open-source\gwt-distributed-compiler\agent\hr\tkd\orka\client\panels\MainPanel.ui.xml
(The system cannot find the path specified)
Obviously the resource is being looked for at the wrong place... It should
be
D:\Devel\open-source\gwt-distributed-compiler\agent\0002\src\hr\tkd\orka\client\panels\MainPanel.ui.xml
the program is run from the
location D:\Devel\open-source\gwt-distributed-compiler\agent\ and the files
needed for compile perms are located in folder 0002\src, 0002\lib and
0002\work. The relevant part of the context class path is set
to D:\Devel\open-source\gwt-distributed-compiler\agent\0002\src but when
resource is fetched from the resource oracle the path is not constructed
correctly. I reckon the resource should be added as
"0002\src\hr\tkd\orka\client\panels\MainPanel.ui.xml"...
On Tue, Jun 1, 2010 at 10:05 PM, Marko Vuksanovic <markovuksano...@gmail.com
> wrote:
> I don't believe it's necessarily true for the system loader to be a parent
>> of the context loader. It's common, but not necessary. The only loader you
>> can't get away from is the boot class loader.
>
>
> Ok, I wasn't totally precise. You're right about the boot and system class
> loader. The point was that all the parent class loaders would be checked
> prior to checking the actual class loader. So checking the context class
> loader would result in checking all the class loaders above it (in the
> hierarchy) - and if the hierarchy wasn't explicitly changed this should be
> perfectly ok.
>
> On Tue, Jun 1, 2010 at 9:17 PM, Lex Spoon <sp...@google.com> wrote:
>
>> On Tue, Jun 1, 2010 at 2:35 PM, Marko Vuksanovic <
>> markovuksano...@gmail.com> wrote:
>>
>>> Class Loaders are checked in parent to child direction - so if you try to
>>> fetch a resource from a context class loader, system class loader is the
>>> first that will be checked and only after resource is not found there, next
>>> child will be checked... and so on... So if something is found in context
>>> class loader, all parent class loaders have been checked. Somebody correct
>>> me if I'm wrong.
>>
>>
>> I don't believe it's necessarily true for the system loader to be a parent
>> of the context loader. It's common, but not necessary. The only loader you
>> can't get away from is the boot class loader.
>>
>> That said, if it's not on the context loader, you might want to ignore it
>> if you can get away with it. For that matter, the same goes for things not
>> in the resource oracle.
>>
>> -Lex
>>
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
ui-binder-generator.patch
Description: Binary data
