Build failed in Jenkins: royale-asjs #936

[apacheroyaleci]

See 


Changes:

[aharui] CanvasLayout should size things with percentages.  Someday handle


--
[...truncated 1.50 MB...]
 [java] 
 [java] var stage:Stage = container.getStage();
 [java]   ^
 [java] 
 [java] 
c:\jenkins\workspace\royale-asjs\frameworks\projects\CreateJS\src\main\royale\org\apache\royale\createjs\core\UIBase.as(575):
 col: 27 Type was not found or was not a compile-time constant: DisplayObject.
 [java] 
 [java] var container:DisplayObject = positioner as 
DisplayObject;
 [java]   ^
 [java] 
 [java] 
c:\jenkins\workspace\royale-asjs\frameworks\projects\CreateJS\src\main\royale\org\apache\royale\createjs\core\UIBase.as(575):
 col: 57 Access of possibly undefined property DisplayObject.
 [java] 
 [java] var container:DisplayObject = positioner as 
DisplayObject;
 [java] ^
 [java] 
 [java] 
c:\jenkins\workspace\royale-asjs\frameworks\projects\CreateJS\src\main\royale\org\apache\royale\createjs\core\UIBase.as(578):
 col: 23 Type was not found or was not a compile-time constant: Stage.
 [java] 
 [java] var stage:Stage = container.getStage();
 [java]   ^
 [java] 
 [java] 
c:\jenkins\workspace\royale-asjs\frameworks\projects\CreateJS\src\main\royale\org\apache\royale\createjs\core\UIBase.as(598):
 col: 27 Type was not found or was not a compile-time constant: DisplayObject.
 [java] 
 [java] var container:DisplayObject = positioner as 
DisplayObject;
 [java]   ^
 [java] 
 [java] 
c:\jenkins\workspace\royale-asjs\frameworks\projects\CreateJS\src\main\royale\org\apache\royale\createjs\core\UIBase.as(598):
 col: 57 Access of possibly undefined property DisplayObject.
 [java] 
 [java] var container:DisplayObject = positioner as 
DisplayObject;
 [java] ^
 [java] 
 [java] 
c:\jenkins\workspace\royale-asjs\frameworks\projects\CreateJS\src\main\royale\org\apache\royale\createjs\core\UIBase.as(601):
 col: 23 Type was not found or was not a compile-time constant: Stage.
 [java] 
 [java] var stage:Stage = container.getStage();
 [java]   ^
 [java] 
 [java] 
c:\jenkins\workspace\royale-asjs\frameworks\projects\CreateJS\src\main\royale\org\apache\royale\createjs\core\UIBase.as(621):
 col: 27 Type was not found or was not a compile-time constant: DisplayObject.
 [java] 
 [java] var container:DisplayObject = positioner as 
DisplayObject;
 [java]   ^
 [java] 
 [java] 
c:\jenkins\workspace\royale-asjs\frameworks\projects\CreateJS\src\main\royale\org\apache\royale\createjs\core\UIBase.as(621):
 col: 57 Access of possibly undefined property DisplayObject.
 [java] 
 [java] var container:DisplayObject = positioner as 
DisplayObject;
 [java] ^
 [java] 
 [java] 
c:\jenkins\workspace\royale-asjs\frameworks\projects\CreateJS\src\main\royale\org\apache\royale\createjs\core\UIBase.as(624):
 col: 23 Type was not found or was not a compile-time constant: Stage.
 [java] 
 [java] var stage:Stage = container.getStage();
 [java]   ^
 [java] 
 [java] 
c:\jenkins\workspace\royale-asjs\frameworks\projects\CreateJS\src\main\royale\org\apache\royale\createjs\core\UIBase.as(634):
 col: 35 Access of possibly undefined property DisplayObject.
 [java] 
 [java] return (positioner as DisplayObject).visible;
 [java]   ^
 [java] 
 [java] 
c:\jenkins\workspace\royale-asjs\frameworks\projects\CreateJS\src\main\royale\org\apache\royale\createjs\core\UIBase.as(642):
 col: 51 Access of possibly undefined property DisplayObject.
 [java] 
 [java] var oldValue:Boolean = (positioner as 
DisplayObject).visible;
 [java]   ^
 [java] 
 [java] 
c:\jenkins\workspace\royale-asjs\frameworks\projects\CreateJS\src\main\royale\org\apache\royale\createjs\core\UIBase.as(647):
 col: 36 Access of possibly undefined property DisplayObject.
 [java] 
 [java] (positioner as DisplayObject).visible = value;
 [java]^
 [java] 
 [java] 
c:\jenkins\workspace\royale-asjs\frameworks\projects\CreateJS\src\main\royale\org\apache\royale\createjs\core\UIBase.as(652):
 col: 36 Access of possibly undefined property DisplayObject.
 [java] 
 [java] (positioner as DisplayObj

Re: Release Manager for 0.9.7

[Christofer Dutz]

Hi Alex,

You can probably claim this as long as you want, it doesn't make it true. 

I started working on this after I didn't get any updates for a long time and 
following the mailing lists (also the private ones) and direct messages with 
people involved came to the conclusion that the steps might have "worked" but 
they were such a challenge for RMs that they had problems actually doing the 
releases (I think Yishay or Piotr (I think) even said, that it was "his fault" 
for not exactly following the guidelines). Even if something works but is so 
fragile to do, that almost no one is able or willing to do it, I would call 
that "broken".

So I guess we can go round pointing fingers and claiming: "It was you!" ... "no 
it was you!" ... like childish kids, or we can actually DO something.

I am willing to help you guys. I'm not trying to "get rid of Ant". All I want 
to do it make this build something anyone in your community could do, so you 
can start releasing in something like monthly or every two months and I won't 
have to invest time in learning and building good tooling for using Typescript 
in Maven (That tooling is pretty crappy from a conceptual point of view).

So can we please stop this unproductive going round in circles?

I know you have "requirements" ... so how about collecting these in a separate 
thread? I'll start it right away. And please don't say "Why replace something 
that is working with something new?" ... if this was true we'd still be 
hand-crafting websites with pure HTML. Evolution is about change. Evolution is 
sometimes replacing something that exists and replace this with something new.

I won't do this on "develop" ... no worries, but I want you guys to give this a 
chance.


You all stay safe in these crazy times,

Chris




Am 20.03.20, 16:52 schrieb "Alex Harui" :



On 3/20/20, 12:25 AM, "Christofer Dutz"  wrote:

I agree with Carlos here,

When reading this thread, I read a lot of "must", but it's actually 
mostly a "want".

Have been waiting for Royale releases for the past months and haven't 
seen much progress on starting the 0.9.7 release.
As far as I understood things from the sidelines, the problem is that 
no one wanted to become RM. I am guessing because
Others have been wasting far too much of their time and resources in 
not frying their big fish, but being stuck in the 13 steps.
Which I can't see as an improvement.

No, the reason is that changes were made to the Maven process that broke 
the 13 steps that were working.  And now it is the responsibility of those who 
broke it to fix it.
Please stop with blame passing and misinformation.

So yes: I am investing time. Time I wouldn't be investing in anything 
else for Royale however. So the only "net-loos" you folks are having is Carlos 
or the time needed to write long emails, which could also be short.

If I succeed with my plans anyone can continue to do their 13 step 
release as you like. However it would enable RMs to choose to do it on their 
machine. As long as we have all bases covered in the process, I doubt there 
will be any objection, right?

No objections from me, because that's what we had before it was broken by 
recent Maven changes.

-Alex



Chris



Am 20.03.20, 00:59 schrieb "Carlos Rovira" :

Hi,

I don't think having a remote machine would be the problem. When we 
finish
I expect people can use remote machine or local machine, as they 
choose, so
all people should be happy. The objective is remove complexity and 
steps
down from 13 to maybe 2 steps, while Ant continues to work as 
expected.

So ok, I'll try to be the RM. I must check some urgent things in 
Jewel
before start, but I hope it will be hopefully soon...

Thanks


El jue., 19 mar. 2020 a las 23:32, Alex Harui 
()
escribió:

> I agree with you 100% Piotr.  My hope now is that in the fixing 
of these
> steps, Chris and Carlos will realize that we really were using 
Maven in a
> proper way, we are just splitting up the release steps into 
individual
> Jenkins jobs so that people don't have to figure out how to get 
things
> working locally.
>
> One can only hope sometimes.
> -Alex
>
> On 3/19/20, 3:23 PM, "Piotr Zarzycki"  
wrote:
>
> I also doesn't understand that based on experience of one 
person (me)
> you
> guys would reinvent the wheel. ;) It looks like you are going 
to do
> that
> despite any argument provide it here.

Requirements for Releases

[Christofer Dutz]

Hi all,

I would like to use this thread to collect some requirements for the release 
process.
Also would I like to ask you not to formulate things like “The release 
artifacts must be built with X” but rather “The release artifacts should be 
usable by X” cause that’s what really matters. I hope you get what I mean.

