[Laszlo-dev] seeking ideas for a better approach to command-line lzc
ben at laszlosystems.com
Mon Jan 8 12:16:18 PST 2007
Not sure, but I think the code that looks at config files would need
One big honking jar! For the *deployed* version, at least. For
development, I think we still want the flexibility of having multiple
jars, but we should at least know which jars, and where they are. The
current count is 101 jars in the tree, with at least a half-dozen
duplicates, and I suspect dozens of unused jars.
Where do we *want* our jars to go? What does it mean that they are
mostly in WEB-INF/lib as opposed to just $LPS_HOME/lib?
On Jan 7, 2007, at 3:42 PM, Henry Minsky wrote:
> That seems like a very worthy goal. Just one honking big jar file?
> I am wondering if the code which accesses lps config files would
> need to be tweaked in some way
> to get these from a different place, or if LPS_HOME would still be
> the pointer to everything?
> On 1/7/07, Benjamin Shine <ben at laszlosystems.com> 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
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Laszlo-dev