Release Step 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. Run:
  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.9
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.9
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.9
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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. Run:
  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.9
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.9
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.9
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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. Run:
  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.9
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.9
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.9
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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. Run:
  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.9
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.9
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.9
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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. Run:
  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.9
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.9
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.9
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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. Run:
  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
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.8
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.8
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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. Run:
  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
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.8
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.8
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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. Run:
  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
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.8
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.8
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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. Run:
  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
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.8
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.8
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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. Run:
  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
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.8
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.8
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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. Run:
  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
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.8
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.8
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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. Run:
  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
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.8
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.8
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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. Run:
  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
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.8
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.8
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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. Run:
  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
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.8
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.8
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.

Re: Release Step 003 Succeeded

[Alex Harui]

Maybe try explicitly listing the profiles like Step 002 does.

HTH,
-Alex

On 12/8/20, 12:39 AM, "Harbs"  wrote:

Here’s what I get when running mvn -v:

Most recent machine:

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\Program Files\apache-maven-3.6.3\bin\..
Java version: 1.8.0_131, vendor: Oracle Corporation, runtime: C:\Program 
Files\Java\jdk1.8.0_131\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

CI server:

Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T18:41:47Z)
Maven home: C:\apache\apache-maven-3.6.0\bin\..
Java version: 1.8.0_201, vendor: Oracle Corporation, runtime: C:\Program 
Files\Java\jdk1.8.0_201\jre
Default locale: en_US, platform encoding: UTF-8
OS name: "windows server 2016", version: "10.0", arch: "amd64", family: 
"windows"


> On Dec 8, 2020, at 10:01 AM, Alex Harui  wrote:
> 
> Are all machines running the same version of Maven and Java?
> 
> Flex-compiler-oem is the Flash Builder integration jar.
> 
> HTH,
> -Alex
> 
> On 12/7/20, 2:53 AM, "Harbs" mailto:harbs.li...@gmail.com>> wrote:
> 
>I’m having a very hard time getting getting the jars to match 
perfectly.
> 
>When building on Windows I get consistent line breaks, so that’s a 
work-around, but I’m having the following issues when comparing jars:
> 
>1. On one Windows machine, I believe file dates matched, but on a 
second machine they didn’t.
>2. On my build I’m getting dependencies on - playerglobal  
com.adobe.flash.framework:playerglobal:swc:20. I noticed this in both 
flex-compiler-oem and compiler-jx.
> 
>I don’t know what flex-compiler-oem does. In the case of compiler-jx, 
that dependency does not seem correct. So the CI build seems to be right, but 
my local build seems wrong.
> 
>Maven is black magic to me, and I have no idea how to go about making 
this work.
> 
> 
>> On Dec 4, 2020, at 12:31 PM, Christofer Dutz  
wrote:
>> 
>> Hi Harbs,
>> 
>> Well I would assume that on the CI it was not built with “with-swf” 
option.
>> Theoretically the archives generated should be identical in the compiler 
module with or without swf, it’s just that “with-swf” turns on all Flash 
released tests and therefore needs a dependency to the playerglobal.
>> 
>> Chris
>> 
>> 
>> 
>> Von: Harbs 
>> Datum: Freitag, 4. Dezember 2020 um 11:18
>> An: dev@royale.apache.org 
>> Betreff: Re: Release Step 003 Succeeded
>> OK. Progress.
>> 
>> I got reproducible build of two jars, but I’m getting a failure on 
flex-compiler-oem.
>> 
>> My build has this in the DEPENDENCIES file which is missing in the CI 
build:
>> 
>> - playerglobal  com.adobe.flash.framework:playerglobal:swc:20.0
>> 
>> Any clues as to why?
>> 
>>> On Nov 26, 2020, at 9:16 PM, apacheroyal...@gmail.com wrote:
>>> 
>>> From the royale-compiler repo:
>>> 1. Run:
>>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
>>> 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.8
>>> 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.8
>>> 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:
>>> 
>>> 
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmaven.apache.org%2FSETTINGS%2F1.1.0data=04%7C01%7Caharui%40adobe.com%7Cae19cf6500984c8fcf2308d89b54cce0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637430135805592907%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=9k9c%2BEw62lsX%2BJrI2ZIGr57tmXDmQNVpGDKW3EhA9l8%3Dreserved=0
 
<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%

Re: Release Step 003 Succeeded

[Harbs]

Here’s what I get when running mvn -v:

Most recent machine:

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\Program Files\apache-maven-3.6.3\bin\..
Java version: 1.8.0_131, vendor: Oracle Corporation, runtime: C:\Program 
Files\Java\jdk1.8.0_131\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

CI server:

Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T18:41:47Z)
Maven home: C:\apache\apache-maven-3.6.0\bin\..
Java version: 1.8.0_201, vendor: Oracle Corporation, runtime: C:\Program 
Files\Java\jdk1.8.0_201\jre
Default locale: en_US, platform encoding: UTF-8
OS name: "windows server 2016", version: "10.0", arch: "amd64", family: 
"windows"


> On Dec 8, 2020, at 10:01 AM, Alex Harui  wrote:
> 
> Are all machines running the same version of Maven and Java?
> 
> Flex-compiler-oem is the Flash Builder integration jar.
> 
> HTH,
> -Alex
> 
> On 12/7/20, 2:53 AM, "Harbs"  <mailto:harbs.li...@gmail.com>> wrote:
> 
>I’m having a very hard time getting getting the jars to match perfectly.
> 
>When building on Windows I get consistent line breaks, so that’s a 
> work-around, but I’m having the following issues when comparing jars:
> 
>1. On one Windows machine, I believe file dates matched, but on a second 
> machine they didn’t.
>2. On my build I’m getting dependencies on - playerglobal  
> com.adobe.flash.framework:playerglobal:swc:20. I noticed this in both 
> flex-compiler-oem and compiler-jx.
> 
>I don’t know what flex-compiler-oem does. In the case of compiler-jx, that 
> dependency does not seem correct. So the CI build seems to be right, but my 
> local build seems wrong.
> 
>Maven is black magic to me, and I have no idea how to go about making this 
> work.
> 
> 
>> On Dec 4, 2020, at 12:31 PM, Christofer Dutz  
>> wrote:
>> 
>> Hi Harbs,
>> 
>> Well I would assume that on the CI it was not built with “with-swf” option.
>> Theoretically the archives generated should be identical in the compiler 
>> module with or without swf, it’s just that “with-swf” turns on all Flash 
>> released tests and therefore needs a dependency to the playerglobal.
>> 
>> Chris
>> 
>> 
>> 
>> Von: Harbs 
>> Datum: Freitag, 4. Dezember 2020 um 11:18
>> An: dev@royale.apache.org 
>> Betreff: Re: Release Step 003 Succeeded
>> OK. Progress.
>> 
>> I got reproducible build of two jars, but I’m getting a failure on 
>> flex-compiler-oem.
>> 
>> My build has this in the DEPENDENCIES file which is missing in the CI build:
>> 
>> - playerglobal  com.adobe.flash.framework:playerglobal:swc:20.0
>> 
>> Any clues as to why?
>> 
>>> On Nov 26, 2020, at 9:16 PM, apacheroyal...@gmail.com wrote:
>>> 
>>> From the royale-compiler repo:
>>> 1. Run:
>>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
>>> 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.8
>>> 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.8
>>> 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:
>>> 
>>> 
>>> >> xsi:schemaLocation="https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmaven.apache.org%2FSETTINGS%2F1.1.0data=04%7C01%7Caharui%40adobe.com%7C95a84d47f29f4bb1887808d89a9e4200%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637429351792288452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=a1y5qdOfgp3yPUNc2pRIGsz%2BM8G6p5KsKcT0rDwzZNk%3Dreserved=0
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmaven.apache.org%2FSETTINGS%2F1.1.0data=04%7C01%7Caharui%40adobe.com%7C95a84d47f29f4bb1887808d89a9e4200%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637429351792288452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi

Re: Release Step 003 Succeeded

[Harbs]

I’m having a very hard time getting getting the jars to match perfectly.

When building on Windows I get consistent line breaks, so that’s a work-around, 
but I’m having the following issues when comparing jars:

1. On one Windows machine, I believe file dates matched, but on a second 
machine they didn’t.
2. On my build I’m getting dependencies on - playerglobal  
com.adobe.flash.framework:playerglobal:swc:20. I noticed this in both 
flex-compiler-oem and compiler-jx.

I don’t know what flex-compiler-oem does. In the case of compiler-jx, that 
dependency does not seem correct. So the CI build seems to be right, but my 
local build seems wrong.

Maven is black magic to me, and I have no idea how to go about making this work.


> On Dec 4, 2020, at 12:31 PM, Christofer Dutz  
> wrote:
> 
> Hi Harbs,
> 
> Well I would assume that on the CI it was not built with “with-swf” option.
> Theoretically the archives generated should be identical in the compiler 
> module with or without swf, it’s just that “with-swf” turns on all Flash 
> released tests and therefore needs a dependency to the playerglobal.
> 
> Chris
> 
> 
> 
> Von: Harbs 
> Datum: Freitag, 4. Dezember 2020 um 11:18
> An: dev@royale.apache.org 
> Betreff: Re: Release Step 003 Succeeded
> OK. Progress.
> 
> I got reproducible build of two jars, but I’m getting a failure on 
> flex-compiler-oem.
> 
> My build has this in the DEPENDENCIES file which is missing in the CI build:
> 
>  - playerglobal  com.adobe.flash.framework:playerglobal:swc:20.0
> 
> Any clues as to why?
> 
>> On Nov 26, 2020, at 9:16 PM, apacheroyal...@gmail.com wrote:
>> 
>> From the royale-compiler repo:
>> 1. Run:
>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
>> 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.8
>> 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.8
>> 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.

AW: Release Step 003 Succeeded

[Christofer Dutz]

Hi Harbs,

Well I would assume that on the CI it was not built with “with-swf” option.
Theoretically the archives generated should be identical in the compiler module 
with or without swf, it’s just that “with-swf” turns on all Flash released 
tests and therefore needs a dependency to the playerglobal.

Chris



Von: Harbs 
Datum: Freitag, 4. Dezember 2020 um 11:18
An: dev@royale.apache.org 
Betreff: Re: Release Step 003 Succeeded
OK. Progress.

I got reproducible build of two jars, but I’m getting a failure on 
flex-compiler-oem.

My build has this in the DEPENDENCIES file which is missing in the CI build:

  - playerglobal  com.adobe.flash.framework:playerglobal:swc:20.0

Any clues as to why?

> On Nov 26, 2020, at 9:16 PM, apacheroyal...@gmail.com wrote:
>
> From the royale-compiler repo:
> 1. Run:
>  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
> 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.8
> 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.8
> 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.

Re: Release Step 003 Succeeded

[Harbs]

OK. Progress.

I got reproducible build of two jars, but I’m getting a failure on 
flex-compiler-oem.

My build has this in the DEPENDENCIES file which is missing in the CI build:

  - playerglobal  com.adobe.flash.framework:playerglobal:swc:20.0

Any clues as to why?

> On Nov 26, 2020, at 9:16 PM, apacheroyal...@gmail.com wrote:
> 
> From the royale-compiler repo:
> 1. Run:
>  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
> 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.8
> 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.8
> 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.

Re: Release Step 003 Succeeded

[Carlos Rovira]

Hi,

I think we should need some way to talk to Adobe and expose the problem. I
understand they need to close the FP line, but things like playerglobal.swc
doesn't do any harm and removing it will just generate problems from their
side.


El vie, 4 dic 2020 a las 11:05, Christofer Dutz ()
escribió:

> I really wonder what will happen, if Adobe took the playerglobals offline.
> I guess after the Flashplayer being gone soon, they would obviously take
> the download-pages offline too.
> As the mavenizer component, which was causing your pain will then not be
> able to do its work anymore.
>
> In that case we’ll have real problems with being able to do a full build
> on new machines.
>
> Chris
>
>
> Von: Harbs 
> Datum: Freitag, 4. Dezember 2020 um 10:27
> An: Apache Royale Development 
> Betreff: Re: Release Step 003 Succeeded
> In running the script on Windows I ran into the same Flash problem.
>
> It seems like I you need to run mvn clean install -Poption-with-swf at
> least once.
>
> I was missing the option-with-swf before...
>
> > On Dec 3, 2020, at 8:00 PM, Alex Harui  wrote:
> >
> > Cross-platform reproducible binaries worked with the zlika plugin
> otherwise we couldn't have verified prior releases.  Then we switched to
> the Maven reproducibility features and it seemed to work in tests but
> apparently not in reality.  It might be that the release steps are not
> triggering the Maven reproducibility features correctly.   It should be
> possible to go back to the zlika plugin.  IIRC, it had a feature to support
> line endings.
> >
> > -Alex
> >
> > On 12/3/20, 9:43 AM, "Harbs"  harbs.li...@gmail.com>> wrote:
> >
> >Yes. I’ll probably finish the release on a Windows machine.
> >
> >After the release is done, we can figure out a plan for
> cross-platform releases.
> >
> >I’d also like to use what I’ve learned from this release to setup
> another CI instance on AWS (which I’m more familiar with than Azure).
> >
> >> On Dec 3, 2020, at 12:28 PM, Christofer Dutz 
> wrote:
> >>
> >> Hi all,
> >>
> >> so Harbs sent me the version built on his machine and one of the
> release.
> >> When doing the “compare archives” in IntelliJ is showed that the
> maven-plugin had differences in the line separators in the resources
> generated by the maven-plugin-plugin and by the maven- jar-plugin
> (pom.properties)
> >>
> >> Unfortunately I have tried several times to use settings like
> “-Dline.separator='\n'” in builds, unfortunately a lot of plugins seem to
> not like this setting. I particularly remember the plugins for antlr2, 3
> and 4 don’t really like taking control of the line.separators.
> >>
> >> So right now, an “easy fix” would be to only do releases on Windows
> machines. But I know that’s not a great solution.
> >>
> >> Chris
> >>
> >>
> >>
> >>
> >> Von: Alex Harui 
> >> Datum: Mittwoch, 2. Dezember 2020 um 20:29
> >> An: dev@royale.apache.org 
> >> Betreff: Re: Release Step 003 Succeeded
> >> A Jar is a zip.  Check the dates of the .class files that are zipped
> into the jar.  We are using a tool that should set the dates correctly, but
> maybe it isn't working.
> >>
> >> On 12/2/20, 11:12 AM, "Harbs"  wrote:
> >>
> >>   I uninstalled from HomeBrew and installed Maven manually. I’m now
> getting 1.8.
> >>
> >>   The script thinks the binaries don’t match, but unzipping them and
> using Meld shows that they do have a binary match.
> >>
> >>   I’m getting close.
> >>
> >>> On Dec 2, 2020, at 5:51 PM, Carlos Rovira 
> wrote:
> >>>
> >>> Hi Harbs,
> >>>
> >>> I installed Maven and Java with home brew and don't have JDK 13. So
> don't
> >>> see a relationship. It's clear that maven requires Java since it is
> done in
> >>> java, but I think the version is not a problem. I think better install
> Java
> >>> (the sdk version you want) and then maven, so it takes that. Did you
> check
> >>> Jenv as I told you? You can have different Java versions, one for
> general
> >>> use, and then you can have a concrete version for a concrete folder.
> For
> >>> example. I have an old product that use JDK 7,and I use jenv to
> configure
> >>> that Java7 for that folder ensuring  the product use Java 7
> >>>
> >>> HTH
> >>>
> >>> Carlos
> >>>
> >>>
> >>> El mié, 2 d

AW: Release Step 003 Succeeded

[Christofer Dutz]

I really wonder what will happen, if Adobe took the playerglobals offline.
I guess after the Flashplayer being gone soon, they would obviously take the 
download-pages offline too.
As the mavenizer component, which was causing your pain will then not be able 
to do its work anymore.

In that case we’ll have real problems with being able to do a full build on new 
machines.

Chris


Von: Harbs 
Datum: Freitag, 4. Dezember 2020 um 10:27
An: Apache Royale Development 
Betreff: Re: Release Step 003 Succeeded
In running the script on Windows I ran into the same Flash problem.

It seems like I you need to run mvn clean install -Poption-with-swf at least 
once.

I was missing the option-with-swf before...

> On Dec 3, 2020, at 8:00 PM, Alex Harui  wrote:
>
> Cross-platform reproducible binaries worked with the zlika plugin otherwise 
> we couldn't have verified prior releases.  Then we switched to the Maven 
> reproducibility features and it seemed to work in tests but apparently not in 
> reality.  It might be that the release steps are not triggering the Maven 
> reproducibility features correctly.   It should be possible to go back to the 
> zlika plugin.  IIRC, it had a feature to support line endings.
>
> -Alex
>
> On 12/3/20, 9:43 AM, "Harbs"  <mailto:harbs.li...@gmail.com>> wrote:
>
>Yes. I’ll probably finish the release on a Windows machine.
>
>After the release is done, we can figure out a plan for cross-platform 
> releases.
>
>I’d also like to use what I’ve learned from this release to setup another 
> CI instance on AWS (which I’m more familiar with than Azure).
>
>> On Dec 3, 2020, at 12:28 PM, Christofer Dutz  
>> wrote:
>>
>> Hi all,
>>
>> so Harbs sent me the version built on his machine and one of the release.
>> When doing the “compare archives” in IntelliJ is showed that the 
>> maven-plugin had differences in the line separators in the resources 
>> generated by the maven-plugin-plugin and by the maven- jar-plugin 
>> (pom.properties)
>>
>> Unfortunately I have tried several times to use settings like 
>> “-Dline.separator='\n'” in builds, unfortunately a lot of plugins seem to 
>> not like this setting. I particularly remember the plugins for antlr2, 3 and 
>> 4 don’t really like taking control of the line.separators.
>>
>> So right now, an “easy fix” would be to only do releases on Windows 
>> machines. But I know that’s not a great solution.
>>
>> Chris
>>
>>
>>
>>
>> Von: Alex Harui 
>> Datum: Mittwoch, 2. Dezember 2020 um 20:29
>> An: dev@royale.apache.org 
>> Betreff: Re: Release Step 003 Succeeded
>> A Jar is a zip.  Check the dates of the .class files that are zipped into 
>> the jar.  We are using a tool that should set the dates correctly, but maybe 
>> it isn't working.
>>
>> On 12/2/20, 11:12 AM, "Harbs"  wrote:
>>
>>   I uninstalled from HomeBrew and installed Maven manually. I’m now getting 
>> 1.8.
>>
>>   The script thinks the binaries don’t match, but unzipping them and using 
>> Meld shows that they do have a binary match.
>>
>>   I’m getting close.
>>
>>> On Dec 2, 2020, at 5:51 PM, Carlos Rovira  wrote:
>>>
>>> Hi Harbs,
>>>
>>> I installed Maven and Java with home brew and don't have JDK 13. So don't
>>> see a relationship. It's clear that maven requires Java since it is done in
>>> java, but I think the version is not a problem. I think better install Java
>>> (the sdk version you want) and then maven, so it takes that. Did you check
>>> Jenv as I told you? You can have different Java versions, one for general
>>> use, and then you can have a concrete version for a concrete folder. For
>>> example. I have an old product that use JDK 7,and I use jenv to configure
>>> that Java7 for that folder ensuring  the product use Java 7
>>>
>>> HTH
>>>
>>> Carlos
>>>
>>>
>>> El mié, 2 dic 2020 a las 13:08, Harbs () escribió:
>>>
>>>> DIrectly.
>>>>
>>>> Well, things get more and more interesting:
>>>>
>>>> brew uninstall openjdk
>>>> Error: Refusing to uninstall /usr/local/Cellar/openjdk/13.0.2+8_2
>>>> because it is required by maven, which is currently installed.
>>>> You can override this and force removal with:
>>>> brew uninstall --ignore-dependencies openjdk
>>>>
>>>> I probably installed maven using HomeBrew which pulls in openjdk 13 as a
>>>> dependency. I guess that explains why I only get JDK