So far I have this:

  *   The release artifacts should be usable by Maven
  *   The release artifacts should be usable by Ant
  *   The release should include tests, which ensure the correct function of 
the royale-maven-plugin
  *   The release should include tests which ensure the correct function of the 
Ant targets
  *   It should be possible to verify a release by comparing it’s binary 
artifacts for equality (reproducible builds)
  *   It should be ensured a release candidate builds correctly with Ant and 
with Maven
  *   The release process should ideally work on any machine

Did I miss something?


Chris

RE: Release Manager for 0.9.7

[Yishay Weiss]

Chris, I appreciate you working on this. Let’s move on please. I think we all 
have more important things to worry about now than the definition of broken.

From: Christofer Dutz
Sent: Saturday, March 21, 2020 11:11 AM
To: dev@royale.apache.org
Subject: Re: Release Manager for 0.9.7

Hi Alex,

You can probably claim this as long as you want, it doesn't make it true.

I started working on this after I didn't get any updates for a long time and 
following the mailing lists (also the private ones) and direct messages with 
people involved came to the conclusion that the steps might have "worked" but 
they were such a challenge for RMs that they had problems actually doing the 
releases (I think Yishay or Piotr (I think) even said, that it was "his fault" 
for not exactly following the guidelines). Even if something works but is so 
fragile to do, that almost no one is able or willing to do it, I would call 
that "broken".

So I guess we can go round pointing fingers and claiming: "It was you!" ... "no 
it was you!" ... like childish kids, or we can actually DO something.

I am willing to help you guys. I'm not trying to "get rid of Ant". All I want 
to do it make this build something anyone in your community could do, so you 
can start releasing in something like monthly or every two months and I won't 
have to invest time in learning and building good tooling for using Typescript 
in Maven (That tooling is pretty crappy from a conceptual point of view).

So can we please stop this unproductive going round in circles?

I know you have "requirements" ... so how about collecting these in a separate 
thread? I'll start it right away. And please don't say "Why replace something 
that is working with something new?" ... if this was true we'd still be 
hand-crafting websites with pure HTML. Evolution is about change. Evolution is 
sometimes replacing something that exists and replace this with something new.

I won't do this on "develop" ... no worries, but I want you guys to give this a 
chance.


You all stay safe in these crazy times,

Chris




Am 20.03.20, 16:52 schrieb "Alex Harui" :



On 3/20/20, 12:25 AM, "Christofer Dutz"  wrote:

I agree with Carlos here,

When reading this thread, I read a lot of "must", but it's actually 
mostly a "want".

Have been waiting for Royale releases for the past months and haven't 
seen much progress on starting the 0.9.7 release.
As far as I understood things from the sidelines, the problem is that 
no one wanted to become RM. I am guessing because
Others have been wasting far too much of their time and resources in 
not frying their big fish, but being stuck in the 13 steps.
Which I can't see as an improvement.

No, the reason is that changes were made to the Maven process that broke 
the 13 steps that were working.  And now it is the responsibility of those who 
broke it to fix it.
Please stop with blame passing and misinformation.

So yes: I am investing time. Time I wouldn't be investing in anything 
else for Royale however. So the only "net-loos" you folks are having is Carlos 
or the time needed to write long emails, which could also be short.

If I succeed with my plans anyone can continue to do their 13 step 
release as you like. However it would enable RMs to choose to do it on their 
machine. As long as we have all bases covered in the process, I doubt there 
will be any objection, right?

No objections from me, because that's what we had before it was broken by 
recent Maven changes.

-Alex



Chris



Am 20.03.20, 00:59 schrieb "Carlos Rovira" :

Hi,

I don't think having a remote machine would be the problem. When we 
finish
I expect people can use remote machine or local machine, as they 
choose, so
all people should be happy. The objective is remove complexity and 
steps
down from 13 to maybe 2 steps, while Ant continues to work as 
expected.

So ok, I'll try to be the RM. I must check some urgent things in 
Jewel
before start, but I hope it will be hopefully soon...

Thanks


El jue., 19 mar. 2020 a las 23:32, Alex Harui 
()
escribió:

> I agree with you 100% Piotr.  My hope now is that in the fixing 
of these
> steps, Chris and Carlos will realize that we really were using 
Maven in a
> proper way, we are just splitting up the release steps into 
individual
> Jenkins jobs so that people don't have to figure out how to get 
things
> working locally.
>
> One can only hope sometimes.
> -Alex
>
> On 3/19/20, 3:23 PM, "Piotr Zarzycki"  
wrote:
>
> I also doesn't understand that based on experience of one 
person (me)
> you
  

RE: Requirements for Releases

[Yishay Weiss]

I would add being able to work on it incrementally. That is, a failure in one 
step does not mean previous steps are thrown away. Not sure how feasible that 
is, but I think it would be nice to have.

From: Christofer Dutz
Sent: Saturday, March 21, 2020 11:20 AM
To: dev@royale.apache.org
Subject: Requirements for Releases

Hi all,

I would like to use this thread to collect some requirements for the release 
process.
Also would I like to ask you not to formulate things like “The release 
artifacts must be built with X” but rather “The release artifacts should be 
usable by X” cause that’s what really matters. I hope you get what I mean.

So far I have this:

  *   The release artifacts should be usable by Maven
  *   The release artifacts should be usable by Ant
  *   The release should include tests, which ensure the correct function of 
the royale-maven-plugin
  *   The release should include tests which ensure the correct function of the 
Ant targets
  *   It should be possible to verify a release by comparing it’s binary 
artifacts for equality (reproducible builds)
  *   It should be ensured a release candidate builds correctly with Ant and 
with Maven
  *   The release process should ideally work on any machine

Did I miss something?


Chris

Re: Requirements for Releases

[Serkan Taş]

I guess the operating system may be added.

 *   The release process should ideally work on these OS's (Linux, Windows, 
MacOS,..)

21.03.2020 12:20 tarihinde Christofer Dutz yazdı:

Hi all,

I would like to use this thread to collect some requirements for the release 
process.
Also would I like to ask you not to formulate things like “The release 
artifacts must be built with X” but rather “The release artifacts should be 
usable by X” cause that’s what really matters. I hope you get what I mean.

So far I have this:

   *   The release artifacts should be usable by Maven
   *   The release artifacts should be usable by Ant
   *   The release should include tests, which ensure the correct function of 
the royale-maven-plugin
   *   The release should include tests which ensure the correct function of 
the Ant targets
   *   It should be possible to verify a release by comparing it’s binary 
artifacts for equality (reproducible builds)
   *   It should be ensured a release candidate builds correctly with Ant and 
with Maven
   *   The release process should ideally work on any machine

Did I miss something?


Chris

Re: Requirements for Releases

[Christofer Dutz]

Hi Yishay,

I am working on the existing steps as we speak ... I'm talking about after 
that. I want to learn what in general the hard requirements are and start a 
discussion on them because currently a lot of "steps" are implemented in order 
to achieve something. I want to learn not what is currently being done, but 
what this step is trying to achieve. Cause perhaps there are multiple ways to 
achieve the same goal. 

Chris

Am 21.03.20, 12:12 schrieb "Yishay Weiss" :

I would add being able to work on it incrementally. That is, a failure in 
one step does not mean previous steps are thrown away. Not sure how feasible 
that is, but I think it would be nice to have.

From: Christofer Dutz
Sent: Saturday, March 21, 2020 11:20 AM
To: dev@royale.apache.org
Subject: Requirements for Releases

Hi all,

I would like to use this thread to collect some requirements for the 
release process.
Also would I like to ask you not to formulate things like “The release 
artifacts must be built with X” but rather “The release artifacts should be 
usable by X” cause that’s what really matters. I hope you get what I mean.

So far I have this:

  *   The release artifacts should be usable by Maven
  *   The release artifacts should be usable by Ant
  *   The release should include tests, which ensure the correct function 
of the royale-maven-plugin
  *   The release should include tests which ensure the correct function of 
the Ant targets
  *   It should be possible to verify a release by comparing it’s binary 
artifacts for equality (reproducible builds)
  *   It should be ensured a release candidate builds correctly with Ant 
and with Maven
  *   The release process should ideally work on any machine

Did I miss something?


Chris

RE: Requirements for Releases

[Yishay Weiss]

I’m not sure I understand. I did not mean the steps should necessarily remain 
the same as they were before you started working on this. My point is that a 
release can take a long time. If some network failure is causing an error in 
the release halfway through, for instance, it would be nice if I could start 
from the same point when I have my network back. Does that example make sense?

From: Christofer Dutz
Sent: Saturday, March 21, 2020 1:17 PM
To: dev@royale.apache.org
Subject: Re: Requirements for Releases

Hi Yishay,

I am working on the existing steps as we speak ... I'm talking about after 
that. I want to learn what in general the hard requirements are and start a 
discussion on them because currently a lot of "steps" are implemented in order 
to achieve something. I want to learn not what is currently being done, but 
what this step is trying to achieve. Cause perhaps there are multiple ways to 
achieve the same goal.

Chris

