Well, I've been thinking about splitting MXRoyale into multiple SWCs. MXRoyale
would contain emulations from the Flex framework.swc and mx.swc, MXRPC would
contain emulations from Flex rpc.swc, and MXCharts would contain emulations
from Flex charts.swc. Not sure about other Flex SWCs just yet.
That doesn't fix this problem per-se. My current opinion about unwanted CSS
from other SWCs is that we should stop using wildcards in our -config.xml
files. We should tune them for commonly used sets. So royale-config.xml would
not list MX**.swc and Spark**.swc. Our version of flex-config would and folks
migrating would use flex-config.xml instead of royale-config.xml since they
were probably using flex-config.xml already. And we might as well remove
certain other SWCs from royale-config.xml like JQuery and CreateJS.
Originally, my thinking was it would be nice for folks to discover these other
libraries in the code-hinting, but on the other hand, too many options will
clutter code-hinting.
The only wrinkle in such a plan is air-config.xml and airmobile-config.xml.
Folks were taught to use configname="air" to switch from Flash APIs to AIR
APIs. It may be that the Royale mobile.swc maps well to AIR apis so that would
be the difference in the Royale version of these configs.
Thoughts?
-Alex
On 11/13/18, 9:25 AM, "Carlos Rovira" <carlosrov...@apache.org> wrote:
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%7Cb05e10178cd845eea2e708d6498d04e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636777267374741418&sdata=T5yNcXGc7%2Fhc4sKvYZmHHvszc15UB9UGtYMidLplVm0%3D&reserved=0
> <
>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FN5As&data=02%7C01%7Caharui%40adobe.com%7Cb05e10178cd845eea2e708d6498d04e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636777267374741418&sdata=T5yNcXGc7%2Fhc4sKvYZmHHvszc15UB9UGtYMidLplVm0%3D&reserved=0>
> <
>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FN5As&data=02%7C01%7Caharui%40adobe.com%7Cb05e10178cd845eea2e708d6498d04e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636777267374741418&sdata=T5yNcXGc7%2Fhc4sKvYZmHHvszc15UB9UGtYMidLplVm0%3D&reserved=0
> <
>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FN5As&data=02%7C01%7Caharui%40adobe.com%7Cb05e10178cd845eea2e708d6498d04e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636777267374741418&sdata=T5yNcXGc7%2Fhc4sKvYZmHHvszc15UB9UGtYMidLplVm0%3D&reserved=0
> >>
>
>
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb05e10178cd845eea2e708d6498d04e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636777267374751428&sdata=stpc0J%2FQSH5P4uguyK9p4%2FjiLZpTt4JiXjPHW3YbSJ4%3D&reserved=0