Re: Release Step 003 Succeeded

[Harbs]

In running the script on Windows I ran into the same Flash problem.

It seems like I you need to run mvn clean install -Poption-with-swf at least 
once.

I was missing the option-with-swf before...

> On Dec 3, 2020, at 8:00 PM, Alex Harui  wrote:
> 
> Cross-platform reproducible binaries worked with the zlika plugin otherwise 
> we couldn't have verified prior releases.  Then we switched to the Maven 
> reproducibility features and it seemed to work in tests but apparently not in 
> reality.  It might be that the release steps are not triggering the Maven 
> reproducibility features correctly.   It should be possible to go back to the 
> zlika plugin.  IIRC, it had a feature to support line endings.
> 
> -Alex
> 
> On 12/3/20, 9:43 AM, "Harbs"  <mailto:harbs.li...@gmail.com>> wrote:
> 
>Yes. I’ll probably finish the release on a Windows machine.
> 
>After the release is done, we can figure out a plan for cross-platform 
> releases.
> 
>I’d also like to use what I’ve learned from this release to setup another 
> CI instance on AWS (which I’m more familiar with than Azure).
> 
>> On Dec 3, 2020, at 12:28 PM, Christofer Dutz  
>> wrote:
>> 
>> Hi all,
>> 
>> so Harbs sent me the version built on his machine and one of the release.
>> When doing the “compare archives” in IntelliJ is showed that the 
>> maven-plugin had differences in the line separators in the resources 
>> generated by the maven-plugin-plugin and by the maven- jar-plugin 
>> (pom.properties)
>> 
>> Unfortunately I have tried several times to use settings like 
>> “-Dline.separator='\n'” in builds, unfortunately a lot of plugins seem to 
>> not like this setting. I particularly remember the plugins for antlr2, 3 and 
>> 4 don’t really like taking control of the line.separators.
>> 
>> So right now, an “easy fix” would be to only do releases on Windows 
>> machines. But I know that’s not a great solution.
>> 
>> Chris
>> 
>> 
>> 
>> 
>> Von: Alex Harui 
>> Datum: Mittwoch, 2. Dezember 2020 um 20:29
>> An: dev@royale.apache.org 
>> Betreff: Re: Release Step 003 Succeeded
>> A Jar is a zip.  Check the dates of the .class files that are zipped into 
>> the jar.  We are using a tool that should set the dates correctly, but maybe 
>> it isn't working.
>> 
>> On 12/2/20, 11:12 AM, "Harbs"  wrote:
>> 
>>   I uninstalled from HomeBrew and installed Maven manually. I’m now getting 
>> 1.8.
>> 
>>   The script thinks the binaries don’t match, but unzipping them and using 
>> Meld shows that they do have a binary match.
>> 
>>   I’m getting close.
>> 
>>> On Dec 2, 2020, at 5:51 PM, Carlos Rovira  wrote:
>>> 
>>> Hi Harbs,
>>> 
>>> I installed Maven and Java with home brew and don't have JDK 13. So don't
>>> see a relationship. It's clear that maven requires Java since it is done in
>>> java, but I think the version is not a problem. I think better install Java
>>> (the sdk version you want) and then maven, so it takes that. Did you check
>>> Jenv as I told you? You can have different Java versions, one for general
>>> use, and then you can have a concrete version for a concrete folder. For
>>> example. I have an old product that use JDK 7,and I use jenv to configure
>>> that Java7 for that folder ensuring  the product use Java 7
>>> 
>>> HTH
>>> 
>>> Carlos
>>> 
>>> 
>>> El mié, 2 dic 2020 a las 13:08, Harbs () escribió:
>>> 
>>>> DIrectly.
>>>> 
>>>> Well, things get more and more interesting:
>>>> 
>>>> brew uninstall openjdk
>>>> Error: Refusing to uninstall /usr/local/Cellar/openjdk/13.0.2+8_2
>>>> because it is required by maven, which is currently installed.
>>>> You can override this and force removal with:
>>>> brew uninstall --ignore-dependencies openjdk
>>>> 
>>>> I probably installed maven using HomeBrew which pulls in openjdk 13 as a
>>>> dependency. I guess that explains why I only get JDK 13 when I use Maven.
>>>> 
>>>> Not being able to install Maven using HomeBrew is a pretty annoying
>>>> limitation. Is there any other way around this problem?
>>>> 
>>>>> On Dec 2, 2020, at 12:11 PM, Christofer Dutz 
>>>> wrote:
>>>>> 
>>>>> Hi Harbs,
>>>>> 
>>>>> Are you running the maven build directly/manually? Or is this triggered
>&

Re: Release Step 003 Succeeded

[Alex Harui]

Cross-platform reproducible binaries worked with the zlika plugin otherwise we 
couldn't have verified prior releases.  Then we switched to the Maven 
reproducibility features and it seemed to work in tests but apparently not in 
reality.  It might be that the release steps are not triggering the Maven 
reproducibility features correctly.   It should be possible to go back to the 
zlika plugin.  IIRC, it had a feature to support line endings.

-Alex

On 12/3/20, 9:43 AM, "Harbs"  wrote:

Yes. I’ll probably finish the release on a Windows machine.

After the release is done, we can figure out a plan for cross-platform 
releases.

I’d also like to use what I’ve learned from this release to setup another 
CI instance on AWS (which I’m more familiar with than Azure).

> On Dec 3, 2020, at 12:28 PM, Christofer Dutz  
wrote:
> 
> Hi all,
> 
> so Harbs sent me the version built on his machine and one of the release.
> When doing the “compare archives” in IntelliJ is showed that the 
maven-plugin had differences in the line separators in the resources generated 
by the maven-plugin-plugin and by the maven- jar-plugin (pom.properties)
> 
> Unfortunately I have tried several times to use settings like 
“-Dline.separator='\n'” in builds, unfortunately a lot of plugins seem to not 
like this setting. I particularly remember the plugins for antlr2, 3 and 4 
don’t really like taking control of the line.separators.
> 
> So right now, an “easy fix” would be to only do releases on Windows 
machines. But I know that’s not a great solution.
> 
> Chris
> 
> 
> 
> 
> Von: Alex Harui 
> Datum: Mittwoch, 2. Dezember 2020 um 20:29
    > An: dev@royale.apache.org 
> Betreff: Re: Release Step 003 Succeeded
> A Jar is a zip.  Check the dates of the .class files that are zipped into 
the jar.  We are using a tool that should set the dates correctly, but maybe it 
isn't working.
> 
> On 12/2/20, 11:12 AM, "Harbs"  wrote:
> 
>I uninstalled from HomeBrew and installed Maven manually. I’m now 
getting 1.8.
> 
>The script thinks the binaries don’t match, but unzipping them and 
using Meld shows that they do have a binary match.
> 
>I’m getting close.
> 
>> On Dec 2, 2020, at 5:51 PM, Carlos Rovira  
wrote:
>> 
>> Hi Harbs,
>> 
>> I installed Maven and Java with home brew and don't have JDK 13. So don't
>> see a relationship. It's clear that maven requires Java since it is done 
in
>> java, but I think the version is not a problem. I think better install 
Java
>> (the sdk version you want) and then maven, so it takes that. Did you 
check
>> Jenv as I told you? You can have different Java versions, one for general
>> use, and then you can have a concrete version for a concrete folder. For
>> example. I have an old product that use JDK 7,and I use jenv to configure
>> that Java7 for that folder ensuring  the product use Java 7
>> 
>> HTH
>> 
>> Carlos
>> 
>> 
>> El mié, 2 dic 2020 a las 13:08, Harbs () escribió:
>> 
>>> DIrectly.
>>> 
>>> Well, things get more and more interesting:
>>> 
>>> brew uninstall openjdk
>>> Error: Refusing to uninstall /usr/local/Cellar/openjdk/13.0.2+8_2
>>> because it is required by maven, which is currently installed.
>>> You can override this and force removal with:
>>> brew uninstall --ignore-dependencies openjdk
>>> 
>>> I probably installed maven using HomeBrew which pulls in openjdk 13 as a
>>> dependency. I guess that explains why I only get JDK 13 when I use 
Maven.
>>> 
>>> Not being able to install Maven using HomeBrew is a pretty annoying
>>> limitation. Is there any other way around this problem?
>>> 
>>>> On Dec 2, 2020, at 12:11 PM, Christofer Dutz 

>>> wrote:
>>>> 
>>>> Hi Harbs,
>>>> 
>>>> Are you running the maven build directly/manually? Or is this triggered
>>> by an IDE or Ant script?
>>>> Cause I usually run most of my builds in IntelliJ and there I simply
>>> select the JDK and it sort of magically gets selected (I don’t have
>>> JAVA_HOME set explicitly either)
>>>> 
>>>> Chris
>>>> 
>>>> 
>>>> 
>>>> Von: Harbs 
>>>> Datum: Dienstag, 1. Dezember 2020 um 19:28
>>>> An

Re: Release Step 003 Succeeded

[Harbs]

Yes. I’ll probably finish the release on a Windows machine.

After the release is done, we can figure out a plan for cross-platform releases.

I’d also like to use what I’ve learned from this release to setup another CI 
instance on AWS (which I’m more familiar with than Azure).

> On Dec 3, 2020, at 12:28 PM, Christofer Dutz  
> wrote:
> 
> Hi all,
> 
> so Harbs sent me the version built on his machine and one of the release.
> When doing the “compare archives” in IntelliJ is showed that the maven-plugin 
> had differences in the line separators in the resources generated by the 
> maven-plugin-plugin and by the maven- jar-plugin (pom.properties)
> 
> Unfortunately I have tried several times to use settings like 
> “-Dline.separator='\n'” in builds, unfortunately a lot of plugins seem to not 
> like this setting. I particularly remember the plugins for antlr2, 3 and 4 
> don’t really like taking control of the line.separators.
> 
> So right now, an “easy fix” would be to only do releases on Windows machines. 
> But I know that’s not a great solution.
> 
> Chris
> 
> 
> 
> 
> Von: Alex Harui 
> Datum: Mittwoch, 2. Dezember 2020 um 20:29
> An: dev@royale.apache.org 
> Betreff: Re: Release Step 003 Succeeded
> A Jar is a zip.  Check the dates of the .class files that are zipped into the 
> jar.  We are using a tool that should set the dates correctly, but maybe it 
> isn't working.
> 
> On 12/2/20, 11:12 AM, "Harbs"  wrote:
> 
>I uninstalled from HomeBrew and installed Maven manually. I’m now getting 
> 1.8.
> 
>The script thinks the binaries don’t match, but unzipping them and using 
> Meld shows that they do have a binary match.
> 
>I’m getting close.
> 
>> On Dec 2, 2020, at 5:51 PM, Carlos Rovira  wrote:
>> 
>> Hi Harbs,
>> 
>> I installed Maven and Java with home brew and don't have JDK 13. So don't
>> see a relationship. It's clear that maven requires Java since it is done in
>> java, but I think the version is not a problem. I think better install Java
>> (the sdk version you want) and then maven, so it takes that. Did you check
>> Jenv as I told you? You can have different Java versions, one for general
>> use, and then you can have a concrete version for a concrete folder. For
>> example. I have an old product that use JDK 7,and I use jenv to configure
>> that Java7 for that folder ensuring  the product use Java 7
>> 
>> HTH
>> 
>> Carlos
>> 
>> 
>> El mié, 2 dic 2020 a las 13:08, Harbs () escribió:
>> 
>>> DIrectly.
>>> 
>>> Well, things get more and more interesting:
>>> 
>>> brew uninstall openjdk
>>> Error: Refusing to uninstall /usr/local/Cellar/openjdk/13.0.2+8_2
>>> because it is required by maven, which is currently installed.
>>> You can override this and force removal with:
>>> brew uninstall --ignore-dependencies openjdk
>>> 
>>> I probably installed maven using HomeBrew which pulls in openjdk 13 as a
>>> dependency. I guess that explains why I only get JDK 13 when I use Maven.
>>> 
>>> Not being able to install Maven using HomeBrew is a pretty annoying
>>> limitation. Is there any other way around this problem?
>>> 
>>>> On Dec 2, 2020, at 12:11 PM, Christofer Dutz 
>>> wrote:
>>>> 
>>>> Hi Harbs,
>>>> 
>>>> Are you running the maven build directly/manually? Or is this triggered
>>> by an IDE or Ant script?
>>>> Cause I usually run most of my builds in IntelliJ and there I simply
>>> select the JDK and it sort of magically gets selected (I don’t have
>>> JAVA_HOME set explicitly either)
>>>> 
>>>> Chris
>>>> 
>>>> 
>>>> 
>>>> Von: Harbs 
>>>> Datum: Dienstag, 1. Dezember 2020 um 19:28
>>>> An: dev@royale.apache.org 
>>>> Betreff: Re: Release Step 003 Succeeded
>>>> echo $JAVA_HOME returns an empty string, so I really don’t think
>>> JAVA_HOME is playing a role. It could be MacBrew uses a symlink which Maven
>>> places as higher priority than my system default. I’ll play some more later
>>> or tomorrow.
>>>> 
>>>>> On Dec 1, 2020, at 3:51 PM, Christofer Dutz 
>>> wrote:
>>>>> 
>>>>> Hi Harbs,
>>>>> 
>>>>> I usually build PLC4X with each JDK from 1.8 to currently 15 and its
>>> super easy to do so. Have you checked if any JAVA_HOME is defined?
>>>>> 
>>>>> Cause I checked the mvn script 

AW: Release Step 003 Succeeded

[Christofer Dutz]

Hi all,

so Harbs sent me the version built on his machine and one of the release.
When doing the “compare archives” in IntelliJ is showed that the maven-plugin 
had differences in the line separators in the resources generated by the 
maven-plugin-plugin and by the maven- jar-plugin (pom.properties)

Unfortunately I have tried several times to use settings like 
“-Dline.separator='\n'” in builds, unfortunately a lot of plugins seem to not 
like this setting. I particularly remember the plugins for antlr2, 3 and 4 
don’t really like taking control of the line.separators.

So right now, an “easy fix” would be to only do releases on Windows machines. 
But I know that’s not a great solution.

Chris




Von: Alex Harui 
Datum: Mittwoch, 2. Dezember 2020 um 20:29
An: dev@royale.apache.org 
Betreff: Re: Release Step 003 Succeeded
A Jar is a zip.  Check the dates of the .class files that are zipped into the 
jar.  We are using a tool that should set the dates correctly, but maybe it 
isn't working.

On 12/2/20, 11:12 AM, "Harbs"  wrote:

I uninstalled from HomeBrew and installed Maven manually. I’m now getting 
1.8.

The script thinks the binaries don’t match, but unzipping them and using 
Meld shows that they do have a binary match.

I’m getting close.

> On Dec 2, 2020, at 5:51 PM, Carlos Rovira  wrote:
>
> Hi Harbs,
>
> I installed Maven and Java with home brew and don't have JDK 13. So don't
> see a relationship. It's clear that maven requires Java since it is done 
in
> java, but I think the version is not a problem. I think better install 
Java
> (the sdk version you want) and then maven, so it takes that. Did you check
> Jenv as I told you? You can have different Java versions, one for general
> use, and then you can have a concrete version for a concrete folder. For
> example. I have an old product that use JDK 7,and I use jenv to configure
> that Java7 for that folder ensuring  the product use Java 7
>
> HTH
>
> Carlos
>
>
> El mié, 2 dic 2020 a las 13:08, Harbs () escribió:
>
>> DIrectly.
>>
>> Well, things get more and more interesting:
>>
>> brew uninstall openjdk
>> Error: Refusing to uninstall /usr/local/Cellar/openjdk/13.0.2+8_2
>> because it is required by maven, which is currently installed.
>> You can override this and force removal with:
>>  brew uninstall --ignore-dependencies openjdk
>>
>> I probably installed maven using HomeBrew which pulls in openjdk 13 as a
>> dependency. I guess that explains why I only get JDK 13 when I use Maven.
>>
>> Not being able to install Maven using HomeBrew is a pretty annoying
>> limitation. Is there any other way around this problem?
>>
>>> On Dec 2, 2020, at 12:11 PM, Christofer Dutz 
>> wrote:
>>>
>>> Hi Harbs,
>>>
>>> Are you running the maven build directly/manually? Or is this triggered
>> by an IDE or Ant script?
>>> Cause I usually run most of my builds in IntelliJ and there I simply
>> select the JDK and it sort of magically gets selected (I don’t have
    >> JAVA_HOME set explicitly either)
>>>
>>> Chris
>>>
>>>
>>>
>>> Von: Harbs 
>>> Datum: Dienstag, 1. Dezember 2020 um 19:28
>>> An: dev@royale.apache.org 
>>> Betreff: Re: Release Step 003 Succeeded
>>> echo $JAVA_HOME returns an empty string, so I really don’t think
>> JAVA_HOME is playing a role. It could be MacBrew uses a symlink which 
Maven
>> places as higher priority than my system default. I’ll play some more 
later
>> or tomorrow.
>>>
>>>> On Dec 1, 2020, at 3:51 PM, Christofer Dutz 
>> wrote:
>>>>
>>>> Hi Harbs,
>>>>
>>>> I usually build PLC4X with each JDK from 1.8 to currently 15 and its
>> super easy to do so. Have you checked if any JAVA_HOME is defined?
>>>>
>>>> Cause I checked the mvn script and it checks if JAVA_HOME is defined,
>> if it is, it uses that, if it’s not defined it tries to find the java
>> executable and use that’s parent directory as JAVA_HOME.
>>>>
>>>> So as you mentioned a “java –version” outputs 1.8 but your build is
>> picking up 13, I would guess that you have a JAVA_HOME environment 
variable
>> set to the Java 13 version.
>>>>
>>>> Chris
>>>>
>>>>
>>>> Von: Harbs mailto:harbs.li

Re: Release Step 003 Succeeded

[Alex Harui]

A Jar is a zip.  Check the dates of the .class files that are zipped into the 
jar.  We are using a tool that should set the dates correctly, but maybe it 
isn't working.

On 12/2/20, 11:12 AM, "Harbs"  wrote:

I uninstalled from HomeBrew and installed Maven manually. I’m now getting 
1.8.

The script thinks the binaries don’t match, but unzipping them and using 
Meld shows that they do have a binary match.

I’m getting close.