Am 21.03.20, 12:12 schrieb "Yishay Weiss" :

I would add being able to work on it incrementally. That is, a failure in 
one step does not mean previous steps are thrown away. Not sure how feasible 
that is, but I think it would be nice to have.

From: Christofer Dutz
Sent: Saturday, March 21, 2020 11:20 AM
To: dev@royale.apache.org
Subject: Requirements for Releases

Hi all,

I would like to use this thread to collect some requirements for the 
release process.
Also would I like to ask you not to formulate things like “The release 
artifacts must be built with X” but rather “The release artifacts should be 
usable by X” cause that’s what really matters. I hope you get what I mean.

So far I have this:

  *   The release artifacts should be usable by Maven
  *   The release artifacts should be usable by Ant
  *   The release should include tests, which ensure the correct function 
of the royale-maven-plugin
  *   The release should include tests which ensure the correct function of 
the Ant targets
  *   It should be possible to verify a release by comparing it’s binary 
artifacts for equality (reproducible builds)
  *   It should be ensured a release candidate builds correctly with Ant 
and with Maven
  *   The release process should ideally work on any machine

Did I miss something?


Chris

RE: Layouts: Changing widthChanged/heightChanged/sizeChanged event rules

[Yishay Weiss]

Works, thanks.


From: Alex Harui 
Sent: Saturday, March 21, 2020 7:34:03 AM
To: dev@royale.apache.org 
Subject: Re: Layouts: Changing widthChanged/heightChanged/sizeChanged event 
rules

OK, looks like CanvasLayout was not behaving.  I pushed a change for it.

On 3/20/20, 10:19 AM, "Yishay Weiss"  wrote:

It’s the same code [1] as below.

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Fqr5i4&data=02%7C01%7Caharui%40adobe.com%7C678378365e9e4f2e08e708d7ccf2d6db%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637203215668587546&sdata=X7WUYeBWTI0s%2BpbDaNjQ2Ro%2BJI8aKPVhyaSfVQvXD7I%3D&reserved=0

From: Yishay Weiss
Sent: Friday, March 20, 2020 11:08 AM
To: dev@royale.apache.org
Subject: RE: Layouts: Changing widthChanged/heightChanged/sizeChanged event 
rules

With percentages. With fixed dimensions it does work.

From: Alex Harui
Sent: Wednesday, March 18, 2020 6:50 PM
To: dev@royale.apache.org
Subject: Re: Layouts: Changing widthChanged/heightChanged/sizeChanged event 
rules

How is the width/height set on the ADG?

-Alex

On 3/18/20, 12:23 AM, "Yishay Weiss"  wrote:

Panel looks fixed, thanks. My ADG is suddenly not showing any data 
though. I’ll need to investigate that later…

From: Alex Harui
Sent: Tuesday, March 17, 2020 9:32 AM
To: dev@royale.apache.org
Subject: Re: Layouts: Changing widthChanged/heightChanged/sizeChanged 
event rules

Try with my latest commit.

On 3/16/20, 11:21 PM, "Yishay Weiss"  wrote:

Mxml looks like this [1]. SuperPanel extends Panel. I’m not sure 
I’m at liberty to post SuperPanel’s source, but if you can’t reproduce the 
problem with the non-custom controls then I could work on it maybe next week.

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Fqr5i4&data=02%7C01%7Caharui%40adobe.com%7C678378365e9e4f2e08e708d7ccf2d6db%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637203215668587546&sdata=X7WUYeBWTI0s%2BpbDaNjQ2Ro%2BJI8aKPVhyaSfVQvXD7I%3D&reserved=0

From: Alex Harui
Sent: Monday, March 16, 2020 6:24 PM
To: dev@royale.apache.org
Subject: Re: Layouts: Changing 
widthChanged/heightChanged/sizeChanged event rules

There was a change made to mx:Panel to not run as many layouts.  
What does the MXML for the broken mx:Panel look like?  I probably missed a case.

-Alex

On 3/16/20, 1:57 AM, "Yishay Weiss"  wrote:

I won’t have time to investigate it today. Rolling back to 
d3e27d65344ad27912000e1e3205b96243d8828e
fixes it.

From: Yishay Weiss
Sent: Monday, March 16, 2020 10:09 AM
To: dev@royale.apache.org
Subject: RE: Layouts: Changing 
widthChanged/heightChanged/sizeChanged event rules

MX|Panel


From: Yishay Weiss 
Sent: Monday, March 16, 2020 10:08:49 AM
To: dev@royale.apache.org 
Subject: RE: Layouts: Changing 
widthChanged/heightChanged/sizeChanged event rules


I’ve just updated Royale and am seeing weird behavior in Panel 
layout. The content is taking up all the space and obliterating the title and 
the rest of the chrome elements. Not sure if it’s related to these changes. 
Will try to isolate it.



From: Alex Harui
Sent: Saturday, March 14, 2020 7:12 AM
To: dev@royale.apache.org
Subject: Layouts: Changing 
widthChanged/heightChanged/sizeChanged event rules



Hi,

I am wanting to change the way UIBase setWidthAndHeight 
dispatches its events to cut down on the number of layout passes.

Right now, if you change both the width and height of a 
component, you get 3 events (widthChanged, heightChanged, sizeChanged).  I want 
to change that so that you only get sizeChanged.  This change would cause the 
"meaning" of widthChanged to mean that only the width changed during a resize 
so you can optimize some of the layout code and similar for heightChanged.   
And thus, you will only ever get one event out of setWidthAndHeight, it will 
either be:

- "widthChanged" meaning that only the width has changed
- "heightChanged" meaning that only the height has changed
- "sizeChanged" meaning that b

Re: Requirements for Releases

[Christofer Dutz]

Ah .. ok ... well now I got you... 

I thought you were referring to the "build steps" on the VM.

I created a google document for collecting requirements as in email it would 
get messy and submitting PRs for the Github Wiki isn't ideal for me at the 
moment. I also added your and Serkan's requirements.

https://docs.google.com/document/d/1kMlNfgVVAtTBNb57Qe88-d0vbM-HdohgQFqWCBr-cAg/edit?usp=sharing

It should be editable for anyone.

Chris



Am 21.03.20, 12:25 schrieb "Yishay Weiss" :

I’m not sure I understand. I did not mean the steps should necessarily 
remain the same as they were before you started working on this. My point is 
that a release can take a long time. If some network failure is causing an 
error in the release halfway through, for instance, it would be nice if I could 
start from the same point when I have my network back. Does that example make 
sense?

From: Christofer Dutz
Sent: Saturday, March 21, 2020 1:17 PM
To: dev@royale.apache.org
Subject: Re: Requirements for Releases

Hi Yishay,

I am working on the existing steps as we speak ... I'm talking about after 
that. I want to learn what in general the hard requirements are and start a 
discussion on them because currently a lot of "steps" are implemented in order 
to achieve something. I want to learn not what is currently being done, but 
what this step is trying to achieve. Cause perhaps there are multiple ways to 
achieve the same goal.

Chris

Am 21.03.20, 12:12 schrieb "Yishay Weiss" :

I would add being able to work on it incrementally. That is, a failure 
in one step does not mean previous steps are thrown away. Not sure how feasible 
that is, but I think it would be nice to have.

From: Christofer Dutz
Sent: Saturday, March 21, 2020 11:20 AM
To: dev@royale.apache.org
Subject: Requirements for Releases

Hi all,

I would like to use this thread to collect some requirements for the 
release process.
Also would I like to ask you not to formulate things like “The release 
artifacts must be built with X” but rather “The release artifacts should be 
usable by X” cause that’s what really matters. I hope you get what I mean.

So far I have this:

  *   The release artifacts should be usable by Maven
  *   The release artifacts should be usable by Ant
  *   The release should include tests, which ensure the correct 
function of the royale-maven-plugin
  *   The release should include tests which ensure the correct 
function of the Ant targets
  *   It should be possible to verify a release by comparing it’s 
binary artifacts for equality (reproducible builds)
  *   It should be ensured a release candidate builds correctly with 
Ant and with Maven
  *   The release process should ideally work on any machine

Did I miss something?


Chris

Re: Requirements for Releases

[Piotr Zarzycki]

Hi Chris,

Each step is trying to achieve as it described here [1]. That is why Carlos
should be RM to understand each step, so you could also learn whether
actually you need to do or not.

[1] https://github.com/apache/royale-asjs/wiki/Release-Steps-Jobs-On-Jenkins

Thanks,
Piotr

sob., 21 mar 2020 o 12:17 Christofer Dutz 
napisał(a):

