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&amp;data=02%7C01%7Caharui%40adobe.com%7Cabbbc463822b406ba8a508d649552bdb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636777027503420180&amp;sdata=5JbsANAR1jMASttdyi7l3IagKD1Sp31rFNzOyhP%2FzAM%3D&amp;reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FN5As&amp;data=02%7C01%7Caharui%40adobe.com%7Cabbbc463822b406ba8a508d649552bdb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636777027503420180&amp;sdata=5JbsANAR1jMASttdyi7l3IagKD1Sp31rFNzOyhP%2FzAM%3D&amp;reserved=0>
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FN5As&amp;data=02%7C01%7Caharui%40adobe.com%7Cabbbc463822b406ba8a508d649552bdb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636777027503420180&amp;sdata=5JbsANAR1jMASttdyi7l3IagKD1Sp31rFNzOyhP%2FzAM%3D&amp;reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FN5As&amp;data=02%7C01%7Caharui%40adobe.com%7Cabbbc463822b406ba8a508d649552bdb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636777027503420180&amp;sdata=5JbsANAR1jMASttdyi7l3IagKD1Sp31rFNzOyhP%2FzAM%3D&amp;reserved=0
> >>
>
>
>
>

-- 
Carlos Rovira
http://about.me/carlosrovira

Reply via email to