> On Dec 2, 2020, at 5:51 PM, Carlos Rovira  wrote:
> 
> Hi Harbs,
> 
> I installed Maven and Java with home brew and don't have JDK 13. So don't
> see a relationship. It's clear that maven requires Java since it is done 
in
> java, but I think the version is not a problem. I think better install 
Java
> (the sdk version you want) and then maven, so it takes that. Did you check
> Jenv as I told you? You can have different Java versions, one for general
> use, and then you can have a concrete version for a concrete folder. For
> example. I have an old product that use JDK 7,and I use jenv to configure
> that Java7 for that folder ensuring  the product use Java 7
> 
> HTH
> 
> Carlos
> 
> 
> El mié, 2 dic 2020 a las 13:08, Harbs () escribió:
> 
>> DIrectly.
>> 
>> Well, things get more and more interesting:
>> 
>> brew uninstall openjdk
>> Error: Refusing to uninstall /usr/local/Cellar/openjdk/13.0.2+8_2
>> because it is required by maven, which is currently installed.
>> You can override this and force removal with:
>>  brew uninstall --ignore-dependencies openjdk
>> 
>> I probably installed maven using HomeBrew which pulls in openjdk 13 as a
>> dependency. I guess that explains why I only get JDK 13 when I use Maven.
>> 
>> Not being able to install Maven using HomeBrew is a pretty annoying
>> limitation. Is there any other way around this problem?
>> 
>>> On Dec 2, 2020, at 12:11 PM, Christofer Dutz 
>> wrote:
>>> 
>>> Hi Harbs,
>>> 
>>> Are you running the maven build directly/manually? Or is this triggered
>> by an IDE or Ant script?
>>> Cause I usually run most of my builds in IntelliJ and there I simply
>> select the JDK and it sort of magically gets selected (I don’t have
>> JAVA_HOME set explicitly either)
>>> 
>>> Chris
>>> 
>>> 
>>> 
>>> Von: Harbs 
>>> Datum: Dienstag, 1. Dezember 2020 um 19:28
>>> An: dev@royale.apache.org 
>>> Betreff: Re: Release Step 003 Succeeded
>>> echo $JAVA_HOME returns an empty string, so I really don’t think
>> JAVA_HOME is playing a role. It could be MacBrew uses a symlink which 
Maven
>> places as higher priority than my system default. I’ll play some more 
later
>> or tomorrow.
>>> 
>>>> On Dec 1, 2020, at 3:51 PM, Christofer Dutz 
>> wrote:
>>>> 
>>>> Hi Harbs,
>>>> 
>>>> I usually build PLC4X with each JDK from 1.8 to currently 15 and its
>> super easy to do so. Have you checked if any JAVA_HOME is defined?
>>>> 
>>>> Cause I checked the mvn script and it checks if JAVA_HOME is defined,
>> if it is, it uses that, if it’s not defined it tries to find the java
>> executable and use that’s parent directory as JAVA_HOME.
>>>> 
>>>> So as you mentioned a “java –version” outputs 1.8 but your build is
>> picking up 13, I would guess that you have a JAVA_HOME environment 
variable
>> set to the Java 13 version.
>>>> 
>>>> Chris
>>>> 
>>>> 
>>>> Von: Harbs mailto:harbs.li...@gmail.com>>
>>>> Datum: Dienstag, 1. Dezember 2020 um 13:45
>>>> An: dev@royale.apache.org <mailto:dev@royale.apache.org> <
>> dev@royale.apache.org <mailto:dev@royale.apache.org>>
>>>> Betreff: Re: Release Step 003 Succeeded
>>>> I did some research.
>>>> 
>>>> I have Java 1.8 installed, but I also have openjdk 13 installed using
>> MacBrew.
>>>> 
>>>> A fresh build of Maven (mvn clean install) on a fresh copy of the
>> compiler repo also seems to use version 13.
>>>> 
>>>> I guess I can probably uninstall openjdk, but that begs the question as
>> to why Maven is usin

Re: Release Step 003 Succeeded

[Harbs]

I uninstalled from HomeBrew and installed Maven manually. I’m now getting 1.8.

The script thinks the binaries don’t match, but unzipping them and using Meld 
shows that they do have a binary match.

I’m getting close.

> On Dec 2, 2020, at 5:51 PM, Carlos Rovira  wrote:
> 
> Hi Harbs,
> 
> I installed Maven and Java with home brew and don't have JDK 13. So don't
> see a relationship. It's clear that maven requires Java since it is done in
> java, but I think the version is not a problem. I think better install Java
> (the sdk version you want) and then maven, so it takes that. Did you check
> Jenv as I told you? You can have different Java versions, one for general
> use, and then you can have a concrete version for a concrete folder. For
> example. I have an old product that use JDK 7,and I use jenv to configure
> that Java7 for that folder ensuring  the product use Java 7
> 
> HTH
> 
> Carlos
> 
> 
> El mié, 2 dic 2020 a las 13:08, Harbs () escribió:
> 
>> DIrectly.
>> 
>> Well, things get more and more interesting:
>> 
>> brew uninstall openjdk
>> Error: Refusing to uninstall /usr/local/Cellar/openjdk/13.0.2+8_2
>> because it is required by maven, which is currently installed.
>> You can override this and force removal with:
>>  brew uninstall --ignore-dependencies openjdk
>> 
>> I probably installed maven using HomeBrew which pulls in openjdk 13 as a
>> dependency. I guess that explains why I only get JDK 13 when I use Maven.
>> 
>> Not being able to install Maven using HomeBrew is a pretty annoying
>> limitation. Is there any other way around this problem?
>> 
>>> On Dec 2, 2020, at 12:11 PM, Christofer Dutz 
>> wrote:
>>> 
>>> Hi Harbs,
>>> 
>>> Are you running the maven build directly/manually? Or is this triggered
>> by an IDE or Ant script?
>>> Cause I usually run most of my builds in IntelliJ and there I simply
>> select the JDK and it sort of magically gets selected (I don’t have
>> JAVA_HOME set explicitly either)
>>> 
>>> Chris
>>> 
>>> 
>>> 
>>> Von: Harbs 
>>> Datum: Dienstag, 1. Dezember 2020 um 19:28
>>> An: dev@royale.apache.org 
>>> Betreff: Re: Release Step 003 Succeeded
>>> echo $JAVA_HOME returns an empty string, so I really don’t think
>> JAVA_HOME is playing a role. It could be MacBrew uses a symlink which Maven
>> places as higher priority than my system default. I’ll play some more later
>> or tomorrow.
>>> 
>>>> On Dec 1, 2020, at 3:51 PM, Christofer Dutz 
>> wrote:
>>>> 
>>>> Hi Harbs,
>>>> 
>>>> I usually build PLC4X with each JDK from 1.8 to currently 15 and its
>> super easy to do so. Have you checked if any JAVA_HOME is defined?
>>>> 
>>>> Cause I checked the mvn script and it checks if JAVA_HOME is defined,
>> if it is, it uses that, if it’s not defined it tries to find the java
>> executable and use that’s parent directory as JAVA_HOME.
>>>> 
>>>> So as you mentioned a “java –version” outputs 1.8 but your build is
>> picking up 13, I would guess that you have a JAVA_HOME environment variable
>> set to the Java 13 version.
>>>> 
>>>> Chris
>>>> 
>>>> 
>>>> Von: Harbs mailto:harbs.li...@gmail.com>>
>>>> Datum: Dienstag, 1. Dezember 2020 um 13:45
>>>> An: dev@royale.apache.org <mailto:dev@royale.apache.org> <
>> dev@royale.apache.org <mailto:dev@royale.apache.org>>
>>>> Betreff: Re: Release Step 003 Succeeded
>>>> I did some research.
>>>> 
>>>> I have Java 1.8 installed, but I also have openjdk 13 installed using
>> MacBrew.
>>>> 
>>>> A fresh build of Maven (mvn clean install) on a fresh copy of the
>> compiler repo also seems to use version 13.
>>>> 
>>>> I guess I can probably uninstall openjdk, but that begs the question as
>> to why Maven is using it considering my default JDK is 1.8.
>>>> 
>>>> I think the Maven build should be fixed so the correct target is always
>> used.
>>>> 
>>>>> On Nov 30, 2020, at 6:25 PM, Alex Harui 
>> wrote:
>>>>> 
>>>>> IMO, it would be worth it to get the exact build of the JDK.  If 231
>> has different ways of outputting some Java, then you can't get reproducible
>> binaries.
>>>>> 
>>>>> It is also possible that some other hash table is iterated differently
>> for some reason and nee

Re: Release Step 003 Succeeded

[Carlos Rovira]

+1

I thought wrapper was already added to maven

El mié, 2 dic 2020 a las 13:41, Christofer Dutz ()
escribió:

> We could also think about using the Maven-Wrapper as we are in a lot of
> other projects.
>
> With this the only requirement to build is Java 1.8+ … when using the
> script it automatically downloads and uses a pre-configured maven version,
> which you don’t have to install.
>
> However we should wait a bit, as the maven-wrapper has been donated to the
> Maven project and with the upcoming maven release this will contain a fully
> Apache maven-wrapper. So when using this we shouldn’t be required to
> attribute anything in our LICENSE or NOTICE files.
>
> Chris
>
>
> Von: Christofer Dutz 
> Datum: Mittwoch, 2. Dezember 2020 um 13:32
> An: dev@royale.apache.org 
> Betreff: AW: Release Step 003 Succeeded
> Hi Harbs,
>
> let me guess … you installed Maven via homebrew?
>
> That would explain this behavior. I would expect the homebrew maven
> installation to be directly tied to that particular Java version.
>
> I think I never installed Maven other than downloading a zip and unpacking
> it and sticking the bin directory on the path.
>
>
> Chris
>
>
> Von: Harbs 
> Datum: Mittwoch, 2. Dezember 2020 um 13:09
> An: dev@royale.apache.org 
> Betreff: Re: Release Step 003 Succeeded
> DIrectly.
>
> Well, things get more and more interesting:
>
> brew uninstall openjdk
> Error: Refusing to uninstall /usr/local/Cellar/openjdk/13.0.2+8_2
> because it is required by maven, which is currently installed.
> You can override this and force removal with:
>   brew uninstall --ignore-dependencies openjdk
>
> I probably installed maven using HomeBrew which pulls in openjdk 13 as a
> dependency. I guess that explains why I only get JDK 13 when I use Maven.
>
> Not being able to install Maven using HomeBrew is a pretty annoying
> limitation. Is there any other way around this problem?
>
> > On Dec 2, 2020, at 12:11 PM, Christofer Dutz 
> wrote:
> >
> > Hi Harbs,
> >
> > Are you running the maven build directly/manually? Or is this triggered
> by an IDE or Ant script?
> > Cause I usually run most of my builds in IntelliJ and there I simply
> select the JDK and it sort of magically gets selected (I don’t have
> JAVA_HOME set explicitly either)
> >
> > Chris
> >
> >
> >
> > Von: Harbs 
> > Datum: Dienstag, 1. Dezember 2020 um 19:28
> > An: dev@royale.apache.org 
> > Betreff: Re: Release Step 003 Succeeded
> > echo $JAVA_HOME returns an empty string, so I really don’t think
> JAVA_HOME is playing a role. It could be MacBrew uses a symlink which Maven
> places as higher priority than my system default. I’ll play some more later
> or tomorrow.
> >
> >> On Dec 1, 2020, at 3:51 PM, Christofer Dutz 
> wrote:
> >>
> >> Hi Harbs,
> >>
> >> I usually build PLC4X with each JDK from 1.8 to currently 15 and its
> super easy to do so. Have you checked if any JAVA_HOME is defined?
> >>
> >> Cause I checked the mvn script and it checks if JAVA_HOME is defined,
> if it is, it uses that, if it’s not defined it tries to find the java
> executable and use that’s parent directory as JAVA_HOME.
> >>
> >> So as you mentioned a “java –version” outputs 1.8 but your build is
> picking up 13, I would guess that you have a JAVA_HOME environment variable
> set to the Java 13 version.
> >>
> >> Chris
> >>
> >>
> >> Von: Harbs mailto:harbs.li...@gmail.com>>
> >> Datum: Dienstag, 1. Dezember 2020 um 13:45
> >> An: dev@royale.apache.org <mailto:dev@royale.apache.org> <
> dev@royale.apache.org <mailto:dev@royale.apache.org>>
> >> Betreff: Re: Release Step 003 Succeeded
> >> I did some research.
> >>
> >> I have Java 1.8 installed, but I also have openjdk 13 installed using
> MacBrew.
> >>
> >> A fresh build of Maven (mvn clean install) on a fresh copy of the
> compiler repo also seems to use version 13.
> >>
> >> I guess I can probably uninstall openjdk, but that begs the question as
> to why Maven is using it considering my default JDK is 1.8.
> >>
> >> I think the Maven build should be fixed so the correct target is always
> used.
> >>
> >>> On Nov 30, 2020, at 6:25 PM, Alex Harui 
> wrote:
> >>>
> >>> IMO, it would be worth it to get the exact build of the JDK.  If 231
> has different ways of outputting some Java, then you can't get reproducible
> binaries.
> >>>
> >>> It is also possible that some other hash

Re: Release Step 003 Succeeded

[Carlos Rovira]

Hi Harbs,

I installed Maven and Java with home brew and don't have JDK 13. So don't
see a relationship. It's clear that maven requires Java since it is done in
java, but I think the version is not a problem. I think better install Java
(the sdk version you want) and then maven, so it takes that. Did you check
Jenv as I told you? You can have different Java versions, one for general
use, and then you can have a concrete version for a concrete folder. For
example. I have an old product that use JDK 7,and I use jenv to configure
that Java7 for that folder ensuring  the product use Java 7

HTH

Carlos


El mié, 2 dic 2020 a las 13:08, Harbs () escribió:

> DIrectly.
>
> Well, things get more and more interesting:
>
> brew uninstall openjdk
> Error: Refusing to uninstall /usr/local/Cellar/openjdk/13.0.2+8_2
> because it is required by maven, which is currently installed.
> You can override this and force removal with:
>   brew uninstall --ignore-dependencies openjdk
>
> I probably installed maven using HomeBrew which pulls in openjdk 13 as a
> dependency. I guess that explains why I only get JDK 13 when I use Maven.
>
> Not being able to install Maven using HomeBrew is a pretty annoying
> limitation. Is there any other way around this problem?
>
> > On Dec 2, 2020, at 12:11 PM, Christofer Dutz 
> wrote:
> >
> > Hi Harbs,
> >
> > Are you running the maven build directly/manually? Or is this triggered
> by an IDE or Ant script?
> > Cause I usually run most of my builds in IntelliJ and there I simply
> select the JDK and it sort of magically gets selected (I don’t have
> JAVA_HOME set explicitly either)
> >
> > Chris
> >
> >
> >
> > Von: Harbs 
> > Datum: Dienstag, 1. Dezember 2020 um 19:28
> > An: dev@royale.apache.org 
> > Betreff: Re: Release Step 003 Succeeded
> > echo $JAVA_HOME returns an empty string, so I really don’t think
> JAVA_HOME is playing a role. It could be MacBrew uses a symlink which Maven
> places as higher priority than my system default. I’ll play some more later
> or tomorrow.
> >
> >> On Dec 1, 2020, at 3:51 PM, Christofer Dutz 
> wrote:
> >>
> >> Hi Harbs,
> >>
> >> I usually build PLC4X with each JDK from 1.8 to currently 15 and its
> super easy to do so. Have you checked if any JAVA_HOME is defined?
> >>
> >> Cause I checked the mvn script and it checks if JAVA_HOME is defined,
> if it is, it uses that, if it’s not defined it tries to find the java
> executable and use that’s parent directory as JAVA_HOME.
> >>
> >> So as you mentioned a “java –version” outputs 1.8 but your build is
> picking up 13, I would guess that you have a JAVA_HOME environment variable
> set to the Java 13 version.
> >>
> >> Chris
> >>
> >>
> >> Von: Harbs mailto:harbs.li...@gmail.com>>
> >> Datum: Dienstag, 1. Dezember 2020 um 13:45
> >> An: dev@royale.apache.org <mailto:dev@royale.apache.org> <
> dev@royale.apache.org <mailto:dev@royale.apache.org>>
> >> Betreff: Re: Release Step 003 Succeeded
> >> I did some research.
> >>
> >> I have Java 1.8 installed, but I also have openjdk 13 installed using
> MacBrew.
> >>
> >> A fresh build of Maven (mvn clean install) on a fresh copy of the
> compiler repo also seems to use version 13.
> >>
> >> I guess I can probably uninstall openjdk, but that begs the question as
> to why Maven is using it considering my default JDK is 1.8.
> >>
> >> I think the Maven build should be fixed so the correct target is always
> used.
> >>
> >>> On Nov 30, 2020, at 6:25 PM, Alex Harui 
> wrote:
> >>>
> >>> IMO, it would be worth it to get the exact build of the JDK.  If 231
> has different ways of outputting some Java, then you can't get reproducible
> binaries.
> >>>
> >>> It is also possible that some other hash table is iterated differently
> for some reason and needs to have its iteration controlled.  I don't think
> anyone has tried to do an exhaustive search of the Java code to ensure
> iteration order.  We just keep finding and fixing them as we do the
> releases.
> >>>
> >>> -Alex
> >>>
> >>> On 11/30/20, 2:05 AM, "Harbs"  harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com  harbs.li...@gmail.com>>> wrote:
> >>>
> >>>  Java version seems to be pretty close:
> >>>
> >>>  C:\jenkins\workspace\Royale_Release_Step_002>java -version
> >>>  Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
>

AW: Release Step 003 Succeeded

[Christofer Dutz]

We could also think about using the Maven-Wrapper as we are in a lot of other 
projects.

With this the only requirement to build is Java 1.8+ … when using the script it 
automatically downloads and uses a pre-configured maven version, which you 
don’t have to install.

However we should wait a bit, as the maven-wrapper has been donated to the 
Maven project and with the upcoming maven release this will contain a fully 
Apache maven-wrapper. So when using this we shouldn’t be required to attribute 
anything in our LICENSE or NOTICE files.

Chris


Von: Christofer Dutz 
Datum: Mittwoch, 2. Dezember 2020 um 13:32
An: dev@royale.apache.org 
Betreff: AW: Release Step 003 Succeeded
Hi Harbs,

let me guess … you installed Maven via homebrew?

That would explain this behavior. I would expect the homebrew maven 
installation to be directly tied to that particular Java version.

I think I never installed Maven other than downloading a zip and unpacking it 
and sticking the bin directory on the path.


Chris


Von: Harbs 
Datum: Mittwoch, 2. Dezember 2020 um 13:09
An: dev@royale.apache.org 
Betreff: Re: Release Step 003 Succeeded
DIrectly.

Well, things get more and more interesting:

brew uninstall openjdk
Error: Refusing to uninstall /usr/local/Cellar/openjdk/13.0.2+8_2
because it is required by maven, which is currently installed.
You can override this and force removal with:
  brew uninstall --ignore-dependencies openjdk

I probably installed maven using HomeBrew which pulls in openjdk 13 as a 
dependency. I guess that explains why I only get JDK 13 when I use Maven.

Not being able to install Maven using HomeBrew is a pretty annoying limitation. 
Is there any other way around this problem?

> On Dec 2, 2020, at 12:11 PM, Christofer Dutz  
> wrote:
>
> Hi Harbs,
>
> Are you running the maven build directly/manually? Or is this triggered by an 
> IDE or Ant script?
> Cause I usually run most of my builds in IntelliJ and there I simply select 
> the JDK and it sort of magically gets selected (I don’t have JAVA_HOME set 
> explicitly either)
>
> Chris
>
>
>
> Von: Harbs 
> Datum: Dienstag, 1. Dezember 2020 um 19:28
> An: dev@royale.apache.org 
> Betreff: Re: Release Step 003 Succeeded
> echo $JAVA_HOME returns an empty string, so I really don’t think JAVA_HOME is 
> playing a role. It could be MacBrew uses a symlink which Maven places as 
> higher priority than my system default. I’ll play some more later or tomorrow.
>
>> On Dec 1, 2020, at 3:51 PM, Christofer Dutz  
>> wrote:
>>
>> Hi Harbs,
>>
>> I usually build PLC4X with each JDK from 1.8 to currently 15 and its super 
>> easy to do so. Have you checked if any JAVA_HOME is defined?
>>
>> Cause I checked the mvn script and it checks if JAVA_HOME is defined, if it 
>> is, it uses that, if it’s not defined it tries to find the java executable 
>> and use that’s parent directory as JAVA_HOME.
>>
>> So as you mentioned a “java –version” outputs 1.8 but your build is picking 
>> up 13, I would guess that you have a JAVA_HOME environment variable set to 
>> the Java 13 version.
>>
>> Chris
>>
>>
>> Von: Harbs mailto:harbs.li...@gmail.com>>
>> Datum: Dienstag, 1. Dezember 2020 um 13:45
>> An: dev@royale.apache.org <mailto:dev@royale.apache.org> 
>> mailto:dev@royale.apache.org>>
>> Betreff: Re: Release Step 003 Succeeded
>> I did some research.
>>
>> I have Java 1.8 installed, but I also have openjdk 13 installed using 
>> MacBrew.
>>
>> A fresh build of Maven (mvn clean install) on a fresh copy of the compiler 
>> repo also seems to use version 13.
>>
>> I guess I can probably uninstall openjdk, but that begs the question as to 
>> why Maven is using it considering my default JDK is 1.8.
>>
>> I think the Maven build should be fixed so the correct target is always used.
>>
>>> On Nov 30, 2020, at 6:25 PM, Alex Harui  wrote:
>>>
>>> IMO, it would be worth it to get the exact build of the JDK.  If 231 has 
>>> different ways of outputting some Java, then you can't get reproducible 
>>> binaries.
>>>
>>> It is also possible that some other hash table is iterated differently for 
>>> some reason and needs to have its iteration controlled.  I don't think 
>>> anyone has tried to do an exhaustive search of the Java code to ensure 
>>> iteration order.  We just keep finding and fixing them as we do the 
>>> releases.
>>>
>>> -Alex
>>>
>>> On 11/30/20, 2:05 AM, "Harbs" >> <mailto:harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com 
>>> <mailto:harbs.li...@gmail.com>>> wrote:
>>>

