The holy grail would be to split these out as separate jars, write
wrappers to create the command-line utilities, and be able to stitch
them together with a different wrapper that creates the server
compiler (still split out from the proxy part of the server). That
would presumably let people embed the laszlo compiler into other
server technologies.
On 2007-01-07, at 19:06 EST, Jim Grandy wrote:
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
[EMAIL PROTECTED]
