Re: Releasing: Finally giving up

[Alex Harui]

On 3/25/20, 4:46 PM, "Carlos Rovira"  wrote:

> What I want to know is what the Maven commands should be to create a
> release in this "conventional process" you are referring to.
>

If you want to know what's the conventional maven process is, I think I can
ask Chris if he wants to work with me on that process, since he already did
many other Apache projects, we can expect the process is what is needed for
us to. But just expect that will be a series of standard maven commands
(prepare, release,...), so nothing strange at all (I expect).

Do you want us to do that?

Yes.  I want to know what the series of standard Maven commands are.  Then we 
can figure out how to convert them to run on the CI server.

-Alex

Thanks


>
> Maybe someone else can explain better than me.
>
> -Alex
>
> On 3/25/20, 2:22 PM, "Carlos Rovira"  wrote:
>
> Hi Alex,
>
> El mié., 25 mar. 2020 a las 21:26, Alex Harui
> ()
> escribió:
>
> > Carlos,
> >
> > I'm pretty sure that part of the "conventional process" you want to
> try
> > requires filling the staging repo from a local machine.
> >
>
> This is what we already did. If you go to [1] will see [2]. That was
> the
> upload of compiler to the staging repo. When trying to do the same for
> typedefs it failed when trying to fill repo from local machine. I 
think
> Chris or I should not take more time in trying to fix Ant scripts that
> are
> failing.
>
> Thanks
>
> [1]
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2F%23stagingRepositories&data=02%7C01%7Caharui%40adobe.com%7C821c810ff88f4f3371a608d7d116c8e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637207768101866118&sdata=qSFTmdvxYB8fK%2FKM5kAd%2Bzslsl0fNxUJi%2BybUIleIUY%3D&reserved=0
> [2]
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fimgur.com%2Fa%2Fw4az7pD&data=02%7C01%7Caharui%40adobe.com%7C821c810ff88f4f3371a608d7d116c8e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637207768101866118&sdata=mOv7%2BFzO764iEkXZgA3DiGEdeRaXQrLp%2Fgq8g%2BOkjt0%3D&reserved=0
>
>
>
>
> >
> > --
> > Carlos Rovira
> >
> 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C821c810ff88f4f3371a608d7d116c8e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637207768101866118&sdata=96pUSZqS1Sc%2FJ4%2BvUUIFpcKEW4b2DAj2FJjCvc9eW2k%3D&reserved=0
> >
> >
> >
> >
>
>
>

-- 
Carlos Rovira

https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C821c810ff88f4f3371a608d7d116c8e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637207768101866118&sdata=96pUSZqS1Sc%2FJ4%2BvUUIFpcKEW4b2DAj2FJjCvc9eW2k%3D&reserved=0

Jenkins build is back to normal : Verify_Royale_Config #827

[apacheroyaleci]

See 

Re: Releasing: Finally giving up

[Carlos Rovira]

 Hi Alex,

El mié., 25 mar. 2020 a las 22:43, Alex Harui ()
escribió:

> Carlos,
>
> When I wrote "from a local machine" that means to use whatever computer
> you want to use and not the CI server or steps.  ç


maybe I there's a communication problem, but what I said is that I used my
local machine not the CI Server (since is what the step required) to do the
staging for step 007 email commands, and while that worked for compiler, It
didn't for typedefs.


> What I want to know is what the Maven commands should be to create a
> release in this "conventional process" you are referring to.
>

If you want to know what's the conventional maven process is, I think I can
ask Chris if he wants to work with me on that process, since he already did
many other Apache projects, we can expect the process is what is needed for
us to. But just expect that will be a series of standard maven commands
(prepare, release,...), so nothing strange at all (I expect).

Do you want us to do that?

Thanks


>
> Maybe someone else can explain better than me.
>
> -Alex
>
> On 3/25/20, 2:22 PM, "Carlos Rovira"  wrote:
>
> Hi Alex,
>
> El mié., 25 mar. 2020 a las 21:26, Alex Harui
> ()
> escribió:
>
> > Carlos,
> >
> > I'm pretty sure that part of the "conventional process" you want to
> try
> > requires filling the staging repo from a local machine.
> >
>
> This is what we already did. If you go to [1] will see [2]. That was
> the
> upload of compiler to the staging repo. When trying to do the same for
> typedefs it failed when trying to fill repo from local machine. I think
> Chris or I should not take more time in trying to fix Ant scripts that
> are
> failing.
>
> Thanks
>
> [1]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2F%23stagingRepositories&data=02%7C01%7Caharui%40adobe.com%7C2c3d44a188fa4d48de6208d7d1029468%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637207681319693950&sdata=TUrFSD0DLQzYs32p2qnzKOl7OLSGLt45sneONbtUnBQ%3D&reserved=0
> [2]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fimgur.com%2Fa%2Fw4az7pD&data=02%7C01%7Caharui%40adobe.com%7C2c3d44a188fa4d48de6208d7d1029468%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637207681319693950&sdata=DKffSbD1IJkCejOgCaV6qu%2FWRvR%2B1nh5p05%2Fex0Zmfg%3D&reserved=0
>
>
>
>
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2c3d44a188fa4d48de6208d7d1029468%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637207681319693950&sdata=H%2BzsfxujvhNDFfQzBT%2BVJG26as70%2BjpZLfCSS%2BCP6kc%3D&reserved=0
> >
> >
> >
> >
>
>
>

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

Re: Releasing: Finally giving up

[Alex Harui]

Carlos,

When I wrote "from a local machine" that means to use whatever computer you 
want to use and not the CI server or steps.  What I want to know is what the 
Maven commands should be to create a release in this "conventional process" you 
are referring to.

Maybe someone else can explain better than me.

-Alex

On 3/25/20, 2:22 PM, "Carlos Rovira"  wrote:

Hi Alex,

El mié., 25 mar. 2020 a las 21:26, Alex Harui ()
escribió:

> Carlos,
>
> I'm pretty sure that part of the "conventional process" you want to try
> requires filling the staging repo from a local machine.
>

This is what we already did. If you go to [1] will see [2]. That was the
upload of compiler to the staging repo. When trying to do the same for
typedefs it failed when trying to fill repo from local machine. I think
Chris or I should not take more time in trying to fix Ant scripts that are
failing.

