Re: Royale Compiler Brings Wrong Dependencies
> >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
> 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" <mailto:yishayj...@hotmail.com> <mailto:yishayj...@hotmail.com yishayj...@hotmail.com>>> wrote:
> >>
> >> Same result.
> >>
> >>
> >>
> >>
> >> From: Piotr Zarzycki 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>>
> >>> 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 <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");
> >&g
Re: Royale Compiler Brings Wrong Dependencies
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 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" <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 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" > <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 >> <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" >> <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 >> <mailto:piotrzarzyck...@gmail.com> <mailto:piotrzarzyck...@gmail.com >>> <mailto:piotrzarzyck...@gmail.com>>>
Re: Royale Compiler Brings Wrong Dependencies
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 () 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" 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 > 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>> 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 > 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" <mailto:yishayj...@hotmail.com> <mailto:yishayj...@hotmail.com yishayj...@hotmail.com>>> wrote: > >> > >> Same result. > >> > >> > >> > >> > >> From: Piotr Zarzycki 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. > >> >
Re: Royale Compiler Brings Wrong Dependencies
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" 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 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" 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 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" mailto:yishayj...@hotmail.com> <mailto:yishayj...@hotmail.com
<mailto:yishayj...@hotmail.com>>> wrote:
>>
>> Same result.
>>
>>
>>
>> ____
>> From: Piotr Zarzycki 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 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
>>>
Re: Royale Compiler Brings Wrong Dependencies
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 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" <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 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" > <mailto:yishayj...@hotmail.com> <mailto:yishayj...@hotmail.com >> <mailto:yishayj...@hotmail.com>>> wrote: >> >> Same result. >> >> >> >> >> From: Piotr Zarzycki > <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 > <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 >> <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 Compi
Re: Royale Compiler Brings Wrong Dependencies
This is a different issue. -Alex On 10/14/18, 2:38 PM, "Carlos Rovira" wrote: Hi, That's why some months ago wanted to make Jewel not dependent of anything that is not needed and removed Basic from its dependency list. Although now Basic is again a dependency, I take care of no load anything from Basic, but UIBase that was carried again to Basic. I'm totally to add only dependencies that are needed. I just useless to have linked coded that you'll never will use, I prefer to add it when required. This not only is good for the weight of your app, the performance and the compiler memory and performance, but as well makes you avoid problems when create code since you can miss to remove some dependency from a library that you really don't want to use. For example, If I create a new component in Jewel from a component in Basic, if I don't link Basic, I'll get the error that some part is missing, and I'll need to create the piece for Jewel, or can choose to reuse the Basic one if it will not change by design at some time. Hope this issue helps to clear my position about trying to separate as much as possible and left users pick up what they really need. thanks Carlos El dom., 14 oct. 2018 a las 19:55, Alex Harui () escribió: > 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" 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 > 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" <mailto:yishayj...@hotmail.com>> wrote: > > > >Same result. > > > > > > > > > >From: Piotr Zarzycki > >Sent: Sunday, October 14, 2018 4:51:56 PM > >To: 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> wrote: > > > >> No. We’re running the
Re: Royale Compiler Brings Wrong Dependencies
Hi, That's why some months ago wanted to make Jewel not dependent of anything that is not needed and removed Basic from its dependency list. Although now Basic is again a dependency, I take care of no load anything from Basic, but UIBase that was carried again to Basic. I'm totally to add only dependencies that are needed. I just useless to have linked coded that you'll never will use, I prefer to add it when required. This not only is good for the weight of your app, the performance and the compiler memory and performance, but as well makes you avoid problems when create code since you can miss to remove some dependency from a library that you really don't want to use. For example, If I create a new component in Jewel from a component in Basic, if I don't link Basic, I'll get the error that some part is missing, and I'll need to create the piece for Jewel, or can choose to reuse the Basic one if it will not change by design at some time. Hope this issue helps to clear my position about trying to separate as much as possible and left users pick up what they really need. thanks Carlos El dom., 14 oct. 2018 a las 19:55, Alex Harui () escribió: > 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" 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 > 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" <mailto:yishayj...@hotmail.com>> wrote: > > > >Same result. > > > > > > > > > >From: Piotr Zarzycki > >Sent: Sunday, October 14, 2018 4:51:56 PM > >To: 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> 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\PortedPrin
Re: Royale Compiler Brings Wrong Dependencies
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" 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 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" mailto:yishayj...@hotmail.com>> wrote:
>
>Same result.
>
>
>
>
>From: Piotr Zarzycki
> Sent: Sunday, October 14, 2018 4:51:56 PM
>To: 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
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
>> Sent: Sunday, October 14, 2018 12:41:41 PM
>> To: 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
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");
>>&
Re: Royale Compiler Brings Wrong Dependencies
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 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" <mailto:yishayj...@hotmail.com>> wrote:
>
>Same result.
>
>
>
>
>From: Piotr Zarzycki
>Sent: Sunday, October 14, 2018 4:51:56 PM
>To: 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 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
>> Sent: Sunday, October 14, 2018 12:41:41 PM
>> To: 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 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%7C026c40ad877444893d0e08d631e213c1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636751244394987609&sdata=No1h%2B8aaaj2EKiV0sFv06DDIt89ZPy0A%2FMOW89qdvCc%3D&reserved=0
>>>
>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FN5As&data=02%7C01%7Caharui%40adobe.com%7C026c40ad877444893d0e08d631e213c1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636751244394987609&sdata=No1h%2B8aaaj2EKiV0sFv06DDIt89ZPy0A%2FMOW89qdvCc%3D&reserved=0>
Re: Royale Compiler Brings Wrong Dependencies
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" wrote:
Same result.
From: Piotr Zarzycki
Sent: Sunday, October 14, 2018 4:51:56 PM
To: 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 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
> Sent: Sunday, October 14, 2018 12:41:41 PM
> To: 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 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%7C026c40ad877444893d0e08d631e213c1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636751244394987609&sdata=No1h%2B8aaaj2EKiV0sFv06DDIt89ZPy0A%2FMOW89qdvCc%3D&reserved=0
> >
> >
>
RE: Royale Compiler Brings Wrong Dependencies
Same result.
From: Piotr Zarzycki
Sent: Sunday, October 14, 2018 4:51:56 PM
To: 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 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
> Sent: Sunday, October 14, 2018 12:41:41 PM
> To: 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 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://paste.apache.org/N5As
> >
> >
>
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 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
> Sent: Sunday, October 14, 2018 12:41:41 PM
> To: 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 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://paste.apache.org/N5As
> >
> >
>
RE: Royale Compiler Brings Wrong Dependencies
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
Sent: Sunday, October 14, 2018 12:41:41 PM
To: 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 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://paste.apache.org/N5As
>
>
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 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://paste.apache.org/N5As
>
>
Royale Compiler Brings Wrong Dependencies
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://paste.apache.org/N5As
