[Laszlo-dev] seeking ideas for a better approach to command-line lzc

[Jim Grandy]

One sacred cow: no big code / build changes for B2.

But medium-term (post-OL4.0), I think we definitely need to move in  
this direction. We should be thinking about separate tools that can  
be built and run separately from the command line. This means any  
caching needs to be optional or separated out, of course.

I'd propose we have three separate jars: script compiler, tag  
compiler, and LPS. The dependency list should be script -> tag ->  
LPS, so you don't have to build the tag compiler to run the script  
compiler, for example.

Having the script compiler separate would give us the beginnings of a  
JS2->JS1 compiler, which the open source community would surely be  
interested in.

jim

On Jan 7, 2007, at 11:27 AM, Benjamin Shine wrote:

>
> I have noticed lots of community and internal trouble using command- 
> line lzc. Trouble with the SOLO deploy wizard is also rampant. The  
> basic problem here, I think, is that these tools were all  
> originally developed as part of a web application, but their  
> current use is not inherently webby. The web server needn't be  
> involved at all in building a swf or a solo zip.
>
> I'm thinking of making a single executable jar containing  
> everything we need to do lzc with just
> $ java -jar lzc-4.0b2.jar test.lzx
> or an ant task
>    <lzc src="test.lzx" runtime="swf7" />
>
> The key here is self-contained, pure java, and architecture  
> neutral. Ideas/sacred cows?
>
>
>
>
>
> benjamin shine
> software engineer
> ben at laszlosystems.com
>
>
>