This is probably not a lot of help but clearly the place where these classes
are being generated is writing the generated code into the wrong stream.
You want to look at the code in the compiler that expands types, which is in
WEB-INF/lps/server/src/org/openlaszlo/compiler/TypeCompiler.java
lzo compiling normally captures this type of intermediate code an inserts it
later into the body of the output file. My suspicion is that because types
have to be processed early, this code is being output to the wrong stream, or
is being output before the capturing mechanism is in place.
Possibly Don will have some input.
On 2012-01-16, at 03:17, Yu Feng wrote:
> Hi Henry, Tucker and everyone,
>
> Parts modules in our project are using new components in trunk and we are
> going to compile them to LZO.
>
> As you can see from the build script error, it can be compiled into LZO
> successfully but fail when compiling the whole project and throw a BOM
> error.
>
> build-libraries:
> [echo] lzc:
> /Users/yufeng/Work/fred-webtop/ol5/walnut/trunk/_sdk/17222/laszlo-webtop-2.2.1.1/webtop-sdk/openlaszlo/_walnut-client-build/client/webtop/walnut/globalcomponents/contact/library.lzx
> [exec] Compiling: library.lzx to library.lzo
> [copy] Copying 1 file to
> /Users/yufeng/Work/fred-webtop/ol5/walnut/trunk/_build/_lzo/globalcomponents/contact
>
> build-client:
> [exec] Compiling: main.lzx to main.swf10.swf
> [exec] Compilation errors occurred:
> * [exec] globalcomponents/contact/library.lzo:1:1: Content is not
> allowed in prolog. Some text editors may insert a Byte-Order Mark (the
> sequence of characters 0xEFBBBF) at the start of your source file without
> your knowledge. Please remove any non-whitespace characters before the
> start of the first '<' character.*
> [exec]
>
> I am trying to dig more information from Parser.java and here is the
> contents in library.lzo:
> *dynamic class $lzc$type_gradient extends $lz$class_PresentationType{static
> var lzxtype="gradient";override function
> accept($a,$b:LzNode,$c:String){return new (lz.CSSGradient)($a)}override
> function present($a,$b:LzNode,$c:String){if($a&&$a.css)return $a.css;return
> null}}*
> *
> *
> *lz.Type.addType("gradient",new $lzc$type_gradient());*
> <!-- This is a binary library. Not meant for human consumption. -->
> <!-- DO NOT EDIT THIS FILE. Edit the source and recompile with `-c` -->
> <library includes="resources/library.lzx
> AlertPreviewListView.lzx
> AlertPreviewItem.lzx
> BasePreviewItem.lzx
> MessagePreviewListView.lzx
> MessagePreviewItem.lzx
> BasePreviewListView.lzx">
> <include href='../../olcontrols/library.lzx' />
> <include href='../../../../components/textservice/library.lzo' />
> <include href='../../../../components/ellipsis/library.lzo' />
> <include href='../../../../components/model/library.lzo' />
> .....
> .....
> </library>
>
> The reason of the error may lie in while handling the reference of new
> components(gradient fill, etc), the compiler is adding some declaration of
> 'dynamic class' which result in an unexpected prolog of a XML.
>
> My question is, do you have any better idea to handle it? I am totally
> stuck by this issue...
>
> thanks,
> -Fred