> Hi Yishay,
>
> I am working on the existing steps as we speak ... I'm talking about after
> that. I want to learn what in general the hard requirements are and start a
> discussion on them because currently a lot of "steps" are implemented in
> order to achieve something. I want to learn not what is currently being
> done, but what this step is trying to achieve. Cause perhaps there are
> multiple ways to achieve the same goal.
>
> Chris
>
> Am 21.03.20, 12:12 schrieb "Yishay Weiss" :
>
> I would add being able to work on it incrementally. That is, a failure
> in one step does not mean previous steps are thrown away. Not sure how
> feasible that is, but I think it would be nice to have.
>
> From: Christofer Dutz
> Sent: Saturday, March 21, 2020 11:20 AM
> To: dev@royale.apache.org
> Subject: Requirements for Releases
>
> Hi all,
>
> I would like to use this thread to collect some requirements for the
> release process.
> Also would I like to ask you not to formulate things like “The release
> artifacts must be built with X” but rather “The release artifacts should be
> usable by X” cause that’s what really matters. I hope you get what I mean.
>
> So far I have this:
>
>   *   The release artifacts should be usable by Maven
>   *   The release artifacts should be usable by Ant
>   *   The release should include tests, which ensure the correct
> function of the royale-maven-plugin
>   *   The release should include tests which ensure the correct
> function of the Ant targets
>   *   It should be possible to verify a release by comparing it’s
> binary artifacts for equality (reproducible builds)
>   *   It should be ensured a release candidate builds correctly with
> Ant and with Maven
>   *   The release process should ideally work on any machine
>
> Did I miss something?
>
>
> Chris
>
>
>
>

-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: Requirements for Releases

[Christofer Dutz]

H Piotr,

this is exactly not what I'm trying to do.

I have read this document multiple times and I do understand fully each step.
The problem is that each step there is one way out of many to achieve 
something. 
I want to find out WHAT is trying to be achieved and WHY ... not HOW.

The reasoning behind this is that usually there are multiple ways to achieve 
something.

1) I want to first collect WHAT is trying to be ensured.
2) Then I want to collect options on HOW these goals can be achieved.
3) Last I would want to implement a proposal for a process that uses a 
combination of HOWs that is most robust and simple at the same time but 
addresses all WHATs.

Chris


Am 21.03.20, 12:42 schrieb "Piotr Zarzycki" :

Hi Chris,

Each step is trying to achieve as it described here [1]. That is why Carlos
should be RM to understand each step, so you could also learn whether
actually you need to do or not.

[1] https://github.com/apache/royale-asjs/wiki/Release-Steps-Jobs-On-Jenkins

Thanks,
Piotr

sob., 21 mar 2020 o 12:17 Christofer Dutz 
napisał(a):

> Hi Yishay,
>
> I am working on the existing steps as we speak ... I'm talking about after
> that. I want to learn what in general the hard requirements are and start 
a
> discussion on them because currently a lot of "steps" are implemented in
> order to achieve something. I want to learn not what is currently being
> done, but what this step is trying to achieve. Cause perhaps there are
> multiple ways to achieve the same goal.
>
> Chris
>
> Am 21.03.20, 12:12 schrieb "Yishay Weiss" :
>
> I would add being able to work on it incrementally. That is, a failure
> in one step does not mean previous steps are thrown away. Not sure how
> feasible that is, but I think it would be nice to have.
>
> From: Christofer Dutz
> Sent: Saturday, March 21, 2020 11:20 AM
> To: dev@royale.apache.org
> Subject: Requirements for Releases
>
> Hi all,
>
> I would like to use this thread to collect some requirements for the
> release process.
> Also would I like to ask you not to formulate things like “The release
> artifacts must be built with X” but rather “The release artifacts should 
be
> usable by X” cause that’s what really matters. I hope you get what I mean.
>
> So far I have this:
>
>   *   The release artifacts should be usable by Maven
>   *   The release artifacts should be usable by Ant
>   *   The release should include tests, which ensure the correct
> function of the royale-maven-plugin
>   *   The release should include tests which ensure the correct
> function of the Ant targets
>   *   It should be possible to verify a release by comparing it’s
> binary artifacts for equality (reproducible builds)
>   *   It should be ensured a release candidate builds correctly with
> Ant and with Maven
>   *   The release process should ideally work on any machine
>
> Did I miss something?
>
>
> Chris
>
>
>
>

-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Jenkins build is back to normal : royale-asjs #937

[apacheroyaleci]

See 

Ways for dumping the effective-configuration of the compiler?

[Christofer Dutz]

Hi all,

is there a way to dump the effective configuration used in the compiler in 
order to see if there are any differences between the maven and the ant 
configutation?

I did find something that sounds like that, but couldn’t find out how to use it.

Configuration seems to support some sort of “dump-config” …

Chris

Re: Potential Binding issue with static variables (was: Jewel DataGrid columnWidth is translated to percentage width)

[Carlos Rovira]

Thanks Josh! I can see it working all again :)

El sáb., 21 mar. 2020 a las 0:02, Josh Tynjala ()
escribió:

> This seems to be caused by my recent commit to the compiler related to
> class/interface exports. Sorry about that! I've reverted for now so that
> I'm not holding up anyone's work. I'll try adding the change again (with
> some tweaks) another day. Or Greg said that he might look into it too.
>
> (What's very strange is that I tested a release build of TourDeJewel before
> pushing my commit, and everything was definitely working fine. Now, the
> failure is obvious on my computer too, so I don't know how I could have
> possibly missed that.)
>
> Anyway, sorry again!
>
> --
> Josh Tynjala
> Bowler Hat LLC 
>
>
> On Thu, Mar 19, 2020 at 7:40 AM Piotr Zarzycki 
> wrote:
>
> > Carlos,
> >
> > I have found issue after couple of hours of searching. It is reproducible
> > in TourDeJewel -> Button playground - release version of build. Following
> > code doesn't work at all:
> >
> > 
> >
> > Static variable PRIMARY is note being setup. We are using static vars to
> > set name of the content and that's why in our app no content is being
> > displayed:
> >
> >   
> >
> > 
> >
> > Greg do you see anything related to latest changes in Binding area ?
> >
> > Thanks,
> > Piotr
> >
> >
> > czw., 19 mar 2020 o 13:54 Piotr Zarzycki 
> > napisał(a):
> >
> > > I'm trying to find that, but currently in release mode navigation
> doesn't
> > > work at all - I moved back to the oldest build [1] and have same issue.
> > In
> > > the other words in release mode I don't see any content at all. I'm
> going
> > > to prepare separate example which shows that issue.
> > >
> > > [1]
> > >
> >
> http://apacheroyaleci2.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/1051/
> > >
> > > czw., 19 mar 2020 o 13:46 Carlos Rovira 
> > > napisał(a):
> > >
> > >> Hi Piotr,
> > >> can you share how it was looking until now?
> > >> Other option is to find from where commit started to fail
> > >>
> > >>
> > >> El jue., 19 mar. 2020 a las 12:07, Piotr Zarzycki (<
> > >> piotrzarzyck...@gmail.com>) escribió:
> > >>
> > >> > Hi Carlos,
> > >> >
> > >> > Your latest changes to containers messed up our UI in app. [1] I
> will
> > >> > adjust it, but I'm really not sure what is actually happen that we
> > have
> > >> so
> > >> > much mess there.
> > >> >
> > >> > [1] https://ibb.co/CPkxx8S
> > >> >
> > >> > Thanks,
> > >> > Piotr
> > >> >
> > >> > śr., 18 mar 2020 o 16:57 Carlos Rovira 
> > >> > napisał(a):
> > >> >
> > >> > > Hi Alex,
> > >> > >
> > >> > > I'll try your sugestion about the flex grow. I revised the flex
> box
> > >> code
> > >> > > and in fact columns right now does not use flex config
> > >> > > thanks
> > >> > >
> > >> > > El mié., 18 mar. 2020 a las 16:45, Alex Harui
> > >> ( > >> > >)
> > >> > > escribió:
> > >> > >
> > >> > > >
> > >> > > >
> > >> > > > On 3/18/20, 3:12 AM, "Carlos Rovira" 
> > >> wrote:
> > >> > > >
> > >> > > > Hi Alex,
> > >> > > >
> > >> > > > I'm experimenting for this concrete case with a calc(% - px)
> > >> > formula
> > >> > > > that
> > >> > > > could work. don't like it so much since it means is
> something
> > >> very
> > >> > > "JS"
> > >> > > > coupled but it should maintain responsiveness. Crossing
> > fingers
> > >> :)
> > >> > > >
> > >> > > > IMO, there is something already "very JS" in the code.  You are
> > >> using
> > >> > > > display="flex" instead of running a layout pass on each
> container
> > >> and
> > >> > > > child.  Which is the right thing to do, IMO, but has
> implications.
> > >> If
> > >> > > your
> > >> > > > calc idea doesn't work out, I wonder what would happen if you
> > simply
> > >> > > > translated percentWidth on the columns to flexGrow or whatever
> > >> > attributes
> > >> > > > give relative sizes to the children in a flexbox.
> > >> > > >
> > >> > > > -Alex
> > >> > > >
> > >> > > > El mié., 18 mar. 2020 a las 3:44, Alex Harui
> > >> > > ( > >> > > > >)
> > >> > > > escribió:
> > >> > > >
> > >> > > > >
> > >> > > > >
> > >> > > > > On 3/17/20, 5:14 PM, "Carlos Rovira" <
> > carlosrov...@apache.org
> > >> >
> > >> > > > wrote:
> > >> > > > >
> > >> > > > > Hi Alex,
> > >> > > > >
> > >> > > > > I'll try to see how things are done in MXRoyale's ADG
> > for
> > >> > > > columns.
> > >> > > > > Really
> > >> > > > > the problem right now is in that concrete case. I'm
> sure
> > >> > > there's
> > >> > > > some
> > >> > > > > way
> > >> > > > > to do it but while I'm using flex box already as you
> > >> suggest
> > >> > > for
> > >> > > > many
> > >> > > > > things, in this case I need to do calculations, since
> > all
> > >> is
> > >> > > > based on
> > >> > > > > how
> > >> > > > > users will configure the columns via mxml with a mix
> (or
> > >> not)
> > >> > > of
> > >> > > > > pixels and
> > >> > > > > percentages.
> > 

