No. I didn’t realize you did that much work already. I guess we should include in the release notes that MXRoyale effecting other frameworks is a known issue and explain the work-around.
> Isn't the workaround to remove MXRoyale.swc if you have no plans to use it? That’s one work-around. Another (which I’m using) is to copy the CSS from Basic into the CSS for your app. That overrides the CSS in MXRoyale. Hopefully, we’ll have a much shorter time period between the next releases and get this resolved before the next one… Harbs > On Nov 13, 2018, at 7:11 PM, Alex Harui <aha...@adobe.com.INVALID> wrote: > > 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 > <mailto: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> <mailto: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 >>> <mailto: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>> <mailto: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> <mailto: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> >>> <mailto: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> <mailto: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> <mailto: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> >>>> <mailto: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> <mailto: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>> >>>>> >>>>> <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>>>
