Hi, I will make a new thread for the current problem of spriteflexjs library compilation since this is not in topic
2017-02-15 23:51 GMT+01:00 Christofer Dutz <christofer.d...@c-ware.de>: > Well the “type” is what we choose … also we can change the “classifier”s … > the scope however is Maven-defined and we currently have to stick to that. > But I’m happy to change naming, if that makes things easier. > > Chris > > Am 15.02.17, 23:48 schrieb "Alex Harui" <aha...@adobe.com>: > > > > On 2/15/17, 1:09 PM, "Christofer Dutz" <christofer.d...@c-ware.de> > wrote: > > >Ok … gee … think I still haven’t understood this completely ☹ > > Yeah, it is a bit tricky. I've been wondering whether the terms we > currently use "typedefs", "externs", "runtime", "provided" are Maven > standards or whether we can change some of them. > > In the dual branch, I am currently changing things so the Core.swc and > CoreJS.swc are more like peers. They both contain .JS files, but the > library.swf in Core is for SWF and the library.swf in CoreJS is for > JS. I > just want to get this working now, cut a release, then look into > packing > everything into one SWC. > > In light of that, my latest attempt to make categories for SWCs says > that > there are categories like: > > 1) External "Platform and JS Framework API" swcs. > Playerglobal > Airglobal > Js > Jquery > Createjs > Most of the flex-typedefs except for GCL. > > 2) External "JS Framework SWCs with SWF Mocks" > We don't have any in the main repos but in flex-tourjs the > BarcodeScanner > makes a SWC like this. > > 3) Google Closure Library External SWCs > GCL.swc > Someday, some others. > > 4) SWF SWCs > Core > Binding > Etc. > > 5) JS SWCs > CoreJS > BindingJS > Etc. > > Bucket 1 always goes on the external-library-path for SWF and JS. > Different ones are used for JS vs SWF. > Bucket 2 goes on the external-library-path for JS, but on the > library-path > for SWF > Bucket 3 goes on the library-path for JS and is not used for SWF > unless it > has a SWF Mock > Bucket 4 goes on the external-library-path for SWC > Bucket 4 goes on the library-path for SWF > Bucket 5 goes on the library-path for cross-compiling to JS > Bucket 5 goes on the external-library-path for building the library.swf > for a JS.swc although it is probably ok if it is on the library-path. > > From another perspective, the JS within a SWC either uses goog.require > or > not. GCL.swc uses goog.require, as will other GCL-compatible code, > and as > our JS files do. That's why they go on the library-path for JS. But > when > building a SWF, you either want the code from a SWC's library.swf in > your > application so you use library-path or you don't and you use > -external-library-path. > > This makes me think we need an easier-to-understand way to mark what > is in > a SWC and have the Mojo figure it out from there. I think we are > currently using > Typedefs + runtime to mean that it is meant for JS but doesn't use > goog.require > Typedefs by itself means that is meant for JS and uses goog.require > Provided and Runtime seem to have the same meaning? > If no typedefs it contains runnable ABC > If no typedefs but provided it is bucket 1 for SWF. > > I think we just want to mark whether a SWC contains JS and/or runnable > ABC > and whether it contains goog.require or not. I'm not sure we have a > combination right now for bucket 2, and the keywords might not have > enough > meaning to others. Can we use different keywords? Classifiers like > "JS", > "ABC", "JS+ABC", Scope of "usesGoog"? > > Thanks, > -Alex > > > > -- Carlos Rovira Director General M: +34 607 22 60 05 http://www.codeoscopic.com http://www.avant2.es 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 necesaria.