Re: Requirements for Releases

[Alex Harui]

That's a good starting point, but I don't like the "should".  I think it is a 
"must", otherwise, we can release broken functionality.

The Ant release artifacts must be reproducible by Ant and the Maven release 
artifacts must be reproducible by Maven.  It isn't sufficient to say that the 
"build" works in the released sources.  Release artifacts are more than just 
the build output.  Ant or Maven users may need to test a binary release 
artifacts/package with their local changes, not just the individual jars/swcs.

To be picky, only the Maven artifacts need to be usable by Maven, and only the 
Ant artifacts need to be usable by Ant, although I'm assuming that's what you 
meant.

HTH,
-Alex

On 3/21/20, 2:20 AM, "Christofer Dutz"  wrote:

Hi all,

I would like to use this thread to collect some requirements for the 
release process.
Also would I like to ask you not to formulate things like “The release 
artifacts must be built with X” but rather “The release artifacts should be 
usable by X” cause that’s what really matters. I hope you get what I mean.

So far I have this:

  *   The release artifacts should be usable by Maven
  *   The release artifacts should be usable by Ant
  *   The release should include tests, which ensure the correct function 
of the royale-maven-plugin
  *   The release should include tests which ensure the correct function of 
the Ant targets
  *   It should be possible to verify a release by comparing it’s binary 
artifacts for equality (reproducible builds)
  *   It should be ensured a release candidate builds correctly with Ant 
and with Maven
  *   The release process should ideally work on any machine

Did I miss something?


Chris

Re: Requirements for Releases

[Christofer Dutz]

Hi Alex,

Argh ... sorry for that ... what I meant was actually: "The release artifacts 
should be usable by X because Y" but missed writing down the rest ... 
I agree without that is doesn't make sense. What I wanted to lay emphasis on is 
to rather provide the reasoning behind the "must" or "should".

Chris

Am 21.03.20, 16:08 schrieb "Alex Harui" :

That's a good starting point, but I don't like the "should".  I think it is 
a "must", otherwise, we can release broken functionality.

The Ant release artifacts must be reproducible by Ant and the Maven release 
artifacts must be reproducible by Maven.  It isn't sufficient to say that the 
"build" works in the released sources.  Release artifacts are more than just 
the build output.  Ant or Maven users may need to test a binary release 
artifacts/package with their local changes, not just the individual jars/swcs.

To be picky, only the Maven artifacts need to be usable by Maven, and only 
the Ant artifacts need to be usable by Ant, although I'm assuming that's what 
you meant.

HTH,
-Alex

On 3/21/20, 2:20 AM, "Christofer Dutz"  wrote:

Hi all,

I would like to use this thread to collect some requirements for the 
release process.
Also would I like to ask you not to formulate things like “The release 
artifacts must be built with X” but rather “The release artifacts should be 
usable by X” cause that’s what really matters. I hope you get what I mean.

So far I have this:

  *   The release artifacts should be usable by Maven
  *   The release artifacts should be usable by Ant
  *   The release should include tests, which ensure the correct 
function of the royale-maven-plugin
  *   The release should include tests which ensure the correct 
function of the Ant targets
  *   It should be possible to verify a release by comparing it’s 
binary artifacts for equality (reproducible builds)
  *   It should be ensured a release candidate builds correctly with 
Ant and with Maven
  *   The release process should ideally work on any machine

Did I miss something?


Chris

Re: Requirements for Releases

[Christofer Dutz]

Well in theory the jars in the compiler built by Maven should also work with 
Ant 
and the other way around and also should it be possible to use the SWCs build 
by Maven with Ant.

For example if I build the distribution with maven and use that in an IDE I 
have seen the IDEs use the Ant targets (which were built with Maven) with the 
SWCs (which were also built by maven) without any problems.

We need to ensure the files are "reasonably equal" (it doesn't break anything 
for ANT if the jars of the Maven build have additional static stuff in 
"META-INF" package, but the interesting stuff like all the class files and 
resources should be identical)

Chris

Am 21.03.20, 16:08 schrieb "Alex Harui" :

That's a good starting point, but I don't like the "should".  I think it is 
a "must", otherwise, we can release broken functionality.

The Ant release artifacts must be reproducible by Ant and the Maven release 
artifacts must be reproducible by Maven.  It isn't sufficient to say that the 
"build" works in the released sources.  Release artifacts are more than just 
the build output.  Ant or Maven users may need to test a binary release 
artifacts/package with their local changes, not just the individual jars/swcs.

To be picky, only the Maven artifacts need to be usable by Maven, and only 
the Ant artifacts need to be usable by Ant, although I'm assuming that's what 
you meant.

HTH,
-Alex

On 3/21/20, 2:20 AM, "Christofer Dutz"  wrote:

Hi all,

I would like to use this thread to collect some requirements for the 
release process.
Also would I like to ask you not to formulate things like “The release 
artifacts must be built with X” but rather “The release artifacts should be 
usable by X” cause that’s what really matters. I hope you get what I mean.

So far I have this:

  *   The release artifacts should be usable by Maven
  *   The release artifacts should be usable by Ant
  *   The release should include tests, which ensure the correct 
function of the royale-maven-plugin
  *   The release should include tests which ensure the correct 
function of the Ant targets
  *   It should be possible to verify a release by comparing it’s 
binary artifacts for equality (reproducible builds)
  *   It should be ensured a release candidate builds correctly with 
Ant and with Maven
  *   The release process should ideally work on any machine

Did I miss something?


Chris

Re: Requirements for Releases

[Alex Harui]

On 3/21/20, 8:19 AM, "Christofer Dutz"  wrote:

Well in theory the jars in the compiler built by Maven should also work 
with Ant 
and the other way around and also should it be possible to use the SWCs 
build by Maven with Ant.

Did you mean "It should be possible to use the SWCs built by Ant with Maven"?   
That's true, but the Ant scripts do not do that currently and I see no reason 
to have them do that, because as you mention below, Maven puts more stuff in 
and around the jars/swcs.  It is easier for Ant to call Maven to do that.

For example if I build the distribution with maven and use that in an IDE I 
have seen the IDEs use the Ant targets (which were built with Maven) with the 
SWCs (which were also built by maven) without any problems.

We need to ensure the files are "reasonably equal" (it doesn't break 
anything for ANT if the jars of the Maven build have additional static stuff in 
"META-INF" package, but the interesting stuff like all the class files and 
resources should be identical)

Agreed.  Bonus points if the RM verification has a smart compare of the Jars 
and SWCs (by unpacking them and comparing the actual class files or SWFs.)

Chris

Am 21.03.20, 16:08 schrieb "Alex Harui" :

That's a good starting point, but I don't like the "should".  I think 
it is a "must", otherwise, we can release broken functionality.

The Ant release artifacts must be reproducible by Ant and the Maven 
release artifacts must be reproducible by Maven.  It isn't sufficient to say 
that the "build" works in the released sources.  Release artifacts are more 
than just the build output.  Ant or Maven users may need to test a binary 
release artifacts/package with their local changes, not just the individual 
jars/swcs.

To be picky, only the Maven artifacts need to be usable by Maven, and 
only the Ant artifacts need to be usable by Ant, although I'm assuming that's 
what you meant.

HTH,
-Alex

On 3/21/20, 2:20 AM, "Christofer Dutz"  
wrote:

Hi all,

I would like to use this thread to collect some requirements for 
the release process.
Also would I like to ask you not to formulate things like “The 
release artifacts must be built with X” but rather “The release artifacts 
should be usable by X” cause that’s what really matters. I hope you get what I 
mean.

So far I have this:

  *   The release artifacts should be usable by Maven
  *   The release artifacts should be usable by Ant
  *   The release should include tests, which ensure the correct 
function of the royale-maven-plugin
  *   The release should include tests which ensure the correct 
function of the Ant targets
  *   It should be possible to verify a release by comparing it’s 
binary artifacts for equality (reproducible builds)
  *   It should be ensured a release candidate builds correctly 
with Ant and with Maven
  *   The release process should ideally work on any machine

Did I miss something?


Chris

Re: Requirements for Releases

