You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Greg Dove <gr...@gmail.com> on 2021/10/06 20:59:28 UTC
MXRoyale splitting to two libs - please provide your feedback.
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
Re: MXRoyale splitting to two libs - please provide your feedback.
Posted by Greg Dove <gr...@gmail.com>.
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 <pi...@gmail.com>
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 <gr...@gmail.com> 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
>
Re: MXRoyale splitting to two libs - please provide your feedback.
Posted by Greg Dove <gr...@gmail.com>.
Hi Andrew,
Thanks, hopefully this is not really too complicated. I think there are
already some crux examples in the SDK that would already be candidates for
changing, for example. I can look at modifying those when I add it,
assuming there are no concerns voiced about moving forward with this. I
might leave it another 36 hours or so and move forward at that point if
there are no objections.
On Thu, Oct 7, 2021 at 11:24 AM Andrew Wetmore <co...@gmail.com> wrote:
> Yes. I would love to help update the documentation to reflect this advance.
> First step would be a clear example app or two. Then I would try to update
> our getting-started material. THEN I would have to tackle the tutorials
> that Carlos wrote.
>
> a
>
> On Wed, Oct 6, 2021 at 7:17 PM Alina Kazi <al...@gmail.com> wrote:
>
> > +1 for two libs
> >
> > On Thu, 7 Oct 2021, 2:42 am Piotr Zarzycki, <pi...@gmail.com>
> > 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 <gr...@gmail.com> 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
> > >
> >
>
>
> --
> Andrew Wetmore
>
> http://cottage14.blogspot.com/
>
Re: MXRoyale splitting to two libs - please provide your feedback.
Posted by Andrew Wetmore <co...@gmail.com>.
Yes. I would love to help update the documentation to reflect this advance.
First step would be a clear example app or two. Then I would try to update
our getting-started material. THEN I would have to tackle the tutorials
that Carlos wrote.
a
On Wed, Oct 6, 2021 at 7:17 PM Alina Kazi <al...@gmail.com> wrote:
> +1 for two libs
>
> On Thu, 7 Oct 2021, 2:42 am Piotr Zarzycki, <pi...@gmail.com>
> 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 <gr...@gmail.com> 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
> >
>
--
Andrew Wetmore
http://cottage14.blogspot.com/
Re: MXRoyale splitting to two libs - please provide your feedback.
Posted by Alina Kazi <al...@gmail.com>.
+1 for two libs
On Thu, 7 Oct 2021, 2:42 am Piotr Zarzycki, <pi...@gmail.com>
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 <gr...@gmail.com> 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
>
Re: MXRoyale splitting to two libs - please provide your feedback.
Posted by Piotr Zarzycki <pi...@gmail.com>.
+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 <gr...@gmail.com> 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
RE: MXRoyale splitting to two libs - please provide your feedback.
Posted by Maria Jose Esteve <mj...@iest.com>.
Sorry? "Madremía!!! , as they say in my country"
No sorry, just a thank you. I wish I could collaborate like you, I'm only half beta tester hahahahahaha.
Thank you very much to you
Hiedra
-----Mensaje original-----
De: Greg Dove <gr...@gmail.com>
Enviado el: viernes, 15 de octubre de 2021 0:02
Para: Apache Royale Development <de...@royale.apache.org>
Asunto: Re: MXRoyale splitting to two libs - please provide your feedback.
Sorry Hiedra, that problem was my fault, and thanks also to Edward from me for figuring it out.
I had based the MXRoyaleBase part of my work on an old version of the ant build file because I actually started work on it last year and didn't come back to it until just recently. So I had the corresponding ant file in an earlier state, without more recent changes that were added to the one in MXRoyale. I had to work through many updates in the actionscript to get everything synced to the current code between MXRoyale and MXRoyaleBase, but didn't notice the change in the build files, which left me wondering why you were seeing issues. Thanks again, Edward!
Greg
On Fri, Oct 15, 2021 at 10:35 AM Maria Jose Esteve <mj...@iest.com>
wrote:
> Solved Edward, I compiled perfectly with your changes.
> Thank you very much.
> Hiedra.
>
> -----Mensaje original-----
> De: Edward Stangler <es...@bradmark.com> Enviado el: jueves, 14 de
> octubre de 2021 4:35
> Para: dev@royale.apache.org
> Asunto: Re: MXRoyale splitting to two libs - please provide your feedback.
>
>
> Well, I meant output from the "ant" command that I previously
> mentioned, but I think I see the issue.
>
> Your MXRoyaleBase.swc (compile-swf) is not happening at all. I think
> it's because the MXRoyaleBase/build.xml doesn't have recent changes
> from MXRoyale/build.xml. (My environment variables are probably
> different from yours, so the build.xml changes make a difference in
> your build but not
> mine.)
>
> Try the changes that I just submitted as PR #1156.
>
>
> On 10/13/2021 4:20 PM, Maria Jose Esteve wrote:
>
> Hi Edward,
>
> Yes, that was the first thing I looked at but I can't identify any
> problems. This is the exit:
>
> ...
>
>
>
>
>
> Hiedra.
>
> -----Mensaje original-----
> De: Edward Stangler
> Enviado el: mi?rcoles, 13 de octubre de 2021 21:19
> Para: dev@royale.apache.org<ma...@royale.apache.org>
> Asunto: Re: MXRoyale splitting to two libs - please provide your feedback.
>
>
>
> Maria,
>
>
>
> If you don't have a MXRoyaleBase.swc file, there must be some errors
> during the MXRoyaleBase part of the compile. What are those errors?
>
> (Or is that section of the compile missing?)
>
>
>
>
>
>
>
> On 10/13/2021 11:07 AM, Maria Jose Esteve wrote:
>
> > Hi Edward,
>
> >
>
> > I have the same error with your compile command. :(
>
> ...
>
> > [java] 0.56729972
> secondsD:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\src\main\config\compile-swf-config.xml(40):
> col: 0 unable to open
> 'D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\libs\MXRoyaleBase.swc'.
>
>
>
>
Re: MXRoyale splitting to two libs - please provide your feedback.
Posted by Greg Dove <gr...@gmail.com>.
Sorry Hiedra, that problem was my fault, and thanks also to Edward from me
for figuring it out.
I had based the MXRoyaleBase part of my work on an old version of the ant
build file because I actually started work on it last year and didn't come
back to it until just recently. So I had the corresponding ant file in an
earlier state, without more recent changes that were added to the one in
MXRoyale. I had to work through many updates in the actionscript to get
everything synced to the current code between MXRoyale and MXRoyaleBase,
but didn't notice the change in the build files, which left me wondering
why you were seeing issues. Thanks again, Edward!
Greg
On Fri, Oct 15, 2021 at 10:35 AM Maria Jose Esteve <mj...@iest.com>
wrote:
> Solved Edward, I compiled perfectly with your changes.
> Thank you very much.
> Hiedra.
>
> -----Mensaje original-----
> De: Edward Stangler <es...@bradmark.com>
> Enviado el: jueves, 14 de octubre de 2021 4:35
> Para: dev@royale.apache.org
> Asunto: Re: MXRoyale splitting to two libs - please provide your feedback.
>
>
> Well, I meant output from the "ant" command that I previously mentioned,
> but I think I see the issue.
>
> Your MXRoyaleBase.swc (compile-swf) is not happening at all. I think it's
> because the MXRoyaleBase/build.xml doesn't have recent changes from
> MXRoyale/build.xml. (My environment variables are probably different from
> yours, so the build.xml changes make a difference in your build but not
> mine.)
>
> Try the changes that I just submitted as PR #1156.
>
>
> On 10/13/2021 4:20 PM, Maria Jose Esteve wrote:
>
> Hi Edward,
>
> Yes, that was the first thing I looked at but I can't identify any
> problems. This is the exit:
>
> ...
>
>
>
>
>
> Hiedra.
>
> -----Mensaje original-----
> De: Edward Stangler
> Enviado el: mi?rcoles, 13 de octubre de 2021 21:19
> Para: dev@royale.apache.org<ma...@royale.apache.org>
> Asunto: Re: MXRoyale splitting to two libs - please provide your feedback.
>
>
>
> Maria,
>
>
>
> If you don't have a MXRoyaleBase.swc file, there must be some errors
> during the MXRoyaleBase part of the compile. What are those errors?
>
> (Or is that section of the compile missing?)
>
>
>
>
>
>
>
> On 10/13/2021 11:07 AM, Maria Jose Esteve wrote:
>
> > Hi Edward,
>
> >
>
> > I have the same error with your compile command. :(
>
> ...
>
> > [java] 0.56729972
> secondsD:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\src\main\config\compile-swf-config.xml(40):
> col: 0 unable to open
> 'D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\libs\MXRoyaleBase.swc'.
>
>
>
>
RE: MXRoyale splitting to two libs - please provide your feedback.
Posted by Maria Jose Esteve <mj...@iest.com>.
Solved Edward, I compiled perfectly with your changes.
Thank you very much.
Hiedra.
-----Mensaje original-----
De: Edward Stangler <es...@bradmark.com>
Enviado el: jueves, 14 de octubre de 2021 4:35
Para: dev@royale.apache.org
Asunto: Re: MXRoyale splitting to two libs - please provide your feedback.
Well, I meant output from the "ant" command that I previously mentioned, but I think I see the issue.
Your MXRoyaleBase.swc (compile-swf) is not happening at all. I think it's because the MXRoyaleBase/build.xml doesn't have recent changes from MXRoyale/build.xml. (My environment variables are probably different from yours, so the build.xml changes make a difference in your build but not mine.)
Try the changes that I just submitted as PR #1156.
On 10/13/2021 4:20 PM, Maria Jose Esteve wrote:
Hi Edward,
Yes, that was the first thing I looked at but I can't identify any problems. This is the exit:
...
Hiedra.
-----Mensaje original-----
De: Edward Stangler
Enviado el: mi?rcoles, 13 de octubre de 2021 21:19
Para: dev@royale.apache.org<ma...@royale.apache.org>
Asunto: Re: MXRoyale splitting to two libs - please provide your feedback.
Maria,
If you don't have a MXRoyaleBase.swc file, there must be some errors during the MXRoyaleBase part of the compile. What are those errors?
(Or is that section of the compile missing?)
On 10/13/2021 11:07 AM, Maria Jose Esteve wrote:
> Hi Edward,
>
> I have the same error with your compile command. :(
...
> [java] 0.56729972 secondsD:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\src\main\config\compile-swf-config.xml(40): col: 0 unable to open 'D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\libs\MXRoyaleBase.swc'.
Re: MXRoyale splitting to two libs - please provide your feedback.
Posted by Edward Stangler <es...@bradmark.com>.
Well, I meant output from the "ant" command that I previously mentioned, but I think I see the issue.
Your MXRoyaleBase.swc (compile-swf) is not happening at all. I think it's because the MXRoyaleBase/build.xml doesn't have recent changes from MXRoyale/build.xml. (My environment variables are probably different from yours, so the build.xml changes make a difference in your build but not mine.)
Try the changes that I just submitted as PR #1156.
On 10/13/2021 4:20 PM, Maria Jose Esteve wrote:
Hi Edward,
Yes, that was the first thing I looked at but I can't identify any problems. This is the exit:
...
Hiedra.
-----Mensaje original-----
De: Edward Stangler
Enviado el: mi?rcoles, 13 de octubre de 2021 21:19
Para: dev@royale.apache.org<ma...@royale.apache.org>
Asunto: Re: MXRoyale splitting to two libs - please provide your feedback.
Maria,
If you don't have a MXRoyaleBase.swc file, there must be some errors during the MXRoyaleBase part of the compile. What are those errors?
(Or is that section of the compile missing?)
On 10/13/2021 11:07 AM, Maria Jose Esteve wrote:
> Hi Edward,
>
> I have the same error with your compile command. :(
...
> [java] 0.56729972 secondsD:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\src\main\config\compile-swf-config.xml(40): col: 0 unable to open 'D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\libs\MXRoyaleBase.swc'.
RE: MXRoyale splitting to two libs - please provide your feedback.
Posted by Maria Jose Esteve <mj...@iest.com>.
Hi Edward,
Yes, that was the first thing I looked at but I can't identify any problems. This is the exit:
[INFO]
[INFO] --------------< org.apache.royale.framework:MXRoyaleBase >--------------
[INFO] Building Apache Royale: Framework: Libs: MXRoyaleBase 0.9.9-SNAPSHOT [22/162]
[INFO] --------------------------------[ swc ]---------------------------------
[INFO]
[INFO] --- maven-clean-plugin:3.1.0:clean (default-clean) @ MXRoyaleBase ---
[INFO]
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-version) @ MXRoyaleBase ---
[INFO]
[INFO] --- royale-maven-plugin:0.9.9-SNAPSHOT:generate-extern (default-generate-extern) @ MXRoyaleBase ---
[INFO]
[INFO] --- royale-maven-plugin:0.9.9-SNAPSHOT:generate-playerglobal (default-generate-playerglobal) @ MXRoyaleBase ---
[INFO]
[INFO] --- maven-remote-resources-plugin:1.7.0:process (process-resource-bundles) @ MXRoyaleBase ---
[INFO] Preparing remote bundle org.apache:apache-jar-resource-bundle:1.4
[INFO] Copying 3 resources from 1 bundle.
[INFO]
[INFO] --- maven-resources-plugin:3.1.0:resources (default-resources) @ MXRoyaleBase ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 3 resources
[INFO]
[INFO] --- royale-maven-plugin:0.9.9-SNAPSHOT:compile-as (default-compile-as) @ MXRoyaleBase ---
[INFO]
[INFO] --- royale-maven-plugin:0.9.9-SNAPSHOT:compile-js (default-compile-js) @ MXRoyaleBase ---
[INFO] Executing COMPC in tool group Royale with args: [-load-config=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\MXRoyaleBase\target\compile-js-config.xml, -js-default-initializers=false, -source-map=true, -source-map-source-root=/frameworks/projects/MXRoyaleBase/src/main/royale/, -js-complex-implicit-coercions=false, -js-vector-index-checks=false, -js-resolve-uncertain=false, -js-compiler-define=COMPILE::JS,true, -js-compiler-define=COMPILE::SWF,false, -js-compiler-define=GOOG::DEBUG,goog.DEBUG, -js-compiler-define=ROYALE::DISPLAYOBJECT,IUIComponent, -js-compiler-define=ROYALE::PROXYVISIBILITY,public, -namespace+=http://ns.adobe.com/mxml/2009,D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\MXRoyaleBase/../../mxml-2009-manifest.xml, -compiler.js-namespaces.namespace+=http://ns.adobe.com/mxml/2009,D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\MXRoyaleBase/../../mxml-2009-manifest.xml, -compiler.js-namespaces.namespace+=library://ns.apache.org/royale/mx,D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\MXRoyaleBase/src/main/resources/mx-royale-manifest.xml, -compiler.warn-instance-of-changes=false, -compiler.warn-this-within-closure=false, -compiler.targets=SWF,JSRoyale, -compiler.strict-xml=true]
args:
-load-config=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\MXRoyaleBase\target\compile-js-config.xml
-js-default-initializers=false
-source-map=true
-source-map-source-root=/frameworks/projects/MXRoyaleBase/src/main/royale/
-js-complex-implicit-coercions=false
-js-vector-index-checks=false
-js-resolve-uncertain=false
-js-compiler-define=COMPILE::JS,true
-js-compiler-define=COMPILE::SWF,false
-js-compiler-define=GOOG::DEBUG,goog.DEBUG
-js-compiler-define=ROYALE::DISPLAYOBJECT,IUIComponent
-js-compiler-define=ROYALE::PROXYVISIBILITY,public
-namespace+=http://ns.adobe.com/mxml/2009,D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\MXRoyaleBase/../../mxml-2009-manifest.xml
-compiler.js-namespaces.namespace+=http://ns.adobe.com/mxml/2009,D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\MXRoyaleBase/../../mxml-2009-manifest.xml
-compiler.js-namespaces.namespace+=library://ns.apache.org/royale/mx,D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\MXRoyaleBase/src/main/resources/mx-royale-manifest.xml
-compiler.warn-instance-of-changes=false
-compiler.warn-this-within-closure=false
-compiler.targets=SWF,JSRoyale
-compiler.strict-xml=true
target:SWF
target:JSRoyale
COMPC
Loading configuration: D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\MXRoyaleBase\target\compile-js-config.xml
653438 bytes written to D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\MXRoyaleBase\target\MXRoyaleBase-0.9.9-SNAPSHOT-js.swc in 1,279 seconds
COMPCJSCRoyale
6.42202245 seconds
[INFO]
[INFO] --- royale-maven-plugin:0.9.9-SNAPSHOT:compile-extern (default-compile-extern) @ MXRoyaleBase ---
[INFO]
[INFO] --- royale-maven-plugin:0.9.9-SNAPSHOT:compile-playerglobal (default-compile-playerglobal) @ MXRoyaleBase ---
[INFO]
[INFO] --- maven-resources-plugin:3.1.0:testResources (default-testResources) @ MXRoyaleBase ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\MXRoyaleBase\src\test\resources
[INFO] Copying 3 resources
[INFO]
[INFO] --- royale-maven-plugin:0.9.9-SNAPSHOT:trust (default-trust) @ MXRoyaleBase ---
- Updating FlashPlayer security trust file at: C:\Users\hiedra\AppData\Roaming\Macromedia\Flash Player\#Security\FlashPlayerTrust\apache-royale-maven-plugin.cfg
- Directory 'D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\MXRoyaleBase\target' already listed in FlashPlayer security trust file at: C:\Users\hiedra\AppData\Roaming\Macromedia\Flash Player\#Security\FlashPlayerTrust\apache-royale-maven-plugin.cfg
[INFO]
[INFO] --- maven-site-plugin:3.7.1:attach-descriptor (attach-descriptor) @ MXRoyaleBase ---
[INFO] Skipping because packaging 'swc' is not pom.
[INFO]
[INFO] --- apache-rat-plugin:0.13:check (license-check) @ MXRoyaleBase ---
[INFO] RAT will not execute since it is configured to be skipped via system property 'rat.skip'.
[INFO]
[INFO] --- maven-install-plugin:2.5.2:install (default-install) @ MXRoyaleBase ---
[INFO] No primary artifact to install, installing attached artifacts instead.
[INFO] Installing D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\MXRoyaleBase\pom.xml to H:\.m2\org\apache\royale\framework\MXRoyaleBase\0.9.9-SNAPSHOT\MXRoyaleBase-0.9.9-SNAPSHOT.pom
[INFO] Installing D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\MXRoyaleBase\target\MXRoyaleBase-0.9.9-SNAPSHOT-js.swc to H:\.m2\org\apache\royale\framework\MXRoyaleBase\0.9.9-SNAPSHOT\MXRoyaleBase-0.9.9-SNAPSHOT-js.swc
[INFO]
[INFO] ----------------< org.apache.royale.framework:Storage >-----------------
[INFO] Building Apache Royale: Framework: Libs: Storage 0.9.9-SNAPSHOT [23/162]
[INFO] --------------------------------[ swc ]---------------------------------
[INFO]
I attach a log of the previous compilation (without MX changes) and another one of the current compilation (the first one ok, and the second one not).
This is the content of the frameworks/libs directory: (from my previous compilation the files are missing: Crux.swc, Icons.swc, Jewel.swc, JewelTheme.swc, KeepsFBFromHanging.swc)
./air/ ./player/
Basic.swc Binding.swc Charts.swc Collections.swc Core.swc CreateJS.swc DragDrop.swc
Effects.swc Express.swc Flat.swc FontAwesome.swc Formatters.swc GoogleMaps.swc Graphics.swc
HTML.swc HTML5.swc jQuery.swc Language.swc MaterialDesignLite.swc Mobile.swc MXRoyale.swc
Network.swc Reflection.swc RoyaleSite.swc RoyaleUnit.swc RoyaleUnitUI.swc SparkRoyale.swc Storage.swc
Text.swc TLF.swc XML.swc
And this is of the frameworks/js/libs (Here it is MXRoyaleBaseJS.swc)
AceJS.swc BasicJS.swc BindingJS.swc ChartsJS.swc CollectionsJS.swc CoreJS.swc CreateJSJS.swc
DragDropJS.swc EffectsJS.swc ExpressJS.swc FlatJS.swc FontAwesomeJS.swc FormattersJS.swc GoogleMapsJS.swc
GraphicsJS.swc HTML5JS.swc HTMLJS.swc jQueryJS.swc LanguageJS.swc MaterialDesignLiteJS.swc MobileJS.swc
MXRoyaleBaseJS.swc MXRoyaleJS.swc NetworkJS.swc ReflectionJS.swc RoyaleSiteJS.swc RoyaleUnitJS.swc RoyaleUnitUIJS.swc
SparkRoyaleJS.swc StorageJS.swc TextJS.swc TLFJS.swc XMLJS.swc
Hahahaha, Do you recognise anything?
Hiedra.
-----Mensaje original-----
De: Edward Stangler <es...@bradmark.com>
Enviado el: miércoles, 13 de octubre de 2021 21:19
Para: dev@royale.apache.org
Asunto: Re: MXRoyale splitting to two libs - please provide your feedback.
Maria,
If you don't have a MXRoyaleBase.swc file, there must be some errors during the MXRoyaleBase part of the compile. What are those errors?
(Or is that section of the compile missing?)
On 10/13/2021 11:07 AM, Maria Jose Esteve wrote:
> Hi Edward,
>
> I have the same error with your compile command. ☹
...
> [java] 0.56729972 secondsD:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\src\main\config\compile-swf-config.xml(40): col: 0 unable to open 'D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\libs\MXRoyaleBase.swc'.
Re: MXRoyale splitting to two libs - please provide your feedback.
Posted by Edward Stangler <es...@bradmark.com>.
Maria,
If you don't have a MXRoyaleBase.swc file, there must be some errors
during the MXRoyaleBase part of the compile. What are those errors?
(Or is that section of the compile missing?)
On 10/13/2021 11:07 AM, Maria Jose Esteve wrote:
> Hi Edward,
>
> I have the same error with your compile command. ☹
...
> [java] 0.56729972 secondsD:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\src\main\config\compile-swf-config.xml(40): col: 0 unable to open 'D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\libs\MXRoyaleBase.swc'.
RE: MXRoyale splitting to two libs - please provide your feedback.
Posted by Maria Jose Esteve <mj...@iest.com>.
Hi Edward,
I have the same error with your compile command. ☹
compile:
[echo] swc-date is 10/13/21 16:44 +0200
compile-swf:
[echo] Compiling libs/Crux.swc
[echo] ROYALE_HOME: D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
[echo] ROYALE_SWF_COMPILER_HOME: D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
[echo] ROYALE_COMPILER_HOME: D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork/js
[java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms256m -Xmx2048m
[java] args:
[java] +royalelib=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork/frameworks
[java] +playerglobal.version=11.1
[java] +env.AIR_HOME=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
[java] -compiler.strict-xml=true
[java] -compiler.targets=SWF,JSRoyale
[java] -metadata.date=10/13/21 16:44 +0200
[java] -metadata.dateFormat=MM/dd/yy HH:mm Z
[java] -swf-debugfile-alias=/org/apache/royale/0.9.9
[java] -output=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux/target/Crux.swc
[java] -load-config=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux/src/main/config/compile-swf-config.xml
[java] -js-load-config=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork/frameworks/js-config.xml
[java] -js-load-config+=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux/../../js/projects/CruxJS/src/main/config/compile-js-config.xml
[java] 0.56729972 secondsD:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\src\main\config\compile-swf-config.xml(40): col: 0 unable to open 'D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\libs\MXRoyaleBase.swc'.
[java]
[java] D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\src\main\config\compile-swf-config.xml (line: 40)
[java]
[java] </external-library-path>
[java]
[java]
Press a key to continue . . .
How can it be if my bat is the same as always?
Compiled fine without problems until commit " <jo...@apache.org> c2f7c2855f70342612bf732e742253434fffe9b032 05/10/2021 18:43:17".
I resubmit my SDK build bat:
call ant super-clean
call mvn clean install -DskipTests -Drat.skip=true -P option-with-sass-compile
SET JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8 -Xms256m -Xmx2048m
call ant all -Dbuild.noprompt=true -Drelease.target=true -Dskip-tests=true
Later I will do another test, "compile Maven without sass" because maybe the problem is there.
Hiedra
-----Mensaje original-----
De: Edward Stangler <es...@bradmark.com>>
Enviado el: miércoles, 13 de octubre de 2021 10:14
Para: dev@royale.apache.org<ma...@royale.apache.org>
Asunto: Re: MXRoyale splitting to two libs - please provide your feedback.
ant -Dskip-tests=1 all
works for me, and it generates MXRoyaleBase.swc.
I've tried various tests and compiles, and so far it hasn't broke.
On 10/13/2021 3:07 AM, Maria Jose Esteve wrote:
> I keep getting errors when compiling, the MXRoyaleBase.swc file is not generated, is this not happening to anyone else?
>
> Hiedra
Re: MXRoyale splitting to two libs - please provide your feedback.
Posted by Edward Stangler <es...@bradmark.com>.
ant -Dskip-tests=1 all
works for me, and it generates MXRoyaleBase.swc.
I've tried various tests and compiles, and so far it hasn't broke.
On 10/13/2021 3:07 AM, Maria Jose Esteve wrote:
> I keep getting errors when compiling, the MXRoyaleBase.swc file is not generated, is this not happening to anyone else?
>
> Hiedra
RE: MXRoyale splitting to two libs - please provide your feedback.
Posted by Maria Jose Esteve <mj...@iest.com>.
I keep getting errors when compiling, the MXRoyaleBase.swc file is not generated, is this not happening to anyone else?
Hiedra
-----Mensaje original-----
De: Maria Jose Esteve <mj...@iest.com>
Enviado el: domingo, 10 de octubre de 2021 4:41
Para: dev@royale.apache.org
Asunto: RE: MXRoyale splitting to two libs - please provide your feedback.
:P
My name is "María José", Hiedra is my nickname (I'm already a few years old...) but anyone will do.
I tried without the -Drelease.target=true option and got the same error.
It does seem strange... because my .bat is the same as always :)
Tomorrow I'll do some more tests and I'll share the results (in Spain it's 4.38 am and I'm too sleepy to see the screen, :P)
Hiedra
-----Mensaje original-----
De: Greg Dove <gr...@gmail.com>
Enviado el: domingo, 10 de octubre de 2021 4:00
Para: Apache Royale Development <de...@royale.apache.org>
Asunto: Re: MXRoyale splitting to two libs - please provide your feedback.
Hiedra (or is it Maria? I apologise, but I am still not sure which name, but I guess it is Hiedra),
I was not able to reproduce the issue you described, when I followed the same build commands that you used. Everything worked for me...
Also, the CI build is working with ant just fine, it seems, build is working after the changes and I can see the MXRoyaleBase.swc in the nightly build when I download it:
http://apacheroyaleci2.westus2.cloudapp.azure.com:8080/job/royale-asjs/
I'm not sure what is causing the problem for you, unless you had some local changes in the build scripts and conflicts that did not resolve well when you pulled the updates (probably not, I am just trying to guess how this could happen).
Hopefully it will resolve next time you try. If anyone else sees the same issue, can you please let me know?
Thanks,
Greg
On Sun, Oct 10, 2021 at 12:57 PM Greg Dove <gr...@gmail.com> wrote:
>
> Thanks I will look into it as soon as I can. I had tested it with my
> daily build which is both ant and maven, so I will try to figure out
> what the difference is (I don't use -Drelease.target=true for
> instance) Greg
>
>
>
> On Sun, Oct 10, 2021 at 12:41 PM Maria Jose Esteve <mj...@iest.com>
> wrote:
>
>> Sorry, I forgot to attach my compilation task:
>> …
>> call ant super-clean
>> call mvn clean install -DskipTests -Drat.skip=true -P
>> option-with-sass-compile SET JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8
>> -Xms256m -Xmx2048m call ant all -Dbuild.noprompt=true
>> -Drelease.target=true -Dskip-tests=true
>>
>> Hiedra
>>
>> De: Maria Jose Esteve <mj...@iest.com> Enviado el: domingo, 10 de
>> octubre de 2021 1:37
>> Para: dev@royale.apache.org
>> Asunto: RE: MXRoyale splitting to two libs - please provide your feedback.
>>
>>
>> Hi,
>>
>> @Greg, I downloaded your latest changes to royale-asjs and got an
>> error in the ant compilation.
>>
>> The general error:
>>
>>
>>
>> BUILD FAILED
>>
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\build.xml:696:
>> The following error occurred while executing this line:
>>
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\build.xml:155:
>> The following error occurred while executing this line:
>>
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\build.xml:554:
>> The following error occurred while executing this line:
>>
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\build.xml:108:
>> The following error occurred while executing this line:
>>
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\build.xml:134:
>> condition satisfied
>>
>>
>>
>> in the compilation ant:
>>
>>
>>
>> Crux:
>>
>> [echo] swc-date is 10/10/21 01:06 +0200
>>
>>
>>
>> clean:
>>
>> [echo] swc-date is 10/10/21 01:06 +0200
>>
>>
>>
>> check-for-tests:
>>
>>
>>
>> clean-tests:
>>
>>
>>
>> check-compiler-home:
>>
>>
>>
>> check-transpiler-home:
>>
>>
>>
>> check-compiler:
>>
>>
>>
>> compile:
>>
>> [echo] swc-date is 10/10/21 01:06 +0200
>>
>>
>>
>> compile-swf:
>>
>> [echo] Compiling libs/Crux.swc
>>
>> [echo] ROYALE_HOME:
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
>>
>> [echo] ROYALE_SWF_COMPILER_HOME:
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
>>
>> [echo] ROYALE_COMPILER_HOME:
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork/js
>>
>> [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
>> -Xms256m -Xmx2048m
>>
>> [java] args:
>>
>> [java]
>> +royalelib=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork/fra
>> +meworks
>>
>> [java] +playerglobal.version=11.1
>>
>> [java]
>> +env.AIR_HOME=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
>>
>> [java] -compiler.strict-xml=true
>>
>> [java] -compiler.targets=SWF,JSRoyale
>>
>> [java] -metadata.date=10/10/21 01:06 +0200
>>
>> [java] -metadata.dateFormat=MM/dd/yy HH:mm Z
>>
>> [java] -swf-debugfile-alias=/org/apache/royale/0.9.9
>>
>> [java]
>> -output=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\framew
>> orks\projects\Crux/target/Crux.swc
>>
>> [java]
>> -load-config=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\f
>> rameworks\projects\Crux/src/main/config/compile-swf-config.xml
>>
>> [java]
>> -js-load-config=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-for
>> k/frameworks/js-config.xml
>>
>> [java]
>> -js-load-config+=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fo
>> -js-load-config+rk\frameworks\projects\Crux/../../js/projects/CruxJS/
>> -js-load-config+src/main/config/compile-js-config.xml
>>
>> [java] 0.601410729 seconds
>>
>> [java]
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\src\main\config\compile-swf-config.xml(40):
>> col: 0 unable to open
>> 'D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\libs\MXRoyaleBase.swc'.
>>
>> [java]
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\pro
>> jects\Crux\src\main\config\compile-swf-config.xml
>> (line: 40)
>>
>> [java]
>>
>> [java] </external-library-path>
>>
>> [java]
>>
>> [java]
>>
>>
>>
>> I have verified that MXRoyaleBase.swc has not been generated.
>>
>> Attached is the compilation log.
>>
>>
>>
>> Hiedra
>>
>>
>>
>> -----Mensaje original-----
>> De: Greg Dove <gr...@gmail.com>>
>> Enviado el: sábado, 9 de octubre de 2021 22:19
>> Para: Apache Royale Development <dev@royale.apache.org<mailto:
>> dev@royale.apache.org>>
>> Asunto: Re: MXRoyale splitting to two libs - please provide your feedback.
>>
>>
>>
>> OK, thanks for the feedback everyone.
>>
>>
>>
>> I pushed the changes yesterday, and made changes to the crux examples
>> to use MXRoyaleBase instead of MXRoyale in the dependencies, and
>> quickly tested the ant and maven builds for those examples.
>>
>> I built one of them again locally using the downloaded maven
>> artifacts today and it worked as it should, so it seems all is well
>> (at least for simple testing).
>>
>>
>>
>> Let me know if you see any issues, but so far I believe it's working
>> as it should.
>>
>> In terms of possibly moving more things from MXRoyale to
>> MXRoyaleBase, there could be more candidates for doing that, but in
>> order to do that there should be no dependency link to any UI implementations for each case.
>>
>>
>>
>> Greg
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Oct 7, 2021 at 6:28 PM Harbs <harbs.lists@gmail.com<mailto:
>> harbs.lists@gmail.com>> wrote:
>>
>>
>>
>> > This will not effect me much. Sounds like a good idea, though.
>>
>> >
>>
>> > Harbs
>>
>> >
>>
>> > > On Oct 6, 2021, at 11:59 PM, Greg Dove <greg.dove@gmail.com<mailto:
>> greg.dove@gmail.com>> 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
>>
>> >
>>
>> >
>>
>
RE: MXRoyale splitting to two libs - please provide your feedback.
Posted by Maria Jose Esteve <mj...@iest.com>.
:P
My name is "María José", Hiedra is my nickname (I'm already a few years old...) but anyone will do.
I tried without the -Drelease.target=true option and got the same error.
It does seem strange... because my .bat is the same as always :)
Tomorrow I'll do some more tests and I'll share the results (in Spain it's 4.38 am and I'm too sleepy to see the screen, :P)
Hiedra
-----Mensaje original-----
De: Greg Dove <gr...@gmail.com>
Enviado el: domingo, 10 de octubre de 2021 4:00
Para: Apache Royale Development <de...@royale.apache.org>
Asunto: Re: MXRoyale splitting to two libs - please provide your feedback.
Hiedra (or is it Maria? I apologise, but I am still not sure which name, but I guess it is Hiedra),
I was not able to reproduce the issue you described, when I followed the same build commands that you used. Everything worked for me...
Also, the CI build is working with ant just fine, it seems, build is working after the changes and I can see the MXRoyaleBase.swc in the nightly build when I download it:
http://apacheroyaleci2.westus2.cloudapp.azure.com:8080/job/royale-asjs/
I'm not sure what is causing the problem for you, unless you had some local changes in the build scripts and conflicts that did not resolve well when you pulled the updates (probably not, I am just trying to guess how this could happen).
Hopefully it will resolve next time you try. If anyone else sees the same issue, can you please let me know?
Thanks,
Greg
On Sun, Oct 10, 2021 at 12:57 PM Greg Dove <gr...@gmail.com> wrote:
>
> Thanks I will look into it as soon as I can. I had tested it with my
> daily build which is both ant and maven, so I will try to figure out
> what the difference is (I don't use -Drelease.target=true for
> instance) Greg
>
>
>
> On Sun, Oct 10, 2021 at 12:41 PM Maria Jose Esteve <mj...@iest.com>
> wrote:
>
>> Sorry, I forgot to attach my compilation task:
>> …
>> call ant super-clean
>> call mvn clean install -DskipTests -Drat.skip=true -P
>> option-with-sass-compile SET JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8
>> -Xms256m -Xmx2048m call ant all -Dbuild.noprompt=true
>> -Drelease.target=true -Dskip-tests=true
>>
>> Hiedra
>>
>> De: Maria Jose Esteve <mj...@iest.com> Enviado el: domingo, 10 de
>> octubre de 2021 1:37
>> Para: dev@royale.apache.org
>> Asunto: RE: MXRoyale splitting to two libs - please provide your feedback.
>>
>>
>> Hi,
>>
>> @Greg, I downloaded your latest changes to royale-asjs and got an
>> error in the ant compilation.
>>
>> The general error:
>>
>>
>>
>> BUILD FAILED
>>
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\build.xml:696:
>> The following error occurred while executing this line:
>>
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\build.xml:155:
>> The following error occurred while executing this line:
>>
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\build.xml:554:
>> The following error occurred while executing this line:
>>
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\build.xml:108:
>> The following error occurred while executing this line:
>>
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\build.xml:134:
>> condition satisfied
>>
>>
>>
>> in the compilation ant:
>>
>>
>>
>> Crux:
>>
>> [echo] swc-date is 10/10/21 01:06 +0200
>>
>>
>>
>> clean:
>>
>> [echo] swc-date is 10/10/21 01:06 +0200
>>
>>
>>
>> check-for-tests:
>>
>>
>>
>> clean-tests:
>>
>>
>>
>> check-compiler-home:
>>
>>
>>
>> check-transpiler-home:
>>
>>
>>
>> check-compiler:
>>
>>
>>
>> compile:
>>
>> [echo] swc-date is 10/10/21 01:06 +0200
>>
>>
>>
>> compile-swf:
>>
>> [echo] Compiling libs/Crux.swc
>>
>> [echo] ROYALE_HOME:
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
>>
>> [echo] ROYALE_SWF_COMPILER_HOME:
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
>>
>> [echo] ROYALE_COMPILER_HOME:
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork/js
>>
>> [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
>> -Xms256m -Xmx2048m
>>
>> [java] args:
>>
>> [java]
>> +royalelib=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork/fra
>> +meworks
>>
>> [java] +playerglobal.version=11.1
>>
>> [java]
>> +env.AIR_HOME=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
>>
>> [java] -compiler.strict-xml=true
>>
>> [java] -compiler.targets=SWF,JSRoyale
>>
>> [java] -metadata.date=10/10/21 01:06 +0200
>>
>> [java] -metadata.dateFormat=MM/dd/yy HH:mm Z
>>
>> [java] -swf-debugfile-alias=/org/apache/royale/0.9.9
>>
>> [java]
>> -output=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\framew
>> orks\projects\Crux/target/Crux.swc
>>
>> [java]
>> -load-config=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\f
>> rameworks\projects\Crux/src/main/config/compile-swf-config.xml
>>
>> [java]
>> -js-load-config=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-for
>> k/frameworks/js-config.xml
>>
>> [java]
>> -js-load-config+=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fo
>> -js-load-config+rk\frameworks\projects\Crux/../../js/projects/CruxJS/
>> -js-load-config+src/main/config/compile-js-config.xml
>>
>> [java] 0.601410729 seconds
>>
>> [java]
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\src\main\config\compile-swf-config.xml(40):
>> col: 0 unable to open
>> 'D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\libs\MXRoyaleBase.swc'.
>>
>> [java]
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\pro
>> jects\Crux\src\main\config\compile-swf-config.xml
>> (line: 40)
>>
>> [java]
>>
>> [java] </external-library-path>
>>
>> [java]
>>
>> [java]
>>
>>
>>
>> I have verified that MXRoyaleBase.swc has not been generated.
>>
>> Attached is the compilation log.
>>
>>
>>
>> Hiedra
>>
>>
>>
>> -----Mensaje original-----
>> De: Greg Dove <gr...@gmail.com>>
>> Enviado el: sábado, 9 de octubre de 2021 22:19
>> Para: Apache Royale Development <dev@royale.apache.org<mailto:
>> dev@royale.apache.org>>
>> Asunto: Re: MXRoyale splitting to two libs - please provide your feedback.
>>
>>
>>
>> OK, thanks for the feedback everyone.
>>
>>
>>
>> I pushed the changes yesterday, and made changes to the crux examples
>> to use MXRoyaleBase instead of MXRoyale in the dependencies, and
>> quickly tested the ant and maven builds for those examples.
>>
>> I built one of them again locally using the downloaded maven
>> artifacts today and it worked as it should, so it seems all is well
>> (at least for simple testing).
>>
>>
>>
>> Let me know if you see any issues, but so far I believe it's working
>> as it should.
>>
>> In terms of possibly moving more things from MXRoyale to
>> MXRoyaleBase, there could be more candidates for doing that, but in
>> order to do that there should be no dependency link to any UI implementations for each case.
>>
>>
>>
>> Greg
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Oct 7, 2021 at 6:28 PM Harbs <harbs.lists@gmail.com<mailto:
>> harbs.lists@gmail.com>> wrote:
>>
>>
>>
>> > This will not effect me much. Sounds like a good idea, though.
>>
>> >
>>
>> > Harbs
>>
>> >
>>
>> > > On Oct 6, 2021, at 11:59 PM, Greg Dove <greg.dove@gmail.com<mailto:
>> greg.dove@gmail.com>> 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
>>
>> >
>>
>> >
>>
>
Re: MXRoyale splitting to two libs - please provide your feedback.
Posted by Greg Dove <gr...@gmail.com>.
Hiedra (or is it Maria? I apologise, but I am still not sure which name,
but I guess it is Hiedra),
I was not able to reproduce the issue you described, when I followed the
same build commands that you used. Everything worked for me...
Also, the CI build is working with ant just fine, it seems, build is
working after the changes and I can see the MXRoyaleBase.swc in the nightly
build when I download it:
http://apacheroyaleci2.westus2.cloudapp.azure.com:8080/job/royale-asjs/
I'm not sure what is causing the problem for you, unless you had some local
changes in the build scripts and conflicts that did not resolve well when
you pulled the updates (probably not, I am just trying to guess how
this could happen).
Hopefully it will resolve next time you try. If anyone else sees the same
issue, can you please let me know?
Thanks,
Greg
On Sun, Oct 10, 2021 at 12:57 PM Greg Dove <gr...@gmail.com> wrote:
>
> Thanks I will look into it as soon as I can. I had tested it with my daily
> build which is both ant and maven, so I will try to figure out what the
> difference is (I don't use -Drelease.target=true for instance)
> Greg
>
>
>
> On Sun, Oct 10, 2021 at 12:41 PM Maria Jose Esteve <mj...@iest.com>
> wrote:
>
>> Sorry, I forgot to attach my compilation task:
>> …
>> call ant super-clean
>> call mvn clean install -DskipTests -Drat.skip=true -P
>> option-with-sass-compile
>> SET JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8 -Xms256m -Xmx2048m
>> call ant all -Dbuild.noprompt=true -Drelease.target=true -Dskip-tests=true
>>
>> Hiedra
>>
>> De: Maria Jose Esteve <mj...@iest.com>
>> Enviado el: domingo, 10 de octubre de 2021 1:37
>> Para: dev@royale.apache.org
>> Asunto: RE: MXRoyale splitting to two libs - please provide your feedback.
>>
>>
>> Hi,
>>
>> @Greg, I downloaded your latest changes to royale-asjs and got an error
>> in the ant compilation.
>>
>> The general error:
>>
>>
>>
>> BUILD FAILED
>>
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\build.xml:696: The
>> following error occurred while executing this line:
>>
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\build.xml:155:
>> The following error occurred while executing this line:
>>
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\build.xml:554:
>> The following error occurred while executing this line:
>>
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\build.xml:108:
>> The following error occurred while executing this line:
>>
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\build.xml:134:
>> condition satisfied
>>
>>
>>
>> in the compilation ant:
>>
>>
>>
>> Crux:
>>
>> [echo] swc-date is 10/10/21 01:06 +0200
>>
>>
>>
>> clean:
>>
>> [echo] swc-date is 10/10/21 01:06 +0200
>>
>>
>>
>> check-for-tests:
>>
>>
>>
>> clean-tests:
>>
>>
>>
>> check-compiler-home:
>>
>>
>>
>> check-transpiler-home:
>>
>>
>>
>> check-compiler:
>>
>>
>>
>> compile:
>>
>> [echo] swc-date is 10/10/21 01:06 +0200
>>
>>
>>
>> compile-swf:
>>
>> [echo] Compiling libs/Crux.swc
>>
>> [echo] ROYALE_HOME:
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
>>
>> [echo] ROYALE_SWF_COMPILER_HOME:
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
>>
>> [echo] ROYALE_COMPILER_HOME:
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork/js
>>
>> [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms256m
>> -Xmx2048m
>>
>> [java] args:
>>
>> [java]
>> +royalelib=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork/frameworks
>>
>> [java] +playerglobal.version=11.1
>>
>> [java]
>> +env.AIR_HOME=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
>>
>> [java] -compiler.strict-xml=true
>>
>> [java] -compiler.targets=SWF,JSRoyale
>>
>> [java] -metadata.date=10/10/21 01:06 +0200
>>
>> [java] -metadata.dateFormat=MM/dd/yy HH:mm Z
>>
>> [java] -swf-debugfile-alias=/org/apache/royale/0.9.9
>>
>> [java]
>> -output=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux/target/Crux.swc
>>
>> [java]
>> -load-config=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux/src/main/config/compile-swf-config.xml
>>
>> [java]
>> -js-load-config=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork/frameworks/js-config.xml
>>
>> [java]
>> -js-load-config+=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux/../../js/projects/CruxJS/src/main/config/compile-js-config.xml
>>
>> [java] 0.601410729 seconds
>>
>> [java]
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\src\main\config\compile-swf-config.xml(40):
>> col: 0 unable to open
>> 'D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\libs\MXRoyaleBase.swc'.
>>
>> [java]
>> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\src\main\config\compile-swf-config.xml
>> (line: 40)
>>
>> [java]
>>
>> [java] </external-library-path>
>>
>> [java]
>>
>> [java]
>>
>>
>>
>> I have verified that MXRoyaleBase.swc has not been generated.
>>
>> Attached is the compilation log.
>>
>>
>>
>> Hiedra
>>
>>
>>
>> -----Mensaje original-----
>> De: Greg Dove <gr...@gmail.com>>
>> Enviado el: sábado, 9 de octubre de 2021 22:19
>> Para: Apache Royale Development <dev@royale.apache.org<mailto:
>> dev@royale.apache.org>>
>> Asunto: Re: MXRoyale splitting to two libs - please provide your feedback.
>>
>>
>>
>> OK, thanks for the feedback everyone.
>>
>>
>>
>> I pushed the changes yesterday, and made changes to the crux examples to
>> use MXRoyaleBase instead of MXRoyale in the dependencies, and quickly
>> tested the ant and maven builds for those examples.
>>
>> I built one of them again locally using the downloaded maven artifacts
>> today and it worked as it should, so it seems all is well (at least for
>> simple testing).
>>
>>
>>
>> Let me know if you see any issues, but so far I believe it's working as
>> it should.
>>
>> In terms of possibly moving more things from MXRoyale to MXRoyaleBase,
>> there could be more candidates for doing that, but in order to do that
>> there should be no dependency link to any UI implementations for each case.
>>
>>
>>
>> Greg
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Oct 7, 2021 at 6:28 PM Harbs <harbs.lists@gmail.com<mailto:
>> harbs.lists@gmail.com>> wrote:
>>
>>
>>
>> > This will not effect me much. Sounds like a good idea, though.
>>
>> >
>>
>> > Harbs
>>
>> >
>>
>> > > On Oct 6, 2021, at 11:59 PM, Greg Dove <greg.dove@gmail.com<mailto:
>> greg.dove@gmail.com>> 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
>>
>> >
>>
>> >
>>
>
Re: MXRoyale splitting to two libs - please provide your feedback.
Posted by Greg Dove <gr...@gmail.com>.
Thanks I will look into it as soon as I can. I had tested it with my daily
build which is both ant and maven, so I will try to figure out what the
difference is (I don't use -Drelease.target=true for instance)
Greg
On Sun, Oct 10, 2021 at 12:41 PM Maria Jose Esteve <mj...@iest.com>
wrote:
> Sorry, I forgot to attach my compilation task:
> …
> call ant super-clean
> call mvn clean install -DskipTests -Drat.skip=true -P
> option-with-sass-compile
> SET JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8 -Xms256m -Xmx2048m
> call ant all -Dbuild.noprompt=true -Drelease.target=true -Dskip-tests=true
>
> Hiedra
>
> De: Maria Jose Esteve <mj...@iest.com>
> Enviado el: domingo, 10 de octubre de 2021 1:37
> Para: dev@royale.apache.org
> Asunto: RE: MXRoyale splitting to two libs - please provide your feedback.
>
>
> Hi,
>
> @Greg, I downloaded your latest changes to royale-asjs and got an error in
> the ant compilation.
>
> The general error:
>
>
>
> BUILD FAILED
>
> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\build.xml:696: The
> following error occurred while executing this line:
>
> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\build.xml:155:
> The following error occurred while executing this line:
>
> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\build.xml:554:
> The following error occurred while executing this line:
>
> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\build.xml:108:
> The following error occurred while executing this line:
>
> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\build.xml:134:
> condition satisfied
>
>
>
> in the compilation ant:
>
>
>
> Crux:
>
> [echo] swc-date is 10/10/21 01:06 +0200
>
>
>
> clean:
>
> [echo] swc-date is 10/10/21 01:06 +0200
>
>
>
> check-for-tests:
>
>
>
> clean-tests:
>
>
>
> check-compiler-home:
>
>
>
> check-transpiler-home:
>
>
>
> check-compiler:
>
>
>
> compile:
>
> [echo] swc-date is 10/10/21 01:06 +0200
>
>
>
> compile-swf:
>
> [echo] Compiling libs/Crux.swc
>
> [echo] ROYALE_HOME:
> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
>
> [echo] ROYALE_SWF_COMPILER_HOME:
> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
>
> [echo] ROYALE_COMPILER_HOME:
> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork/js
>
> [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms256m
> -Xmx2048m
>
> [java] args:
>
> [java]
> +royalelib=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork/frameworks
>
> [java] +playerglobal.version=11.1
>
> [java]
> +env.AIR_HOME=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
>
> [java] -compiler.strict-xml=true
>
> [java] -compiler.targets=SWF,JSRoyale
>
> [java] -metadata.date=10/10/21 01:06 +0200
>
> [java] -metadata.dateFormat=MM/dd/yy HH:mm Z
>
> [java] -swf-debugfile-alias=/org/apache/royale/0.9.9
>
> [java]
> -output=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux/target/Crux.swc
>
> [java]
> -load-config=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux/src/main/config/compile-swf-config.xml
>
> [java]
> -js-load-config=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork/frameworks/js-config.xml
>
> [java]
> -js-load-config+=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux/../../js/projects/CruxJS/src/main/config/compile-js-config.xml
>
> [java] 0.601410729 seconds
>
> [java]
> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\src\main\config\compile-swf-config.xml(40):
> col: 0 unable to open
> 'D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\libs\MXRoyaleBase.swc'.
>
> [java]
> D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\src\main\config\compile-swf-config.xml
> (line: 40)
>
> [java]
>
> [java] </external-library-path>
>
> [java]
>
> [java]
>
>
>
> I have verified that MXRoyaleBase.swc has not been generated.
>
> Attached is the compilation log.
>
>
>
> Hiedra
>
>
>
> -----Mensaje original-----
> De: Greg Dove <gr...@gmail.com>>
> Enviado el: sábado, 9 de octubre de 2021 22:19
> Para: Apache Royale Development <dev@royale.apache.org<mailto:
> dev@royale.apache.org>>
> Asunto: Re: MXRoyale splitting to two libs - please provide your feedback.
>
>
>
> OK, thanks for the feedback everyone.
>
>
>
> I pushed the changes yesterday, and made changes to the crux examples to
> use MXRoyaleBase instead of MXRoyale in the dependencies, and quickly
> tested the ant and maven builds for those examples.
>
> I built one of them again locally using the downloaded maven artifacts
> today and it worked as it should, so it seems all is well (at least for
> simple testing).
>
>
>
> Let me know if you see any issues, but so far I believe it's working as it
> should.
>
> In terms of possibly moving more things from MXRoyale to MXRoyaleBase,
> there could be more candidates for doing that, but in order to do that
> there should be no dependency link to any UI implementations for each case.
>
>
>
> Greg
>
>
>
>
>
>
>
>
>
> On Thu, Oct 7, 2021 at 6:28 PM Harbs <harbs.lists@gmail.com<mailto:
> harbs.lists@gmail.com>> wrote:
>
>
>
> > This will not effect me much. Sounds like a good idea, though.
>
> >
>
> > Harbs
>
> >
>
> > > On Oct 6, 2021, at 11:59 PM, Greg Dove <greg.dove@gmail.com<mailto:
> greg.dove@gmail.com>> 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
>
> >
>
> >
>
RE: MXRoyale splitting to two libs - please provide your feedback.
Posted by Maria Jose Esteve <mj...@iest.com>.
Sorry, I forgot to attach my compilation task:
…
call ant super-clean
call mvn clean install -DskipTests -Drat.skip=true -P option-with-sass-compile
SET JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8 -Xms256m -Xmx2048m
call ant all -Dbuild.noprompt=true -Drelease.target=true -Dskip-tests=true
Hiedra
De: Maria Jose Esteve <mj...@iest.com>
Enviado el: domingo, 10 de octubre de 2021 1:37
Para: dev@royale.apache.org
Asunto: RE: MXRoyale splitting to two libs - please provide your feedback.
Hi,
@Greg, I downloaded your latest changes to royale-asjs and got an error in the ant compilation.
The general error:
BUILD FAILED
D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\build.xml:696: The following error occurred while executing this line:
D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\build.xml:155: The following error occurred while executing this line:
D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\build.xml:554: The following error occurred while executing this line:
D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\build.xml:108: The following error occurred while executing this line:
D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\build.xml:134: condition satisfied
in the compilation ant:
Crux:
[echo] swc-date is 10/10/21 01:06 +0200
clean:
[echo] swc-date is 10/10/21 01:06 +0200
check-for-tests:
clean-tests:
check-compiler-home:
check-transpiler-home:
check-compiler:
compile:
[echo] swc-date is 10/10/21 01:06 +0200
compile-swf:
[echo] Compiling libs/Crux.swc
[echo] ROYALE_HOME: D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
[echo] ROYALE_SWF_COMPILER_HOME: D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
[echo] ROYALE_COMPILER_HOME: D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork/js
[java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms256m -Xmx2048m
[java] args:
[java] +royalelib=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork/frameworks
[java] +playerglobal.version=11.1
[java] +env.AIR_HOME=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
[java] -compiler.strict-xml=true
[java] -compiler.targets=SWF,JSRoyale
[java] -metadata.date=10/10/21 01:06 +0200
[java] -metadata.dateFormat=MM/dd/yy HH:mm Z
[java] -swf-debugfile-alias=/org/apache/royale/0.9.9
[java] -output=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux/target/Crux.swc
[java] -load-config=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux/src/main/config/compile-swf-config.xml
[java] -js-load-config=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork/frameworks/js-config.xml
[java] -js-load-config+=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux/../../js/projects/CruxJS/src/main/config/compile-js-config.xml
[java] 0.601410729 seconds
[java] D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\src\main\config\compile-swf-config.xml(40): col: 0 unable to open 'D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\libs\MXRoyaleBase.swc'.
[java] D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\src\main\config\compile-swf-config.xml (line: 40)
[java]
[java] </external-library-path>
[java]
[java]
I have verified that MXRoyaleBase.swc has not been generated.
Attached is the compilation log.
Hiedra
-----Mensaje original-----
De: Greg Dove <gr...@gmail.com>>
Enviado el: sábado, 9 de octubre de 2021 22:19
Para: Apache Royale Development <de...@royale.apache.org>>
Asunto: Re: MXRoyale splitting to two libs - please provide your feedback.
OK, thanks for the feedback everyone.
I pushed the changes yesterday, and made changes to the crux examples to use MXRoyaleBase instead of MXRoyale in the dependencies, and quickly tested the ant and maven builds for those examples.
I built one of them again locally using the downloaded maven artifacts today and it worked as it should, so it seems all is well (at least for simple testing).
Let me know if you see any issues, but so far I believe it's working as it should.
In terms of possibly moving more things from MXRoyale to MXRoyaleBase, there could be more candidates for doing that, but in order to do that there should be no dependency link to any UI implementations for each case.
Greg
On Thu, Oct 7, 2021 at 6:28 PM Harbs <ha...@gmail.com>> wrote:
> This will not effect me much. Sounds like a good idea, though.
>
> Harbs
>
> > On Oct 6, 2021, at 11:59 PM, Greg Dove <gr...@gmail.com>> 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
>
>
RE: MXRoyale splitting to two libs - please provide your feedback.
Posted by Maria Jose Esteve <mj...@iest.com>.
Hi,
@Greg, I downloaded your latest changes to royale-asjs and got an error in the ant compilation.
The general error:
BUILD FAILED
D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\build.xml:696: The following error occurred while executing this line:
D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\build.xml:155: The following error occurred while executing this line:
D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\build.xml:554: The following error occurred while executing this line:
D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\build.xml:108: The following error occurred while executing this line:
D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\build.xml:134: condition satisfied
in the compilation ant:
Crux:
[echo] swc-date is 10/10/21 01:06 +0200
clean:
[echo] swc-date is 10/10/21 01:06 +0200
check-for-tests:
clean-tests:
check-compiler-home:
check-transpiler-home:
check-compiler:
compile:
[echo] swc-date is 10/10/21 01:06 +0200
compile-swf:
[echo] Compiling libs/Crux.swc
[echo] ROYALE_HOME: D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
[echo] ROYALE_SWF_COMPILER_HOME: D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
[echo] ROYALE_COMPILER_HOME: D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork/js
[java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms256m -Xmx2048m
[java] args:
[java] +royalelib=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork/frameworks
[java] +playerglobal.version=11.1
[java] +env.AIR_HOME=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork
[java] -compiler.strict-xml=true
[java] -compiler.targets=SWF,JSRoyale
[java] -metadata.date=10/10/21 01:06 +0200
[java] -metadata.dateFormat=MM/dd/yy HH:mm Z
[java] -swf-debugfile-alias=/org/apache/royale/0.9.9
[java] -output=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux/target/Crux.swc
[java] -load-config=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux/src/main/config/compile-swf-config.xml
[java] -js-load-config=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork/frameworks/js-config.xml
[java] -js-load-config+=D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux/../../js/projects/CruxJS/src/main/config/compile-js-config.xml
[java] 0.601410729 seconds
[java] D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\src\main\config\compile-swf-config.xml(40): col: 0 unable to open 'D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\libs\MXRoyaleBase.swc'.
[java] D:\Develop_Royale\Projects\Royale-SDK\royale-asjs-fork\frameworks\projects\Crux\src\main\config\compile-swf-config.xml (line: 40)
[java]
[java] </external-library-path>
[java]
[java]
I have verified that MXRoyaleBase.swc has not been generated.
Attached is the compilation log.
Hiedra
-----Mensaje original-----
De: Greg Dove <gr...@gmail.com>
Enviado el: sábado, 9 de octubre de 2021 22:19
Para: Apache Royale Development <de...@royale.apache.org>
Asunto: Re: MXRoyale splitting to two libs - please provide your feedback.
OK, thanks for the feedback everyone.
I pushed the changes yesterday, and made changes to the crux examples to use MXRoyaleBase instead of MXRoyale in the dependencies, and quickly tested the ant and maven builds for those examples.
I built one of them again locally using the downloaded maven artifacts today and it worked as it should, so it seems all is well (at least for simple testing).
Let me know if you see any issues, but so far I believe it's working as it should.
In terms of possibly moving more things from MXRoyale to MXRoyaleBase, there could be more candidates for doing that, but in order to do that there should be no dependency link to any UI implementations for each case.
Greg
On Thu, Oct 7, 2021 at 6:28 PM Harbs <ha...@gmail.com>> wrote:
> This will not effect me much. Sounds like a good idea, though.
>
> Harbs
>
> > On Oct 6, 2021, at 11:59 PM, Greg Dove <gr...@gmail.com>> 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
>
>
Re: MXRoyale splitting to two libs - please provide your feedback.
Posted by Greg Dove <gr...@gmail.com>.
OK, thanks for the feedback everyone.
I pushed the changes yesterday, and made changes to the crux examples to
use MXRoyaleBase instead of MXRoyale in the dependencies, and quickly
tested the ant and maven builds for those examples.
I built one of them again locally using the downloaded maven artifacts
today and it worked as it should, so it seems all is well (at least for
simple testing).
Let me know if you see any issues, but so far I believe it's working as it
should.
In terms of possibly moving more things from MXRoyale to MXRoyaleBase,
there could be more candidates for doing that, but in order to do that
there should be no dependency link to any UI implementations for each case.
Greg
On Thu, Oct 7, 2021 at 6:28 PM Harbs <ha...@gmail.com> wrote:
> This will not effect me much. Sounds like a good idea, though.
>
> Harbs
>
> > On Oct 6, 2021, at 11:59 PM, Greg Dove <gr...@gmail.com> 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
>
>
Re: MXRoyale splitting to two libs - please provide your feedback.
Posted by Harbs <ha...@gmail.com>.
This will not effect me much. Sounds like a good idea, though.
Harbs
> On Oct 6, 2021, at 11:59 PM, Greg Dove <gr...@gmail.com> 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