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%7C1d5f7c0c64674f47286308d631fadc24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636751350843541623&sdata=cdmNUHByZWf1%2BiimmpEgjy%2FAoZzLTmbZo6s%2Bnvy7ud0%3D&reserved=0 >>>> >>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FN5As&data=02%7C01%7Caharui%40adobe.com%7C1d5f7c0c64674f47286308d631fadc24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636751350843541623&sdata=cdmNUHByZWf1%2BiimmpEgjy%2FAoZzLTmbZo6s%2Bnvy7ud0%3D&reserved=0> >>>> >>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FN5As&data=02%7C01%7Caharui%40adobe.com%7C1d5f7c0c64674f47286308d631fadc24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636751350843541623&sdata=cdmNUHByZWf1%2BiimmpEgjy%2FAoZzLTmbZo6s%2Bnvy7ud0%3D&reserved=0 >>>> >>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FN5As&data=02%7C01%7Caharui%40adobe.com%7C1d5f7c0c64674f47286308d631fadc24%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636751350843541623&sdata=cdmNUHByZWf1%2BiimmpEgjy%2FAoZzLTmbZo6s%2Bnvy7ud0%3D&reserved=0>>