[Christofer Dutz]

Hi Alex,

In general there should be nothing preventing Maven to use the SWCs built by 
ant too.

The additional stuff I mentioned is in the Jars, not the SWCs (perhaps in the 
JS SWCs) and in these there is just a copy of the pom and the values of any 
property during execution. 

Both are not used or needed by any program I know of. Just consider them 
Meta-Data.

They are mainly used for tools like Nexus to know where to put them and if you 
were to sort of find a jar in some directory know how to reproduce it.

Chris

Am 21.03.20, 16:46 schrieb "Alex Harui" :



On 3/21/20, 8:19 AM, "Christofer Dutz"  wrote:

Well in theory the jars in the compiler built by Maven should also work 
with Ant 
and the other way around and also should it be possible to use the SWCs 
build by Maven with Ant.

Did you mean "It should be possible to use the SWCs built by Ant with 
Maven"?   That's true, but the Ant scripts do not do that currently and I see 
no reason to have them do that, because as you mention below, Maven puts more 
stuff in and around the jars/swcs.  It is easier for Ant to call Maven to do 
that.

For example if I build the distribution with maven and use that in an 
IDE I have seen the IDEs use the Ant targets (which were built with Maven) with 
the SWCs (which were also built by maven) without any problems.

We need to ensure the files are "reasonably equal" (it doesn't break 
anything for ANT if the jars of the Maven build have additional static stuff in 
"META-INF" package, but the interesting stuff like all the class files and 
resources should be identical)

Agreed.  Bonus points if the RM verification has a smart compare of the 
Jars and SWCs (by unpacking them and comparing the actual class files or SWFs.)

Chris

Am 21.03.20, 16:08 schrieb "Alex Harui" :

That's a good starting point, but I don't like the "should".  I 
think it is a "must", otherwise, we can release broken functionality.

The Ant release artifacts must be reproducible by Ant and the Maven 
release artifacts must be reproducible by Maven.  It isn't sufficient to say 
that the "build" works in the released sources.  Release artifacts are more 
than just the build output.  Ant or Maven users may need to test a binary 
release artifacts/package with their local changes, not just the individual 
jars/swcs.

To be picky, only the Maven artifacts need to be usable by Maven, 
and only the Ant artifacts need to be usable by Ant, although I'm assuming 
that's what you meant.

HTH,
-Alex

On 3/21/20, 2:20 AM, "Christofer Dutz"  
wrote:

Hi all,

I would like to use this thread to collect some requirements 
for the release process.
Also would I like to ask you not to formulate things like “The 
release artifacts must be built with X” but rather “The release artifacts 
should be usable by X” cause that’s what really matters. I hope you get what I 
mean.

So far I have this:

  *   The release artifacts should be usable by Maven
  *   The release artifacts should be usable by Ant
  *   The release should include tests, which ensure the 
correct function of the royale-maven-plugin
  *   The release should include tests which ensure the correct 
function of the Ant targets
  *   It should be possible to verify a release by comparing 
it’s binary artifacts for equality (reproducible builds)
  *   It should be ensured a release candidate builds correctly 
with Ant and with Maven
  *   The release process should ideally work on any machine

Did I miss something?


Chris

Re: Requirements for Releases

[Alex Harui]

OK, good to know.   I had never checked to see if Maven put things in the SWC 
to be managed in the Maven Central.  But again, the Ant build does not 
currently generate all of the collateral files (checksums and sigs for each 
SWC) and, IMO, it is easier just to call Maven to do that.

While we're on the subject of "reasonably equal", one thing that is not a 
requirement but I want to point out is that the "mvn clean install" in 
royale-asjs takes significantly longer thant "ant clean main" even if all 
dependencies are already downloaded because currently, Maven produces a SWC for 
every flavor of the Jewel themes where Ant does not because a bare .css file is 
a valid theme in Flex/Royale.  I think there is a way to have a bare .css file 
as a valid Maven artifact.  And figuring that out might make the Maven build 
faster.

Food for thought,
-Alex

On 3/21/20, 8:57 AM, "Christofer Dutz"  wrote:

Hi Alex,

In general there should be nothing preventing Maven to use the SWCs built 
by ant too.

The additional stuff I mentioned is in the Jars, not the SWCs (perhaps in 
the JS SWCs) and in these there is just a copy of the pom and the values of any 
property during execution. 

Both are not used or needed by any program I know of. Just consider them 
Meta-Data.

They are mainly used for tools like Nexus to know where to put them and if 
you were to sort of find a jar in some directory know how to reproduce it.

Chris

Am 21.03.20, 16:46 schrieb "Alex Harui" :



On 3/21/20, 8:19 AM, "Christofer Dutz"  
wrote:

Well in theory the jars in the compiler built by Maven should also 
work with Ant 
and the other way around and also should it be possible to use the 
SWCs build by Maven with Ant.

Did you mean "It should be possible to use the SWCs built by Ant with 
Maven"?   That's true, but the Ant scripts do not do that currently and I see 
no reason to have them do that, because as you mention below, Maven puts more 
stuff in and around the jars/swcs.  It is easier for Ant to call Maven to do 
that.

For example if I build the distribution with maven and use that in 
an IDE I have seen the IDEs use the Ant targets (which were built with Maven) 
with the SWCs (which were also built by maven) without any problems.

We need to ensure the files are "reasonably equal" (it doesn't 
break anything for ANT if the jars of the Maven build have additional static 
stuff in "META-INF" package, but the interesting stuff like all the class files 
and resources should be identical)

Agreed.  Bonus points if the RM verification has a smart compare of the 
Jars and SWCs (by unpacking them and comparing the actual class files or SWFs.)

Chris

Am 21.03.20, 16:08 schrieb "Alex Harui" :

That's a good starting point, but I don't like the "should".  I 
think it is a "must", otherwise, we can release broken functionality.

The Ant release artifacts must be reproducible by Ant and the 
Maven release artifacts must be reproducible by Maven.  It isn't sufficient to 
say that the "build" works in the released sources.  Release artifacts are more 
than just the build output.  Ant or Maven users may need to test a binary 
release artifacts/package with their local changes, not just the individual 
jars/swcs.

To be picky, only the Maven artifacts need to be usable by 
Maven, and only the Ant artifacts need to be usable by Ant, although I'm 
assuming that's what you meant.

HTH,
-Alex

On 3/21/20, 2:20 AM, "Christofer Dutz" 
 wrote:

Hi all,

I would like to use this thread to collect some 
requirements for the release process.
Also would I like to ask you not to formulate things like 
“The release artifacts must be built with X” but rather “The release artifacts 
should be usable by X” cause that’s what really matters. I hope you get what I 
mean.

So far I have this:

  *   The release artifacts should be usable by Maven
  *   The release artifacts should be usable by Ant
  *   The release should include tests, which ensure the 
correct function of the royale-maven-plugin
  *   The release should include tests which ensure the 
correct function of the Ant targets
  *   It should be possible to verify a release by 
comparing it’s binary artifacts for equality (reproducible builds)
  *   It should be ensured a release candidate builds 
correctly with Ant and with Ma

Re: Requirements for Releases

[Christofer Dutz]

Hi Alex,

regarding the build time for Maven ... I too have noticed that. But as far as I 
understood it the themes are all sass files that are compiled to css files, 
correct? 

The packaging of these into a SWC aren’t what's taking long, it's the sass 
compilation. Not sure how to optimize that ... 

The actual "compilation" is then pretty fast. I think the only thing the 
compiler really does here is to create the "library.swf" inside.

And it's not always just a CSS but sometimes there are assets coming along ... 
if it was just a CSS we could come up with a different "packaging" that just 
deploys the CSS but currently we kept all the same for user-simplicity.

Chris


Am 21.03.20, 17:26 schrieb "Alex Harui" :

OK, good to know.   I had never checked to see if Maven put things in the 
SWC to be managed in the Maven Central.  But again, the Ant build does not 
currently generate all of the collateral files (checksums and sigs for each 
SWC) and, IMO, it is easier just to call Maven to do that.

While we're on the subject of "reasonably equal", one thing that is not a 
requirement but I want to point out is that the "mvn clean install" in 
royale-asjs takes significantly longer thant "ant clean main" even if all 
dependencies are already downloaded because currently, Maven produces a SWC for 
every flavor of the Jewel themes where Ant does not because a bare .css file is 
a valid theme in Flex/Royale.  I think there is a way to have a bare .css file 
as a valid Maven artifact.  And figuring that out might make the Maven build 
faster.

Food for thought,
-Alex

On 3/21/20, 8:57 AM, "Christofer Dutz"  wrote:

Hi Alex,

In general there should be nothing preventing Maven to use the SWCs 
built by ant too.

The additional stuff I mentioned is in the Jars, not the SWCs (perhaps 
in the JS SWCs) and in these there is just a copy of the pom and the values of 
any property during execution. 

Both are not used or needed by any program I know of. Just consider 
them Meta-Data.

They are mainly used for tools like Nexus to know where to put them and 
if you were to sort of find a jar in some directory know how to reproduce it.

