I think most of the people will end using MXRoyale at some point. For example, I'm using Jewel at 94%, MX at 5% (RPC, RO classes) and Basic at 1% (UIBase, and probably some other class or bead), seems a combination that more people could star using, so removing MX/Spark doesn't seem the best option to me. IOW, flex emulation will be a point of support for people migrating or needed some concrete functionality that is now working on emulation, maybe some day a new implementation in pure royale comes, but seems all we must leave some time with MX/Spark, and only maybe sometime (or never), be able to remove in pro of newer things.
just my 2 El mar., 13 nov. 2018 a las 18:11, Alex Harui (<aha...@adobe.com.invalid>) escribió: > The release branch has been cut and I am verifying the RC. Should I just > scrap the 8 hours I spent making that happen? > > Isn't the workaround to remove MXRoyale.swc if you have no plans to use it? > > -Alex > > On 11/13/18, 2:45 AM, "Harbs" <harbs.li...@gmail.com> wrote: > > I hit this issue with another app. > > This is going to be a problem for lots of folks, I think we need some > solution to this problem before our next release. > > Should we just subclass MXRoyale components for now and deal with the > bigger problem later? > > Harbs > > > On Oct 14, 2018, at 8:55 PM, Alex Harui <aha...@adobe.com.INVALID> > wrote: > > > > Subclasses just to get around this problem adds weight. It doesn't > matter so much for MXRoyale, but IMO this sort of thing may crop up > elsewhere. We might need to provide finer-grain control over dependencies > in general. To me, the base problem is that we pile every SWC into the > library-path. That really won't scale, IMO. Imagine if there were 100 > SWCs to load for every compile. It would push the limits on compiler > memory and resolving identifiers and probably push the limits on > code-hinting in IDEs. > > > > So, if we have 100 swcs and potential CSS collisions, maybe we > should organize them in some way other than one single folder. I think the > -library-path doesn't search subfolders, so we could group certain kinds of > SWCs in subfolders and have different -config.xml files that have different > default -library-paths. > > > > For that matter, we could be explicit about the SWCs in the > library-path in different -config.xml files. Either royale-config.xml > would not reference MXRoyale or it would and we would have a > basic-config.xml that doesn't. > > > > The compiler lets you add to the library-path with +=. I don't know > if it supports -= or what it would take to get that to work. > > > > Lots of choices. The simplest one is to be explicit in the > -config.xml files. > > > > My 2 cents, > > -Alex > > > > On 10/14/18, 10:31 AM, "Harbs" <harbs.li...@gmail.com <mailto: > harbs.li...@gmail.com>> wrote: > > > > That’s problematic. I look at it that it’s a limitation that you > have to declare the dependencies in Maven. I’d rather that everything > should just be available. > > > > What about subclassing the basic classes in MXRoyale so we don’t > need to declare new CSS dependencies for Basic components there? > > > >> On Oct 14, 2018, at 7:26 PM, Alex Harui <aha...@adobe.com.INVALID> > wrote: > >> > >> Ah yes, I hadn't thought about that. Folks only using Basic should > probably find a way to not include MXRoyale and SparkRoyale on the > library-paths. > >> > >> So I think some chocies are: > >> -Delete the MXRoyale and SparkRoyale swcs from frameworks/libs and > frameworks/js/libs. > >> -Explicitly list which SWCs you want in your app. > >> > >> IMO, as Royale picks up more and more component sets, folks will > have to be more explicit about their SWC dependencies. That's one thing > Maven is better at. > >> > >> -Alex > >> > >> On 10/14/18, 7:33 AM, "Yishay Weiss" <yishayj...@hotmail.com > <mailto:yishayj...@hotmail.com> <mailto:yishayj...@hotmail.com <mailto: > yishayj...@hotmail.com>>> wrote: > >> > >> Same result. > >> > >> > >> > >> ________________________________ > >> From: Piotr Zarzycki <piotrzarzyck...@gmail.com <mailto: > piotrzarzyck...@gmail.com>> > >> Sent: Sunday, October 14, 2018 4:51:56 PM > >> To: dev@royale.apache.org <mailto:dev@royale.apache.org> > >> Subject: Re: Royale Compiler Brings Wrong Dependencies > >> > >> Maybe you should try point to the theme from Basic. > >> > >> On Sun, Oct 14, 2018, 1:09 PM Yishay Weiss < > yishayj...@hotmail.com <mailto:yishayj...@hotmail.com>> wrote: > >> > >>> No. We’re running the compiler-jx project with the following > arguments: > >>> > >>> > >>> > >>> +royalelib="C:\dev\flexjs\royale-asjs\frameworks" > >>> > >>> +configname=royale > >>> > >>> -debug > >>> > >>> -closure-lib=C:\dev\goog\closure-library > >>> > >>> > >>> > --js-library-path+=C:\Users\Yishay\Documents\printui-flexjs\PortedPrintUI\lib > >>> > >>> > >>> > --js-external-library-path+=C:\Users\Yishay\Documents\printui-flexjs\PortedPrintUI\typedefs > >>> > >>> --remove-circulars=true > >>> > >>> --html-template=src\resources\mdl-js-index-template.html > >>> > >>> --js-compiler-option+=--skip_type_inference > >>> > >>> --targets=JSRoyale > >>> > >>> > >>> > C:\Users\Yishay\Documents\printui-flexjs\PortedPrintUI\src\PortedPrintUI.mxml > >>> > >>> > >>> > >>> ________________________________ > >>> From: Piotr Zarzycki <piotrzarzyck...@gmail.com <mailto: > piotrzarzyck...@gmail.com>> > >>> Sent: Sunday, October 14, 2018 12:41:41 PM > >>> To: dev@royale.apache.org <mailto:dev@royale.apache.org> > >>> Subject: Re: Royale Compiler Brings Wrong Dependencies > >>> > >>> Hi Yishay, > >>> > >>> Do you load during the build -theme? > >>> > >>> Piotr > >>> > >>> On Sun, Oct 14, 2018, 9:45 AM Yishay Weiss <yishayj...@hotmail.com > <mailto:yishayj...@hotmail.com>> wrote: > >>> > >>>> Hi, > >>>> > >>>> We’re seeing a bug where beads from MXRoyale are loaded even > though the > >>>> project doesn’t reference MXRoyale. This results in a runtime > error when > >>>> opening a ComboBox. > >>>> > >>>> Specifically, it looks like these lines > >>>> > >>>> Basic|ComboBoxList > >>>> { > >>>> IDataProviderItemRendererMapper: > >>>> > >>> > ClassReference("mx.controls.listClasses.DataItemRendererFactoryForICollectionViewData"); > >>>> IBeadModel: > >>>> > >>> > ClassReference("mx.controls.beads.models.SingleSelectionICollectionViewModel"); > >>>> } > >>>> > >>>> Are bring read from MXRoyale’s defaults.css, changing the default > model > >>>> for ComboBoxList. I haven’t been able to reproduce this in a > simple [1] > >>>> example. > >>>> > >>>> I spent some time in the compiler trying to figure out what was > going on > >>>> but no luck so far. What I have noticed is that in > >>>> RoyaleJSTarget.findAllCompilationUnitsToLink() the list of found > >>>> dependencies includes compilation units I wouldn’t expect to > find. For > >>>> example, in the simple test [1] I created one of the dependencies > has the > >>>> AceJS compilation unit. > >>>> > >>>> Any pointers? > >>>> > >>>> [1] > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FN5As&data=02%7C01%7Caharui%40adobe.com%7Cabbbc463822b406ba8a508d649552bdb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636777027503420180&sdata=5JbsANAR1jMASttdyi7l3IagKD1Sp31rFNzOyhP%2FzAM%3D&reserved=0 > < > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FN5As&data=02%7C01%7Caharui%40adobe.com%7Cabbbc463822b406ba8a508d649552bdb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636777027503420180&sdata=5JbsANAR1jMASttdyi7l3IagKD1Sp31rFNzOyhP%2FzAM%3D&reserved=0> > < > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FN5As&data=02%7C01%7Caharui%40adobe.com%7Cabbbc463822b406ba8a508d649552bdb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636777027503420180&sdata=5JbsANAR1jMASttdyi7l3IagKD1Sp31rFNzOyhP%2FzAM%3D&reserved=0 > < > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FN5As&data=02%7C01%7Caharui%40adobe.com%7Cabbbc463822b406ba8a508d649552bdb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636777027503420180&sdata=5JbsANAR1jMASttdyi7l3IagKD1Sp31rFNzOyhP%2FzAM%3D&reserved=0 > >> > > > > -- Carlos Rovira http://about.me/carlosrovira