AW: Release Step 003 Succeeded

[Christofer Dutz]

Hi Harbs,

let me guess … you installed Maven via homebrew?

That would explain this behavior. I would expect the homebrew maven 
installation to be directly tied to that particular Java version.

I think I never installed Maven other than downloading a zip and unpacking it 
and sticking the bin directory on the path.


Chris


Von: Harbs 
Datum: Mittwoch, 2. Dezember 2020 um 13:09
An: dev@royale.apache.org 
Betreff: Re: Release Step 003 Succeeded
DIrectly.

Well, things get more and more interesting:

brew uninstall openjdk
Error: Refusing to uninstall /usr/local/Cellar/openjdk/13.0.2+8_2
because it is required by maven, which is currently installed.
You can override this and force removal with:
  brew uninstall --ignore-dependencies openjdk

I probably installed maven using HomeBrew which pulls in openjdk 13 as a 
dependency. I guess that explains why I only get JDK 13 when I use Maven.

Not being able to install Maven using HomeBrew is a pretty annoying limitation. 
Is there any other way around this problem?

> On Dec 2, 2020, at 12:11 PM, Christofer Dutz  
> wrote:
>
> Hi Harbs,
>
> Are you running the maven build directly/manually? Or is this triggered by an 
> IDE or Ant script?
> Cause I usually run most of my builds in IntelliJ and there I simply select 
> the JDK and it sort of magically gets selected (I don’t have JAVA_HOME set 
> explicitly either)
>
> Chris
>
>
>
> Von: Harbs 
> Datum: Dienstag, 1. Dezember 2020 um 19:28
> An: dev@royale.apache.org 
> Betreff: Re: Release Step 003 Succeeded
> echo $JAVA_HOME returns an empty string, so I really don’t think JAVA_HOME is 
> playing a role. It could be MacBrew uses a symlink which Maven places as 
> higher priority than my system default. I’ll play some more later or tomorrow.
>
>> On Dec 1, 2020, at 3:51 PM, Christofer Dutz  
>> wrote:
>>
>> Hi Harbs,
>>
>> I usually build PLC4X with each JDK from 1.8 to currently 15 and its super 
>> easy to do so. Have you checked if any JAVA_HOME is defined?
>>
>> Cause I checked the mvn script and it checks if JAVA_HOME is defined, if it 
>> is, it uses that, if it’s not defined it tries to find the java executable 
>> and use that’s parent directory as JAVA_HOME.
>>
>> So as you mentioned a “java –version” outputs 1.8 but your build is picking 
>> up 13, I would guess that you have a JAVA_HOME environment variable set to 
>> the Java 13 version.
>>
>> Chris
>>
>>
>> Von: Harbs mailto:harbs.li...@gmail.com>>
>> Datum: Dienstag, 1. Dezember 2020 um 13:45
>> An: dev@royale.apache.org <mailto:dev@royale.apache.org> 
>> mailto:dev@royale.apache.org>>
>> Betreff: Re: Release Step 003 Succeeded
>> I did some research.
>>
>> I have Java 1.8 installed, but I also have openjdk 13 installed using 
>> MacBrew.
>>
>> A fresh build of Maven (mvn clean install) on a fresh copy of the compiler 
>> repo also seems to use version 13.
>>
>> I guess I can probably uninstall openjdk, but that begs the question as to 
>> why Maven is using it considering my default JDK is 1.8.
>>
>> I think the Maven build should be fixed so the correct target is always used.
>>
>>> On Nov 30, 2020, at 6:25 PM, Alex Harui  wrote:
>>>
>>> IMO, it would be worth it to get the exact build of the JDK.  If 231 has 
>>> different ways of outputting some Java, then you can't get reproducible 
>>> binaries.
>>>
>>> It is also possible that some other hash table is iterated differently for 
>>> some reason and needs to have its iteration controlled.  I don't think 
>>> anyone has tried to do an exhaustive search of the Java code to ensure 
>>> iteration order.  We just keep finding and fixing them as we do the 
>>> releases.
>>>
>>> -Alex
>>>
>>> On 11/30/20, 2:05 AM, "Harbs" >> <mailto:harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com 
>>> <mailto:harbs.li...@gmail.com>>> wrote:
>>>
>>>  Java version seems to be pretty close:
>>>
>>>  C:\jenkins\workspace\Royale_Release_Step_002>java -version
>>>  Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
>>>  java version "1.8.0_201"
>>>  Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
>>>  Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)
>>>
>>>  Harbss-Mac-mini:release harbs$ java -version
>>>  java version "1.8.0_231"
>>>  Java(TM) SE Runtime Environment (build 1.8.0_231-b11)
>>>  Java HotSpot(TM) 64-Bit Server VM (build 25.231-b11, mixed mode)
>>>
&

Re: Release Step 003 Succeeded

[Harbs]

DIrectly.

Well, things get more and more interesting:

brew uninstall openjdk
Error: Refusing to uninstall /usr/local/Cellar/openjdk/13.0.2+8_2
because it is required by maven, which is currently installed.
You can override this and force removal with:
  brew uninstall --ignore-dependencies openjdk

I probably installed maven using HomeBrew which pulls in openjdk 13 as a 
dependency. I guess that explains why I only get JDK 13 when I use Maven.

Not being able to install Maven using HomeBrew is a pretty annoying limitation. 
Is there any other way around this problem?

> On Dec 2, 2020, at 12:11 PM, Christofer Dutz  
> wrote:
> 
> Hi Harbs,
> 
> Are you running the maven build directly/manually? Or is this triggered by an 
> IDE or Ant script?
> Cause I usually run most of my builds in IntelliJ and there I simply select 
> the JDK and it sort of magically gets selected (I don’t have JAVA_HOME set 
> explicitly either)
> 
> Chris
> 
> 
> 
> Von: Harbs 
> Datum: Dienstag, 1. Dezember 2020 um 19:28
> An: dev@royale.apache.org 
> Betreff: Re: Release Step 003 Succeeded
> echo $JAVA_HOME returns an empty string, so I really don’t think JAVA_HOME is 
> playing a role. It could be MacBrew uses a symlink which Maven places as 
> higher priority than my system default. I’ll play some more later or tomorrow.
> 
>> On Dec 1, 2020, at 3:51 PM, Christofer Dutz  
>> wrote:
>> 
>> Hi Harbs,
>> 
>> I usually build PLC4X with each JDK from 1.8 to currently 15 and its super 
>> easy to do so. Have you checked if any JAVA_HOME is defined?
>> 
>> Cause I checked the mvn script and it checks if JAVA_HOME is defined, if it 
>> is, it uses that, if it’s not defined it tries to find the java executable 
>> and use that’s parent directory as JAVA_HOME.
>> 
>> So as you mentioned a “java –version” outputs 1.8 but your build is picking 
>> up 13, I would guess that you have a JAVA_HOME environment variable set to 
>> the Java 13 version.
>> 
>> Chris
>> 
>> 
>> Von: Harbs mailto:harbs.li...@gmail.com>>
>> Datum: Dienstag, 1. Dezember 2020 um 13:45
>> An: dev@royale.apache.org <mailto:dev@royale.apache.org> 
>> mailto:dev@royale.apache.org>>
>> Betreff: Re: Release Step 003 Succeeded
>> I did some research.
>> 
>> I have Java 1.8 installed, but I also have openjdk 13 installed using 
>> MacBrew.
>> 
>> A fresh build of Maven (mvn clean install) on a fresh copy of the compiler 
>> repo also seems to use version 13.
>> 
>> I guess I can probably uninstall openjdk, but that begs the question as to 
>> why Maven is using it considering my default JDK is 1.8.
>> 
>> I think the Maven build should be fixed so the correct target is always used.
>> 
>>> On Nov 30, 2020, at 6:25 PM, Alex Harui  wrote:
>>> 
>>> IMO, it would be worth it to get the exact build of the JDK.  If 231 has 
>>> different ways of outputting some Java, then you can't get reproducible 
>>> binaries.
>>> 
>>> It is also possible that some other hash table is iterated differently for 
>>> some reason and needs to have its iteration controlled.  I don't think 
>>> anyone has tried to do an exhaustive search of the Java code to ensure 
>>> iteration order.  We just keep finding and fixing them as we do the 
>>> releases.
>>> 
>>> -Alex
>>> 
>>> On 11/30/20, 2:05 AM, "Harbs" >> <mailto:harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com 
>>> <mailto:harbs.li...@gmail.com>>> wrote:
>>> 
>>>  Java version seems to be pretty close:
>>> 
>>>  C:\jenkins\workspace\Royale_Release_Step_002>java -version
>>>  Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
>>>  java version "1.8.0_201"
>>>  Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
>>>  Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)
>>> 
>>>  Harbss-Mac-mini:release harbs$ java -version
>>>  java version "1.8.0_231"
>>>  Java(TM) SE Runtime Environment (build 1.8.0_231-b11)
>>>  Java HotSpot(TM) 64-Bit Server VM (build 25.231-b11, mixed mode)
>>> 
>>> 
>>>  When comparing the royale-maven-plugin jar, almost all the classes have 
>>> different binaries.
>>> 
>>>  The manifest has the similar content, but in a different order:
>>> 
>>>  The only difference is the Build-Jdk-Spec which is 1.8 in the artifacts, 
>>> but 13 in the source build.
>>> 
>>>  Artifacts:
>>>  Ma

AW: Release Step 003 Succeeded

[Christofer Dutz]

Hi Harbs,

Are you running the maven build directly/manually? Or is this triggered by an 
IDE or Ant script?
Cause I usually run most of my builds in IntelliJ and there I simply select the 
JDK and it sort of magically gets selected (I don’t have JAVA_HOME set 
explicitly either)

Chris



Von: Harbs 
Datum: Dienstag, 1. Dezember 2020 um 19:28
An: dev@royale.apache.org 
Betreff: Re: Release Step 003 Succeeded
echo $JAVA_HOME returns an empty string, so I really don’t think JAVA_HOME is 
playing a role. It could be MacBrew uses a symlink which Maven places as higher 
priority than my system default. I’ll play some more later or tomorrow.

> On Dec 1, 2020, at 3:51 PM, Christofer Dutz  wrote:
>
> Hi Harbs,
>
> I usually build PLC4X with each JDK from 1.8 to currently 15 and its super 
> easy to do so. Have you checked if any JAVA_HOME is defined?
>
> Cause I checked the mvn script and it checks if JAVA_HOME is defined, if it 
> is, it uses that, if it’s not defined it tries to find the java executable 
> and use that’s parent directory as JAVA_HOME.
>
> So as you mentioned a “java –version” outputs 1.8 but your build is picking 
> up 13, I would guess that you have a JAVA_HOME environment variable set to 
> the Java 13 version.
>
> Chris
>
>
> Von: Harbs mailto:harbs.li...@gmail.com>>
> Datum: Dienstag, 1. Dezember 2020 um 13:45
> An: dev@royale.apache.org <mailto:dev@royale.apache.org> 
> mailto:dev@royale.apache.org>>
> Betreff: Re: Release Step 003 Succeeded
> I did some research.
>
> I have Java 1.8 installed, but I also have openjdk 13 installed using MacBrew.
>
> A fresh build of Maven (mvn clean install) on a fresh copy of the compiler 
> repo also seems to use version 13.
>
> I guess I can probably uninstall openjdk, but that begs the question as to 
> why Maven is using it considering my default JDK is 1.8.
>
> I think the Maven build should be fixed so the correct target is always used.
>
>> On Nov 30, 2020, at 6:25 PM, Alex Harui  wrote:
>>
>> IMO, it would be worth it to get the exact build of the JDK.  If 231 has 
>> different ways of outputting some Java, then you can't get reproducible 
>> binaries.
>>
>> It is also possible that some other hash table is iterated differently for 
>> some reason and needs to have its iteration controlled.  I don't think 
>> anyone has tried to do an exhaustive search of the Java code to ensure 
>> iteration order.  We just keep finding and fixing them as we do the releases.
>>
>> -Alex
>>
>> On 11/30/20, 2:05 AM, "Harbs" > <mailto:harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com 
>> <mailto:harbs.li...@gmail.com>>> wrote:
>>
>>   Java version seems to be pretty close:
>>
>>   C:\jenkins\workspace\Royale_Release_Step_002>java -version
>>   Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
>>   java version "1.8.0_201"
>>   Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
>>   Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)
>>
>>   Harbss-Mac-mini:release harbs$ java -version
>>   java version "1.8.0_231"
>>   Java(TM) SE Runtime Environment (build 1.8.0_231-b11)
>>   Java HotSpot(TM) 64-Bit Server VM (build 25.231-b11, mixed mode)
>>
>>
>>   When comparing the royale-maven-plugin jar, almost all the classes have 
>> different binaries.
>>
>>   The manifest has the similar content, but in a different order:
>>
>>   The only difference is the Build-Jdk-Spec which is 1.8 in the artifacts, 
>> but 13 in the source build.
>>
>>   Artifacts:
>>   Manifest-Version: 1.0
>>   Implementation-Title: Apache Royale: Royale Maven Plugin
>>   Implementation-Version: 0.9.8
>>   Specification-Vendor: The Apache Software Foundation
>>   Specification-Title: Apache Royale: Royale Maven Plugin
>>   Build-Jdk-Spec: 1.8
>>   Created-By: Maven Jar Plugin 3.2.0
>>   Specification-Version: 0.9
>>   Implementation-Vendor: The Apache Software Foundation
>>
>>
>>   Source:
>>   Manifest-Version: 1.0
>>   Created-By: Maven Jar Plugin 3.2.0
>>   Build-Jdk-Spec: 13
>>   Specification-Title: Apache Royale: Royale Maven Plugin
>>   Specification-Version: 0.9
>>   Specification-Vendor: The Apache Software Foundation
>>   Implementation-Title: Apache Royale: Royale Maven Plugin
>>   Implementation-Version: 0.9.8
>>   Implementation-Vendor: The Apache Software Foundation
>>
>>   I’m clueless as to where the version 13 spec is coming from:
>>
>>   Here’s what I get when I check my java jdks:
>>
>>   /usr/

Re: Release Step 003 Succeeded

[Carlos Rovira]

Hi Harbs,

for MacBrew you refer to HomeBrew?
I use brew in mac too and to manage JAVA_HOME I use jenv (installed through
brew of course).
You can check this tutorial I made some time ago that talks about
installing royale with brew, jenv, and more.

https://github.com/apache/royale-asjs/wiki/Apache-Royale-OS-X-development-environment-in-five-minutes

I think I updated this year when I changed my macbookpro, so I think is
mostly up to date

HTH


El mar, 1 dic 2020 a las 19:28, Harbs () escribió:

> echo $JAVA_HOME returns an empty string, so I really don’t think JAVA_HOME
> is playing a role. It could be MacBrew uses a symlink which Maven places as
> higher priority than my system default. I’ll play some more later or
> tomorrow.
>
> > On Dec 1, 2020, at 3:51 PM, Christofer Dutz 
> wrote:
> >
> > Hi Harbs,
> >
> > I usually build PLC4X with each JDK from 1.8 to currently 15 and its
> super easy to do so. Have you checked if any JAVA_HOME is defined?
> >
> > Cause I checked the mvn script and it checks if JAVA_HOME is defined, if
> it is, it uses that, if it’s not defined it tries to find the java
> executable and use that’s parent directory as JAVA_HOME.
> >
> > So as you mentioned a “java –version” outputs 1.8 but your build is
> picking up 13, I would guess that you have a JAVA_HOME environment variable
> set to the Java 13 version.
> >
> > Chris
> >
> >
> > Von: Harbs mailto:harbs.li...@gmail.com>>
> > Datum: Dienstag, 1. Dezember 2020 um 13:45
> > An: dev@royale.apache.org <mailto:dev@royale.apache.org> <
> dev@royale.apache.org <mailto:dev@royale.apache.org>>
> > Betreff: Re: Release Step 003 Succeeded
> > I did some research.
> >
> > I have Java 1.8 installed, but I also have openjdk 13 installed using
> MacBrew.
> >
> > A fresh build of Maven (mvn clean install) on a fresh copy of the
> compiler repo also seems to use version 13.
> >
> > I guess I can probably uninstall openjdk, but that begs the question as
> to why Maven is using it considering my default JDK is 1.8.
> >
> > I think the Maven build should be fixed so the correct target is always
> used.
> >
> >> On Nov 30, 2020, at 6:25 PM, Alex Harui 
> wrote:
> >>
> >> IMO, it would be worth it to get the exact build of the JDK.  If 231
> has different ways of outputting some Java, then you can't get reproducible
> binaries.
> >>
> >> It is also possible that some other hash table is iterated differently
> for some reason and needs to have its iteration controlled.  I don't think
> anyone has tried to do an exhaustive search of the Java code to ensure
> iteration order.  We just keep finding and fixing them as we do the
> releases.
> >>
> >> -Alex
> >>
> >> On 11/30/20, 2:05 AM, "Harbs"  harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com  harbs.li...@gmail.com>>> wrote:
> >>
> >>   Java version seems to be pretty close:
> >>
> >>   C:\jenkins\workspace\Royale_Release_Step_002>java -version
> >>   Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
> >>   java version "1.8.0_201"
> >>   Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
> >>   Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)
> >>
> >>   Harbss-Mac-mini:release harbs$ java -version
> >>   java version "1.8.0_231"
> >>   Java(TM) SE Runtime Environment (build 1.8.0_231-b11)
> >>   Java HotSpot(TM) 64-Bit Server VM (build 25.231-b11, mixed mode)
> >>
> >>
> >>   When comparing the royale-maven-plugin jar, almost all the classes
> have different binaries.
> >>
> >>   The manifest has the similar content, but in a different order:
> >>
> >>   The only difference is the Build-Jdk-Spec which is 1.8 in the
> artifacts, but 13 in the source build.
> >>
> >>   Artifacts:
> >>   Manifest-Version: 1.0
> >>   Implementation-Title: Apache Royale: Royale Maven Plugin
> >>   Implementation-Version: 0.9.8
> >>   Specification-Vendor: The Apache Software Foundation
> >>   Specification-Title: Apache Royale: Royale Maven Plugin
> >>   Build-Jdk-Spec: 1.8
> >>   Created-By: Maven Jar Plugin 3.2.0
> >>   Specification-Version: 0.9
> >>   Implementation-Vendor: The Apache Software Foundation
> >>
> >>
> >>   Source:
> >>   Manifest-Version: 1.0
> >>   Created-By: Maven Jar Plugin 3.2.0
> >>   Build-Jdk-Spec: 13
> >>   Specification-Title: Apa

Re: Release Step 003 Succeeded