Thanks

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2F%23stagingRepositories&data=02%7C01%7Caharui%40adobe.com%7C2c3d44a188fa4d48de6208d7d1029468%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637207681319693950&sdata=TUrFSD0DLQzYs32p2qnzKOl7OLSGLt45sneONbtUnBQ%3D&reserved=0
[2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fimgur.com%2Fa%2Fw4az7pD&data=02%7C01%7Caharui%40adobe.com%7C2c3d44a188fa4d48de6208d7d1029468%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637207681319693950&sdata=DKffSbD1IJkCejOgCaV6qu%2FWRvR%2B1nh5p05%2Fex0Zmfg%3D&reserved=0




>
> --
> Carlos Rovira
> 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2c3d44a188fa4d48de6208d7d1029468%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637207681319693950&sdata=H%2BzsfxujvhNDFfQzBT%2BVJG26as70%2BjpZLfCSS%2BCP6kc%3D&reserved=0
>
>
>
>

Re: Releasing: Finally giving up

[Carlos Rovira]

Hi Alex,

El mié., 25 mar. 2020 a las 21:26, Alex Harui ()
escribió:

> Carlos,
>
> I'm pretty sure that part of the "conventional process" you want to try
> requires filling the staging repo from a local machine.
>

This is what we already did. If you go to [1] will see [2]. That was the
upload of compiler to the staging repo. When trying to do the same for
typedefs it failed when trying to fill repo from local machine. I think
Chris or I should not take more time in trying to fix Ant scripts that are
failing.

Thanks

[1] https://repository.apache.org/#stagingRepositories
[2] https://imgur.com/a/w4az7pD




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

Re: Releasing: Finally giving up

[Alex Harui]

Reproducible builds for Royale is certainly new.  There could be bugs in North 
vs South hemispheres.  Don't know.  Volunteers are welcome to improve this 
portion of our code.

I believe one (maybe the only one) of the challenges is to figure out how to 
choose a timestamp that can be used in the SWCs for at least those needing to 
reproduce the SWCs.  The ZipEntry used in the SWC does not contain a timezone 
so I think there are some challenges to that.

You can try building the SWCs using the timestamps used in the daily builds and 
see if you also see time skews and propose solutions.

-Alex 

On 3/25/20, 1:28 PM, "Greg Dove"  wrote:

 'It could be an issue when the US and Europe have different daylight
savings time settings.  When we saw it work, we were not at one of
those transition points.'

Southern hemisphere and northern hemisphere differences pivot by 2 hours
through these transition gaps, which are typically 2 weeks or 1 week when
the application or non-application of DST is aligned between the two
countries being compared.
For the majority of the year DST is not aligned. The end of each transition
results in things being 2 hours different from whatever was 'normal'
before.

If the nature of this problem is as-described, which seems to require DST
alignment, does that mean the timestamp issues might be present most of the
time for someone south of the equator and perhaps only work in the
'transitions' when DST 'settings' are briefly aligned?
So far, I know this hasn't been a problem, with Royale having had no RM
from southern climes, iirc. So I'm just asking mainly to clarify my
understanding of the problem itself. If the answer is "I'm not sure, try it
and see" I am not at that point yet :)

If, however, there is something specific that I can investigate about
timestamp issues, I am happy to try.


On Thu, Mar 26, 2020 at 7:23 AM Alex Harui  wrote:

> That has nothing to do with the Ant build of release artifacts.  That is
> just using Ant to run command line commands to download and verify Maven
> release artifacts.  I'm pretty sure you can just look at the steps and 
type
> them in manually at the command line and you'll get the same results.
>
> AFAICT, the problem is that the reproducible binaries generated by Maven
> aren't reproducible.It could be an issue when the US and Europe have
> different daylight savings time settings.  When we saw it work, we were 
not
> at one of those transition points.  So maybe it is best to just wait until
> Sunday.  But it did work for me in the US and Piotr in EU.
>
> Proposals for better ways to have an RM verify artifacts built on a remote
> machine are welcome.  Testing reproducible binaries was the only way I
> could think of and implement.
>
> -Alex
>
> On 3/25/20, 11:13 AM, "Carlos Rovira"  wrote:
>
> Hi Alex,
>
> after run CI Server 007 we get this email:
>
> From the royale-typedefs repo:
> 1. Run ant -f releasesteps.xml Release_Step_007 
-Drelease.version=0.9.7
> -DskipTests=true
> This will download the artifacts then unzip and compile the source
> artifact.
> 2. Validate that the compiled artifacts match the downloaded 
artifacts.
> 3. If they do, then run ant -f releasesteps.xml Release_Step_007_Sign
> -Drelease.version=0.9.7
> This will PGP sign the source ZIP and compiled JARs
> 4. Then run ant -f releasesteps.xml Release_Step_007_Upload
> -Drelease.version=0.9.7
> This will upload the signed artifacts to Maven Release Staging. Do not
> "Close" the staging repository until the other repos have been added.
>
> This is what is failing from sub step 007-1, so as part of the step,
> I'm
> downloading with ant and building, signing and then uploading (Or 
steps
> should allow me to do that, but is failing)
>
> A part from that I don't think we really want a solution where of
> breaking
> steps event more. What we're requesting is remove steps.
>
>
>
>
> El mié., 25 mar. 2020 a las 18:54, Alex Harui
> ()
> escribió:
>
> > I'm sorry, I must have missed something.  Where was Ant involved in
> any of
> > the problems reported so far?  AFAICT, it was all Maven plugins
> driving our
> > compiler and we couldn't get reproducible binaries.
> >
> > I suggested in one reply that Chris fills a staging repo using his
> local
> > machine just to make sure we know what Maven commands need to be run
> to
> > generate all of the Maven artifacts.   And that would validate the
> claim
> > that it is really doable in two or three steps.  A partial
> verification of
>  

Re: Releasing: Finally giving up

[Greg Dove]

 'It could be an issue when the US and Europe have different daylight
savings time settings.  When we saw it work, we were not at one of
those transition points.'

Southern hemisphere and northern hemisphere differences pivot by 2 hours
through these transition gaps, which are typically 2 weeks or 1 week when
the application or non-application of DST is aligned between the two
countries being compared.
For the majority of the year DST is not aligned. The end of each transition
results in things being 2 hours different from whatever was 'normal'
before.

If the nature of this problem is as-described, which seems to require DST
alignment, does that mean the timestamp issues might be present most of the
time for someone south of the equator and perhaps only work in the
'transitions' when DST 'settings' are briefly aligned?
So far, I know this hasn't been a problem, with Royale having had no RM
from southern climes, iirc. So I'm just asking mainly to clarify my
understanding of the problem itself. If the answer is "I'm not sure, try it
and see" I am not at that point yet :)

If, however, there is something specific that I can investigate about
timestamp issues, I am happy to try.


On Thu, Mar 26, 2020 at 7:23 AM Alex Harui  wrote:

> That has nothing to do with the Ant build of release artifacts.  That is
> just using Ant to run command line commands to download and verify Maven
> release artifacts.  I'm pretty sure you can just look at the steps and type
> them in manually at the command line and you'll get the same results.
>
> AFAICT, the problem is that the reproducible binaries generated by Maven
> aren't reproducible.It could be an issue when the US and Europe have
> different daylight savings time settings.  When we saw it work, we were not
> at one of those transition points.  So maybe it is best to just wait until
> Sunday.  But it did work for me in the US and Piotr in EU.
>
> Proposals for better ways to have an RM verify artifacts built on a remote
> machine are welcome.  Testing reproducible binaries was the only way I
> could think of and implement.
>
> -Alex
>
> On 3/25/20, 11:13 AM, "Carlos Rovira"  wrote:
>
> Hi Alex,
>
> after run CI Server 007 we get this email:
>
> From the royale-typedefs repo:
> 1. Run ant -f releasesteps.xml Release_Step_007 -Drelease.version=0.9.7
> -DskipTests=true
> This will download the artifacts then unzip and compile the source
> artifact.
> 2. Validate that the compiled artifacts match the downloaded artifacts.
> 3. If they do, then run ant -f releasesteps.xml Release_Step_007_Sign
> -Drelease.version=0.9.7
> This will PGP sign the source ZIP and compiled JARs
> 4. Then run ant -f releasesteps.xml Release_Step_007_Upload
> -Drelease.version=0.9.7
> This will upload the signed artifacts to Maven Release Staging. Do not
> "Close" the staging repository until the other repos have been added.
>
> This is what is failing from sub step 007-1, so as part of the step,
> I'm
> downloading with ant and building, signing and then uploading (Or steps
> should allow me to do that, but is failing)
>
> A part from that I don't think we really want a solution where of
> breaking
> steps event more. What we're requesting is remove steps.
>
>
>
>
> El mié., 25 mar. 2020 a las 18:54, Alex Harui
> ()
> escribió:
>
> > I'm sorry, I must have missed something.  Where was Ant involved in
> any of
> > the problems reported so far?  AFAICT, it was all Maven plugins
> driving our
> > compiler and we couldn't get reproducible binaries.
> >
> > I suggested in one reply that Chris fills a staging repo using his
> local
> > machine just to make sure we know what Maven commands need to be run
> to
> > generate all of the Maven artifacts.   And that would validate the
> claim
> > that it is really doable in two or three steps.  A partial
> verification of
> > validity is to check that the same set of files was produced as in
> 0.9.6
> > (there might be some new SWCs though).
> >
> > Then someone else (maybe Carlos) would download all of the
> artifacts, run
> > the same steps, download the new artifacts and verify that the binary
> > match.  Then we can work on splitting those steps into chunks for
> the CI
> > server.
> >
> > -Alex
> >
> >
> > On 3/25/20, 10:13 AM, "Carlos Rovira" 
> wrote:
> >
> > We imposed ourselves a need to release building with two build
> systems.
> > That's the biggest issue and that's a requirement of this PMC.
> > That's what makes the need of the actual CI steps and the
> complex and
> > intricate process.
> >
> > For the rest of Apache a release is:
> >
> > "For an *Apache* project, that means any publication outside the
> > development community, defined as individuals actively
> participating in
> > development or fol

Re: Releasing: Finally giving up

[Alex Harui]

Carlos,

I'm pretty sure that part of the "conventional process" you want to try 
requires filling the staging repo from a local machine.  I am suggesting that 
Chris and/or you do exactly that and document the steps and have someone else 
try those steps, so we can understand what that portion of the "conventional 
process" looks like.  Then it might be more clear what needs to be done to get 
it work on the CI server.

-Alex

On 3/25/20, 1:16 PM, "Carlos Rovira"  wrote:

 Hi Alex,

El mié., 25 mar. 2020 a las 20:37, Alex Harui ()
escribió:

> But as I suggested in my previous post, it might help to first come up
> with the set of maven commands required to reproduce (using your local
> machine) the same number of files with the same names (other than the
> version portion) that were in 0.9.6.
>

I think we're done what the process required. If there's other things we
need to do, those are not in the current process, so I think is your
responsibility to update that to make it work to prove that the process is
valid. I think you can't expect Chris or I invest more time in the process
when we are exposing all the problems behind it. I think we did our best,
and now is the turn of others to try it, or as I already proposed lets us
do a release with a more conventional process that does not try to do all
that steps, that we think are not necessary, based on the rest of hundreds
and hundreds of Apache projects.

Hope you can understand it.

Thanks

-- 
Carlos Rovira

https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C467696ba4ee245a5f09108d7d0f957f1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637207641651664238&sdata=HdyvFUveH6nxvIkp%2FSyPyzfkfTQ6TJHTtN24GZC0vjs%3D&reserved=0

Build failed in Jenkins: Verify_Royale_Config #826

[apacheroyaleci]

See 


Changes:


--
Started by upstream project "royale-asjs" build number 952
originally caused by:
 Started by upstream project "royale-asjs_jsonly" build number 1127
 originally caused by:
  Started by upstream project "royale-typedefs" build number 457
  originally caused by:
   Started by upstream project "royale-compiler" build number 288
   originally caused by:
Started by an SCM change
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on agent1 in workspace 

[WS-CLEANUP] Deleting project workspace...
[WS-CLEANUP] Deferred wipeout is used...
[WS-CLEANUP] Done
No credentials specified
Cloning the remote Git repository
Cloning repository http://github.com/apache/royale-asjs
 > C:\Program Files\Git\cmd\git.exe init 
 > 
 >  # timeout=10
Fetching upstream changes from http://github.com/apache/royale-asjs
 > C:\Program Files\Git\cmd\git.exe --version # timeout=10
 > C:\Program Files\Git\cmd\git.exe fetch --tags --force --progress -- 
 > http://github.com/apache/royale-asjs +refs/heads/*:refs/remotes/origin/*
ERROR: Timeout after 10 minutes
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "C:\Program Files\Git\cmd\git.exe 
fetch --tags --force --progress -- http://github.com/apache/royale-asjs 
+refs/heads/*:refs/remotes/origin/*" returned status code 130:
stdout: 
stderr: warning: redirecting to https://github.com/apache/royale-asjs/
remote: Enumerating objects: 109, done.
remote: Counting objects:   0% (1/109)remote: Counting objects:   1% 
(2/109)remote: Counting objects:   2% (3/109)remote: Counting 
objects:   3% (4/109)remote: Counting objects:   4% (5/109)
remote: Counting objects:   5% (6/109)remote: Counting objects:   6% 
(7/109)remote: Counting objects:   7% (8/109)remote: Counting 
objects:   8% (9/109)remote: Counting objects:   9% (10/109)
remote: Counting objects:  10% (11/109)remote: Counting objects:  11% 
(12/109)remote: Counting objects:  12% (14/109)remote: Counting 
objects:  13% (15/109)remote: Counting objects:  14% (16/109)
remote: Counting objects:  15% (17/109)remote: Counting objects:  16% 
(18/109)remote: Counting objects:  17% (19/109)remote: Counting 
objects:  18% (20/109)remote: Counting objects:  19% (21/109)
remote: Counting objects:  20% (22/109)remote: Counting objects:  21% 
(23/109)remote: Counting objects:  22% (24/109)remote: Counting 
objects:  23% (26/109)remote: Counting objects:  24% (27/109)
remote: Counting objects:  25% (28/109)remote: Counting objects:  26% 
(29/109)remote: Counting objects:  27% (30/109)remote: Counting 
objects:  28% (31/109)remote: Counting objects:  29% (32/109)
remote: Counting objects:  30% (33/109)remote: Counting objects:  31% 
(34/109)remote: Counting objects:  32% (35/109)remote: Counting 
objects:  33% (36/109)remote: Counting objects:  34% (38/109)
remote: Counting objects:  35% (39/109)remote: Counting objects:  36% 
(40/109)remote: Counting objects:  37% (41/109)remote: Counting 
objects:  38% (42/109)remote: Counting objects:  39% (43/109)
remote: Counting objects:  40% (44/109)remote: Counting objects:  41% 
(45/109)remote: Counting objects:  42% (46/109)remote: Counting 
objects:  43% (47/109)remote: Counting objects:  44% (48/109)
remote: Counting objects:  45% (50/109)remote: Counting objects:  46% 
(51/109)remote: Counting objects:  47% (52/109)remote: Counting 
objects:  48% (53/109)remote: Counting objects:  49% (54/109)
remote: Counting objects:  50% (55/109)remote: Counting objects:  51% 
(56/109)remote: Counting objects:  52% (57/109)remote: Counting 
objects:  53% (58/109)remote: Counting objects:  54% (59/109)
remote: Counting objects:  55% (60/109)remote: Counting objects:  56% 
(62/109)remote: Counting objects:  57% (63/109)remote: Counting 
objects:  58% (64/109)remote: Counting objects:  59% (65/109)
remote: Counting objects:  60% (66/109)remote: Counting objects:  61% 
(67/109)remote: Counting objects:  62% (68/109)remote: Counting 
objects:  63% (69/109)remote: Counting objects:  64% (70/109)
remote: Counting objects:  65% (71/109)remote: Counting objects:  66% 
(72/109)remote: Counting objects:

Re: Releasing: Finally giving up

[Carlos Rovira]

 Hi Alex,

El mié., 25 mar. 2020 a las 20:37, Alex Harui ()
escribió:

> But as I suggested in my previous post, it might help to first come up
> with the set of maven commands required to reproduce (using your local
> machine) the same number of files with the same names (other than the
> version portion) that were in 0.9.6.
>

I think we're done what the process required. If there's other things we
need to do, those are not in the current process, so I think is your
responsibility to update that to make it work to prove that the process is
valid. I think you can't expect Chris or I invest more time in the process
when we are exposing all the problems behind it. I think we did our best,
and now is the turn of others to try it, or as I already proposed lets us
do a release with a more conventional process that does not try to do all
that steps, that we think are not necessary, based on the rest of hundreds
and hundreds of Apache projects.

Hope you can understand it.

Thanks

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

Re: Releasing: Finally giving up

[Carlos Rovira]

Hi, Alex

El mié., 25 mar. 2020 a las 19:23, Alex Harui ()
escribió:

> That has nothing to do with the Ant build of release artifacts.  That is
> just using Ant to run command line commands to download and verify Maven
> release artifacts.  I'm pretty sure you can just look at the steps and type
> them in manually at the command line and you'll get the same results.
>

As I said, this requested step from the CI Server failed for me, so I could
not sign and then upload. Is what we're trying to say.

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

Re: Releasing: Finally giving up

[Alex Harui]

IMO, reproducible binaries are useful for more than building artifacts on a 
remote machine.  I think enough folks agree that they produced plugins for 
Maven to help with reproducibility.  When I introduced it to Royale, it wasn't 
just to solve the CI build issue, it was to set us up for the future, in case 
signed binaries become required for installation for security/anti-malware 
reasons.

But as I suggested in my previous post, it might help to first come up with the 
set of maven commands required to reproduce (using your local machine) the same 
number of files with the same names (other than the version portion) that were 
in 0.9.6.
  
-Alex

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

Hi Alex,

this is again under the premise that releases "must" be done on the CI 
server, which I would personally like to question.

Royale is, as far as I know, the only project insisting on this. 

If you build the release on your machine you don't have to check if this is 
really what you build on your machine.

Chris



Am 25.03.20, 19:23 schrieb "Alex Harui" :

That has nothing to do with the Ant build of release artifacts.  That 
is just using Ant to run command line commands to download and verify Maven 
release artifacts.  I'm pretty sure you can just look at the steps and type 
them in manually at the command line and you'll get the same results.

AFAICT, the problem is that the reproducible binaries generated by 
Maven aren't reproducible.It could be an issue when the US and Europe have 
different daylight savings time settings.  When we saw it work, we were not at 
one of those transition points.  So maybe it is best to just wait until Sunday. 
 But it did work for me in the US and Piotr in EU.

Proposals for better ways to have an RM verify artifacts built on a 
remote machine are welcome.  Testing reproducible binaries was the only way I 
could think of and implement.

-Alex

On 3/25/20, 11:13 AM, "Carlos Rovira"  wrote:

Hi Alex,

after run CI Server 007 we get this email:

From the royale-typedefs repo:
1. Run ant -f releasesteps.xml Release_Step_007 
-Drelease.version=0.9.7
-DskipTests=true
This will download the artifacts then unzip and compile the source 
artifact.
2. Validate that the compiled artifacts match the downloaded 
artifacts.
3. If they do, then run ant -f releasesteps.xml 
Release_Step_007_Sign
-Drelease.version=0.9.7
This will PGP sign the source ZIP and compiled JARs
4. Then run ant -f releasesteps.xml Release_Step_007_Upload
-Drelease.version=0.9.7
This will upload the signed artifacts to Maven Release Staging. Do 
not
"Close" the staging repository until the other repos have been 
added.

This is what is failing from sub step 007-1, so as part of the 
step, I'm
downloading with ant and building, signing and then uploading (Or 
steps
should allow me to do that, but is failing)

A part from that I don't think we really want a solution where of 
breaking
steps event more. What we're requesting is remove steps.




El mié., 25 mar. 2020 a las 18:54, Alex Harui 
()
escribió:

> I'm sorry, I must have missed something.  Where was Ant involved 
in any of
> the problems reported so far?  AFAICT, it was all Maven plugins 
driving our
> compiler and we couldn't get reproducible binaries.
>
> I suggested in one reply that Chris fills a staging repo using 
his local
> machine just to make sure we know what Maven commands need to be 
run to
> generate all of the Maven artifacts.   And that would validate 
the claim
> that it is really doable in two or three steps.  A partial 
verification of
> validity is to check that the same set of files was produced as 
in 0.9.6
> (there might be some new SWCs though).
>
> Then someone else (maybe Carlos) would download all of the 
artifacts, run
> the same steps, download the new artifacts and verify that the 
binary
> match.  Then we can work on splitting those steps into chunks for 
the CI
> server.
>
> -Alex
>
>
> On 3/25/20, 10:13 AM, "Carlos Rovira"  
wrote:
>
> We imposed ourselves a need to release building with two 
build systems.
> That's the biggest issue and that's a requirement of this PMC.
> That's what makes the need of the actual CI steps and the 
com

Re: Releasing: Finally giving up

[Christofer Dutz]

Hi Alex,

this is again under the premise that releases "must" be done on the CI server, 
which I would personally like to question.

Royale is, as far as I know, the only project insisting on this. 

If you build the release on your machine you don't have to check if this is 
really what you build on your machine.

Chris



Am 25.03.20, 19:23 schrieb "Alex Harui" :

That has nothing to do with the Ant build of release artifacts.  That is 
just using Ant to run command line commands to download and verify Maven 
release artifacts.  I'm pretty sure you can just look at the steps and type 
them in manually at the command line and you'll get the same results.

AFAICT, the problem is that the reproducible binaries generated by Maven 
aren't reproducible.It could be an issue when the US and Europe have 
different daylight savings time settings.  When we saw it work, we were not at 
one of those transition points.  So maybe it is best to just wait until Sunday. 
 But it did work for me in the US and Piotr in EU.

Proposals for better ways to have an RM verify artifacts built on a remote 
machine are welcome.  Testing reproducible binaries was the only way I could 
think of and implement.

-Alex

On 3/25/20, 11:13 AM, "Carlos Rovira"  wrote:

Hi Alex,

after run CI Server 007 we get this email:

From the royale-typedefs repo:
1. Run ant -f releasesteps.xml Release_Step_007 -Drelease.version=0.9.7
-DskipTests=true
This will download the artifacts then unzip and compile the source 
artifact.
2. Validate that the compiled artifacts match the downloaded artifacts.
3. If they do, then run ant -f releasesteps.xml Release_Step_007_Sign
-Drelease.version=0.9.7
This will PGP sign the source ZIP and compiled JARs
4. Then run ant -f releasesteps.xml Release_Step_007_Upload
-Drelease.version=0.9.7
This will upload the signed artifacts to Maven Release Staging. Do not
"Close" the staging repository until the other repos have been added.

This is what is failing from sub step 007-1, so as part of the step, I'm
downloading with ant and building, signing and then uploading (Or steps
should allow me to do that, but is failing)

A part from that I don't think we really want a solution where of 
breaking
steps event more. What we're requesting is remove steps.




El mié., 25 mar. 2020 a las 18:54, Alex Harui 
()
escribió:

> I'm sorry, I must have missed something.  Where was Ant involved in 
any of
> the problems reported so far?  AFAICT, it was all Maven plugins 
driving our
> compiler and we couldn't get reproducible binaries.
>
> I suggested in one reply that Chris fills a staging repo using his 
local
> machine just to make sure we know what Maven commands need to be run 
to
> generate all of the Maven artifacts.   And that would validate the 
claim
> that it is really doable in two or three steps.  A partial 
verification of
> validity is to check that the same set of files was produced as in 
0.9.6
> (there might be some new SWCs though).
>
> Then someone else (maybe Carlos) would download all of the artifacts, 
run
> the same steps, download the new artifacts and verify that the binary
> match.  Then we can work on splitting those steps into chunks for the 
CI
> server.
>
> -Alex
>
>
> On 3/25/20, 10:13 AM, "Carlos Rovira"  wrote:
>
> We imposed ourselves a need to release building with two build 
systems.
> That's the biggest issue and that's a requirement of this PMC.
> That's what makes the need of the actual CI steps and the complex 
and
> intricate process.
>
> For the rest of Apache a release is:
>
> "For an *Apache* project, that means any publication outside the
> development community, defined as individuals actively 
participating in
> development or following the dev list. More narrowly, an official
> *Apache
> release* is one which has been endorsed as an "act of the 
Foundation"
> by a
> PMC."
>
> That means that we can release with ANT, with Maven, or any other 
build
> systems as part of the process, and even try what we're doing of
> trying to
> build with n build systems and try to check all is ok with the
> artifacts
> generated by all that build systems and check all of them...but if
> that's
> what we want, I personally will left this wagon, and wish you the 
best
> of
> lucks in the process.
   

Control over export/rename: Finally giving up

[Josh Tynjala]

(With credit to Chris for the subject name 😏)

Some of you may know that over the last 2-3 months I've been looking into
ways to add more control over how the compiler handles renaming and
exporting APIs in the generated JS. Ideally, my work would have culminated
in a variety of options that would allow release builds to be much smaller,
if you were willing to sacrifice certain capabilities (things along the
lines of dynamic access of properties and reflection). Obviously, you would
have been able to keep things working the same as they do today, so my
changes would have been opt-in.

I've determined that Closure does not actually expose the ability to
prevent renaming of JS APIs, except by exporting them. The advanced
compiler APIs that Closure exposes to prevent renaming are specifically
intended for compiling multiple related projects together (like we're doing
with modules). Additionally, I discovered that Closure does not guarantee
that any custom rename mappings will be respected. In fact, the
documentation says they may be completely ignored, and there is official
guidance that says not to do what I was originally trying to do. I could
not find any other Closure compiler APIs accessible in Java that could do
what we want here, so I think that our original assumption that preventing
renaming programmatically would be possible was incorrect.

In the case of disabling exports, I found that there are parts of the
Royale framework that rely on the fact that properties are exported.
Bindings and setting properties in MXML are the most visible. There are
probably more that I didn't discover yet because the first two had such a
big impact. Honestly, I am not experienced enough in the framework side of
Royale to know that I won't break anything if I try to start making changes
to ensure that all framework code can handle property renaming. Maybe
disabling exports is still possible, but I don't think that I'm the one who
can do it.

In the end, I was left feeling extremely frustrated with Closure compiler
once again. It's not the first time, and it's unlikely to be the last. I
wasted two whole months trying to follow its incredibly strict rule system.
In the past, I have tried to fight Closure instead, so I thought that I was
doing things right this time. I really wish I would have spent that time
doing something else that would have benefitted Royale more.

Side note: As I was reverting the rename/export changes I had made to the
compiler, I realized that there were some issues with my previous attempts
to improve the situation with warn-public-vars. With that in mind, I
reverted those changes too (for now). I plan to look into a better solution
for warn-public-vars soon, but I can't guarantee that anything will work
because it's another place where Closure compiler is the cause of the issue.

--
Josh Tynjala
Bowler Hat LLC 

Re: Releasing: Finally giving up

[Alex Harui]

That has nothing to do with the Ant build of release artifacts.  That is just 
using Ant to run command line commands to download and verify Maven release 
artifacts.  I'm pretty sure you can just look at the steps and type them in 
manually at the command line and you'll get the same results.

AFAICT, the problem is that the reproducible binaries generated by Maven aren't 
reproducible.It could be an issue when the US and Europe have different 
daylight savings time settings.  When we saw it work, we were not at one of 
those transition points.  So maybe it is best to just wait until Sunday.  But 
it did work for me in the US and Piotr in EU.

Proposals for better ways to have an RM verify artifacts built on a remote 
machine are welcome.  Testing reproducible binaries was the only way I could 
think of and implement.

-Alex

On 3/25/20, 11:13 AM, "Carlos Rovira"  wrote:

Hi Alex,

after run CI Server 007 we get this email:

From the royale-typedefs repo:
1. Run ant -f releasesteps.xml Release_Step_007 -Drelease.version=0.9.7
-DskipTests=true
This will download the artifacts then unzip and compile the source artifact.
2. Validate that the compiled artifacts match the downloaded artifacts.
3. If they do, then run ant -f releasesteps.xml Release_Step_007_Sign
-Drelease.version=0.9.7
This will PGP sign the source ZIP and compiled JARs
4. Then run ant -f releasesteps.xml Release_Step_007_Upload
-Drelease.version=0.9.7
This will upload the signed artifacts to Maven Release Staging. Do not
"Close" the staging repository until the other repos have been added.

This is what is failing from sub step 007-1, so as part of the step, I'm
downloading with ant and building, signing and then uploading (Or steps
should allow me to do that, but is failing)

A part from that I don't think we really want a solution where of breaking
steps event more. What we're requesting is remove steps.




El mié., 25 mar. 2020 a las 18:54, Alex Harui ()
escribió:

> I'm sorry, I must have missed something.  Where was Ant involved in any of
> the problems reported so far?  AFAICT, it was all Maven plugins driving 
our
> compiler and we couldn't get reproducible binaries.
>
> I suggested in one reply that Chris fills a staging repo using his local
> machine just to make sure we know what Maven commands need to be run to
> generate all of the Maven artifacts.   And that would validate the claim
> that it is really doable in two or three steps.  A partial verification of
> validity is to check that the same set of files was produced as in 0.9.6
> (there might be some new SWCs though).
>
> Then someone else (maybe Carlos) would download all of the artifacts, run
> the same steps, download the new artifacts and verify that the binary
> match.  Then we can work on splitting those steps into chunks for the CI
> server.
>
> -Alex
>
>
> On 3/25/20, 10:13 AM, "Carlos Rovira"  wrote:
>
> We imposed ourselves a need to release building with two build 
systems.
> That's the biggest issue and that's a requirement of this PMC.
> That's what makes the need of the actual CI steps and the complex and
> intricate process.
>
> For the rest of Apache a release is:
>
> "For an *Apache* project, that means any publication outside the
> development community, defined as individuals actively participating 
in
> development or following the dev list. More narrowly, an official
> *Apache
> release* is one which has been endorsed as an "act of the Foundation"
> by a
> PMC."
>
> That means that we can release with ANT, with Maven, or any other 
build
> systems as part of the process, and even try what we're doing of
> trying to
> build with n build systems and try to check all is ok with the
> artifacts
> generated by all that build systems and check all of them...but if
> that's
> what we want, I personally will left this wagon, and wish you the best
> of
> lucks in the process.
>
> Chris and I proposed to just use Maven *for release* (so please, I
> expect
> no body starts to say we are throwing away ANT from the project for
> building, pleasewe are just discussing release here).
>
> What do you think about to try to release just with Maven? If can do
> in the
> next day or two and get the release published...will that work for
> you? I
> think we don't need anything more, and I'm sure our users will be
> happy too.
>
> And yes, people wanting then to build with Ant or with Maven will be
> able
> to do so... :-)
>
> Thanks
>
> Carlos
>
>
> [1]
> 
https://nam

Re: Releasing: Finally giving up

[Carlos Rovira]

Hi Alex,

after run CI Server 007 we get this email:

>From the royale-typedefs repo:
1. Run ant -f releasesteps.xml Release_Step_007 -Drelease.version=0.9.7
-DskipTests=true
This will download the artifacts then unzip and compile the source artifact.
2. Validate that the compiled artifacts match the downloaded artifacts.
3. If they do, then run ant -f releasesteps.xml Release_Step_007_Sign
-Drelease.version=0.9.7
This will PGP sign the source ZIP and compiled JARs
4. Then run ant -f releasesteps.xml Release_Step_007_Upload
-Drelease.version=0.9.7
This will upload the signed artifacts to Maven Release Staging. Do not
"Close" the staging repository until the other repos have been added.

This is what is failing from sub step 007-1, so as part of the step, I'm
downloading with ant and building, signing and then uploading (Or steps
should allow me to do that, but is failing)

A part from that I don't think we really want a solution where of breaking
steps event more. What we're requesting is remove steps.




El mié., 25 mar. 2020 a las 18:54, Alex Harui ()
escribió:

> I'm sorry, I must have missed something.  Where was Ant involved in any of
> the problems reported so far?  AFAICT, it was all Maven plugins driving our
> compiler and we couldn't get reproducible binaries.
>
> I suggested in one reply that Chris fills a staging repo using his local
> machine just to make sure we know what Maven commands need to be run to
> generate all of the Maven artifacts.   And that would validate the claim
> that it is really doable in two or three steps.  A partial verification of
> validity is to check that the same set of files was produced as in 0.9.6
> (there might be some new SWCs though).
>
> Then someone else (maybe Carlos) would download all of the artifacts, run
> the same steps, download the new artifacts and verify that the binary
> match.  Then we can work on splitting those steps into chunks for the CI
> server.
>
> -Alex
>
>
> On 3/25/20, 10:13 AM, "Carlos Rovira"  wrote:
>
> We imposed ourselves a need to release building with two build systems.
> That's the biggest issue and that's a requirement of this PMC.
> That's what makes the need of the actual CI steps and the complex and
> intricate process.
>
> For the rest of Apache a release is:
>
> "For an *Apache* project, that means any publication outside the
> development community, defined as individuals actively participating in
> development or following the dev list. More narrowly, an official
> *Apache
> release* is one which has been endorsed as an "act of the Foundation"
> by a
> PMC."
>
> That means that we can release with ANT, with Maven, or any other build
> systems as part of the process, and even try what we're doing of
> trying to
> build with n build systems and try to check all is ok with the
> artifacts
> generated by all that build systems and check all of them...but if
> that's
> what we want, I personally will left this wagon, and wish you the best
> of
> lucks in the process.
>
> Chris and I proposed to just use Maven *for release* (so please, I
> expect
> no body starts to say we are throwing away ANT from the project for
> building, pleasewe are just discussing release here).
>
> What do you think about to try to release just with Maven? If can do
> in the
> next day or two and get the release published...will that work for
> you? I
> think we don't need anything more, and I'm sure our users will be
> happy too.
>
> And yes, people wanting then to build with Ant or with Maven will be
> able
> to do so... :-)
>
> Thanks
>
> Carlos
>
>
> [1]
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Fdev%2Frelease-publishing.html&data=02%7C01%7Caharui%40adobe.com%7C051d4367ac9743249ec808d7d0dfd038%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637207532001774243&sdata=JWLztd6WGtyugYMEzRLqytO41ypZsDYQIdUhaPIMEG4%3D&reserved=0
>
>
>
> El mié., 25 mar. 2020 a las 17:46, Christofer Dutz (<
> christofer.d...@c-ware.de>) escribió:
>
> > Hi Yiashay,
> >
> > I agree ... but I didn't create Maven ... haven't even provided a
> single
> > PR to it ;-)
> > I think my only noticeable contribution was that they changed their
> > website to forbid the usage of "maven-{something}-plugin" to Apache
> Maven
> > Core modules (It initially said Apache Maven Plugins which would have
> > applied for maven-flex-plugin and maven-plc4x-plugin)
> >
> > I think you should focus not on the process, but the bases a process
> > should cover.
> >
> > Focus on what you want to be provided or ensured by any process, no
> matter
> > which tool it is based on.
> >
> > That's what I created the google doc for.
> >
> > If you decide to loosen the requirement on sticking 100% to the
> existing
> > process I am more than willing to help.
> > However if y

Re: Releasing: Finally giving up

[Alex Harui]

I'm sorry, I must have missed something.  Where was Ant involved in any of the 
problems reported so far?  AFAICT, it was all Maven plugins driving our 
compiler and we couldn't get reproducible binaries.

I suggested in one reply that Chris fills a staging repo using his local 
machine just to make sure we know what Maven commands need to be run to 
generate all of the Maven artifacts.   And that would validate the claim that 
it is really doable in two or three steps.  A partial verification of validity 
is to check that the same set of files was produced as in 0.9.6 (there might be 
some new SWCs though).

Then someone else (maybe Carlos) would download all of the artifacts, run the 
same steps, download the new artifacts and verify that the binary match.  Then 
we can work on splitting those steps into chunks for the CI server.

-Alex


On 3/25/20, 10:13 AM, "Carlos Rovira"  wrote:

We imposed ourselves a need to release building with two build systems.
That's the biggest issue and that's a requirement of this PMC.
That's what makes the need of the actual CI steps and the complex and
intricate process.

For the rest of Apache a release is:

"For an *Apache* project, that means any publication outside the
development community, defined as individuals actively participating in
development or following the dev list. More narrowly, an official *Apache
release* is one which has been endorsed as an "act of the Foundation" by a
PMC."

That means that we can release with ANT, with Maven, or any other build
systems as part of the process, and even try what we're doing of trying to
build with n build systems and try to check all is ok with the artifacts
generated by all that build systems and check all of them...but if that's
what we want, I personally will left this wagon, and wish you the best of
lucks in the process.

Chris and I proposed to just use Maven *for release* (so please, I expect
no body starts to say we are throwing away ANT from the project for
building, pleasewe are just discussing release here).

What do you think about to try to release just with Maven? If can do in the
next day or two and get the release published...will that work for you? I
think we don't need anything more, and I'm sure our users will be happy too.

And yes, people wanting then to build with Ant or with Maven will be able
to do so... :-)

Thanks

Carlos


[1] 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Fdev%2Frelease-publishing.html&data=02%7C01%7Caharui%40adobe.com%7C051d4367ac9743249ec808d7d0dfd038%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637207532001774243&sdata=JWLztd6WGtyugYMEzRLqytO41ypZsDYQIdUhaPIMEG4%3D&reserved=0



El mié., 25 mar. 2020 a las 17:46, Christofer Dutz (<
christofer.d...@c-ware.de>) escribió:

> Hi Yiashay,
>
> I agree ... but I didn't create Maven ... haven't even provided a single
> PR to it ;-)
> I think my only noticeable contribution was that they changed their
> website to forbid the usage of "maven-{something}-plugin" to Apache Maven
> Core modules (It initially said Apache Maven Plugins which would have
> applied for maven-flex-plugin and maven-plc4x-plugin)
>
> I think you should focus not on the process, but the bases a process
> should cover.
>
> Focus on what you want to be provided or ensured by any process, no matter
> which tool it is based on.
>
> That's what I created the google doc for.
>
> If you decide to loosen the requirement on sticking 100% to the existing
> process I am more than willing to help.
> However if you stick to the current process, it doesn't make any sense for
> me to do so.
>
> Looking forward to a productive discussion,
>
> Chris
>
>
> Am 25.03.20, 17:36 schrieb "Yishay Weiss" :
>
> I think the focus should be to agree on the requirements. Whether an
> RM uses the tool created by Chris or Alex can be a matter of choice.
>
> From: Carlos Rovira
> Sent: Wednesday, March 25, 2020 5:18 PM
> To: Apache Royale Development
> Subject: Re: Releasing: Finally giving up
>
> Hi,
>
> first of all, many thanks for all the time invested by Chris this
> days. We
> almost didn't have any normal life this latest 2'5 days, but as well
> many
> other work (spliced in many hours in the several previous days) was
> prepared to start this release, so for a person out side this project,
> I
> think we all should thanks a lot his dedications. The good output is
> that
> process was streamlined, removing unneeded params to enter and fixing
> many
> bugs over the

Re: Releasing: Finally giving up

[Carlos Rovira]

We imposed ourselves a need to release building with two build systems.
That's the biggest issue and that's a requirement of this PMC.
That's what makes the need of the actual CI steps and the complex and
intricate process.

For the rest of Apache a release is:

"For an *Apache* project, that means any publication outside the
development community, defined as individuals actively participating in
development or following the dev list. More narrowly, an official *Apache
release* is one which has been endorsed as an "act of the Foundation" by a
PMC."

That means that we can release with ANT, with Maven, or any other build
systems as part of the process, and even try what we're doing of trying to
build with n build systems and try to check all is ok with the artifacts
generated by all that build systems and check all of them...but if that's
what we want, I personally will left this wagon, and wish you the best of
lucks in the process.

Chris and I proposed to just use Maven *for release* (so please, I expect
no body starts to say we are throwing away ANT from the project for
building, pleasewe are just discussing release here).

What do you think about to try to release just with Maven? If can do in the
next day or two and get the release published...will that work for you? I
think we don't need anything more, and I'm sure our users will be happy too.

And yes, people wanting then to build with Ant or with Maven will be able
to do so... :-)

Thanks

Carlos


[1] http://www.apache.org/dev/release-publishing.html



El mié., 25 mar. 2020 a las 17:46, Christofer Dutz (<
christofer.d...@c-ware.de>) escribió:

> Hi Yiashay,
>
> I agree ... but I didn't create Maven ... haven't even provided a single
> PR to it ;-)
> I think my only noticeable contribution was that they changed their
> website to forbid the usage of "maven-{something}-plugin" to Apache Maven
> Core modules (It initially said Apache Maven Plugins which would have
> applied for maven-flex-plugin and maven-plc4x-plugin)
>
> I think you should focus not on the process, but the bases a process
> should cover.
>
> Focus on what you want to be provided or ensured by any process, no matter
> which tool it is based on.
>
> That's what I created the google doc for.
>
> If you decide to loosen the requirement on sticking 100% to the existing
> process I am more than willing to help.
> However if you stick to the current process, it doesn't make any sense for
> me to do so.
>
> Looking forward to a productive discussion,
>
> Chris
>
>
> Am 25.03.20, 17:36 schrieb "Yishay Weiss" :
>
> I think the focus should be to agree on the requirements. Whether an
> RM uses the tool created by Chris or Alex can be a matter of choice.
>
> From: Carlos Rovira
> Sent: Wednesday, March 25, 2020 5:18 PM
> To: Apache Royale Development
> Subject: Re: Releasing: Finally giving up
>
> Hi,
>
> first of all, many thanks for all the time invested by Chris this
> days. We
> almost didn't have any normal life this latest 2'5 days, but as well
> many
> other work (spliced in many hours in the several previous days) was
> prepared to start this release, so for a person out side this project,
> I
> think we all should thanks a lot his dedications. The good output is
> that
> process was streamlined, removing unneeded params to enter and fixing
> many
> bugs over the place. That only can be performed by a good specialist in
> build systems like Chris, I just could be a companion to execute steps
> and
> try to be trained in the process.
>
> About me: I must to say that I tried hard to make this work, but I must
> assume I don't have the skills to do it (what is normal, since if an
> expert
> in build stuff like Chris can't do it, I don't think any other one
> could do
> it, and less me). The good point is that I know I have a great a deep
> knowledge about the overall process, and while in November I could
> envision, something of what I could see this days, now I have a clear
> knowledge of all of it (taking into account that we just go through
> compiler and typedefs and not framework, that could be, due to size, a
> much
> bigger challenge...)
>
> About the process: I must say that the initial intention was so good,
> and I
> think we all want the premise offered thanks to Alex. The reality I
> think
> is defeating the premise, and we should all see the reality with clear
> sight and without worrying about egos but just looking and what the
> project
> need.
>
> Since the CI process involves so many steps, manual commands in CI
> steps,
> and...manual commands in local machine. One of the most annoying
> things is
> the CI server hanging lots of time (the Java agent exits and that
> means you
> must reboot in order the system working all again without problems).
> The
> final problem is 

Re: Releasing: Finally giving up

[Christofer Dutz]

Hi Yiashay,

I agree ... but I didn't create Maven ... haven't even provided a single PR to 
it ;-)
I think my only noticeable contribution was that they changed their website to 
forbid the usage of "maven-{something}-plugin" to Apache Maven Core modules (It 
initially said Apache Maven Plugins which would have applied for 
maven-flex-plugin and maven-plc4x-plugin)

I think you should focus not on the process, but the bases a process should 
cover.

Focus on what you want to be provided or ensured by any process, no matter 
which tool it is based on. 

That's what I created the google doc for.

If you decide to loosen the requirement on sticking 100% to the existing 
process I am more than willing to help.
However if you stick to the current process, it doesn't make any sense for me 
to do so.

Looking forward to a productive discussion,

Chris


Am 25.03.20, 17:36 schrieb "Yishay Weiss" :

I think the focus should be to agree on the requirements. Whether an RM 
uses the tool created by Chris or Alex can be a matter of choice.

From: Carlos Rovira
Sent: Wednesday, March 25, 2020 5:18 PM
To: Apache Royale Development
Subject: Re: Releasing: Finally giving up

Hi,

first of all, many thanks for all the time invested by Chris this days. We
almost didn't have any normal life this latest 2'5 days, but as well many
other work (spliced in many hours in the several previous days) was
prepared to start this release, so for a person out side this project, I
think we all should thanks a lot his dedications. The good output is that
process was streamlined, removing unneeded params to enter and fixing many
bugs over the place. That only can be performed by a good specialist in
build systems like Chris, I just could be a companion to execute steps and
try to be trained in the process.

About me: I must to say that I tried hard to make this work, but I must
assume I don't have the skills to do it (what is normal, since if an expert
in build stuff like Chris can't do it, I don't think any other one could do
it, and less me). The good point is that I know I have a great a deep
knowledge about the overall process, and while in November I could
envision, something of what I could see this days, now I have a clear
knowledge of all of it (taking into account that we just go through
compiler and typedefs and not framework, that could be, due to size, a much
bigger challenge...)

About the process: I must say that the initial intention was so good, and I
think we all want the premise offered thanks to Alex. The reality I think
is defeating the premise, and we should all see the reality with clear
sight and without worrying about egos but just looking and what the project
need.

Since the CI process involves so many steps, manual commands in CI steps,
and...manual commands in local machine. One of the most annoying things is
the CI server hanging lots of time (the Java agent exits and that means you
must reboot in order the system working all again without problems). The
final problem is that you as a RM will fail some times in doing what the
process needs (indicated in emails), and although you are trained a lot in
how to do the project you will found stuck in some situations where you
simple don't know what to do.

(For example I forgot or did a bad step that makes me rollover things in
succeed steps, so I had to roll back versions in the compiler, but since I
was doing a tools release too, I didn't have into account that I need to
roll back versions in tools too. It's clear as Chris notice that, but not
for me at all. So we all should know with this example that the process is
not automatic at all. If just involve 2-3 steps, that would be manageable,
but we are talking of 13 steps with 32 manual steps (until step 7), plus
maybe other 30 or so commands until step 13?)...hope you understand the
challenge here and that is nothing easy for any of us.

What I mean, and my advice, from someone that loves this project and want
it to make it shine: We should try to simple focus in what's important.
Chris is offering a way that ensures release done simple and easily. My
take is that we can't afford to go this way more time, since the project
will see his existence threatened. We're here many years here, and this
actual problem is a big one. It's clear that we have a problem if we can
release every month (or two month) with a process that is easy for everyone
and requires not a great training to do so, and will require some few
commands and operations to be done. We simply can't release, and we can
rely in a process that is so fragile, to make every change we do in the
future will break it.

The fact is that we

RE: Releasing: Finally giving up

[Yishay Weiss]

I think the focus should be to agree on the requirements. Whether an RM uses 
the tool created by Chris or Alex can be a matter of choice.

From: Carlos Rovira
Sent: Wednesday, March 25, 2020 5:18 PM
To: Apache Royale Development
Subject: Re: Releasing: Finally giving up

Hi,

first of all, many thanks for all the time invested by Chris this days. We
almost didn't have any normal life this latest 2'5 days, but as well many
other work (spliced in many hours in the several previous days) was
prepared to start this release, so for a person out side this project, I
think we all should thanks a lot his dedications. The good output is that
process was streamlined, removing unneeded params to enter and fixing many
bugs over the place. That only can be performed by a good specialist in
build systems like Chris, I just could be a companion to execute steps and
try to be trained in the process.

About me: I must to say that I tried hard to make this work, but I must
assume I don't have the skills to do it (what is normal, since if an expert
in build stuff like Chris can't do it, I don't think any other one could do
it, and less me). The good point is that I know I have a great a deep
knowledge about the overall process, and while in November I could
envision, something of what I could see this days, now I have a clear
knowledge of all of it (taking into account that we just go through
compiler and typedefs and not framework, that could be, due to size, a much
bigger challenge...)

About the process: I must say that the initial intention was so good, and I
think we all want the premise offered thanks to Alex. The reality I think
is defeating the premise, and we should all see the reality with clear
sight and without worrying about egos but just looking and what the project
need.

Since the CI process involves so many steps, manual commands in CI steps,
and...manual commands in local machine. One of the most annoying things is
the CI server hanging lots of time (the Java agent exits and that means you
must reboot in order the system working all again without problems). The
final problem is that you as a RM will fail some times in doing what the
process needs (indicated in emails), and although you are trained a lot in
how to do the project you will found stuck in some situations where you
simple don't know what to do.

(For example I forgot or did a bad step that makes me rollover things in
succeed steps, so I had to roll back versions in the compiler, but since I
was doing a tools release too, I didn't have into account that I need to
roll back versions in tools too. It's clear as Chris notice that, but not
for me at all. So we all should know with this example that the process is
not automatic at all. If just involve 2-3 steps, that would be manageable,
but we are talking of 13 steps with 32 manual steps (until step 7), plus
maybe other 30 or so commands until step 13?)...hope you understand the
challenge here and that is nothing easy for any of us.

What I mean, and my advice, from someone that loves this project and want
it to make it shine: We should try to simple focus in what's important.
Chris is offering a way that ensures release done simple and easily. My
take is that we can't afford to go this way more time, since the project
will see his existence threatened. We're here many years here, and this
actual problem is a big one. It's clear that we have a problem if we can
release every month (or two month) with a process that is easy for everyone
and requires not a great training to do so, and will require some few
commands and operations to be done. We simply can't release, and we can
rely in a process that is so fragile, to make every change we do in the
future will break it.

The fact is that we didn't get so many people jumping to Royale and the
ones with an eye on this project can finally gone if we continue trying to
force things that we don't need. We can release just with maven in few
steps, that's a fact, and we don't really need to make things in the actual
way. If we do is because we're forcing it, but nobody cares, and my vision
is that will cost the project.

We simplify the build Maven process to make it more reliable, that break
the release process in November. The build process has priority over the
release process, since lots of users depend on them (royale devs, and
users). The release process is important in the project context to offer
the bits to the public as a tag or point in time.

We simply can't put the release process to the service of the build process
and make all of that stop in time to not break a fragile release process.
That's not an option for an open source project. The release process is at
the service of the rest (people, builds, code)

I'd want people here to rethink all of this since:


   - We can't afford this project not to release easily monthly (or every 2
   months) for anyone here (and I mean all peo

Re: Releasing: Finally giving up

[OmPrakash Muppirala]

>
>
>
>
> We are passing in the timestamp (slightly different format, however still
> correct as we also adjusted the format-string). When building locally, the
> timestamp is exactly as the timestamp string tells the compiler. On the CI
> however there’s this 60 minute offset. I have explicitly set the time-zone
> wherever I found time-zone relevant code to UTC (Which is the general best
> practice for date stuff). However the offset didn’t change. So I am
> completely out of ideas what could be causing this. If it really is the
> Summertime in the US, well I don’t know how to fix it (perhaps setup a rule
> to not release in this time).
>

Thanks for all the hard work.  It is really appreciated!
Dumb question - have you tried setting the computer date/time manually on
the server to match what you have?  Just see if the problem goes away?

Thanks,
Om

Re: Releasing: Finally giving up

[Carlos Rovira]

Hi,

first of all, many thanks for all the time invested by Chris this days. We
almost didn't have any normal life this latest 2'5 days, but as well many
other work (spliced in many hours in the several previous days) was
prepared to start this release, so for a person out side this project, I
think we all should thanks a lot his dedications. The good output is that
process was streamlined, removing unneeded params to enter and fixing many
bugs over the place. That only can be performed by a good specialist in
build systems like Chris, I just could be a companion to execute steps and
try to be trained in the process.

About me: I must to say that I tried hard to make this work, but I must
assume I don't have the skills to do it (what is normal, since if an expert
in build stuff like Chris can't do it, I don't think any other one could do
it, and less me). The good point is that I know I have a great a deep
knowledge about the overall process, and while in November I could
envision, something of what I could see this days, now I have a clear
knowledge of all of it (taking into account that we just go through
compiler and typedefs and not framework, that could be, due to size, a much
bigger challenge...)

About the process: I must say that the initial intention was so good, and I
think we all want the premise offered thanks to Alex. The reality I think
is defeating the premise, and we should all see the reality with clear
sight and without worrying about egos but just looking and what the project
need.

Since the CI process involves so many steps, manual commands in CI steps,
and...manual commands in local machine. One of the most annoying things is
the CI server hanging lots of time (the Java agent exits and that means you
must reboot in order the system working all again without problems). The
final problem is that you as a RM will fail some times in doing what the
process needs (indicated in emails), and although you are trained a lot in
how to do the project you will found stuck in some situations where you
simple don't know what to do.

(For example I forgot or did a bad step that makes me rollover things in
succeed steps, so I had to roll back versions in the compiler, but since I
was doing a tools release too, I didn't have into account that I need to
roll back versions in tools too. It's clear as Chris notice that, but not
for me at all. So we all should know with this example that the process is
not automatic at all. If just involve 2-3 steps, that would be manageable,
but we are talking of 13 steps with 32 manual steps (until step 7), plus
maybe other 30 or so commands until step 13?)...hope you understand the
challenge here and that is nothing easy for any of us.

What I mean, and my advice, from someone that loves this project and want
it to make it shine: We should try to simple focus in what's important.
Chris is offering a way that ensures release done simple and easily. My
take is that we can't afford to go this way more time, since the project
will see his existence threatened. We're here many years here, and this
actual problem is a big one. It's clear that we have a problem if we can
release every month (or two month) with a process that is easy for everyone
and requires not a great training to do so, and will require some few
commands and operations to be done. We simply can't release, and we can
rely in a process that is so fragile, to make every change we do in the
future will break it.

The fact is that we didn't get so many people jumping to Royale and the
ones with an eye on this project can finally gone if we continue trying to
force things that we don't need. We can release just with maven in few
steps, that's a fact, and we don't really need to make things in the actual
way. If we do is because we're forcing it, but nobody cares, and my vision
is that will cost the project.

We simplify the build Maven process to make it more reliable, that break
the release process in November. The build process has priority over the
release process, since lots of users depend on them (royale devs, and
users). The release process is important in the project context to offer
the bits to the public as a tag or point in time.

We simply can't put the release process to the service of the build process
and make all of that stop in time to not break a fragile release process.
That's not an option for an open source project. The release process is at
the service of the rest (people, builds, code)

I'd want people here to rethink all of this since:


   - We can't afford this project not to release easily monthly (or every 2
   months) for anyone here (and I mean all people here that wants to be an RM).
   - We can't afford so many hours invested to release, or to maintain a
   process that is very, very, very difficult to operate, fragile and easy to
   break.


The motivations are:


   1. Although the process was designed and done with very good intentions,
   the final product does not match the

Jenkins build is back to normal : royale-typedefs #456

[apacheroyaleci]

See 

Releasing: Finally giving up

[Christofer Dutz]

Hi all,

after 3-4 days of some times 10-16 hours of working on getting the “process” 
running, I’m finally giving up.
We managed to fix a lot of issues in the way the steps were setup and managed 
to get to step 7 however there’s no getting past that.

The problem are the reproducible builds.

While for the java part I think we have all bases covered, however I can’t see 
however how I can fix the compiler to actually produce reproducible builds.

We are passing in the timestamp (slightly different format, however still 
correct as we also adjusted the format-string). When building locally, the 
timestamp is exactly as the timestamp string tells the compiler. On the CI 
however there’s this 60 minute offset. I have explicitly set the time-zone 
wherever I found time-zone relevant code to UTC (Which is the general best 
practice for date stuff). However the offset didn’t change. So I am completely 
out of ideas what could be causing this. If it really is the Summertime in the 
US, well I don’t know how to fix it (perhaps setup a rule to not release in 
this time).

Besides that, there are still differences in the library SWF:

  *   As I mentioned yesterday, the node typedef contains a “net” object 
definition in the local build and a “http” one on the CI server version.
  *   In other modules it’s simply the order of items generated. I guess it’s a 
similar issue as the one I fixed in the build-tools, but I have no idea how to 
fix it in the compiler

So in the end I’m giving up … I think the “process” is now way more stable than 
before, but it’s still a really fragile construct. Today Greg, Carlos and I did 
it together via Zoom and still we had to re-do some steps because one little 
preparation was missed.

I would strongly doubt that the reproducible builds really built globally 
reproducible builds in the past … perhaps it worked in a narrow corridor of 
time-zones and OS/Java versions (I did use java 1.8), but I simply can’t 
believe it ever was 100% reproducible.

So as long as this reproducibility is a requirement, I guess we’re done. I do 
understand what it’s used for in this context, however I think it’s just not 
working.

The other option would be to simply release with maven, which would have been a 
1-2 hour experience for all modules.

I do agree that if the steps work and all preconditions would be checked (which 
they currently are not) it is very easy to break the “process”. And it involves 
running 13 jobs … but as far as I got it also the execution of 32 manual 
commands for everything till step 7
4 + 6 + 3 + 3 + 3 + 4 + 2 + 3 + 3 = 32

So as long as we’re forced to stick to this process … I guess someone else will 
have to do it.

Please feel free to revert any changes I did in the last few months.

Signing off,
Chris

PS: You really should make this ApacheRoyaleCI guy a committer considering the 
amount of emails he’s writing ;-)

Build failed in Jenkins: royale-typedefs #455

[apacheroyaleci]

See 


Changes:

[carlosrovira] [maven-release-plugin] prepare branch @{releaseLabel}

[carlosrovira] [maven-release-plugin] prepare for next development iteration

[carlosrovira] reset versions

[carlosrovira] [maven-release-plugin] prepare branch @{releaseLabel}

[carlosrovira] [maven-release-plugin] prepare for next development iteration


--
Started by an SCM change
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on agent1 in workspace 

No credentials specified
 > C:\Program Files\Git\cmd\git.exe rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > C:\Program Files\Git\cmd\git.exe config remote.origin.url 
 > https://github.com/apache/royale-typedefs # timeout=10
Fetching upstream changes from https://github.com/apache/royale-typedefs
 > C:\Program Files\Git\cmd\git.exe --version # timeout=10
 > C:\Program Files\Git\cmd\git.exe fetch --tags --force --progress -- 
 > https://github.com/apache/royale-typedefs +refs/heads/*:refs/remotes/origin/*
 > C:\Program Files\Git\cmd\git.exe rev-parse 
 > "refs/remotes/origin/develop^{commit}" # timeout=10
 > C:\Program Files\Git\cmd\git.exe rev-parse 
 > "refs/remotes/origin/origin/develop^{commit}" # timeout=10
Checking out Revision 523fa3db7e1b316453f5cc2af6a9ca0db56c6b32 
(refs/remotes/origin/develop)
 > C:\Program Files\Git\cmd\git.exe config core.sparsecheckout # timeout=10
 > C:\Program Files\Git\cmd\git.exe checkout -f 
 > 523fa3db7e1b316453f5cc2af6a9ca0db56c6b32
Commit message: "[maven-release-plugin] prepare for next development iteration"
 > C:\Program Files\Git\cmd\git.exe rev-list --no-walk 
 > 9ddcb4c6979911289c96adcad7e92b4c7ebb9e57 # timeout=10
[royale-typedefs] $ cmd.exe /C "C:\apache\apache-ant-1.9.9\bin\ant.bat 
-Dbuild.number=455 main && exit %%ERRORLEVEL%%"
Buildfile: 


main:
 [echo] swc-date is 03/25/20 10:04 +

download:
 [echo] 


BUILD FAILED
:58:
 The following error occurred while executing this line:
:91:
 src 
'
 doesn't exist.

Total time: 0 seconds
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m -Xmx2g
Build step 'Invoke Ant' marked build as failure

Release Step 007 Succeeded

[apacheroyaleci]

>From the royale-typedefs repo:
1. Run ant -f releasesteps.xml Release_Step_007 -Drelease.version=0.9.7 
-DskipTests=true
This will download the artifacts then unzip and compile the source artifact.
2. Validate that the compiled artifacts match the downloaded artifacts.
3. If they do, then run ant -f releasesteps.xml Release_Step_007_Sign 
-Drelease.version=0.9.7
This will PGP sign the source ZIP and compiled JARs
4. Then run ant -f releasesteps.xml Release_Step_007_Upload 
-Drelease.version=0.9.7
This will upload the signed artifacts to Maven Release Staging. Do not "Close" 
the staging repository until the other repos have been added.

Release Step 006 Succeeded

[apacheroyaleci]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_006 and run the following commands:
git push
git push origin org.apache.royale.typedefs-0.9.7-rc1

You will need your Apache/Github username and 2FA token.

Release Step 005a Succeeded

[apacheroyaleci]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_005a_If_Utils and run
the following commands:
git push

You will need your Apache/Github username and 2FA token.

Release Step 005 Succeeded

[apacheroyaleci]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_005 and run the
following commands:
git push

You will need your Apache/Github username and 2FA token.

Release Step 004 Succeeded

[apacheroyaleci]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_004 and run the following commands:
git push
git checkout release/0.9.7
git push -u origin release/0.9.7

You will need your Apache/Github username and 2FA token.

Release Step 007 Succeeded

[apacheroyaleci]

>From the royale-typedefs repo:
1. Run ant -f releasesteps.xml Release_Step_007 -Drelease.version=0.9.7 
-DskipTests=true
This will download the artifacts then unzip and compile the source artifact.
2. Validate that the compiled artifacts match the downloaded artifacts.
3. If they do, then run ant -f releasesteps.xml Release_Step_007_Sign 
-Drelease.version=0.9.7
This will PGP sign the source ZIP and compiled JARs
4. Then run ant -f releasesteps.xml Release_Step_007_Upload 
-Drelease.version=0.9.7
This will upload the signed artifacts to Maven Release Staging. Do not "Close" 
the staging repository until the other repos have been added.

Release Step 006 Succeeded

[apacheroyaleci]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_006 and run the following commands:
git push
git push origin org.apache.royale.typedefs-0.9.7-rc1

You will need your Apache/Github username and 2FA token.

Release Step 005a Succeeded

[apacheroyaleci]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_005a_If_Utils and run
the following commands:
git push

You will need your Apache/Github username and 2FA token.

Release Step 005 Succeeded

[apacheroyaleci]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_005 and run the
following commands:
git push

You will need your Apache/Github username and 2FA token.

Royale_Release_Step_005 - Build # 10 - Still Failing!

[apacheroyaleci]

Royale_Release_Step_005 - Build # 10 - Still Failing:

Check console output at 
http://apacheroyaleci2.westus2.cloudapp.azure.com:8080/job/Royale_Release_Step_005/10/
 to view the results.

Royale_Release_Step_005 - Build # 9 - Still Failing!

[apacheroyaleci]

Royale_Release_Step_005 - Build # 9 - Still Failing:

Check console output at 
http://apacheroyaleci2.westus2.cloudapp.azure.com:8080/job/Royale_Release_Step_005/9/
 to view the results.

Royale_Release_Step_005 - Build # 8 - Still Failing!

[apacheroyaleci]

Royale_Release_Step_005 - Build # 8 - Still Failing:

Check console output at 
http://apacheroyaleci2.westus2.cloudapp.azure.com:8080/job/Royale_Release_Step_005/8/
 to view the results.

Royale_Release_Step_005 - Build # 7 - Still Failing!

[apacheroyaleci]

Royale_Release_Step_005 - Build # 7 - Still Failing:

Check console output at 
http://apacheroyaleci2.westus2.cloudapp.azure.com:8080/job/Royale_Release_Step_005/7/
 to view the results.

Royale_Release_Step_005 - Build # 6 - Failure!

[apacheroyaleci]

Royale_Release_Step_005 - Build # 6 - Failure:

Check console output at 
http://apacheroyaleci2.westus2.cloudapp.azure.com:8080/job/Royale_Release_Step_005/6/
 to view the results.

Release Step 004 Succeeded

[apacheroyaleci]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_004 and run the following commands:
git push
git checkout release/0.9.7
git push -u origin release/0.9.7

You will need your Apache/Github username and 2FA token.

Release Step 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. If you are releasing the utils jars (compiler-jburg-types and 
compiler-build-tools) - you have set in previous step for mentioned projects 
version ex. 1.1.0 not snapshot, run:
  ant -f releasesteps.xml Release_Step_003 -Dutils=true -Drelease.version=0.9.7 
-DskipTests=true
Otherwise, run:
  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.7
This will download the artifacts then unzip and compile the source artifact.
2. Validate that the compiled artifacts match the downloaded artifacts.
3. If they do, then run ant -f releasesteps.xml Release_Step_003_Sign 
-Drelease.version=0.9.7
This will PGP sign the source ZIP and compiled JARs
4. Then run ant -f releasesteps.xml Release_Step_003_Upload 
-Drelease.version=0.9.7
This will upload the signed artifacts to Maven Release Staging. If you are 
getting 401 responses from Nexus (permission denied) please be sure to have 
your apache creedentials configured in your .m2/settings.xml file. 

Feel free to use this template if you haven't got a settings.xml yet:


http://maven.apache.org/SETTINGS/1.1.0 
http://maven.apache.org/xsd/settings-1.1.0.xsd"; 
xmlns="http://maven.apache.org/SETTINGS/1.1.0";
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
  


  apache.releases.https
  {your apache user id}
  {your apache user password}

  


(Be sure to replace the placeholders with your actual apache committer id and 
your Apache password)

If you already have a settings.xml, just be sure the "server" block containing 
your credentials is added to a servers block in that file.

Do not "Close" the staging repository until the other repos have been added.

Release Step 002a Succeeded

[apacheroyaleci]

Continue on to Release Step 003

Release Step 002 Succeeded

[apacheroyaleci]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_002 and run the following commands:
git push
git push origin org.apache.royale.compiler-0.9.7-rc1

You will need your Apache/Github username and 2FA token.

Release Step 001a Succeeded

[apacheroyaleci]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_001a_If_Utils and run the following 
commands:

(Push the local changes to develop)
git push origin develop
(Get the commit id of the last change (The output is considered COMMIT_ID))
git log --format="%H" -n 1
(Switch to the release branch)
git checkout release/0.9.7
(Cherry-Pick the last change to develop to the release branch)
git cherry-pick {COMMIT_ID}
(Push the changes to the release branch)
git push origin release/0.9.7

You will need your Apache/Github username and 2FA token.

Release Step 001 Succeeded

[apacheroyaleci]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_001 and run the following commands:
git push
git checkout release/0.9.7
git push -u origin release/0.9.7

You will need your Apache/Github username and 2FA token.