Chris

Am 21.03.20, 16:46 schrieb "Alex Harui" :



On 3/21/20, 8:19 AM, "Christofer Dutz"  
wrote:

Well in theory the jars in the compiler built by Maven should 
also work with Ant 
and the other way around and also should it be possible to use 
the SWCs build by Maven with Ant.

Did you mean "It should be possible to use the SWCs built by Ant 
with Maven"?   That's true, but the Ant scripts do not do that currently and I 
see no reason to have them do that, because as you mention below, Maven puts 
more stuff in and around the jars/swcs.  It is easier for Ant to call Maven to 
do that.

For example if I build the distribution with maven and use that 
in an IDE I have seen the IDEs use the Ant targets (which were built with 
Maven) with the SWCs (which were also built by maven) without any problems.

We need to ensure the files are "reasonably equal" (it doesn't 
break anything for ANT if the jars of the Maven build have additional static 
stuff in "META-INF" package, but the interesting stuff like all the class files 
and resources should be identical)

Agreed.  Bonus points if the RM verification has a smart compare of 
the Jars and SWCs (by unpacking them and comparing the actual class files or 
SWFs.)

Chris

Am 21.03.20, 16:08 schrieb "Alex Harui" 
:

That's a good starting point, but I don't like the 
"should".  I think it is a "must", otherwise, we can release broken 
functionality.

The Ant release artifacts must be reproducible by Ant and 
the Maven release artifacts must be reproducible by Maven.  It isn't sufficient 
to say that the "build" works in the released sources.  Release artifacts are 
more than just the build output.  Ant or Maven users may need to test a binary 
release artifacts/package with their local changes, not just the individual 
jars/swcs.

To be picky, only the Maven artifacts need to be usable by 
Maven, and only the Ant artifacts need to be usable by Ant, although I'm 
assuming that's what you meant.

HTH,
-Alex

On 3/21/20, 2:20 AM, "Christofer Dutz" 
 wrote:

Hi all,

I would like to use this thread to collect some 
requirements for the release process.

As of 00.00 today I cannot compile my project.

[Maria Jose Esteve]

Hello, see if someone can help me because I can't work ...
My project is compiled with maven and since 0.00 today (although I have not 
compiled the SDK artifacts are downloaded)
The errors are:

Error: interface method dispatchEvent in interface IEventDispatcher is 
implemented with an incompatible signature in class VisualWaitingDisplay
Error: interface method dispatchEvent in interface IEventDispatcher is 
implemented with an incompatible signature in class LabelTruncateItemRenderer

For example, LabelTruncateItemRenderer.mxml:


http://ns.adobe.com/mxml/2009";
xmlns:j="library://ns.apache.org/royale/jewel"
xmlns:js="library://ns.apache.org/royale/basic"
xmlns:html="library://ns.apache.org/royale/html">















I have removed the beads, but it is not that ..

Does anyone know what's going on? Any hints I can follow?
Thanks in advance,
Hiedra.

Re: As of 00.00 today I cannot compile my project.

[Piotr Zarzycki]

Hi Maria,

Add to compiler configuration option: true

Thanks,
Piotr

On Sat, Mar 21, 2020, 6:45 PM Maria Jose Esteve  wrote:

>
> Hello, see if someone can help me because I can't work ...
> My project is compiled with maven and since 0.00 today (although I have
> not compiled the SDK artifacts are downloaded)
> The errors are:
>
> Error: interface method dispatchEvent in interface IEventDispatcher is
> implemented with an incompatible signature in class VisualWaitingDisplay
> Error: interface method dispatchEvent in interface IEventDispatcher is
> implemented with an incompatible signature in class
> LabelTruncateItemRenderer
>
> For example, LabelTruncateItemRenderer.mxml:
>
> 
> http://ns.adobe.com/mxml/2009";
> xmlns:j="library://ns.apache.org/royale/jewel"
> xmlns:js="library://ns.apache.org/royale/basic"
> xmlns:html="library://ns.apache.org/royale/html">
>
> 
> 
> 
> 
> 
>
> 
> 
> 
> 
> 
>
> 
>
> I have removed the beads, but it is not that ..
>
> Does anyone know what's going on? Any hints I can follow?
> Thanks in advance,
> Hiedra.
>
>
>

RE: As of 00.00 today I cannot compile my project.

[Maria Jose Esteve]

PERFECT!!! Thank you very much Piotr.
It did not occur to me to replicate the modifications of the pom's (Merge pull 
request # 765 from chrisdutz / develop)

Thanks again Piotr



Mª José Esteve García 
Dpto. Sistemas
mjest...@iest.com



Informática del Este S.L. 
C/ Camino Peñarrocha, 3 - Esc. D - Planta 1ª 
46023 - València (ESPAÑA) 
+34 669 488 195 | +34 963 485 874
www.iest.com

¡¡Síguenos en Redes Sociales!!

    

  

-Mensaje original-
De: Piotr Zarzycki  
Enviado el: sábado, 21 de marzo de 2020 19:15
Para: Apache Royale Development 
Asunto: Re: As of 00.00 today I cannot compile my project.

Hi Maria,

Add to compiler configuration option: true

Thanks,
Piotr

On Sat, Mar 21, 2020, 6:45 PM Maria Jose Esteve  wrote:

>
> Hello, see if someone can help me because I can't work ...
> My project is compiled with maven and since 0.00 today (although I 
> have not compiled the SDK artifacts are downloaded) The errors are:
>
> Error: interface method dispatchEvent in interface IEventDispatcher is 
> implemented with an incompatible signature in class 
> VisualWaitingDisplay
> Error: interface method dispatchEvent in interface IEventDispatcher is 
> implemented with an incompatible signature in class 
> LabelTruncateItemRenderer
>
> For example, LabelTruncateItemRenderer.mxml:
>
>   xmlns:fx="http://ns.adobe.com/mxml/2009";
> xmlns:j="library://ns.apache.org/royale/jewel"
> xmlns:js="library://ns.apache.org/royale/basic"
> xmlns:html="library://ns.apache.org/royale/html">
>
> 
> 
> 
> 
> 
>
> 
> 
> 
> 
> 
>
> 
>
> I have removed the beads, but it is not that ..
>
> Does anyone know what's going on? Any hints I can follow?
> Thanks in advance,
> Hiedra.
>
>
>

Re: Maven Distribution SDK fixed and working for IDEs

[Carlos Rovira]

Hi Piotr,

Chris, just made maven distribution mxmlc and compc executables.

   - I test and VSCode works fine
   - command line worked too [1]
   - Moonshine:  I couldn't launch a compilation with SDK. Just upgrade to
   latest version as Moonshine requested me. I have the SDK configured to the
   distribution created with Maven. Then with TDJ project loaded when to
   Project > Build Project, but nothings happen

So just need to see how to check Moonshine so we can check Maven
distribution is completed at last. I want to have that for this release
0.9.7

Thanks

Carlos

[1] output in command line for Tour de Jewel:

macbookpro:TourDeJewel carlosrovira$
/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/js/bin/mxmlc
-load-config+=obj/TourDeJewelConfig.xml -debug=true -source-map=true
-compiler.targets=JSRoyale
-js-output="/Users/carlosrovira/Dev/Royale/Source/royale-asjs/examples/royale/TourDeJewel/binary

>

macbookpro:TourDeJewel carlosrovira$
/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/js/bin/mxmlc
-load-config+=obj/TourDeJewelConfig.xml -debug=true -source-map=true
-compiler.targets=JSRoyale
-js-output=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/examples/royale/TourDeJewel/binary

Using Royale Compiler codebase:
/Users/carlosrovira/Dev/Royale/Source/royale-compiler

Using Royale SDK: /Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven

MXMLJSC

+royalelib=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/frameworks

-sdk-js-lib=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/frameworks/js/Royale/generated-sources

-load-config+=obj/TourDeJewelConfig.xml

-debug=true

-source-map=true

-compiler.targets=JSRoyale

-js-output=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/examples/royale/TourDeJewel/binary

The project 'App' has been successfully compiled.

7.080432099 seconds

El lun., 10 feb. 2020 a las 18:19, Carlos Rovira ()
escribió:

