Sure Piotr,
If you need MXRoyale (with MXRoyale view components)
then it would be exactly the same as before:
<dependency>
<groupId>org.apache.royale.framework</groupId>
<artifactId>MXRoyale</artifactId>
<version>0.9.9-SNAPSHOT</version>
<type>swc</type>
<classifier>js</classifier>
</dependency>
Currently where you are using MXRoyale service classes only (and don't want
view components or css), you had to do this:
<dependency>
<groupId>org.apache.royale.framework</groupId>
<artifactId>MXRoyale</artifactId>
<version>0.9.9-SNAPSHOT</version>
<type>swc</type>
<classifier>js</classifier>
</dependency>
and include this in <additionalCompilerOptions>:
-compiler.exclude-defaults-css-files=MXRoyale-0.9.9-SNAPSHOT-js.swc:defaults.css;
(this is for maven specifically, for ant or IDE builds the directive is
slightly different to reflect the different swc filename conventions)
Instead of doing the above two things, you will simply be able to do this
instead:
<dependency>
<groupId>org.apache.royale.framework</groupId>
<artifactId>MXRoyaleBase</artifactId>
<version>0.9.9-SNAPSHOT</version>
<type>swc</type>
<classifier>js</classifier>
</dependency>
On Thu, Oct 7, 2021 at 10:42 AM Piotr Zarzycki <[email protected]>
wrote:
> +1 for that.
>
> Could you share for application which is being build by Maven how would
> look like dependencies if someone would like to use both libraries.
>
> It’s just for the documentation purposes here.
>
> Thanks,
> Piotr
>
> On Wed, 6 Oct 2021 at 22:59, Greg Dove <[email protected]> wrote:
>
> > I have had at least two requests for it, and others still express support
> > for it, and it has been said in past discussions that if someone is
> willing
> > to 'put in the work' that it's welcome... so I wanted to signal my
> > intention to split MXRoyale up into two libraries - the first being most
> of
> > the non-UI classes "MXRoyaleBase", and the second being the same as the
> > current "MXRoyale" lib is now.
> >
> > I already have this working locally, so this is really just a check-in to
> > make sure everyone is comfortable with it before I push any changes
> related
> > to this.
> > If, after reading this post, you have any concerns, can you please share
> > them in reply to this thread.
> >
> > The change will make it easier for people who want to use (for example)
> the
> > mx services/remoting support with a non-emulation component set (e.g.
> > Jewel). It may also make it easier for any Royale developer who wants to
> > take a shot at an alternate version of the mx emulation set (if anyone is
> > so inclined) because the non-UI parts and likely some of the UI
> interfaces
> > only will be in the MXRoyaleBase library. As an example, someone might
> want
> > to create a new emulation set that more closely mirrors (assuming it is
> > possible to do so) the original measurement and layout aspects of the
> Flex
> > lifecycle, or which takes advantage of more modern browser APIs because
> > they don't care about support for older browsers, or simply for whatever
> > other reasons they might have.
> >
> > What impact will it have on me?
> > *Royale User:*
> > No change for emulation users: If you are using MXRoyale currently, it
> will
> > continue to work as it has before.
> > Non-emulation users: If you want to use mx service classes (for example)
> in
> > some non-emulation component set (e.g. Jewel or Basic), it will make
> things
> > easier for you because you can switch to MXRoyaleBase.swc and won't have
> to
> > exclude the css from the MXRoyale.swc. At the same time, the current
> > approach for excluding css will continue to work as before.
> >
> > *Royale Developer:*
> > The source code from the current MXRoyale codebase will be split into two
> > libraries- MXRoyaleBase for mostly non-UI code and MXRoyale which will be
> > mostly the UI implementation code. MXRoyale swc build will include the
> > MXRoyaleBase source code and its mxml component definitions so that the
> > code from the other swc gets included, resulting in the same swc build as
> > before for MXRoyale (this avoids breaking any builds for folks using
> > MXRoyale). The biggest impact from an emulation developer's perspective
> is
> > that potentially you might need to look in two library codebases (e.g. if
> > you are making changes to IUIComponent which is in MXRoyaleBase and
> > UIComponent which is in MXRoyale). If you are working on non-UI code, it
> > should mainly be in MXRoyaleBase. If you are mainly working mainly on the
> > UI code, which I think is very often the case, it will continue to be in
> > MXRoyale.
> >
> >
> > Thanks,
> > Greg
> >
> --
>
> Piotr Zarzycki
>