[Harbs]

echo $JAVA_HOME returns an empty string, so I really don’t think JAVA_HOME is 
playing a role. It could be MacBrew uses a symlink which Maven places as higher 
priority than my system default. I’ll play some more later or tomorrow.

> On Dec 1, 2020, at 3:51 PM, Christofer Dutz  wrote:
> 
> Hi Harbs,
> 
> I usually build PLC4X with each JDK from 1.8 to currently 15 and its super 
> easy to do so. Have you checked if any JAVA_HOME is defined?
> 
> Cause I checked the mvn script and it checks if JAVA_HOME is defined, if it 
> is, it uses that, if it’s not defined it tries to find the java executable 
> and use that’s parent directory as JAVA_HOME.
> 
> So as you mentioned a “java –version” outputs 1.8 but your build is picking 
> up 13, I would guess that you have a JAVA_HOME environment variable set to 
> the Java 13 version.
> 
> Chris
> 
> 
> Von: Harbs mailto:harbs.li...@gmail.com>>
> Datum: Dienstag, 1. Dezember 2020 um 13:45
> An: dev@royale.apache.org <mailto:dev@royale.apache.org> 
> mailto:dev@royale.apache.org>>
> Betreff: Re: Release Step 003 Succeeded
> I did some research.
> 
> I have Java 1.8 installed, but I also have openjdk 13 installed using MacBrew.
> 
> A fresh build of Maven (mvn clean install) on a fresh copy of the compiler 
> repo also seems to use version 13.
> 
> I guess I can probably uninstall openjdk, but that begs the question as to 
> why Maven is using it considering my default JDK is 1.8.
> 
> I think the Maven build should be fixed so the correct target is always used.
> 
>> On Nov 30, 2020, at 6:25 PM, Alex Harui  wrote:
>> 
>> IMO, it would be worth it to get the exact build of the JDK.  If 231 has 
>> different ways of outputting some Java, then you can't get reproducible 
>> binaries.
>> 
>> It is also possible that some other hash table is iterated differently for 
>> some reason and needs to have its iteration controlled.  I don't think 
>> anyone has tried to do an exhaustive search of the Java code to ensure 
>> iteration order.  We just keep finding and fixing them as we do the releases.
>> 
>> -Alex
>> 
>> On 11/30/20, 2:05 AM, "Harbs" > <mailto:harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com 
>> <mailto:harbs.li...@gmail.com>>> wrote:
>> 
>>   Java version seems to be pretty close:
>> 
>>   C:\jenkins\workspace\Royale_Release_Step_002>java -version
>>   Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
>>   java version "1.8.0_201"
>>   Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
>>   Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)
>> 
>>   Harbss-Mac-mini:release harbs$ java -version
>>   java version "1.8.0_231"
>>   Java(TM) SE Runtime Environment (build 1.8.0_231-b11)
>>   Java HotSpot(TM) 64-Bit Server VM (build 25.231-b11, mixed mode)
>> 
>> 
>>   When comparing the royale-maven-plugin jar, almost all the classes have 
>> different binaries.
>> 
>>   The manifest has the similar content, but in a different order:
>> 
>>   The only difference is the Build-Jdk-Spec which is 1.8 in the artifacts, 
>> but 13 in the source build.
>> 
>>   Artifacts:
>>   Manifest-Version: 1.0
>>   Implementation-Title: Apache Royale: Royale Maven Plugin
>>   Implementation-Version: 0.9.8
>>   Specification-Vendor: The Apache Software Foundation
>>   Specification-Title: Apache Royale: Royale Maven Plugin
>>   Build-Jdk-Spec: 1.8
>>   Created-By: Maven Jar Plugin 3.2.0
>>   Specification-Version: 0.9
>>   Implementation-Vendor: The Apache Software Foundation
>> 
>> 
>>   Source:
>>   Manifest-Version: 1.0
>>   Created-By: Maven Jar Plugin 3.2.0
>>   Build-Jdk-Spec: 13
>>   Specification-Title: Apache Royale: Royale Maven Plugin
>>   Specification-Version: 0.9
>>   Specification-Vendor: The Apache Software Foundation
>>   Implementation-Title: Apache Royale: Royale Maven Plugin
>>   Implementation-Version: 0.9.8
>>   Implementation-Vendor: The Apache Software Foundation
>> 
>>   I’m clueless as to where the version 13 spec is coming from:
>> 
>>   Here’s what I get when I check my java jdks:
>> 
>>   /usr/libexec/java_home -V
>> 
>>   Matching Java Virtual Machines (3):
>>   1.8.0_231, x86_64: "Java SE 8" 
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_231.jdk/Contents/Home
>>   1.6.0_65-b14-468, x86_64:  "Java SE 6" 
>> /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
>>   1.6.0_6

AW: Release Step 003 Succeeded

[Christofer Dutz]

Hi Harbs,

I usually build PLC4X with each JDK from 1.8 to currently 15 and its super easy 
to do so. Have you checked if any JAVA_HOME is defined?

Cause I checked the mvn script and it checks if JAVA_HOME is defined, if it is, 
it uses that, if it’s not defined it tries to find the java executable and use 
that’s parent directory as JAVA_HOME.

So as you mentioned a “java –version” outputs 1.8 but your build is picking up 
13, I would guess that you have a JAVA_HOME environment variable set to the 
Java 13 version.

Chris


Von: Harbs 
Datum: Dienstag, 1. Dezember 2020 um 13:45
An: dev@royale.apache.org 
Betreff: Re: Release Step 003 Succeeded
I did some research.

I have Java 1.8 installed, but I also have openjdk 13 installed using MacBrew.

A fresh build of Maven (mvn clean install) on a fresh copy of the compiler repo 
also seems to use version 13.

I guess I can probably uninstall openjdk, but that begs the question as to why 
Maven is using it considering my default JDK is 1.8.

I think the Maven build should be fixed so the correct target is always used.

> On Nov 30, 2020, at 6:25 PM, Alex Harui  wrote:
>
> IMO, it would be worth it to get the exact build of the JDK.  If 231 has 
> different ways of outputting some Java, then you can't get reproducible 
> binaries.
>
> It is also possible that some other hash table is iterated differently for 
> some reason and needs to have its iteration controlled.  I don't think anyone 
> has tried to do an exhaustive search of the Java code to ensure iteration 
> order.  We just keep finding and fixing them as we do the releases.
>
> -Alex
>
> On 11/30/20, 2:05 AM, "Harbs"  <mailto:harbs.li...@gmail.com>> wrote:
>
>Java version seems to be pretty close:
>
>C:\jenkins\workspace\Royale_Release_Step_002>java -version
>Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
>java version "1.8.0_201"
>Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
>Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)
>
>Harbss-Mac-mini:release harbs$ java -version
>java version "1.8.0_231"
>Java(TM) SE Runtime Environment (build 1.8.0_231-b11)
>Java HotSpot(TM) 64-Bit Server VM (build 25.231-b11, mixed mode)
>
>
>When comparing the royale-maven-plugin jar, almost all the classes have 
> different binaries.
>
>The manifest has the similar content, but in a different order:
>
>The only difference is the Build-Jdk-Spec which is 1.8 in the artifacts, 
> but 13 in the source build.
>
>Artifacts:
>Manifest-Version: 1.0
>Implementation-Title: Apache Royale: Royale Maven Plugin
>Implementation-Version: 0.9.8
>Specification-Vendor: The Apache Software Foundation
>Specification-Title: Apache Royale: Royale Maven Plugin
>Build-Jdk-Spec: 1.8
>Created-By: Maven Jar Plugin 3.2.0
>Specification-Version: 0.9
>Implementation-Vendor: The Apache Software Foundation
>
>
>Source:
>Manifest-Version: 1.0
>Created-By: Maven Jar Plugin 3.2.0
>Build-Jdk-Spec: 13
>Specification-Title: Apache Royale: Royale Maven Plugin
>Specification-Version: 0.9
>Specification-Vendor: The Apache Software Foundation
>Implementation-Title: Apache Royale: Royale Maven Plugin
>Implementation-Version: 0.9.8
>Implementation-Vendor: The Apache Software Foundation
>
>I’m clueless as to where the version 13 spec is coming from:
>
>Here’s what I get when I check my java jdks:
>
>/usr/libexec/java_home -V
>
>Matching Java Virtual Machines (3):
>1.8.0_231, x86_64: "Java SE 8" 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_231.jdk/Contents/Home
>1.6.0_65-b14-468, x86_64:  "Java SE 6" 
> /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
>1.6.0_65-b14-468, i386:"Java SE 6" 
> /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
>
>/Library/Java/JavaVirtualMachines/jdk1.8.0_231.jdk/Contents/Home
>
>
>> On Nov 30, 2020, at 4:26 AM, Alex Harui  wrote:
>>
>> The "snapshot" in the script output should just be checking if the release 
>> is for jburg-types as well as the main jars (which it isn't).
>>
>> The main pom.xml should not be using -SNAPSHOT for jburg-types and 
>> build-tools.   It seems ok to me.
>>
>> Verify the Java version on the system that has a difference.  It needs to be 
>> the same as the CI server.  Then diff the two jars and see what is 
>> different.  Try unzipping each jar in a separate directory and compare the 
>> directories.
>>
>> HTH,
>> -Alex
>>
>>
>> On 11/29/20, 4:05 AM

Re: Release Step 003 Succeeded

[Andrew Wetmore]

;
> >>   Yes. But that was compiler-build-tools. This is compiler-jburg-types.
> >>
> >>> On Nov 29, 2020, at 2:02 PM, Piotr Zarzycki  <mailto:piotrzarzyck...@gmail.com>> wrote:
> >>>
> >>> In a Apache Maven central - when you staged artifacts (I don't remember
> >>> url), after vote on release you need to click there to make that
> release
> >>> happen. Did you do something like this ?
> >>>
> >>> niedz., 29 lis 2020 o 12:44 Harbs  harbs.li...@gmail.com>> napisał(a):
> >>>
> >>>> I see that compiler-jburg-types is still 1.2.0-SNAPSHOT.
> >>>>
> >>>> Did I need to do a release on that in addition to
> compiler-build-tools?
> >>>>
> >>>> I really don’t understand all these Maven side-projects...
> >>>>
> >>>>> On Nov 29, 2020, at 1:38 PM, Harbs  harbs.li...@gmail.com>> wrote:
> >>>>>
> >>>>> I still cannot get it to work on that machine (MacBook Pro running
> >>>> Catalina).
> >>>>>
> >>>>> It did work on my main machine (Mac Mini running Mojave), but now I’m
> >>>> getting this failure:
> >>>>>
> >>>>> get-utils-version:
> >>>>>  [echo] utils version is 1.2.0-SNAPSHOT
> >>>>>
> >>>>> write-out-maven-jars-list:
> >>>>>
> >>>>> write-out-maven-utils-jars-list:
> >>>>>
> >>>>> compare-jars:
> >>>>>  [copy] Copying 1 file to /Apache/royale-compiler/temp_folder
> >>>>>
> >>>>> loopOnce:
> >>>>>  [copy] Copying 1 file to /Apache/royale-compiler/temp_folder
> >>>>>
> >>>>> notlast:
> >>>>>
> >>>>> get-jar-version:
> >>>>>
> >>>>> compare_files:
> >>>>>  [echo] comparing royale-maven-plugin-0.9.8
> >>>>>
> >>>>> BUILD FAILED
> >>>>> /Apache/royale-compiler/releasesteps.xml:213: The following error
> >>>> occurred while executing this line:
> >>>>> /Apache/royale-compiler/releasesteps.xml:241: The following error
> >>>> occurred while executing this line:
> >>>>> /Apache/royale-compiler/releasesteps.xml:248: The following error
> >>>> occurred while executing this line:
> >>>>> /Apache/royale-compiler/releasesteps.xml:283:
> >>>> royale-maven-plugin-0.9.8.jar does not match
> >>>>>
> >>>>> I don’t know why I’m not getting a reproducible build, but I wonder
> if
> >>>> it’s because it’s using 1.2.0-SNAPSHOT instead of 1.2.1.
> >>>>>
> >>>>> I don’t know why that would be. I’m on the release branch.
> >>>>>
> >>>>>> On Nov 27, 2020, at 1:03 AM, Alex Harui  <mailto:aha...@adobe.com.INVALID>>
> >>>> wrote:
> >>>>>>
> >>>>>> IIRC, on your local machine, if you clone the repo and run "mvn
> clean
> >>>> install", it should allow you to type a response and then that machine
> >>>> should be ok to use after that.
> >>>>>>
> >>>>>> -Alex
> >>>>>>
> >>>>>> On 11/26/20, 1:46 PM, "Harbs"  harbs.li...@gmail.com>> wrote:
> >>>>>>
> >>>>>> That’s on my local machine. Passing the Dcom option to the ant
> script
> >>>> doesn’t help.
> >>>>>>
> >>>>>> How would I manually get the Adobe artifacts on my machine?
> >>>>>>
> >>>>>>> On Nov 26, 2020, at 11:18 PM, Christofer Dutz <
> >>>> christofer.d...@c-ware.de <mailto:christofer.d...@c-ware.de>> wrote:
> >>>>>>>
> >>>>>>> I can tell you what’s going on here.
> >>>>>>>
> >>>>>>> You are building on a system where the Adobe artifacts aren’t
> >>>> available in the maven local repo.
> >>>>>>> So the mavenizer (AKA maven extension I built to make non maven
> >>>> artifacts available as Maven artifacts) is kicking in. It expects a
> user to
> >>>> accept the license terms. It seems the MAC address of the network
> >>>> configuration of the build mach

Re: Release Step 003 Succeeded

[Harbs]

; 
>>> niedz., 29 lis 2020 o 12:44 Harbs >> <mailto:harbs.li...@gmail.com>> napisał(a):
>>> 
>>>> I see that compiler-jburg-types is still 1.2.0-SNAPSHOT.
>>>> 
>>>> Did I need to do a release on that in addition to compiler-build-tools?
>>>> 
>>>> I really don’t understand all these Maven side-projects...
>>>> 
>>>>> On Nov 29, 2020, at 1:38 PM, Harbs >>>> <mailto:harbs.li...@gmail.com>> wrote:
>>>>> 
>>>>> I still cannot get it to work on that machine (MacBook Pro running
>>>> Catalina).
>>>>> 
>>>>> It did work on my main machine (Mac Mini running Mojave), but now I’m
>>>> getting this failure:
>>>>> 
>>>>> get-utils-version:
>>>>>  [echo] utils version is 1.2.0-SNAPSHOT
>>>>> 
>>>>> write-out-maven-jars-list:
>>>>> 
>>>>> write-out-maven-utils-jars-list:
>>>>> 
>>>>> compare-jars:
>>>>>  [copy] Copying 1 file to /Apache/royale-compiler/temp_folder
>>>>> 
>>>>> loopOnce:
>>>>>  [copy] Copying 1 file to /Apache/royale-compiler/temp_folder
>>>>> 
>>>>> notlast:
>>>>> 
>>>>> get-jar-version:
>>>>> 
>>>>> compare_files:
>>>>>  [echo] comparing royale-maven-plugin-0.9.8
>>>>> 
>>>>> BUILD FAILED
>>>>> /Apache/royale-compiler/releasesteps.xml:213: The following error
>>>> occurred while executing this line:
>>>>> /Apache/royale-compiler/releasesteps.xml:241: The following error
>>>> occurred while executing this line:
>>>>> /Apache/royale-compiler/releasesteps.xml:248: The following error
>>>> occurred while executing this line:
>>>>> /Apache/royale-compiler/releasesteps.xml:283:
>>>> royale-maven-plugin-0.9.8.jar does not match
>>>>> 
>>>>> I don’t know why I’m not getting a reproducible build, but I wonder if
>>>> it’s because it’s using 1.2.0-SNAPSHOT instead of 1.2.1.
>>>>> 
>>>>> I don’t know why that would be. I’m on the release branch.
>>>>> 
>>>>>> On Nov 27, 2020, at 1:03 AM, Alex Harui >>>>> <mailto:aha...@adobe.com.INVALID>>
>>>> wrote:
>>>>>> 
>>>>>> IIRC, on your local machine, if you clone the repo and run "mvn clean
>>>> install", it should allow you to type a response and then that machine
>>>> should be ok to use after that.
>>>>>> 
>>>>>> -Alex
>>>>>> 
>>>>>> On 11/26/20, 1:46 PM, "Harbs" >>>>> <mailto:harbs.li...@gmail.com>> wrote:
>>>>>> 
>>>>>> That’s on my local machine. Passing the Dcom option to the ant script
>>>> doesn’t help.
>>>>>> 
>>>>>> How would I manually get the Adobe artifacts on my machine?
>>>>>> 
>>>>>>> On Nov 26, 2020, at 11:18 PM, Christofer Dutz <
>>>> christofer.d...@c-ware.de <mailto:christofer.d...@c-ware.de>> wrote:
>>>>>>> 
>>>>>>> I can tell you what’s going on here.
>>>>>>> 
>>>>>>> You are building on a system where the Adobe artifacts aren’t
>>>> available in the maven local repo.
>>>>>>> So the mavenizer (AKA maven extension I built to make non maven
>>>> artifacts available as Maven artifacts) is kicking in. It expects a user to
>>>> accept the license terms. It seems the MAC address of the network
>>>> configuration of the build machine changed. You need to pass
>>>>>>> 
>>>>>>> 
>>>> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
>>>>>>> 
>>>>>>> To the build job
>>>>>>> 
>>>>>>> Chris
>>>>>>> 
>>>>>>> 
>>>>>>> Von: Harbs mailto:harbs.li...@gmail.com>>
>>>>>>> Datum: Donnerstag, 26. November 2020 um 21:53
>>>>>>> An: Apache Royale Development >>>>>> <mailto:dev@royale.apache.org>>
>>>>>>> Betreff: Re: Relea

Re: Release Step 003 Succeeded

[Alex Harui]

-jars-list:
>>>> 
>>>> compare-jars:
>>>>   [copy] Copying 1 file to /Apache/royale-compiler/temp_folder
>>>> 
>>>> loopOnce:
>>>>   [copy] Copying 1 file to /Apache/royale-compiler/temp_folder
>>>> 
>>>> notlast:
>>>> 
>>>> get-jar-version:
>>>> 
>>>> compare_files:
>>>>   [echo] comparing royale-maven-plugin-0.9.8
>>>> 
>>>> BUILD FAILED
>>>> /Apache/royale-compiler/releasesteps.xml:213: The following error
>>> occurred while executing this line:
>>>> /Apache/royale-compiler/releasesteps.xml:241: The following error
>>> occurred while executing this line:
>>>> /Apache/royale-compiler/releasesteps.xml:248: The following error
>>> occurred while executing this line:
>>>> /Apache/royale-compiler/releasesteps.xml:283:
>>> royale-maven-plugin-0.9.8.jar does not match
>>>> 
>>>> I don’t know why I’m not getting a reproducible build, but I wonder if
>>> it’s because it’s using 1.2.0-SNAPSHOT instead of 1.2.1.
>>>> 
>>>> I don’t know why that would be. I’m on the release branch.
>>>> 
>>>>> On Nov 27, 2020, at 1:03 AM, Alex Harui 
>>> wrote:
>>>>> 
>>>>> IIRC, on your local machine, if you clone the repo and run "mvn clean
>>> install", it should allow you to type a response and then that machine
>>> should be ok to use after that.
>>>>> 
>>>>> -Alex
>>>>> 
>>>>> On 11/26/20, 1:46 PM, "Harbs"  wrote:
>>>>> 
>>>>> That’s on my local machine. Passing the Dcom option to the ant script
>>> doesn’t help.
>>>>> 
>>>>> How would I manually get the Adobe artifacts on my machine?
>>>>> 
>>>>>> On Nov 26, 2020, at 11:18 PM, Christofer Dutz <
>>> christofer.d...@c-ware.de> wrote:
>>>>>> 
>>>>>> I can tell you what’s going on here.
>>>>>> 
>>>>>> You are building on a system where the Adobe artifacts aren’t
>>> available in the maven local repo.
>>>>>> So the mavenizer (AKA maven extension I built to make non maven
>>> artifacts available as Maven artifacts) is kicking in. It expects a 
user to
>>> accept the license terms. It seems the MAC address of the network
>>> configuration of the build machine changed. You need to pass
>>>>>> 
>>>>>> 
>>> 
-Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
>>>>>> 
>>>>>> To the build job
>>>>>> 
>>>>>> Chris
>>>>>> 
>>>>>> 
>>>>>> Von: Harbs 
>>>>>> Datum: Donnerstag, 26. November 2020 um 21:53
>>>>>> An: Apache Royale Development 
>>>>>> Betreff: Re: Release Step 003 Succeeded
>>>>>> I don’t get it. I’m getting an endless loop of:
>>>>>> 
>>>>>> [exec] The Adobe SDK license agreement applies to the Adobe Flash
>>> Player playerglobal.swc. Do you want to install the Adobe Flash Player
>>> playerglobal.swc?
>>>>>> [exec] (In a non-interactive build such as a CI server build,
>>> alternatively to typing y or yes you can also set a system property
>>> containing your system which is interpreted as equivalent to accepting 
by
>>> typing y or yes:
>>> 
-Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
>>> )
>>>>>> [exec] Do you accept (Yes/No) ? Your System-Id: b57aca16
>>>>>> 
>>>>>> when I run:
>>>>>>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
>>>>>> 
>>>>>> Where is that coming from and why?
>>>>>> 
>>>>>>> On Nov 26, 2020, at 9:16 PM, apacheroyal...@gmail.com wrote:
>>>>>>> 
>>>>>>> From the royale-compiler repo:
>>>>>>> 1. Run:
>>>>>>> ant 

AW: Release Step 003 Succeeded

[Christofer Dutz]

Hi Harbs,

but that means that in one case it’s actually built with Java 13 … which would 
explain the differences.
But from what you checked on the console … only the major version should have 
an impact. Not sure if there’s a difference if the Oracle JDK is used on one 
and OpenJDK on another, even if the major number is the dame.

Just an idea … even if you execute “java –version” on the command-line … the 
build job could be using a different version per configuration?

Is “Artifacts” built on your machine and “Source” is built on the CI server, or 
is it the other way around?

And not necessarily all Java SDKs have to be in the same location … I for 
example use sdkman to switch them and that puts them in a totally different 
location.

Chris

Von: Harbs 
Datum: Montag, 30. November 2020 um 11:05
An: dev@royale.apache.org 
Betreff: Re: Release Step 003 Succeeded
Java version seems to be pretty close:

C:\jenkins\workspace\Royale_Release_Step_002>java -version
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)