> Ok Josh,
> understood, will take into account as I check what's going on with latest
> fails
> thanks
>
> El lun., 10 feb. 2020 a las 17:16, Josh Tynjala (<
> joshtynj...@bowlerhat.dev>) escribió:
>
>> VSCode happens to run the JAR files directly with Java, and doesn't run
>> anything in js/bin. If the contents of js/bin do not have the correct
>> exectuable permissions, it wouldn't affect VSCode. However, fixing those
>> permissions would still be a problem that should be addressed to have a
>> proper distribution. Moonshine is not doing anything out of the ordinary
>> by
>> running js/bin/mxmlc (and that's what someone compiling from the command
>> line without Maven or Ant would use too). If anything, it's VSCode that is
>> not doing things in the ordinary way.
>>
>> --
>> Josh Tynjala
>> Bowler Hat LLC 
>>
>>
>> On Mon, Feb 10, 2020 at 12:48 AM Carlos Rovira 
>> wrote:
>>
>> > Hi,
>> >
>> > @Piotr Zarzycki  I was over the big button
>> to
>> > nightly builds, since you told me to download that. So from the big
>> button
>> > I choosed "other downloads" and choosed non sandbox one. Both url goes
>> to
>> > the same link: Moonshine_Signed_NonSandbox.pkg
>> > <
>> >
>> https://moonshine-ide.com/downloads/releases/dev/macos/Moonshine_Signed_NonSandbox.pkg
>> > >
>> > 07-Feb-2020 21:11 156571205
>> >
>> > About the permissions: My guess is that is something related to
>> Moonshine,
>> > not to user or maven, since VSCode is dealing with the same SDK without
>> > complain. I can give permissions to try this, but I suggest the
>> moonshine
>> > team could look to how VSCode work with user files and mimic that to
>> > avoid this kind of problem.
>> >
>> > Thanks
>> >
>> >
>> > El lun., 10 feb. 2020 a las 5:50, Alex Harui (> >)
>> > escribió:
>> >
>> > > IMO, the Maven commands that build the Distribution SDK should change
>> the
>> > > permissions.
>> > >
>> > > My 2 cents,
>> > > -Alex
>> > >
>> > > On 2/9/20, 11:04 AM, "Piotr Zarzycki" 
>> > wrote:
>> > >
>> > > Permission to "mxmlc" file in SDK. - You have to add permission
>> for
>> > > usage
>> > > manually to that file.
>> > >
>> > > I will explain you more on Monday if you won't figure it out your
>> > self,
>> > > what is all about.
>> > >
>> > > You can literally paste in Google last sentence from stack trace
>> > error
>> > > and
>> > > add: How to add permission to file on Mac.
>> > >
>> > >
>> > >
>> > > On Sun, Feb 9, 2020, 7:09 PM Carlos Rovira <
>> carlosrov...@apache.org>
>> > > wrote:
>> > >
>> > > > Hi Piotr,
>> > > >
>> > > > but what kind of permission? to the moonshine executable?
>> > > >
>> > > > El dom., 9 feb. 2020 a las 17:49, Piotr Zarzycki (<
>> > > > piotrzarzyck...@gmail.com>)
>> > > > escribió:
>> > > >
>> > > > > If you are using your own SDK (not downloaded trough Moonshine
>> > > getting
>> > > > > started) you have to add permission to mxmlc file. There is a
>> > > command on
>> > > > > Mac chmod - try to search using that command on a Google.
>> > 

Themes compilation now optional

[Carlos Rovira]

Hi,

just let you know that Chris creates a new profile [1] to run themes SASS
generation

To activate it add this profile:


   - option-with-sass-compile: To compile all SASS in themes. You just need
   to use this profile when update themes and want to generate final CSS.

Most probably is that just me is using this profile, so better for you all
to save precious time on each build ;)

Additional: with his refactor each theme compilation is under 1 sec
And all build with themes saves many time (depends on each machine). On my
Mac is around 5' less now :D

HTH

Carlos

[1]
https://github.com/apache/royale-asjs/wiki/Build-Apache-Royale-with-Maven

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

Build failed in Jenkins: royale-asjs #940

[apacheroyaleci]

See 


Changes:

[carlosrovira] jewel-themes: update to card simple


--
[...truncated 714.22 KB...]
  [get] Getting: 
https://raw.githubusercontent.com/royale-extras/closure-compiler/royale/externs/browser/html5.js
  [get] To: 
C:\jenkins\workspace\royale-typedefs\js\target\downloads\browser\html5.js
 [echo] swc-date is 03/22/20 01:04 +

double-check-file:
 [echo] ${env.ROYALE_DOWNLOAD_CACHE}
 [echo] Need file: ${still_no_file}

get-from-cache-if-needed:
 [echo] swc-date is 03/22/20 01:04 +

double-check-file:
 [echo] ${env.ROYALE_DOWNLOAD_CACHE}
 [echo] Need file: ${still_no_file}

get-from-cache-if-needed:
 [echo] swc-date is 03/22/20 01:04 +

double-check-file:
 [echo] ${env.ROYALE_DOWNLOAD_CACHE}
 [echo] Need file: ${still_no_file}

get-from-cache-if-needed:
 [echo] swc-date is 03/22/20 01:04 +

double-check-file:
 [echo] ${env.ROYALE_DOWNLOAD_CACHE}
 [echo] Need file: ${still_no_file}

get-from-cache-if-needed:
 [echo] swc-date is 03/22/20 01:04 +

double-check-file:
 [echo] ${env.ROYALE_DOWNLOAD_CACHE}
 [echo] Need file: ${still_no_file}

get-from-cache-if-needed:
 [echo] swc-date is 03/22/20 01:04 +

double-check-file:
 [echo] ${env.ROYALE_DOWNLOAD_CACHE}
 [echo] Need file: ${still_no_file}

get-from-cache-if-needed:
 [echo] swc-date is 03/22/20 01:04 +

double-check-file:
 [echo] ${env.ROYALE_DOWNLOAD_CACHE}
 [echo] Need file: ${still_no_file}

get-from-cache-if-needed:
 [echo] swc-date is 03/22/20 01:04 +

double-check-file:
 [echo] ${env.ROYALE_DOWNLOAD_CACHE}
 [echo] Need file: ${still_no_file}

get-from-cache-if-needed:
 [echo] swc-date is 03/22/20 01:04 +

fail-if-not-found:

preprocess:

externc:
 [java] Math parameters not found!  0
 [java] Reflect parameters not found!  0
 [java] Atomics parameters not found!  0
 [java] Intl parameters not found!  0
 [java] 4.0740524 seconds
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m -Xmx2g

postprocess:

compc:
 [copy] Copying 1 file to C:\jenkins\workspace\royale-typedefs\js\target
 [java] args:
 [java] +royalelib=externs/frameworks
 [java] -targets=SWF
 [java] 
-load-config=C:\jenkins\workspace\royale-typedefs\js/target/compile-as-config.xml
 [java] -metadata.date=03/22/20 01:04 +
 [java] -metadata.dateFormat=MM/dd/yy HH:mm Z
 [java] -output=C:\jenkins\workspace\royale-typedefs\js/target/js.swc
 [java] target:SWF
 [java] COMPC
 [java] Loading configuration: 
C:\jenkins\workspace\royale-typedefs\js\target\compile-as-config.xml
 [java] 
 [java] 653190 bytes written to 
C:\jenkins\workspace\royale-typedefs\js\target\js.swc in 9.222 seconds
 [java] 9.7567562 seconds
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m -Xmx2g

main:
 [echo] swc-date is 03/22/20 01:04 +

preprocess:

externc:

postprocess:

compc:
 [copy] Copying 1 file to C:\jenkins\workspace\royale-typedefs\GCL\target
 [java] args:
 [java] +royalelib=externs/frameworks
 [java] -targets=SWF
 [java] 
-external-library-path+=C:\jenkins\workspace\royale-typedefs\GCL/../js/target/js.swc
 [java] 
-load-config=C:\jenkins\workspace\royale-typedefs\GCL/target/compile-as-config.xml
 [java] -metadata.date=03/22/20 01:04 +
 [java] -metadata.dateFormat=MM/dd/yy HH:mm Z
 [java] -output=C:\jenkins\workspace\royale-typedefs\GCL/target/GCL.swc
 [java] target:SWF
 [java] COMPC
 [java] Loading configuration: 
C:\jenkins\workspace\royale-typedefs\GCL\target\compile-as-config.xml
 [java] 
 [java] 15004 bytes written to 
C:\jenkins\workspace\royale-typedefs\GCL\target\GCL.swc in 1.437 seconds
 [java] 2.0310774 seconds
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m -Xmx2g

main:
 [echo] swc-date is 03/22/20 01:04 +

preprocess:

externc:
 [java] 0.9834816 seconds
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m -Xmx2g

postprocess:

compc:
 [copy] Copying 1 file to 
C:\jenkins\workspace\royale-typedefs\cordova\target
 [java] args:
 [java] +royalelib=externs/frameworks
 [java] -targets=SWF
 [java] 
-external-library-path+=C:\jenkins\workspace\royale-typedefs\cordova/../js/target/js.swc
 [java] 
-load-config=C:\jenkins\workspace\royale-typedefs\cordova/target/compile-as-config.xml
 [java] -metadata.date=03/22/20 01:04 +
 [java] -metadata.dateFormat=MM/dd/yy HH:mm Z
 [java] 
-output=C:\jenkins\workspace\royale-typedefs\cordova/target/cordova.swc
 [java] target:SWF
 [java] COMPC
 [java] Loading configuration: 
C:\jenkins\workspace\royale-typedefs\cordova\target\compile-as-config.xml
 [java] 
 [java] 15108 bytes written

Jenkins build is back to normal : royale-asjs #941

[apacheroyaleci]

See