flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik de Bruin <e...@ixsoftware.nl>
Subject Re: [FLEXJS] IDE integration discussion
Date Fri, 29 Nov 2013 11:50:09 GMT
Trying to cut the launch commands down to bare metal I came up with this:

SCRIPT_HOME="/Applications/Adobe Flash Builder 4.7/sdks/4.11.0_overlay"

java -Xmx384m -Dfile.encoding=UTF8 -Dsun.io.useCanonCaches=false
-Dflexcompiler=${SCRIPT_HOME} -Dflexlib=${SCRIPT_HOME}/frameworks -jar

Which "seems" to be what both 'mxmlc' and the FB launch files need.
However, when I run above from the command line, I get:

Error: Could not find or load main class Flash

What is missing/am I doing wrong?


On Fri, Nov 29, 2013 at 12:07 PM, Erik de Bruin <erik@ixsoftware.nl> wrote:
> Ok, the FDT people raised some interesting targets; I'd like to
> discuss them one by one, to get a better understanding where we are
> and what we're aiming for.
> 1. The user can get the FULLY functional Flex JS SDK by unzipping a
> downloaded file(best soultion) or a downloaded installer if it is
> executed does every step to create fully functional Flex JS SDK.
> This is what the Installer will do once the 'ant' stuff is checked in?
> 2. Java should be the only extern dependency of the Flex JS SDK.
> Everything else should be contained in the SDK. Also the compiler
> should not refer to the SDK by using environment variables.
> If we include the Closure Library download in the Installer, this is true?
> 3. The compiler can be started by calling a java class in some jar file.
> Looking at 'mxmlc', this is already the case (java -jar "../lib/mxmlc.jar")?
> 4. The settings needed to compile a Action Script project with the
> Flex JS Compiler should be the reference to the main class, to the
> source folders, to the swcs, to the used Flex JS SDK and the output
> folder. The rest like references to Google Closure library should have
> default values refering into the Flex JS SDK via relative paths. All
> other settings should have usefull default values which do not block
> compilation.
> Besides what's already discussed in 2., I think all we need to do is
> give '-closure-lib' a proper (relative) default?
> 5. The compiler output should be a directory or file containing
> everything necessary to start the project.
> Already the case.
> 6. The compiler output should be launchable by sending some file like
> index.html to the browser.
> Already the case.
> 7. The hello world example should only need the reference to one main
> class, one source folder, a few swcs, the sdk, and an output folder
> and should be successfully compiled with no other settings given to
> the compiler.
> Given 4., this is the case?
> 8. The compiler interface should be stable over time. We are not
> willing to adjust the transfered settings each new version.
> Seems logical to have a stable API... Nothing here, moving along.
> 9. The necessary jars of the compiler should be placed all in one
> folder of the sdk.
> Already the case?
> 10. The compiler jars should have the ability to be unloaded from the
> jvm if the classloader of these jars is dropped.
> I have no idea what that means...
> 11. The compiler interface should be simple like: Instantiaton of a
> class. Then using some setters to set main class, source files, swc
> files, sdk location, output location, and a progress listener with the
> possibility to interrupt the compilation if the user wish that. The
> main build method should return the result as a list of
> errors/warnings or simply success.
> Not sure about the first part (interrupting compilation), but I'm
> pretty sure we've got the basics for the return values.
> Thoughts, ideas?
> EdB
> --
> Ix Multimedia Software
> Jan Luykenstraat 27
> 3521 VB Utrecht
> T. 06-51952295
> I. www.ixsoftware.nl

Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

View raw message