Harbss-Mac-mini:release harbs$ java -version
java version "1.8.0_231"
Java(TM) SE Runtime Environment (build 1.8.0_231-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.231-b11, mixed mode)


When comparing the royale-maven-plugin jar, almost all the classes have 
different binaries.

The manifest has the similar content, but in a different order:

The only difference is the Build-Jdk-Spec which is 1.8 in the artifacts, but 13 
in the source build.

Artifacts:
Manifest-Version: 1.0
Implementation-Title: Apache Royale: Royale Maven Plugin
Implementation-Version: 0.9.8
Specification-Vendor: The Apache Software Foundation
Specification-Title: Apache Royale: Royale Maven Plugin
Build-Jdk-Spec: 1.8
Created-By: Maven Jar Plugin 3.2.0
Specification-Version: 0.9
Implementation-Vendor: The Apache Software Foundation


Source:
Manifest-Version: 1.0
Created-By: Maven Jar Plugin 3.2.0
Build-Jdk-Spec: 13
Specification-Title: Apache Royale: Royale Maven Plugin
Specification-Version: 0.9
Specification-Vendor: The Apache Software Foundation
Implementation-Title: Apache Royale: Royale Maven Plugin
Implementation-Version: 0.9.8
Implementation-Vendor: The Apache Software Foundation

I’m clueless as to where the version 13 spec is coming from:

Here’s what I get when I check my java jdks:

/usr/libexec/java_home -V

Matching Java Virtual Machines (3):
1.8.0_231, x86_64:  "Java SE 8" 
/Library/Java/JavaVirtualMachines/jdk1.8.0_231.jdk/Contents/Home
1.6.0_65-b14-468, x86_64:   "Java SE 6" 
/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
1.6.0_65-b14-468, i386: "Java SE 6" 
/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

/Library/Java/JavaVirtualMachines/jdk1.8.0_231.jdk/Contents/Home


