flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlos.rov...@codeoscopic.com>
Subject Re: [FlexJS] Make the closure compilation use the closure jar instead of an exploded directory
Date Mon, 24 Oct 2016 08:32:34 GMT
Thanks for looking into this speed issue, since it would improve greatly
working with FlexJS and maven

2016-10-23 16:28 GMT+02:00 Alex Harui <aharui@adobe.com>:

> On 10/23/16, 3:10 AM, "Christofer Dutz" <christofer.dutz@c-ware.de> wrote:
> >Hi,
> >
> >
> >I was thinking about how to speed up the build time of application
> >compilation for the maven build. Currently as part of the build, I take
> >the closure library and expand it to the current modules target
> >directory, which is taking quite some time (and when cleaning up). I was
> >thinking about ways to do this differently (for example expanding it to a
> >temp directory once and referencing it wherever I need it in the build).
> >
> >
> >Then I thought about it that the closure guys don't expand the resources,
> >but directly use the resources from the jar. It should be possible for us
> >to do the same. I guess this expansion requirement is a relic from the
> >times where the flexjs compiler required to have the js files in an
> >expanded form.
> >
> >
> >Would it be possible to change the closure compilation part to use the
> >closure lib as a jar and not a directory? I guess this would speed up
> >compilation dramatically as accessing resources from a jar in the
> >classpath is way faster than accessing them from the filesystem
> >individually.
> >
> The history behind where we are is that for non-Maven users, folks wanted
> to bundle the closure files in the FlexJS binary release artifact in order
> to save on another download that could go wrong.  This ended up meaning
> that we had to work from a subset of the GCL because the full GCL contains
> what looks like crypto code and stuff from third-parties that complicate
> Apache licensing and export requirements.  So right now, we only bundle 27
> files from GCL, and I don't expect that list to grow any longer.
> So maybe the answer is to pack these 27 files into one of the FalconJX
> jars and copy from there.  Then we still don't have to download the full
> GCL and don't have licensing and export issues.
> Thoughts?
> -Alex


Carlos Rovira
Director General
M: +34 607 22 60 05

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message