> Excellent! I assume that COMPC uses flex2/tools/oem/Library.java Nope, I don't if I do well but I mapped what was before, a call to COMPC as I do for Mxmlc which is what IJ expect.
> 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. Yes (well if I get you correctly) but with other package which then don't work, the Falcon conf classes are not the ones IJ expect, I had to rely on the legacy ones and I will have to tweak them at some point, at least, I guess, when I will have to make them validate the new element in the flex-config.xml > 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. I didn't try with 4.14.1 but amongst few other things, I had to generate a new compc.jar to make IJ happy, now, it works well with the 2 IJ compiler options. http://snag.gy/3o0SH.jpg > 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. Cool, it would be nice I could debug in IJ without to rely on the Flex SDK :-) > Thanks for working on this. Welcome !! Also, my work is not clean and once clean, I will require your help with Ant or better, will commit anyway in a branch and if you can make the Ant build working, it would be nice, never been able to complete it with the flex-oem-compiler and not only because of the tests but some dependencies, I will come back to you with more detail when it will be the time, in between, I build it with IJ. Thanks. Frédéric THOMAS > From: aha...@adobe.com > To: dev@flex.apache.org > Subject: Re: AW: AW: AW: [FlexJS] IntelliJ Integration > Date: Mon, 25 May 2015 04:47:13 +0000 > > > > On 5/24/15, 8:09 AM, "Frédéric THOMAS" <webdoubl...@hotmail.com> wrote: > > >Hi Alex, > > > >> IIRC, the FB compiler calls flex2/tools/oem/Application.java. You can > >>see > >> 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. > -Alex >