> On Nov 30, 2020, at 4:26 AM, Alex Harui  wrote:
>
> The "snapshot" in the script output should just be checking if the release is 
> for jburg-types as well as the main jars (which it isn't).
>
> The main pom.xml should not be using -SNAPSHOT for jburg-types and 
> build-tools.   It seems ok to me.
>
> Verify the Java version on the system that has a difference.  It needs to be 
> the same as the CI server.  Then diff the two jars and see what is different. 
>  Try unzipping each jar in a separate directory and compare the directories.
>
> HTH,
> -Alex
>
>
> On 11/29/20, 4:05 AM, "Harbs"  <mailto:harbs.li...@gmail.com>> wrote:
>
>Yes. But that was compiler-build-tools. This is compiler-jburg-types.
>
>> On Nov 29, 2020, at 2:02 PM, Piotr Zarzycki  
>> wrote:
>>
>> In a Apache Maven central - when you staged artifacts (I don't remember
>> url), after vote on release you need to click there to make that release
>> happen. Did you do something like this ?
>>
>> niedz., 29 lis 2020 o 12:44 Harbs  napisał(a):
>>
>>> I see that compiler-jburg-types is still 1.2.0-SNAPSHOT.
>>>
>>> Did I need to do a release on that in addition to compiler-build-tools?
>>>
>>> I really don’t understand all these Maven side-projects...
>>>
>>>> On Nov 29, 2020, at 1:38 PM, Harbs  wrote:
>>>>
>>>> I still cannot get it to work on that machine (MacBook Pro running
>>> Catalina).
>>>>
>>>> It did work on my main machine (Mac Mini running Mojave), but now I’m
>>> getting this failure:
>>>>
>>>> get-utils-version:
>>>>   [echo] utils version is 1.2.0-SNAPSHOT
>>>>
>>>> write-out-maven-jars-list:
>>>>
>>>> write-out-maven-utils-jars-list:
>>>>
>

Re: Release Step 003 Succeeded

[Harbs]

le executing this line:
>>>> /Apache/royale-compiler/releasesteps.xml:283:
>>> royale-maven-plugin-0.9.8.jar does not match
>>>> 
>>>> I don’t know why I’m not getting a reproducible build, but I wonder if
>>> it’s because it’s using 1.2.0-SNAPSHOT instead of 1.2.1.
>>>> 
>>>> I don’t know why that would be. I’m on the release branch.
>>>> 
>>>>> On Nov 27, 2020, at 1:03 AM, Alex Harui 
>>> wrote:
>>>>> 
>>>>> IIRC, on your local machine, if you clone the repo and run "mvn clean
>>> install", it should allow you to type a response and then that machine
>>> should be ok to use after that.
>>>>> 
>>>>> -Alex
>>>>> 
>>>>> On 11/26/20, 1:46 PM, "Harbs"  wrote:
>>>>> 
>>>>> That’s on my local machine. Passing the Dcom option to the ant script
>>> doesn’t help.
>>>>> 
>>>>> How would I manually get the Adobe artifacts on my machine?
>>>>> 
>>>>>> On Nov 26, 2020, at 11:18 PM, Christofer Dutz <
>>> christofer.d...@c-ware.de> wrote:
>>>>>> 
>>>>>> I can tell you what’s going on here.
>>>>>> 
>>>>>> You are building on a system where the Adobe artifacts aren’t
>>> available in the maven local repo.
>>>>>> So the mavenizer (AKA maven extension I built to make non maven
>>> artifacts available as Maven artifacts) is kicking in. It expects a user to
>>> accept the license terms. It seems the MAC address of the network
>>> configuration of the build machine changed. You need to pass
>>>>>> 
>>>>>> 
>>> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
>>>>>> 
>>>>>> To the build job
>>>>>> 
>>>>>> Chris
>>>>>> 
>>>>>> 
>>>>>> Von: Harbs 
>>>>>> Datum: Donnerstag, 26. November 2020 um 21:53
>>>>>> An: Apache Royale Development 
>>>>>> Betreff: Re: Release Step 003 Succeeded
>>>>>> I don’t get it. I’m getting an endless loop of:
>>>>>> 
>>>>>> [exec] The Adobe SDK license agreement applies to the Adobe Flash
>>> Player playerglobal.swc. Do you want to install the Adobe Flash Player
>>> playerglobal.swc?
>>>>>> [exec] (In a non-interactive build such as a CI server build,
>>> alternatively to typing y or yes you can also set a system property
>>> containing your system which is interpreted as equivalent to accepting by
>>> typing y or yes:
>>> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
>>> )
>>>>>> [exec] Do you accept (Yes/No) ? Your System-Id: b57aca16
>>>>>> 
>>>>>> when I run:
>>>>>>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
>>>>>> 
>>>>>> Where is that coming from and why?
>>>>>> 
>>>>>>> On Nov 26, 2020, at 9:16 PM, apacheroyal...@gmail.com wrote:
>>>>>>> 
>>>>>>> From the royale-compiler repo:
>>>>>>> 1. Run:
>>>>>>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
>>>>>>> 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.8
>>>>>>> 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.8
>>>>>>> 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:
>>>>>>> 
>>>>>>> 
>>>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmaven.apache.org%2FSETTINGS%2F1.1.0data=04%7C01%7Caharui%40adobe.com%7C

Re: Release Step 003 Succeeded

[Christofer Dutz]

Also if you copy both versions of the jar into intellij, then select both and 
select "compare files" it will do this comparison automatically and give you a 
nice diff view.

Chris


Von: Alex Harui 
Gesendet: Montag, 30. November 2020 03:26
An: dev@royale.apache.org 
Betreff: Re: Release Step 003 Succeeded

The "snapshot" in the script output should just be checking if the release is 
for jburg-types as well as the main jars (which it isn't).

The main pom.xml should not be using -SNAPSHOT for jburg-types and build-tools. 
  It seems ok to me.

Verify the Java version on the system that has a difference.  It needs to be 
the same as the CI server.  Then diff the two jars and see what is different.  
Try unzipping each jar in a separate directory and compare the directories.

HTH,
-Alex


On 11/29/20, 4:05 AM, "Harbs"  wrote:

Yes. But that was compiler-build-tools. This is compiler-jburg-types.

> On Nov 29, 2020, at 2:02 PM, Piotr Zarzycki  
wrote:
>
> In a Apache Maven central - when you staged artifacts (I don't remember
> url), after vote on release you need to click there to make that release
> happen. Did you do something like this ?
>
> niedz., 29 lis 2020 o 12:44 Harbs  napisał(a):
>
>> I see that compiler-jburg-types is still 1.2.0-SNAPSHOT.
>>
>> Did I need to do a release on that in addition to compiler-build-tools?
>>
>> I really don’t understand all these Maven side-projects...
>>
>>> On Nov 29, 2020, at 1:38 PM, Harbs  wrote:
>>>
>>> I still cannot get it to work on that machine (MacBook Pro running
>> Catalina).
>>>
>>> It did work on my main machine (Mac Mini running Mojave), but now I’m
>> getting this failure:
>>>
>>> get-utils-version:
>>>[echo] utils version is 1.2.0-SNAPSHOT
>>>
>>> write-out-maven-jars-list:
>>>
>>> write-out-maven-utils-jars-list:
>>>
>>> compare-jars:
>>>[copy] Copying 1 file to /Apache/royale-compiler/temp_folder
>>>
>>> loopOnce:
>>>[copy] Copying 1 file to /Apache/royale-compiler/temp_folder
>>>
>>> notlast:
>>>
>>> get-jar-version:
>>>
>>> compare_files:
>>>[echo] comparing royale-maven-plugin-0.9.8
>>>
>>> BUILD FAILED
>>> /Apache/royale-compiler/releasesteps.xml:213: The following error
>> occurred while executing this line:
>>> /Apache/royale-compiler/releasesteps.xml:241: The following error
>> occurred while executing this line:
>>> /Apache/royale-compiler/releasesteps.xml:248: The following error
>> occurred while executing this line:
>>> /Apache/royale-compiler/releasesteps.xml:283:
>> royale-maven-plugin-0.9.8.jar does not match
>>>
>>> I don’t know why I’m not getting a reproducible build, but I wonder if
>> it’s because it’s using 1.2.0-SNAPSHOT instead of 1.2.1.
>>>
>>> I don’t know why that would be. I’m on the release branch.
>>>
>>>> On Nov 27, 2020, at 1:03 AM, Alex Harui 
>> wrote:
>>>>
>>>> IIRC, on your local machine, if you clone the repo and run "mvn clean
>> install", it should allow you to type a response and then that machine
>> should be ok to use after that.
>>>>
>>>> -Alex
>>>>
>>>> On 11/26/20, 1:46 PM, "Harbs"  wrote:
>>>>
>>>>  That’s on my local machine. Passing the Dcom option to the ant script
>> doesn’t help.
>>>>
>>>>  How would I manually get the Adobe artifacts on my machine?
>>>>
>>>>> On Nov 26, 2020, at 11:18 PM, Christofer Dutz <
>> christofer.d...@c-ware.de> wrote:
>>>>>
>>>>> I can tell you what’s going on here.
>>>>>
>>>>> You are building on a system where the Adobe artifacts aren’t
>> available in the maven local repo.
>>>>> So the mavenizer (AKA maven extension I built to make non maven
>> artifacts available as Maven artifacts) is kicking in. It expects a user 
to
>> accept the license terms. It seems the MAC address of the network
>> configuration of the build machine changed. You need to pass
>>>>>
>>>>>
>> 
-Dc

Re: Release Step 003 Succeeded

[Alex Harui]

The "snapshot" in the script output should just be checking if the release is 
for jburg-types as well as the main jars (which it isn't).

The main pom.xml should not be using -SNAPSHOT for jburg-types and build-tools. 
  It seems ok to me.

Verify the Java version on the system that has a difference.  It needs to be 
the same as the CI server.  Then diff the two jars and see what is different.  
Try unzipping each jar in a separate directory and compare the directories.

HTH,
-Alex


On 11/29/20, 4:05 AM, "Harbs"  wrote:

Yes. But that was compiler-build-tools. This is compiler-jburg-types.

> On Nov 29, 2020, at 2:02 PM, Piotr Zarzycki  
wrote:
> 
> In a Apache Maven central - when you staged artifacts (I don't remember
> url), after vote on release you need to click there to make that release
> happen. Did you do something like this ?
> 
> niedz., 29 lis 2020 o 12:44 Harbs  napisał(a):
> 
>> I see that compiler-jburg-types is still 1.2.0-SNAPSHOT.
>> 
>> Did I need to do a release on that in addition to compiler-build-tools?
>> 
>> I really don’t understand all these Maven side-projects...
>> 
>>> On Nov 29, 2020, at 1:38 PM, Harbs  wrote:
>>> 
>>> I still cannot get it to work on that machine (MacBook Pro running
>> Catalina).
>>> 
>>> It did work on my main machine (Mac Mini running Mojave), but now I’m
>> getting this failure:
>>> 
>>> get-utils-version:
>>>[echo] utils version is 1.2.0-SNAPSHOT
>>> 
>>> write-out-maven-jars-list:
>>> 
>>> write-out-maven-utils-jars-list:
>>> 
>>> compare-jars:
>>>[copy] Copying 1 file to /Apache/royale-compiler/temp_folder
>>> 
>>> loopOnce:
>>>[copy] Copying 1 file to /Apache/royale-compiler/temp_folder
>>> 
>>> notlast:
>>> 
>>> get-jar-version:
>>> 
>>> compare_files:
>>>[echo] comparing royale-maven-plugin-0.9.8
>>> 
>>> BUILD FAILED
>>> /Apache/royale-compiler/releasesteps.xml:213: The following error
>> occurred while executing this line:
>>> /Apache/royale-compiler/releasesteps.xml:241: The following error
>> occurred while executing this line:
>>> /Apache/royale-compiler/releasesteps.xml:248: The following error
>> occurred while executing this line:
>>> /Apache/royale-compiler/releasesteps.xml:283:
>> royale-maven-plugin-0.9.8.jar does not match
>>> 
>>> I don’t know why I’m not getting a reproducible build, but I wonder if
>> it’s because it’s using 1.2.0-SNAPSHOT instead of 1.2.1.
>>> 
>>> I don’t know why that would be. I’m on the release branch.
>>> 
>>>> On Nov 27, 2020, at 1:03 AM, Alex Harui 
>> wrote:
>>>> 
>>>> IIRC, on your local machine, if you clone the repo and run "mvn clean
>> install", it should allow you to type a response and then that machine
>> should be ok to use after that.
>>>> 
>>>> -Alex
>>>> 
>>>> On 11/26/20, 1:46 PM, "Harbs"  wrote:
>>>> 
>>>>  That’s on my local machine. Passing the Dcom option to the ant script
>> doesn’t help.
>>>> 
>>>>  How would I manually get the Adobe artifacts on my machine?
>>>> 
>>>>> On Nov 26, 2020, at 11:18 PM, Christofer Dutz <
>> christofer.d...@c-ware.de> wrote:
>>>>> 
>>>>> I can tell you what’s going on here.
>>>>> 
>>>>> You are building on a system where the Adobe artifacts aren’t
>> available in the maven local repo.
>>>>> So the mavenizer (AKA maven extension I built to make non maven
>> artifacts available as Maven artifacts) is kicking in. It expects a user 
to
>> accept the license terms. It seems the MAC address of the network
>> configuration of the build machine changed. You need to pass
>>>>> 
>>>>> 
>> 
-Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
>>>>> 
>>>>> To the build job
>>>>> 
>>>>> Chris
>>>>> 
>>>>> 
>>>>> Von: Harbs 
>>>>> 

Re: Release Step 003 Succeeded

[Harbs]

Yes. But that was compiler-build-tools. This is compiler-jburg-types.

> On Nov 29, 2020, at 2:02 PM, Piotr Zarzycki  wrote:
> 
> In a Apache Maven central - when you staged artifacts (I don't remember
> url), after vote on release you need to click there to make that release
> happen. Did you do something like this ?
> 
> niedz., 29 lis 2020 o 12:44 Harbs  napisał(a):
> 
>> I see that compiler-jburg-types is still 1.2.0-SNAPSHOT.
>> 
>> Did I need to do a release on that in addition to compiler-build-tools?
>> 
>> I really don’t understand all these Maven side-projects...
>> 
>>> On Nov 29, 2020, at 1:38 PM, Harbs  wrote:
>>> 
>>> I still cannot get it to work on that machine (MacBook Pro running
>> Catalina).
>>> 
>>> It did work on my main machine (Mac Mini running Mojave), but now I’m
>> getting this failure:
>>> 
>>> get-utils-version:
>>>[echo] utils version is 1.2.0-SNAPSHOT
>>> 
>>> write-out-maven-jars-list:
>>> 
>>> write-out-maven-utils-jars-list:
>>> 
>>> compare-jars:
>>>[copy] Copying 1 file to /Apache/royale-compiler/temp_folder
>>> 
>>> loopOnce:
>>>[copy] Copying 1 file to /Apache/royale-compiler/temp_folder
>>> 
>>> notlast:
>>> 
>>> get-jar-version:
>>> 
>>> compare_files:
>>>[echo] comparing royale-maven-plugin-0.9.8
>>> 
>>> BUILD FAILED
>>> /Apache/royale-compiler/releasesteps.xml:213: The following error
>> occurred while executing this line:
>>> /Apache/royale-compiler/releasesteps.xml:241: The following error
>> occurred while executing this line:
>>> /Apache/royale-compiler/releasesteps.xml:248: The following error
>> occurred while executing this line:
>>> /Apache/royale-compiler/releasesteps.xml:283:
>> royale-maven-plugin-0.9.8.jar does not match
>>> 
>>> I don’t know why I’m not getting a reproducible build, but I wonder if
>> it’s because it’s using 1.2.0-SNAPSHOT instead of 1.2.1.
>>> 
>>> I don’t know why that would be. I’m on the release branch.
>>> 
>>>> On Nov 27, 2020, at 1:03 AM, Alex Harui 
>> wrote:
>>>> 
>>>> IIRC, on your local machine, if you clone the repo and run "mvn clean
>> install", it should allow you to type a response and then that machine
>> should be ok to use after that.
>>>> 
>>>> -Alex
>>>> 
>>>> On 11/26/20, 1:46 PM, "Harbs"  wrote:
>>>> 
>>>>  That’s on my local machine. Passing the Dcom option to the ant script
>> doesn’t help.
>>>> 
>>>>  How would I manually get the Adobe artifacts on my machine?
>>>> 
>>>>> On Nov 26, 2020, at 11:18 PM, Christofer Dutz <
>> christofer.d...@c-ware.de> wrote:
>>>>> 
>>>>> I can tell you what’s going on here.
>>>>> 
>>>>> You are building on a system where the Adobe artifacts aren’t
>> available in the maven local repo.
>>>>> So the mavenizer (AKA maven extension I built to make non maven
>> artifacts available as Maven artifacts) is kicking in. It expects a user to
>> accept the license terms. It seems the MAC address of the network
>> configuration of the build machine changed. You need to pass
>>>>> 
>>>>> 
>> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
>>>>> 
>>>>> To the build job
>>>>> 
>>>>> Chris
>>>>> 
>>>>> 
>>>>> Von: Harbs 
>>>>> Datum: Donnerstag, 26. November 2020 um 21:53
>>>>> An: Apache Royale Development 
>>>>> Betreff: Re: Release Step 003 Succeeded
>>>>> I don’t get it. I’m getting an endless loop of:
>>>>> 
>>>>>  [exec] The Adobe SDK license agreement applies to the Adobe Flash
>> Player playerglobal.swc. Do you want to install the Adobe Flash Player
>> playerglobal.swc?
>>>>>  [exec] (In a non-interactive build such as a CI server build,
>> alternatively to typing y or yes you can also set a system property
>> containing your system which is interpreted as equivalent to accepting by
>> typing y or yes:
>> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
>> )
>>>>>  [exec] Do you accept (Yes/No) ? Your System-Id: b57aca16
>>>>> 
>>>>> when I 

Re: Release Step 003 Succeeded

[Piotr Zarzycki]

In a Apache Maven central - when you staged artifacts (I don't remember
url), after vote on release you need to click there to make that release
happen. Did you do something like this ?

niedz., 29 lis 2020 o 12:44 Harbs  napisał(a):

> I see that compiler-jburg-types is still 1.2.0-SNAPSHOT.
>
> Did I need to do a release on that in addition to compiler-build-tools?
>
> I really don’t understand all these Maven side-projects...
>
> > On Nov 29, 2020, at 1:38 PM, Harbs  wrote:
> >
> > I still cannot get it to work on that machine (MacBook Pro running
> Catalina).
> >
> > It did work on my main machine (Mac Mini running Mojave), but now I’m
> getting this failure:
> >
> > get-utils-version:
> > [echo] utils version is 1.2.0-SNAPSHOT
> >
> > write-out-maven-jars-list:
> >
> > write-out-maven-utils-jars-list:
> >
> > compare-jars:
> > [copy] Copying 1 file to /Apache/royale-compiler/temp_folder
> >
> > loopOnce:
> > [copy] Copying 1 file to /Apache/royale-compiler/temp_folder
> >
> > notlast:
> >
> > get-jar-version:
> >
> > compare_files:
> > [echo] comparing royale-maven-plugin-0.9.8
> >
> > BUILD FAILED
> > /Apache/royale-compiler/releasesteps.xml:213: The following error
> occurred while executing this line:
> > /Apache/royale-compiler/releasesteps.xml:241: The following error
> occurred while executing this line:
> > /Apache/royale-compiler/releasesteps.xml:248: The following error
> occurred while executing this line:
> > /Apache/royale-compiler/releasesteps.xml:283:
> royale-maven-plugin-0.9.8.jar does not match
> >
> > I don’t know why I’m not getting a reproducible build, but I wonder if
> it’s because it’s using 1.2.0-SNAPSHOT instead of 1.2.1.
> >
> > I don’t know why that would be. I’m on the release branch.
> >
> >> On Nov 27, 2020, at 1:03 AM, Alex Harui 
> wrote:
> >>
> >> IIRC, on your local machine, if you clone the repo and run "mvn clean
> install", it should allow you to type a response and then that machine
> should be ok to use after that.
> >>
> >> -Alex
> >>
> >> On 11/26/20, 1:46 PM, "Harbs"  wrote:
> >>
> >>   That’s on my local machine. Passing the Dcom option to the ant script
> doesn’t help.
> >>
> >>   How would I manually get the Adobe artifacts on my machine?
> >>
> >>> On Nov 26, 2020, at 11:18 PM, Christofer Dutz <
> christofer.d...@c-ware.de> wrote:
> >>>
> >>> I can tell you what’s going on here.
> >>>
> >>> You are building on a system where the Adobe artifacts aren’t
> available in the maven local repo.
> >>> So the mavenizer (AKA maven extension I built to make non maven
> artifacts available as Maven artifacts) is kicking in. It expects a user to
> accept the license terms. It seems the MAC address of the network
> configuration of the build machine changed. You need to pass
> >>>
> >>>
> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
> >>>
> >>> To the build job
> >>>
> >>> Chris
> >>>
> >>>
> >>> Von: Harbs 
> >>> Datum: Donnerstag, 26. November 2020 um 21:53
> >>> An: Apache Royale Development 
> >>> Betreff: Re: Release Step 003 Succeeded
> >>> I don’t get it. I’m getting an endless loop of:
> >>>
> >>>   [exec] The Adobe SDK license agreement applies to the Adobe Flash
> Player playerglobal.swc. Do you want to install the Adobe Flash Player
> playerglobal.swc?
> >>>   [exec] (In a non-interactive build such as a CI server build,
> alternatively to typing y or yes you can also set a system property
> containing your system which is interpreted as equivalent to accepting by
> typing y or yes:
> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
> )
> >>>   [exec] Do you accept (Yes/No) ? Your System-Id: b57aca16
> >>>
> >>> when I run:
> >>>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
> >>>
> >>> Where is that coming from and why?
> >>>
> >>>> On Nov 26, 2020, at 9:16 PM, apacheroyal...@gmail.com wrote:
> >>>>
> >>>> From the royale-compiler repo:
> >>>> 1. Run:
> >>>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
> >>>> This will download the artifacts then

Re: Release Step 003 Succeeded

[Harbs]

I see that compiler-jburg-types is still 1.2.0-SNAPSHOT.

Did I need to do a release on that in addition to compiler-build-tools?

I really don’t understand all these Maven side-projects...

> On Nov 29, 2020, at 1:38 PM, Harbs  wrote:
> 
> I still cannot get it to work on that machine (MacBook Pro running Catalina).
> 
> It did work on my main machine (Mac Mini running Mojave), but now I’m getting 
> this failure:
> 
> get-utils-version:
> [echo] utils version is 1.2.0-SNAPSHOT
> 
> write-out-maven-jars-list:
> 
> write-out-maven-utils-jars-list:
> 
> compare-jars:
> [copy] Copying 1 file to /Apache/royale-compiler/temp_folder
> 
> loopOnce:
> [copy] Copying 1 file to /Apache/royale-compiler/temp_folder
> 
> notlast:
> 
> get-jar-version:
> 
> compare_files:
> [echo] comparing royale-maven-plugin-0.9.8
> 
> BUILD FAILED
> /Apache/royale-compiler/releasesteps.xml:213: The following error occurred 
> while executing this line:
> /Apache/royale-compiler/releasesteps.xml:241: The following error occurred 
> while executing this line:
> /Apache/royale-compiler/releasesteps.xml:248: The following error occurred 
> while executing this line:
> /Apache/royale-compiler/releasesteps.xml:283: royale-maven-plugin-0.9.8.jar 
> does not match
> 
> I don’t know why I’m not getting a reproducible build, but I wonder if it’s 
> because it’s using 1.2.0-SNAPSHOT instead of 1.2.1.
> 
> I don’t know why that would be. I’m on the release branch.
> 
>> On Nov 27, 2020, at 1:03 AM, Alex Harui  wrote:
>> 
>> IIRC, on your local machine, if you clone the repo and run "mvn clean 
>> install", it should allow you to type a response and then that machine 
>> should be ok to use after that.
>> 
>> -Alex
>> 
>> On 11/26/20, 1:46 PM, "Harbs"  wrote:
>> 
>>   That’s on my local machine. Passing the Dcom option to the ant script 
>> doesn’t help.
>> 
>>   How would I manually get the Adobe artifacts on my machine?
>> 
>>> On Nov 26, 2020, at 11:18 PM, Christofer Dutz  
>>> wrote:
>>> 
>>> I can tell you what’s going on here.
>>> 
>>> You are building on a system where the Adobe artifacts aren’t available in 
>>> the maven local repo.
>>> So the mavenizer (AKA maven extension I built to make non maven artifacts 
>>> available as Maven artifacts) is kicking in. It expects a user to accept 
>>> the license terms. It seems the MAC address of the network configuration of 
>>> the build machine changed. You need to pass
>>> 
>>> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
>>> 
>>> To the build job
>>> 
>>> Chris
>>> 
>>> 
>>> Von: Harbs 
>>> Datum: Donnerstag, 26. November 2020 um 21:53
>>> An: Apache Royale Development 
>>> Betreff: Re: Release Step 003 Succeeded
>>> I don’t get it. I’m getting an endless loop of:
>>> 
>>>   [exec] The Adobe SDK license agreement applies to the Adobe Flash Player 
>>> playerglobal.swc. Do you want to install the Adobe Flash Player 
>>> playerglobal.swc?
>>>   [exec] (In a non-interactive build such as a CI server build, 
>>> alternatively to typing y or yes you can also set a system property 
>>> containing your system which is interpreted as equivalent to accepting by 
>>> typing y or yes: 
>>> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
>>>  )
>>>   [exec] Do you accept (Yes/No) ? Your System-Id: b57aca16
>>> 
>>> when I run:
>>>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
>>> 
>>> Where is that coming from and why?
>>> 
>>>> On Nov 26, 2020, at 9:16 PM, apacheroyal...@gmail.com wrote:
>>>> 
>>>> From the royale-compiler repo:
>>>> 1. Run:
>>>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
>>>> 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.8
>>>> 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.8
>>>> This will upload the signed artifacts to Maven Release Staging. If you are 
>>>> getting 4

Re: Release Step 003 Succeeded

[Harbs]

I still cannot get it to work on that machine (MacBook Pro running Catalina).

It did work on my main machine (Mac Mini running Mojave), but now I’m getting 
this failure:

get-utils-version:
 [echo] utils version is 1.2.0-SNAPSHOT

write-out-maven-jars-list:

write-out-maven-utils-jars-list:

compare-jars:
 [copy] Copying 1 file to /Apache/royale-compiler/temp_folder

loopOnce:
 [copy] Copying 1 file to /Apache/royale-compiler/temp_folder

notlast:

get-jar-version:

compare_files:
 [echo] comparing royale-maven-plugin-0.9.8

BUILD FAILED
/Apache/royale-compiler/releasesteps.xml:213: The following error occurred 
while executing this line:
/Apache/royale-compiler/releasesteps.xml:241: The following error occurred 
while executing this line:
/Apache/royale-compiler/releasesteps.xml:248: The following error occurred 
while executing this line:
/Apache/royale-compiler/releasesteps.xml:283: royale-maven-plugin-0.9.8.jar 
does not match

I don’t know why I’m not getting a reproducible build, but I wonder if it’s 
because it’s using 1.2.0-SNAPSHOT instead of 1.2.1.

I don’t know why that would be. I’m on the release branch.

> On Nov 27, 2020, at 1:03 AM, Alex Harui  wrote:
> 
> IIRC, on your local machine, if you clone the repo and run "mvn clean 
> install", it should allow you to type a response and then that machine should 
> be ok to use after that.
> 
> -Alex
> 
> On 11/26/20, 1:46 PM, "Harbs"  wrote:
> 
>That’s on my local machine. Passing the Dcom option to the ant script 
> doesn’t help.
> 
>How would I manually get the Adobe artifacts on my machine?
> 
>> On Nov 26, 2020, at 11:18 PM, Christofer Dutz  
>> wrote:
>> 
>> I can tell you what’s going on here.
>> 
>> You are building on a system where the Adobe artifacts aren’t available in 
>> the maven local repo.
>> So the mavenizer (AKA maven extension I built to make non maven artifacts 
>> available as Maven artifacts) is kicking in. It expects a user to accept the 
>> license terms. It seems the MAC address of the network configuration of the 
>> build machine changed. You need to pass
>> 
>> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
>> 
>> To the build job
>> 
>> Chris
>> 
>> 
>> Von: Harbs 
>> Datum: Donnerstag, 26. November 2020 um 21:53
>> An: Apache Royale Development 
>> Betreff: Re: Release Step 003 Succeeded
>> I don’t get it. I’m getting an endless loop of:
>> 
>>[exec] The Adobe SDK license agreement applies to the Adobe Flash Player 
>> playerglobal.swc. Do you want to install the Adobe Flash Player 
>> playerglobal.swc?
>>[exec] (In a non-interactive build such as a CI server build, 
>> alternatively to typing y or yes you can also set a system property 
>> containing your system which is interpreted as equivalent to accepting by 
>> typing y or yes: 
>> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
>>  )
>>[exec] Do you accept (Yes/No) ? Your System-Id: b57aca16
>> 
>> when I run:
>>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
>> 
>> Where is that coming from and why?
>> 
>>> On Nov 26, 2020, at 9:16 PM, apacheroyal...@gmail.com wrote:
>>> 
>>> From the royale-compiler repo:
>>> 1. Run:
>>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
>>> 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.8
>>> 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.8
>>> 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:
>>> 
>>> 
>>> >> xsi:schemaLocation="https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmaven.apache.org%2FSETTINGS%2F1.1.0data=04%7C01%7Caharui%40adobe.com%7Cc3e8334de4804345982a08d89254b15b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637420239736235404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=3ccTB4X%2BJ%2BDcgoXu4f5%2Bsn4gNvhzKW3XflhRviKqxxM%3Dreserved=0
>>>

AW: Release Step 003 Succeeded

[Christofer Dutz]

Hi Harbs,

If you want to, try to ping me when you try it the next time and I could try 
assisting you via Zoom.

Chris


Von: Harbs 
Datum: Freitag, 27. November 2020 um 11:07
An: Apache Royale Development 
Betreff: Re: Release Step 003 Succeeded
It didn’t work for me…

I don’t know what Maven has against me, but I seem to have trouble with it at 
every turn… ;-)

I’ll try again after my Sabbath.

> On Nov 27, 2020, at 1:03 AM, Alex Harui  wrote:
>
> IIRC, on your local machine, if you clone the repo and run "mvn clean 
> install", it should allow you to type a response and then that machine should 
> be ok to use after that.
>
> -Alex
>
> On 11/26/20, 1:46 PM, "Harbs"  <mailto:harbs.li...@gmail.com>> wrote:
>
>That’s on my local machine. Passing the Dcom option to the ant script 
> doesn’t help.
>
>How would I manually get the Adobe artifacts on my machine?
>
>> On Nov 26, 2020, at 11:18 PM, Christofer Dutz  
>> wrote:
>>
>> I can tell you what’s going on here.
>>
>> You are building on a system where the Adobe artifacts aren’t available in 
>> the maven local repo.
>> So the mavenizer (AKA maven extension I built to make non maven artifacts 
>> available as Maven artifacts) is kicking in. It expects a user to accept the 
>> license terms. It seems the MAC address of the network configuration of the 
>> build machine changed. You need to pass
>>
>> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
>>
>> To the build job
>>
>> Chris
>>
>>
>> Von: Harbs 
>> Datum: Donnerstag, 26. November 2020 um 21:53
>> An: Apache Royale Development 
>> Betreff: Re: Release Step 003 Succeeded
>> I don’t get it. I’m getting an endless loop of:
>>
>>[exec] The Adobe SDK license agreement applies to the Adobe Flash Player 
>> playerglobal.swc. Do you want to install the Adobe Flash Player 
>> playerglobal.swc?
>>[exec] (In a non-interactive build such as a CI server build, 
>> alternatively to typing y or yes you can also set a system property 
>> containing your system which is interpreted as equivalent to accepting by 
>> typing y or yes: 
>> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
>>  )
>>[exec] Do you accept (Yes/No) ? Your System-Id: b57aca16
>>
>> when I run:
>>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
>>
>> Where is that coming from and why?
>>
>>> On Nov 26, 2020, at 9:16 PM, apacheroyal...@gmail.com wrote:
>>>
>>> From the royale-compiler repo:
>>> 1. Run:
>>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
>>> 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.8
>>> 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.8
>>> 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:
>>>
>>> 
>>> >> xsi:schemaLocation="https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmaven.apache.org%2FSETTINGS%2F1.1.0data=04%7C01%7Caharui%40adobe.com%7Cc3e8334de4804345982a08d89254b15b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637420239736235404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=3ccTB4X%2BJ%2BDcgoXu4f5%2Bsn4gNvhzKW3XflhRviKqxxM%3Dreserved=0
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmaven.apache.org%2FSETTINGS%2F1.1.0data=04%7C01%7Caharui%40adobe.com%7Cc3e8334de4804345982a08d89254b15b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637420239736235404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=3ccTB4X%2BJ%2BDcgoXu4f5%2Bsn4gNvhzKW3XflhRviKqxxM%3Dreserved=0>
>>>  
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmaven.apache.org%2Fxsd%2Fsettings-1.1.0.xsddata=04%7C01%7Caharui%40adobe.com%7Cc3e8334de4804345982a08d89254b15b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637420239736235404%7CUnknown%7CTWFpbGZsb3d8eyJ

Re: Release Step 003 Succeeded

[Harbs]

It didn’t work for me…

I don’t know what Maven has against me, but I seem to have trouble with it at 
every turn… ;-)

I’ll try again after my Sabbath.

> On Nov 27, 2020, at 1:03 AM, Alex Harui  wrote:
> 
> IIRC, on your local machine, if you clone the repo and run "mvn clean 
> install", it should allow you to type a response and then that machine should 
> be ok to use after that.
> 
> -Alex
> 
> On 11/26/20, 1:46 PM, "Harbs"  <mailto:harbs.li...@gmail.com>> wrote:
> 
>That’s on my local machine. Passing the Dcom option to the ant script 
> doesn’t help.
> 
>How would I manually get the Adobe artifacts on my machine?
> 
>> On Nov 26, 2020, at 11:18 PM, Christofer Dutz  
>> wrote:
>> 
>> I can tell you what’s going on here.
>> 
>> You are building on a system where the Adobe artifacts aren’t available in 
>> the maven local repo.
>> So the mavenizer (AKA maven extension I built to make non maven artifacts 
>> available as Maven artifacts) is kicking in. It expects a user to accept the 
>> license terms. It seems the MAC address of the network configuration of the 
>> build machine changed. You need to pass
>> 
>> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
>> 
>> To the build job
>> 
>> Chris
>> 
>> 
>> Von: Harbs 
>> Datum: Donnerstag, 26. November 2020 um 21:53
>> An: Apache Royale Development 
>> Betreff: Re: Release Step 003 Succeeded
>> I don’t get it. I’m getting an endless loop of:
>> 
>>[exec] The Adobe SDK license agreement applies to the Adobe Flash Player 
>> playerglobal.swc. Do you want to install the Adobe Flash Player 
>> playerglobal.swc?
>>[exec] (In a non-interactive build such as a CI server build, 
>> alternatively to typing y or yes you can also set a system property 
>> containing your system which is interpreted as equivalent to accepting by 
>> typing y or yes: 
>> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
>>  )
>>[exec] Do you accept (Yes/No) ? Your System-Id: b57aca16
>> 
>> when I run:
>>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
>> 
>> Where is that coming from and why?
>> 
>>> On Nov 26, 2020, at 9:16 PM, apacheroyal...@gmail.com wrote:
>>> 
>>> From the royale-compiler repo:
>>> 1. Run:
>>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
>>> 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.8
>>> 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.8
>>> 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:
>>> 
>>> 
>>> >> xsi:schemaLocation="https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmaven.apache.org%2FSETTINGS%2F1.1.0data=04%7C01%7Caharui%40adobe.com%7Cc3e8334de4804345982a08d89254b15b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637420239736235404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=3ccTB4X%2BJ%2BDcgoXu4f5%2Bsn4gNvhzKW3XflhRviKqxxM%3Dreserved=0
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmaven.apache.org%2FSETTINGS%2F1.1.0data=04%7C01%7Caharui%40adobe.com%7Cc3e8334de4804345982a08d89254b15b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637420239736235404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=3ccTB4X%2BJ%2BDcgoXu4f5%2Bsn4gNvhzKW3XflhRviKqxxM%3Dreserved=0>
>>>  
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmaven.apache.org%2Fxsd%2Fsettings-1.1.0.xsddata=04%7C01%7Caharui%40adobe.com%7Cc3e8334de4804345982a08d89254b15b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637420239736235404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=xlWxXIj0l7KQJhY%2BhYw1hf%2FwTZ%2Bteq5dnuTbkxTIS6I%3Dreserved=0
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%

Re: Release Step 003 Succeeded

[Alex Harui]

IIRC, on your local machine, if you clone the repo and run "mvn clean install", 
it should allow you to type a response and then that machine should be ok to 
use after that.

-Alex

On 11/26/20, 1:46 PM, "Harbs"  wrote:

That’s on my local machine. Passing the Dcom option to the ant script 
doesn’t help.

How would I manually get the Adobe artifacts on my machine?

> On Nov 26, 2020, at 11:18 PM, Christofer Dutz  
wrote:
> 
> I can tell you what’s going on here.
> 
> You are building on a system where the Adobe artifacts aren’t available 
in the maven local repo.
> So the mavenizer (AKA maven extension I built to make non maven artifacts 
available as Maven artifacts) is kicking in. It expects a user to accept the 
license terms. It seems the MAC address of the network configuration of the 
build machine changed. You need to pass
> 
> 
-Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
> 
> To the build job
> 
> Chris
> 
> 
> Von: Harbs 
> Datum: Donnerstag, 26. November 2020 um 21:53
    > An: Apache Royale Development 
> Betreff: Re: Release Step 003 Succeeded
> I don’t get it. I’m getting an endless loop of:
> 
> [exec] The Adobe SDK license agreement applies to the Adobe Flash 
Player playerglobal.swc. Do you want to install the Adobe Flash Player 
playerglobal.swc?
> [exec] (In a non-interactive build such as a CI server build, 
alternatively to typing y or yes you can also set a system property containing 
your system which is interpreted as equivalent to accepting by typing y or yes: 
-Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
 )
> [exec] Do you accept (Yes/No) ? Your System-Id: b57aca16
> 
> when I run:
>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
> 
> Where is that coming from and why?
> 
>> On Nov 26, 2020, at 9:16 PM, apacheroyal...@gmail.com wrote:
>> 
>> From the royale-compiler repo:
>> 1. Run:
>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
>> 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.8
>> 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.8
>> 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:
>> 
>> 
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmaven.apache.org%2FSETTINGS%2F1.1.0data=04%7C01%7Caharui%40adobe.com%7Cc3e8334de4804345982a08d89254b15b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637420239736235404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=3ccTB4X%2BJ%2BDcgoXu4f5%2Bsn4gNvhzKW3XflhRviKqxxM%3Dreserved=0
 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmaven.apache.org%2Fxsd%2Fsettings-1.1.0.xsddata=04%7C01%7Caharui%40adobe.com%7Cc3e8334de4804345982a08d89254b15b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637420239736235404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=xlWxXIj0l7KQJhY%2BhYw1hf%2FwTZ%2Bteq5dnuTbkxTIS6I%3Dreserved=0;
 
xmlns="https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmaven.apache.org%2FSETTINGS%2F1.1.0data=04%7C01%7Caharui%40adobe.com%7Cc3e8334de4804345982a08d89254b15b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637420239736235404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=3ccTB4X%2BJ%2BDcgoXu4f5%2Bsn4gNvhzKW3XflhRviKqxxM%3Dreserved=0;
>> 
xmlns:xsi="https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instancedata=04%7C01%7Caharui%40adobe.com%7Cc3e8334de4804345982a08d89254b15b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637420239736235404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=b%2BVeRzz2WAJe8I7fMz3GVhdRPJ%2FIWBX4Jej5cRUU4wA%3Dreserved=0;>
>> 
>>   
>>   
>> apache.releases.https
>> {your apache user id}
>> {your apache user password}
>>   
>> 
   

Re: Release Step 003 Succeeded

[Piotr Zarzycki]

Harbs,

I can send you off the list tomorrow and you can put it to a proper dir ;)
It’s a hack :) You will do that once and forgot about that. Of course if we
are talking about Maven:)

