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>>
