Not sure, but I think the code that looks at config files would need
to change.
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 <[EMAIL PROTECTED]> 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]
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
