flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: AW: AW: AW: [FlexJS] IntelliJ Integration
Date Mon, 25 May 2015 04:47:13 GMT

On 5/24/15, 8:09 AM, "Frédéric THOMAS" <webdoublefx@hotmail.com> wrote:

>Hi Alex,
>> IIRC, the FB compiler calls flex2/tools/oem/Application.java.  You can
>> how this class builds up an OEMReport with messages.
>Thanks, I've been able to create and OEMReport based on that.
>So, at the moment, using the Mxml entry point they use, plug into the
>MCMLC and sending old report (logs), I can compile and have reports on
>success, info, warnings and errors, I did the same with COMPC but didn't
>test it yet.

Excellent!  I assume that COMPC uses flex2/tools/oem/Library.java

>I re-introduce the proccessConfiguration too to make IJ happy, maybe I
>could mock it but I need to determinate first what they do exactly with
>the flex2.compiler.common.Configuration, it seems they get and use the
>CompilerConfiguration class though, so, I would probably need to mock it.

I seem to recall messing around with CompilerConfiguration when
integrating with FB.  So there may already be code that maps it to the
Falcon configurations.

>There are some limitations though:
>1- They patched the FileConfigurator class and now, there's a UnkownError
>which has an Info level and then doesn't avoid the compilation at all
>using their MXMLX / COMPC compile choice option .
>2- The most anoying thing is their build-in compiler option, it seems
>they totally revamped the CompilerAPI, create a process based on the
>Mxmlc and it doesn't work anymore indeed, but the worst is that for some
>reason I didn't get yet, their code path is switching all the time
>between those 2 compilers creating a very bad user experience:
>If I choose the Mcmlc, I can compile once, after no changes, it wont try
>to compile again, if there is at least one file changed, it will
>automatically try to compile with the build-in compiler and fail indeed,
>the user has to manualy select their build-in compiler again, try and
>fail again, switch back to the Mxmlc one to make it build.

I would assume that, if you are using an Apache Flex 4.14.1 SDK and choose
the Mxmlc option the above scenarios work correctly?  If so, that still
implies to me that IJ has some assumption about flex-oem-compiler.jar that
isn’t mocked up correctly.  Otherwise IJ hasn’t implemented that option.
I ended up putting breakpoints or console logging most of the public APIs
in flex-oem-compiler to see what FB was doing and then guessed correctly a
few times and it started to work.

Feel free to check in what you have.  I’m hoping to work on the packaging
of FDB so that the nightly builds get closer and closer to working in IJ.

Thanks for working on this.

View raw message