Hi,
Figured it out: the Maven version of the GCC is not complete, it misses
some libs, which in turn leads to all the nasty and stacked errors we saw.
If you use the GitHub version, all is well, even with the latest version of
the library. In order to be able to use the GitHub version (which is only
provided as source), you need to build it first... Which the new
'downloads.xml' for FalconJX now takes care of.
My work looking for the answer had some nice side effects:
- rewrote the downloads.xml for both Falcon and FalconJX for clarity and
usability
- updated all Falcon and FalconJX dependencies - all but JBurg, that is -
to their latests versions
- download, extract and build latest GC version
- created a new class JSClosureCompilerWrapper which uses the actual Java
implementation of the GC, not the Google provided wrapper class -> this
sets the stage for even tighter compilation of the generated JS code and
gives more control over the post-compilation steps
I think I have done my due diligence by checking all tests and build files
to see if they work with these new files and classes, and I haven't found
any problems. Please test.
EdB
On Mon, Jun 23, 2014 at 4:37 PM, Alex Harui <aha...@adobe.com> wrote:
> Hi Erik,
>
> Thanks for looking into this. It might be true that flex-falcon works ok.
> I ran into my issues compiling flex-asjs/examples/DataBindingTest.
> That's when I got disturbing warnings from GCC. I would have expected the
> same warnings from compiler.jx.tests when it compiles a FlexJS app, but it
> might be that those warnings are not caught by the test.
>
> Thanks,
> -Alex
>
> On 6/23/14 7:28 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>
> >Alex,
> >
> >I have (locally) updated both Falcon's and FalconJX's download.xml. I'm
> >now
> >downloading the latest versions of all dependencies but JBurg. When I do a
> >'ant wipe-all all' on the root of the 'flex-falcon' dir, everything builds
> >and all tests pass...
> >
> >Before I move on, can you confirm this is also what you were seeing? This
> >would rule out any issues with GCC and the code itself.
> >
> >EdB
> >
> >
> >
> >
> >On Fri, Jun 20, 2014 at 5:21 PM, Alex Harui <aha...@adobe.com> wrote:
> >
> >> Yeah, I agree that at some point we want to move forward to latest GCC
> >>and
> >> GCL, but I think we need to get a release out now and worry about it
> >>later.
> >>
> >> It isn't just a Java 7 dependency. We are already locking to a Java 7
> >> version in FlexJS/FalconJX 0.0.1. The issues appear to be that GCC and
> >> GCL are doing serious rework to be ES5 compliant and GCC now does more
> >> compiler magic to handle that. New flags are being added and new
> >> expectations around external dependencies have been added. I spent last
> >> night trying to go down that road and gave up. It was starting to look
> >> like a chain of changes.
> >>
> >> -Alex
> >>
> >> On 6/20/14 8:12 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
> >>
> >> >I am thoroughly against knowingly locking FlexJS to older versions of
> >>the
> >> >GC tools. I'm aware of the issues that currently block the
> >>implementation
> >> >of the most recent GCC and GCL, but these will only become worse when
> >>we
> >> >get further behind. My main concern about that is that at some point
> >>the
> >> >older artefacts ("hacked") won't be available anymore, which will then
> >> >leave FlexJS in a very bad state...
> >> >
> >> >If this is all you can manage at this time, than you should go ahead.
> >> >
> >> >I'll try to find time to look at what the issues are (I think it was
> >> >related to a requirement for Java 7 in the newer GCC?) and submit a
> >>fix.
> >> >However, I'm spending what time I can on trying to get a VanillaSDK
> >> >version
> >> >up to date and running - as that is what passes for "fun" for me these
> >> >days
> >> >;-) - so I'm not sure when I can come around to this.
> >> >
> >> >EdB
> >> >
> >> >
> >> >
> >> >
> >> >On Fri, Jun 20, 2014 at 4:48 PM, Alex Harui <aha...@adobe.com> wrote:
> >> >
> >> >> Hi Folks, This is mostly directed at the PMC members:
> >> >>
> >> >> As you've seen Darkstone has been translating the installer strings
> >>to
> >> >> Chinese. The current FlexJS release cannot be installed in China
> >> >>because
> >> >> some google sites are blocked over there. Last night I found the
> >>Google
> >> >> Closure Compiler binaries on Maven (only sources are available on
> >> >>GitHub)
> >> >> and have found a version I think works, but for Google Closure
> >>Library
> >> >> which also exists on GitHub, there has been much upheaval in the code
> >> >>base
> >> >> recently, and we get bunches of warnings with the only distribution I
> >> >>can
> >> >> find there. It seems to require a newer version of GCC which in
> >>turns
> >> >> seems to have additional integration issues with FlexJS. I tried
> >> >> integrating the latest GCC, but after a couple of tries decided it
> >>might
> >> >> be a longer series of issues than I want to spend time on right now,
> >>so
> >> >>I
> >> >> think I've found a version that works with our code, but not the GCL
> >> >> distribution.
> >> >>
> >> >> So, my next plan is to bundle GCL in the FlexJS binary package.
> >>Because
> >> >> of all of the upheaval in GCL, I'm not sure we want folks to override
> >> >> which version they use. So by bundling and locking in a version, we
> >> >>also
> >> >> remove another barrier to being able to install in China. GCL is
> >>under
> >> >>AL
> >> >> so I believe we can "just do it".
> >> >>
> >> >> I'm testing it out now. Let me know if you can think of any issues
> >>or
> >> >> reasons we shouldn't do it.
> >> >>
> >> >> Thanks,
> >> >> -Alex
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >--
> >> >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
>
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