Thanks,
Piotr

On Thu, 26 Nov 2020 at 22:46, Harbs  wrote:

> That’s on my local machine. Passing the Dcom option to the ant script
> doesn’t help.
>
> How would I manually get the Adobe artifacts on my machine?
>
> > On Nov 26, 2020, at 11:18 PM, Christofer Dutz 
> wrote:
> >
> > I can tell you what’s going on here.
> >
> > You are building on a system where the Adobe artifacts aren’t available
> in the maven local repo.
> > So the mavenizer (AKA maven extension I built to make non maven
> artifacts available as Maven artifacts) is kicking in. It expects a user to
> accept the license terms. It seems the MAC address of the network
> configuration of the build machine changed. You need to pass
> >
> >
> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
> >
> > To the build job
> >
> > Chris
> >
> >
> > Von: Harbs 
> > Datum: Donnerstag, 26. November 2020 um 21:53
> > An: Apache Royale Development 
> > Betreff: Re: Release Step 003 Succeeded
> > I don’t get it. I’m getting an endless loop of:
> >
> > [exec] The Adobe SDK license agreement applies to the Adobe Flash
> Player playerglobal.swc. Do you want to install the Adobe Flash Player
> playerglobal.swc?
> > [exec] (In a non-interactive build such as a CI server build,
> alternatively to typing y or yes you can also set a system property
> containing your system which is interpreted as equivalent to accepting by
> typing y or yes:
> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
> )
> > [exec] Do you accept (Yes/No) ? Your System-Id: b57aca16
> >
> > when I run:
> >> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
> >
> > Where is that coming from and why?
> >
> >> On Nov 26, 2020, at 9:16 PM, apacheroyal...@gmail.com wrote:
> >>
> >> From the royale-compiler repo:
> >> 1. Run:
> >> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
> >> 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.8
> >> 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.8
> >> 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.
>
> --

Piotr Zarzycki

Re: Release Step 003 Succeeded

[Harbs]

That’s on my local machine. Passing the Dcom option to the ant script doesn’t 
help.

How would I manually get the Adobe artifacts on my machine?

> On Nov 26, 2020, at 11:18 PM, Christofer Dutz  
> wrote:
> 
> I can tell you what’s going on here.
> 
> You are building on a system where the Adobe artifacts aren’t available in 
> the maven local repo.
> So the mavenizer (AKA maven extension I built to make non maven artifacts 
> available as Maven artifacts) is kicking in. It expects a user to accept the 
> license terms. It seems the MAC address of the network configuration of the 
> build machine changed. You need to pass
> 
> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
> 
> To the build job
> 
> Chris
> 
> 
> Von: Harbs 
> Datum: Donnerstag, 26. November 2020 um 21:53
> An: Apache Royale Development 
> Betreff: Re: Release Step 003 Succeeded
> I don’t get it. I’m getting an endless loop of:
> 
> [exec] The Adobe SDK license agreement applies to the Adobe Flash Player 
> playerglobal.swc. Do you want to install the Adobe Flash Player 
> playerglobal.swc?
> [exec] (In a non-interactive build such as a CI server build, 
> alternatively to typing y or yes you can also set a system property 
> containing your system which is interpreted as equivalent to accepting by 
> typing y or yes: 
> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
>  )
> [exec] Do you accept (Yes/No) ? Your System-Id: b57aca16
> 
> when I run:
>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
> 
> Where is that coming from and why?
> 
>> On Nov 26, 2020, at 9:16 PM, apacheroyal...@gmail.com wrote:
>> 
>> From the royale-compiler repo:
>> 1. Run:
>> ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
>> 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.8
>> 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.8
>> 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.

AW: Release Step 003 Succeeded

[Christofer Dutz]

I can tell you what’s going on here.

You are building on a system where the Adobe artifacts aren’t available in the 
maven local repo.
So the mavenizer (AKA maven extension I built to make non maven artifacts 
available as Maven artifacts) is kicking in. It expects a user to accept the 
license terms. It seems the MAC address of the network configuration of the 
build machine changed. You need to pass

-Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16

To the build job

Chris


Von: Harbs 
Datum: Donnerstag, 26. November 2020 um 21:53
An: Apache Royale Development 
Betreff: Re: Release Step 003 Succeeded
I don’t get it. I’m getting an endless loop of:

 [exec] The Adobe SDK license agreement applies to the Adobe Flash Player 
playerglobal.swc. Do you want to install the Adobe Flash Player 
playerglobal.swc?
 [exec] (In a non-interactive build such as a CI server build, 
alternatively to typing y or yes you can also set a system property containing 
your system which is interpreted as equivalent to accepting by typing y or yes: 
-Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
 )
 [exec] Do you accept (Yes/No) ? Your System-Id: b57aca16

when I run:
>  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8

Where is that coming from and why?

> On Nov 26, 2020, at 9:16 PM, apacheroyal...@gmail.com wrote:
>
> From the royale-compiler repo:
> 1. Run:
>  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
> 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.8
> 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.8
> 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.

Re: Release Step 003 Succeeded

[Harbs]

I don’t get it. I’m getting an endless loop of:

 [exec] The Adobe SDK license agreement applies to the Adobe Flash Player 
playerglobal.swc. Do you want to install the Adobe Flash Player 
playerglobal.swc?
 [exec] (In a non-interactive build such as a CI server build, 
alternatively to typing y or yes you can also set a system property containing 
your system which is interpreted as equivalent to accepting by typing y or yes: 
-Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=b57aca16
 )
 [exec] Do you accept (Yes/No) ? Your System-Id: b57aca16

when I run:
>  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8

Where is that coming from and why?

> On Nov 26, 2020, at 9:16 PM, apacheroyal...@gmail.com wrote:
> 
> From the royale-compiler repo:
> 1. Run:
>  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
> 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.8
> 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.8
> 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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. Run:
  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.8
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.8
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.8
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.

Royale Compiler Build Tools Release Step 003 Succeeded

[apacheroyaleci]

Folder 1.2.1 created. Login to CI server. Change directory to 
C:\jenkins\workspace\Royale_Compiler_Build_Tools_Release_Step_003 and run 'svn 
commit -m "add version folder" -- username='. You will need your svn username 
and password.

Release Step 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. 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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. 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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. 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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. 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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. 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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. 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 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. 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.

RE: Royale Compiler Build Tools Release Step 003 Succeeded

[Yishay Weiss]

Finally saw the correct instruction. I was confused because the steps 1-4 are 
numbered, but the last instruction looks like a footnote without a number. I 
would put the last instruction as (5) right underneath (4) and leave the m2 
settings xml as a footnote.


From: Alex Harui 
Sent: Monday, April 13, 2020 10:15:59 PM
To: dev@royale.apache.org 
Subject: Re: Royale Compiler Build Tools Release Step 003 Succeeded

The one from today looks ok.  The one you quoted was from my practice runs over 
the weekend which I fixed.

That folder does exist so step 003's message is correct.  I think Step 004 is 
failing because you missed the last instruction in 002's email.

-Alex

On 4/13/20, 12:08 PM, "Yishay Weiss"  wrote:

Looks like the email wasn’t sent correctly, which is why I got the ‘folder 
already exists’ message instead.

From: apacheroyal...@gmail.com<mailto:apacheroyal...@gmail.com>
Sent: Saturday, April 11, 2020 8:36 AM
To: dev@royale.apache.org<mailto:dev@royale.apache.org>
Subject: Royale Compiler Build Tools Release Step 003 Succeeded

ERROR: File 'email.txt' does not exist


From: Alex Harui<mailto:aha...@adobe.com.INVALID>
Sent: Monday, April 13, 2020 10:16 PM
To: dev@royale.apache.org<mailto:dev@royale.apache.org>
Subject: Re: Royale Compiler Build Tools Release Step 003 Succeeded

The one from today looks ok.  The one you quoted was from my practice runs over 
the weekend which I fixed.

That folder does exist so step 003's message is correct.  I think Step 004 is 
failing because you missed the last instruction in 002's email.

-Alex

On 4/13/20, 12:08 PM, "Yishay Weiss"  wrote:

Looks like the email wasn’t sent correctly, which is why I got the ‘folder 
already exists’ message instead.

From: apacheroyal...@gmail.com<mailto:apacheroyal...@gmail.com>
Sent: Saturday, April 11, 2020 8:36 AM
To: dev@royale.apache.org<mailto:dev@royale.apache.org>
    Subject: Royale Compiler Build Tools Release Step 003 Succeeded

ERROR: File 'email.txt' does not exist

Re: Royale Compiler Build Tools Release Step 003 Succeeded

[Alex Harui]

The one from today looks ok.  The one you quoted was from my practice runs over 
the weekend which I fixed.

That folder does exist so step 003's message is correct.  I think Step 004 is 
failing because you missed the last instruction in 002's email.

-Alex

On 4/13/20, 12:08 PM, "Yishay Weiss"  wrote:

Looks like the email wasn’t sent correctly, which is why I got the ‘folder 
already exists’ message instead.

From: apacheroyal...@gmail.com<mailto:apacheroyal...@gmail.com>
Sent: Saturday, April 11, 2020 8:36 AM
To: dev@royale.apache.org<mailto:dev@royale.apache.org>
Subject: Royale Compiler Build Tools Release Step 003 Succeeded

ERROR: File 'email.txt' does not exist

RE: Royale Compiler Build Tools Release Step 003 Succeeded

[Yishay Weiss]

Looks like the email wasn’t sent correctly, which is why I got the ‘folder 
already exists’ message instead.

From: apacheroyal...@gmail.com<mailto:apacheroyal...@gmail.com>
Sent: Saturday, April 11, 2020 8:36 AM
To: dev@royale.apache.org<mailto:dev@royale.apache.org>
Subject: Royale Compiler Build Tools Release Step 003 Succeeded

ERROR: File 'email.txt' does not exist

Royale Compiler Build Tools Release Step 003 Succeeded

[apacheroyaleci]

Folder 1.2.0 already exists.  Continue to next step.

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.

Royale Compiler Build Tools Release Step 003 Succeeded

[apacheroyaleci]

Folder 1.2.0 already exists.  Continue to next step.

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 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 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 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 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. Do not "Close" 
the staging repository until the other repos have been added.

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. Do not "Close" 
the staging repository until the other repos have been added.

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. Do not "Close" 
the staging repository until the other repos have been added.

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. Do not "Close" 
the staging repository until the other repos have been added.

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. Do not "Close" 
the staging repository until the other repos have been added.

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. Do not "Close" 
the staging repository until the other repos have been added.

Release Step 003 Succeeded

[Apache Royale CI Server]

>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.6 
-DskipTests=true
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

>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.6 
-DskipTests=true
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

>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.6 
-DskipTests=true
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

>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.6
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

>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.6
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

>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.6
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

>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.6
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

>From the royale-compiler repo:
1. If you are releasing the utils jars (compiler-jburg-types and 
compiler-build-tools), Run:
  ant -f releasesteps.xml Release_Step_003 -Dutils=true -Drelease.version=0.9.6
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

>From the royale-compiler repo:
1. If you are releasing the utils jars (compiler-jburg-types and 
compiler-build-tools), Run:
  ant -f releasesteps.xml Release_Step_003 -Dutils=true -Drelease.version=0.9.6
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

>From the royale-compiler repo:
1. If you are releasing the utils jars (compiler-jburg-types and 
compiler-build-tools), Run:
  ant -f releasesteps.xml Release_Step_003 -Dutils=true -Drelease.version=0.9.6
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

>From the royale-compiler repo:
1. If you are releasing the utils jars (compiler-jburg-types and 
compiler-build-tools), Run:
  ant -f releasesteps.xml Release_Step_003 -Dutils=true -Drelease.version=0.9.6
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

>From the royale-compiler repo:
1. If you are releasing the utils jars (compiler-jburg-types and 
compiler-build-tools), Run:
  ant -f releasesteps.xml Release_Step_003 -Dutils=true -Drelease.version=0.9.6
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

>From the royale-compiler repo:
1. If you are releasing the utils jars (compiler-jburg-types and 
compiler-build-tools), Run:
  ant -f releasesteps.xml Release_Step_003 -Dutils=true -Drelease.version=0.9.6
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

>From the royale-compiler repo:
1. If you are releasing the utils jars (compiler-jburg-types and 
compiler-build-tools), Run:
  ant -f releasesteps.xml Release_Step_003 -Dutils=true -Drelease.version=0.9.6
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

0. From the royale-compiler repo:
1. If you are releasing the utils jars (compiler-jburg-types and 
compiler-build-tools), Run:
  ant -f releasesteps.xml Release_Step_003 -Dutils=true -Drelease.version=0.9.6
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

1. If you are releasing the utils jars (compiler-jburg-types and 
compiler-build-tools), Run:
  ant -f releasesteps.xml Release_Step_003 -Dutils=true -Drelease.version=0.9.6
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

1. If you are releasing the utils jars (compiler-jburg-types and 
compiler-build-tools), Run:
  ant -f releasesteps.xml Release_Step_003 -Dutils=true -Drelease.version=0.9.6
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

1. If you are releasing the utils jars (compiler-jburg-types and 
compiler-build-tools), Run:
  ant -f releasesteps.xml Release_Step_003 -Dutils=true -Drelease.version=0.9.6
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

1. If you are releasing the utils jars (compiler-jburg-types and 
compiler-build-tools), Run:
  ant -f releasesteps.xml Release_Step_003 -Dutils=true -Drelease.version=0.9.6
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

1. If you are releasing the utils jars (compiler-jburg-types and 
compiler-build-tools), Run:
  ant -f releasesteps.xml Release_Step_003 -Dutils=true -Drelease.version=0.9.6
Otherwise, Run:
 ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
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 003 Succeeded

[Apache Royale CI Server]

1. Run ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6
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.6
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.6
This will upload the signed artifacts to Maven Release Staging.  Do not "Close" 
the staging repository until the other repos have been added.