Re: Website - create Showcase section
Thanks Om! That's very useful, I'll try to use that as a guide and unify with website. I'll be posting soon the data everyone need to post to be added with the corresponding sizes and additional info. El mié., 24 jul. 2019 a las 21:55, OmPrakash Muppirala (< bigosma...@gmail.com>) escribió: > If we can mimic how the Flex showcase works, that would be a good starting > point. > > http://flex.apache.org/community-showcase.html > > Thanks, > Om > > On Wed, Jul 24, 2019, 9:51 AM Yishay Weiss wrote: > > > Sounds good, thanks. > > > > > > > > > > From: Carlos Rovira > > Sent: Wednesday, July 24, 2019 7:35:54 PM > > To: dev@royale.apache.org > > Subject: Re: Website - create Showcase section > > > > Hi Yishay, > > > > good to know! ok we can start posting. > > In our case, I was thinking yesterday in make white brand version of our > > app to avoid conflicts with our clients, since the important thing is to > > showcase and put screenshots available to browse. > > For All apps we'll need some screenshots in concrete sizes-dimensions, in > > case we want to show case as screenshots. Other than that, could be post > > some video or gif animation, but I think the screen shot option will be > > more elegant to generate good visuals. > > > > I can revisit that part of the website and post soon info and material > that > > app creators must provide in order to fill its own page. > > > > Also, I have in my plate the page for Third party companies that wants to > > be listed in our site to sell services and consultancy around Apache > > Royale. > > > > thanks > > > > > > El mié., 24 jul. 2019 a las 8:17, Yishay Weiss ( >) > > escribió: > > > > > Hi, > > > > > > Is it time to have a production showcase section? > > > > > > We have Harbs [1] and Justin [2] in production. Hopefully Carlos, > Alina, > > > Andrew, et al join them soon. > > > > > > Tour de Flex and documentation app can also be made to be showcase > > worthy, > > > although perhaps in a different section. > > > > > > What do you all think? > > > > > > Yishay > > > > > > [1] https://marketinginflection.com/printui-demo.php > > > [2] https://rest-swf.prominic.net/Royale/Native/1.0.3/index.html > > > > > > > > > > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira > > > -- Carlos Rovira http://about.me/carlosrovira
Re: library-path changes
Hi Greg,
ok! I thought there was something more involved. About understanding better
how things work in maven plugin and know the reasons I think it could be
good to ask Chris Dutz about it, since he can give us the clues about all
of that.
Thanks!
El mié., 24 jul. 2019 a las 22:50, Greg Dove ()
escribió:
> Hi Carlos,
>
> Just to clarify: I had wondered whether there were inconsistencies in the
> framework so I checked more on that before adding my previous post in this
> thread.
> It seems that
> true was
> achieving a similar result to using 'provided' for the (inter)dependencies
> inside each framework project, so my concerns were not valid.
>
> When I look inside royale-maven-plugin, I do see some minor differences
> with respect to "runtime" specifically but tbh I would need to spend more
> time to understand why it is doing what it does with a combination of
> classifier and scope checks specifically for "runtime" and not "provided".
> Other than those differences, I think "runtime" and "provided" do seem to
> be treated the same.
>
>
>
>
> On Thu, Jul 25, 2019 at 5:36 AM Carlos Rovira
> wrote:
>
> > Hi,
> >
> > if I understand correctly, both "runtime" and "provided" are right now
> > equal for the compiler, right? I'm ok to understand conceptually
> > "runtime" and "provided" as Greg says. At least for now, although if we
> can
> > inform the compiler to differentiate as well would be great.
> >
> > In the other hand, flemojos seems to me more natural ("merged",
> > "external",...) since is what we use to manage in Flex days and in
> > FlashBuilder,
> > but don't know if is worth it to go to that kind of names, or better go
> to
> > the standard maven names. If it was easy to add flemojos names, I'd
> choose
> > those, but since there's many things to do, maybe we can stick with what
> we
> > have.
> >
> > In the other hand, thanks to Greg, we have this config solved in our real
> > App now. But I think in the process of doing this fix I think Greg saw
> some
> > issues
> > at framework level for maven. Hope Greg can expose it better if that's
> the
> > case, since maybe I'm wrong.
> >
> > thanks
> >
> >
> >
> >
> > El mié., 24 jul. 2019 a las 2:15, Greg Dove ()
> > escribió:
> >
> > > Just to add to the discussion on the 'provided' vs. 'runtime' scopes...
> > > I'm not really sure what scope name should be used for what, but here's
> > > what I have assumed:
> > > 'runtime' is for 'native' libs where the runtime provides the api
> surface
> > > that is represented by the swc. (playerglobal/ js-typedefs examples)
> > > 'provided' is for dependencies that are pre-compiled swc dependencies,
> > > where the dependency is expected to provided when the application is
> > built
> > > (in this case I have assumed it is explicitly listed as a dependency
> for
> > > the application build).
> > >
> > > I think these are different to what used to be the case with FlexMojos
> > (see
> > > 'Scope options in Flexmojos' [1])
> > > Also it seems that we don't do any of this in the framework project
> level
> > > poms, so I assume
> > > that true at
> > > frameworks/projects/pom.xml is a 'brute-force' override, simulating
> > > provided for each of the child framework projects'
> swc
> > > dependencies, and avoiding them being merged in for each of the
> framework
> > > swcs. I assume this might be another difference from [1] also, but I'm
> > not
> > > really sure as my only exposure to maven has been since FlexJS/Royale.
> > >
> > >
> > > 1.
> > >
> https://www.adobe.com/devnet/flex/articles/flex-maven-flexmojos-pt3.html
> > >
> > >
> > >
> > > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: library-path changes
Hi Carlos,
Just to clarify: I had wondered whether there were inconsistencies in the
framework so I checked more on that before adding my previous post in this
thread.
It seems that
true was
achieving a similar result to using 'provided' for the (inter)dependencies
inside each framework project, so my concerns were not valid.
When I look inside royale-maven-plugin, I do see some minor differences
with respect to "runtime" specifically but tbh I would need to spend more
time to understand why it is doing what it does with a combination of
classifier and scope checks specifically for "runtime" and not "provided".
Other than those differences, I think "runtime" and "provided" do seem to
be treated the same.
On Thu, Jul 25, 2019 at 5:36 AM Carlos Rovira
wrote:
> Hi,
>
> if I understand correctly, both "runtime" and "provided" are right now
> equal for the compiler, right? I'm ok to understand conceptually
> "runtime" and "provided" as Greg says. At least for now, although if we can
> inform the compiler to differentiate as well would be great.
>
> In the other hand, flemojos seems to me more natural ("merged",
> "external",...) since is what we use to manage in Flex days and in
> FlashBuilder,
> but don't know if is worth it to go to that kind of names, or better go to
> the standard maven names. If it was easy to add flemojos names, I'd choose
> those, but since there's many things to do, maybe we can stick with what we
> have.
>
> In the other hand, thanks to Greg, we have this config solved in our real
> App now. But I think in the process of doing this fix I think Greg saw some
> issues
> at framework level for maven. Hope Greg can expose it better if that's the
> case, since maybe I'm wrong.
>
> thanks
>
>
>
>
> El mié., 24 jul. 2019 a las 2:15, Greg Dove ()
> escribió:
>
> > Just to add to the discussion on the 'provided' vs. 'runtime' scopes...
> > I'm not really sure what scope name should be used for what, but here's
> > what I have assumed:
> > 'runtime' is for 'native' libs where the runtime provides the api surface
> > that is represented by the swc. (playerglobal/ js-typedefs examples)
> > 'provided' is for dependencies that are pre-compiled swc dependencies,
> > where the dependency is expected to provided when the application is
> built
> > (in this case I have assumed it is explicitly listed as a dependency for
> > the application build).
> >
> > I think these are different to what used to be the case with FlexMojos
> (see
> > 'Scope options in Flexmojos' [1])
> > Also it seems that we don't do any of this in the framework project level
> > poms, so I assume
> > that true at
> > frameworks/projects/pom.xml is a 'brute-force' override, simulating
> > provided for each of the child framework projects' swc
> > dependencies, and avoiding them being merged in for each of the framework
> > swcs. I assume this might be another difference from [1] also, but I'm
> not
> > really sure as my only exposure to maven has been since FlexJS/Royale.
> >
> >
> > 1.
> > https://www.adobe.com/devnet/flex/articles/flex-maven-flexmojos-pt3.html
> >
> >
> >
> > --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: Website - create Showcase section
If we can mimic how the Flex showcase works, that would be a good starting point. http://flex.apache.org/community-showcase.html Thanks, Om On Wed, Jul 24, 2019, 9:51 AM Yishay Weiss wrote: > Sounds good, thanks. > > > > > From: Carlos Rovira > Sent: Wednesday, July 24, 2019 7:35:54 PM > To: dev@royale.apache.org > Subject: Re: Website - create Showcase section > > Hi Yishay, > > good to know! ok we can start posting. > In our case, I was thinking yesterday in make white brand version of our > app to avoid conflicts with our clients, since the important thing is to > showcase and put screenshots available to browse. > For All apps we'll need some screenshots in concrete sizes-dimensions, in > case we want to show case as screenshots. Other than that, could be post > some video or gif animation, but I think the screen shot option will be > more elegant to generate good visuals. > > I can revisit that part of the website and post soon info and material that > app creators must provide in order to fill its own page. > > Also, I have in my plate the page for Third party companies that wants to > be listed in our site to sell services and consultancy around Apache > Royale. > > thanks > > > El mié., 24 jul. 2019 a las 8:17, Yishay Weiss () > escribió: > > > Hi, > > > > Is it time to have a production showcase section? > > > > We have Harbs [1] and Justin [2] in production. Hopefully Carlos, Alina, > > Andrew, et al join them soon. > > > > Tour de Flex and documentation app can also be made to be showcase > worthy, > > although perhaps in a different section. > > > > What do you all think? > > > > Yishay > > > > [1] https://marketinginflection.com/printui-demo.php > > [2] https://rest-swf.prominic.net/Royale/Native/1.0.3/index.html > > > > > > > > -- > Carlos Rovira > http://about.me/carlosrovira >
Re: library-path changes
Hi,
if I understand correctly, both "runtime" and "provided" are right now
equal for the compiler, right? I'm ok to understand conceptually
"runtime" and "provided" as Greg says. At least for now, although if we can
inform the compiler to differentiate as well would be great.
In the other hand, flemojos seems to me more natural ("merged",
"external",...) since is what we use to manage in Flex days and in
FlashBuilder,
but don't know if is worth it to go to that kind of names, or better go to
the standard maven names. If it was easy to add flemojos names, I'd choose
those, but since there's many things to do, maybe we can stick with what we
have.
In the other hand, thanks to Greg, we have this config solved in our real
App now. But I think in the process of doing this fix I think Greg saw some
issues
at framework level for maven. Hope Greg can expose it better if that's the
case, since maybe I'm wrong.
thanks
El mié., 24 jul. 2019 a las 2:15, Greg Dove ()
escribió:
> Just to add to the discussion on the 'provided' vs. 'runtime' scopes...
> I'm not really sure what scope name should be used for what, but here's
> what I have assumed:
> 'runtime' is for 'native' libs where the runtime provides the api surface
> that is represented by the swc. (playerglobal/ js-typedefs examples)
> 'provided' is for dependencies that are pre-compiled swc dependencies,
> where the dependency is expected to provided when the application is built
> (in this case I have assumed it is explicitly listed as a dependency for
> the application build).
>
> I think these are different to what used to be the case with FlexMojos (see
> 'Scope options in Flexmojos' [1])
> Also it seems that we don't do any of this in the framework project level
> poms, so I assume
> that true at
> frameworks/projects/pom.xml is a 'brute-force' override, simulating
> provided for each of the child framework projects' swc
> dependencies, and avoiding them being merged in for each of the framework
> swcs. I assume this might be another difference from [1] also, but I'm not
> really sure as my only exposure to maven has been since FlexJS/Royale.
>
>
> 1.
> https://www.adobe.com/devnet/flex/articles/flex-maven-flexmojos-pt3.html
>
>
>
> --
Carlos Rovira
http://about.me/carlosrovira
RE: Website - create Showcase section
Sounds good, thanks. From: Carlos Rovira Sent: Wednesday, July 24, 2019 7:35:54 PM To: dev@royale.apache.org Subject: Re: Website - create Showcase section Hi Yishay, good to know! ok we can start posting. In our case, I was thinking yesterday in make white brand version of our app to avoid conflicts with our clients, since the important thing is to showcase and put screenshots available to browse. For All apps we'll need some screenshots in concrete sizes-dimensions, in case we want to show case as screenshots. Other than that, could be post some video or gif animation, but I think the screen shot option will be more elegant to generate good visuals. I can revisit that part of the website and post soon info and material that app creators must provide in order to fill its own page. Also, I have in my plate the page for Third party companies that wants to be listed in our site to sell services and consultancy around Apache Royale. thanks El mié., 24 jul. 2019 a las 8:17, Yishay Weiss () escribió: > Hi, > > Is it time to have a production showcase section? > > We have Harbs [1] and Justin [2] in production. Hopefully Carlos, Alina, > Andrew, et al join them soon. > > Tour de Flex and documentation app can also be made to be showcase worthy, > although perhaps in a different section. > > What do you all think? > > Yishay > > [1] https://marketinginflection.com/printui-demo.php > [2] https://rest-swf.prominic.net/Royale/Native/1.0.3/index.html > > > -- Carlos Rovira http://about.me/carlosrovira
Re: Website - create Showcase section
Hi Yishay, good to know! ok we can start posting. In our case, I was thinking yesterday in make white brand version of our app to avoid conflicts with our clients, since the important thing is to showcase and put screenshots available to browse. For All apps we'll need some screenshots in concrete sizes-dimensions, in case we want to show case as screenshots. Other than that, could be post some video or gif animation, but I think the screen shot option will be more elegant to generate good visuals. I can revisit that part of the website and post soon info and material that app creators must provide in order to fill its own page. Also, I have in my plate the page for Third party companies that wants to be listed in our site to sell services and consultancy around Apache Royale. thanks El mié., 24 jul. 2019 a las 8:17, Yishay Weiss () escribió: > Hi, > > Is it time to have a production showcase section? > > We have Harbs [1] and Justin [2] in production. Hopefully Carlos, Alina, > Andrew, et al join them soon. > > Tour de Flex and documentation app can also be made to be showcase worthy, > although perhaps in a different section. > > What do you all think? > > Yishay > > [1] https://marketinginflection.com/printui-demo.php > [2] https://rest-swf.prominic.net/Royale/Native/1.0.3/index.html > > > -- Carlos Rovira http://about.me/carlosrovira
Re: Discuss of release steps preparation
Btw. Once I finish steps - Can I publish artefacts and start RC1 vote on dev ? Does anything I should know at the end which is not mention ? śr., 24 lip 2019 o 17:59 Piotr Zarzycki napisał(a): > By compare to dypedefs step - do you mean that I should look into Jenkins > configuration of that steps or something else ? > > śr., 24 lip 2019 o 17:56 Alex Harui napisał(a): > >> Hi Piotr, >> >> You can compare the output from previous builds and also the typedefs >> build configuration because both successfully used the date format. The >> Java documentation says that "Z" is for timezone. It shouldn't matter >> which one you use, but in the typedefs you hadn't specified one at all. >> >> It looks like in this case extra quotes are wrapped around the date. >> You'll have to compare against the typedefs steps to see why that's >> happening. >> >> HTH, >> -Alex >> >> On 7/24/19, 3:53 AM, "Piotr Zarzycki" wrote: >> >> Hi Alex, >> >> I was able to overcome issue with date for typedefs. Instruction >> there is >> saying: >> >> MM/dd/yy HH:mm Z >> > Where MM/dd/yy is the US-formatted date and HH:MM is a faked time to >> > encode the release version such as: >> > 2/10/19 9:06 -0800 >> >> >> I have typed 7/24/2019 HH (I don't remember what was that) and -0800 >> - This >> part I completely do not understand - what is for there minus ? Can >> you >> send exact example of what I should put there ? >> >> What's more I have went trough forward and in steps related to >> royale-asjs >> I see that typing either >> >> 7/24/19 9:06 -0800 or just 7/24/19 9:06 causes an exception with >> following >> message: >> >> >> [INFO] COMPC >> [INFO] Loading configuration: >> >> C:\jenkins\workspace\Royale_Release_Step_011\target\checkout\frameworks\themes\Jewel-Dark-NoFlat-Emphasized-Yellow-Theme\target\compile-swf-config.xml >> [INFO] >> [INFO] java.text.ParseException: Unparseable date: ""7/24/19 9:06"" >> [INFO] at java.text.DateFormat.parse(DateFormat.java:366) >> [INFO] at >> org.apache.royale.compiler.internal.targets.SWCTarget.processFileEntry(SWCTarget.java:330) >> [INFO] at >> org.apache.royale.compiler.internal.targets.SWCTarget.addFileEntriesToSWC(SWCTarget.java:291) >> >> It looks like there are some additional parentheses - Maybe it's an >> issue. >> >> >> Thanks, >> >> Piotr >> >> >> wt., 23 lip 2019 o 18:56 Alex Harui >> napisał(a): >> >> > Hi Piotr, >> > >> > What differences did you see? I downloaded the two SWCs and the >> only >> > difference I saw was the timestamps in the catalog.xml in the SWCs. >> > >> > The timestamps are set by the SWCDATE parameter in Step 005. The >> log >> > indicates that you did not specify a timezone so maybe that's why >> the >> > timestamps are not matching up. Please update the instructions so >> that >> > future RMs do not forget to include a timezone. The example >> pattern that >> > Jenkins should show should include a timezone. >> > >> > You will have to remove the tag and revert any commits from steps >> 5, 6, >> > and 7 before re-running step 5. >> > >> > HTH, >> > -Alex >> > >> > On 7/23/19, 6:57 AM, "Piotr Zarzycki" >> wrote: >> > >> > Hi Alex, >> > >> > Thanks! I have moved forward and in step 7 - related to >> typedefs during >> > build on my local machine I got mismatch error [1]. What could >> actually >> > happen? I did compare some files inside those two swc and they >> are >> > indeed >> > different - I have used Total Command to compare them. >> > >> > When I'm starting steps related to typedefs - first step >> actually >> > checkout >> > fresh sources ? I'm wondering whether Jenkins checkout them >> earlier >> > when I >> > started one of the step before typedefs steps? This those 2 >> files [2] >> > >> > [1] >> > >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Fbren2&data=02%7C01%7Caharui%40adobe.com%7C723db0a370484a11979e08d7102531f4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636995624254959025&sdata=MQFWoxta0CmaNxaVLnMZI3Efqr5%2B7UEPIOdLljGJ3IE%3D&reserved=0 >> > [2] >> > >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2F1drv.ms%2Fu%2Fs!ApVpLyjpHDC2icJBcCsTMZrzfnTTuQ%3Fe%3DNwidMg&data=02%7C01%7Caharui%40adobe.com%7C723db0a370484a11979e08d7102531f4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636995624254959025&sdata=Ed3it1kshjNy5c7sKI44Q9xa6iO196gi5bFgahDX8HA%3D&reserved=0 >> > >> > Thanks, >> > Piotr >> > >> > wt., 23 lip 2019 o 07:31 Alex Harui >> > napisał(a): >> > >> > > Hi Piotr, >> > > >> > > The email with the subject "Release Step 003 Succeeded" says: >> > > >> > > 1. If you are releasing the utils jars (compil
Re: Discuss of release steps preparation
By compare to dypedefs step - do you mean that I should look into Jenkins configuration of that steps or something else ? śr., 24 lip 2019 o 17:56 Alex Harui napisał(a): > Hi Piotr, > > You can compare the output from previous builds and also the typedefs > build configuration because both successfully used the date format. The > Java documentation says that "Z" is for timezone. It shouldn't matter > which one you use, but in the typedefs you hadn't specified one at all. > > It looks like in this case extra quotes are wrapped around the date. > You'll have to compare against the typedefs steps to see why that's > happening. > > HTH, > -Alex > > On 7/24/19, 3:53 AM, "Piotr Zarzycki" wrote: > > Hi Alex, > > I was able to overcome issue with date for typedefs. Instruction there > is > saying: > > MM/dd/yy HH:mm Z > > Where MM/dd/yy is the US-formatted date and HH:MM is a faked time to > > encode the release version such as: > > 2/10/19 9:06 -0800 > > > I have typed 7/24/2019 HH (I don't remember what was that) and -0800 - > This > part I completely do not understand - what is for there minus ? Can you > send exact example of what I should put there ? > > What's more I have went trough forward and in steps related to > royale-asjs > I see that typing either > > 7/24/19 9:06 -0800 or just 7/24/19 9:06 causes an exception with > following > message: > > > [INFO] COMPC > [INFO] Loading configuration: > > C:\jenkins\workspace\Royale_Release_Step_011\target\checkout\frameworks\themes\Jewel-Dark-NoFlat-Emphasized-Yellow-Theme\target\compile-swf-config.xml > [INFO] > [INFO] java.text.ParseException: Unparseable date: ""7/24/19 9:06"" > [INFO] at java.text.DateFormat.parse(DateFormat.java:366) > [INFO] at > org.apache.royale.compiler.internal.targets.SWCTarget.processFileEntry(SWCTarget.java:330) > [INFO] at > org.apache.royale.compiler.internal.targets.SWCTarget.addFileEntriesToSWC(SWCTarget.java:291) > > It looks like there are some additional parentheses - Maybe it's an > issue. > > > Thanks, > > Piotr > > > wt., 23 lip 2019 o 18:56 Alex Harui > napisał(a): > > > Hi Piotr, > > > > What differences did you see? I downloaded the two SWCs and the only > > difference I saw was the timestamps in the catalog.xml in the SWCs. > > > > The timestamps are set by the SWCDATE parameter in Step 005. The log > > indicates that you did not specify a timezone so maybe that's why the > > timestamps are not matching up. Please update the instructions so > that > > future RMs do not forget to include a timezone. The example pattern > that > > Jenkins should show should include a timezone. > > > > You will have to remove the tag and revert any commits from steps 5, > 6, > > and 7 before re-running step 5. > > > > HTH, > > -Alex > > > > On 7/23/19, 6:57 AM, "Piotr Zarzycki" > wrote: > > > > Hi Alex, > > > > Thanks! I have moved forward and in step 7 - related to typedefs > during > > build on my local machine I got mismatch error [1]. What could > actually > > happen? I did compare some files inside those two swc and they > are > > indeed > > different - I have used Total Command to compare them. > > > > When I'm starting steps related to typedefs - first step actually > > checkout > > fresh sources ? I'm wondering whether Jenkins checkout them > earlier > > when I > > started one of the step before typedefs steps? This those 2 > files [2] > > > > [1] > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Fbren2&data=02%7C01%7Caharui%40adobe.com%7C723db0a370484a11979e08d7102531f4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636995624254959025&sdata=MQFWoxta0CmaNxaVLnMZI3Efqr5%2B7UEPIOdLljGJ3IE%3D&reserved=0 > > [2] > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2F1drv.ms%2Fu%2Fs!ApVpLyjpHDC2icJBcCsTMZrzfnTTuQ%3Fe%3DNwidMg&data=02%7C01%7Caharui%40adobe.com%7C723db0a370484a11979e08d7102531f4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636995624254959025&sdata=Ed3it1kshjNy5c7sKI44Q9xa6iO196gi5bFgahDX8HA%3D&reserved=0 > > > > Thanks, > > Piotr > > > > wt., 23 lip 2019 o 07:31 Alex Harui > > napisał(a): > > > > > Hi Piotr, > > > > > > The email with the subject "Release Step 003 Succeeded" says: > > > > > > 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 > > > > > > It looks like you are not using the -Dutils=true. Please > improve the > > > email so future RMs will not miss that parameter. > >
Re: Discuss of release steps preparation
Hi Piotr, You can compare the output from previous builds and also the typedefs build configuration because both successfully used the date format. The Java documentation says that "Z" is for timezone. It shouldn't matter which one you use, but in the typedefs you hadn't specified one at all. It looks like in this case extra quotes are wrapped around the date. You'll have to compare against the typedefs steps to see why that's happening. HTH, -Alex On 7/24/19, 3:53 AM, "Piotr Zarzycki" wrote: Hi Alex, I was able to overcome issue with date for typedefs. Instruction there is saying: MM/dd/yy HH:mm Z > Where MM/dd/yy is the US-formatted date and HH:MM is a faked time to > encode the release version such as: > 2/10/19 9:06 -0800 I have typed 7/24/2019 HH (I don't remember what was that) and -0800 - This part I completely do not understand - what is for there minus ? Can you send exact example of what I should put there ? What's more I have went trough forward and in steps related to royale-asjs I see that typing either 7/24/19 9:06 -0800 or just 7/24/19 9:06 causes an exception with following message: [INFO] COMPC [INFO] Loading configuration: C:\jenkins\workspace\Royale_Release_Step_011\target\checkout\frameworks\themes\Jewel-Dark-NoFlat-Emphasized-Yellow-Theme\target\compile-swf-config.xml [INFO] [INFO] java.text.ParseException: Unparseable date: ""7/24/19 9:06"" [INFO] at java.text.DateFormat.parse(DateFormat.java:366) [INFO] at org.apache.royale.compiler.internal.targets.SWCTarget.processFileEntry(SWCTarget.java:330) [INFO] at org.apache.royale.compiler.internal.targets.SWCTarget.addFileEntriesToSWC(SWCTarget.java:291) It looks like there are some additional parentheses - Maybe it's an issue. Thanks, Piotr wt., 23 lip 2019 o 18:56 Alex Harui napisał(a): > Hi Piotr, > > What differences did you see? I downloaded the two SWCs and the only > difference I saw was the timestamps in the catalog.xml in the SWCs. > > The timestamps are set by the SWCDATE parameter in Step 005. The log > indicates that you did not specify a timezone so maybe that's why the > timestamps are not matching up. Please update the instructions so that > future RMs do not forget to include a timezone. The example pattern that > Jenkins should show should include a timezone. > > You will have to remove the tag and revert any commits from steps 5, 6, > and 7 before re-running step 5. > > HTH, > -Alex > > On 7/23/19, 6:57 AM, "Piotr Zarzycki" wrote: > > Hi Alex, > > Thanks! I have moved forward and in step 7 - related to typedefs during > build on my local machine I got mismatch error [1]. What could actually > happen? I did compare some files inside those two swc and they are > indeed > different - I have used Total Command to compare them. > > When I'm starting steps related to typedefs - first step actually > checkout > fresh sources ? I'm wondering whether Jenkins checkout them earlier > when I > started one of the step before typedefs steps? This those 2 files [2] > > [1] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Fbren2&data=02%7C01%7Caharui%40adobe.com%7C723db0a370484a11979e08d7102531f4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636995624254959025&sdata=MQFWoxta0CmaNxaVLnMZI3Efqr5%2B7UEPIOdLljGJ3IE%3D&reserved=0 > [2] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2F1drv.ms%2Fu%2Fs!ApVpLyjpHDC2icJBcCsTMZrzfnTTuQ%3Fe%3DNwidMg&data=02%7C01%7Caharui%40adobe.com%7C723db0a370484a11979e08d7102531f4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636995624254959025&sdata=Ed3it1kshjNy5c7sKI44Q9xa6iO196gi5bFgahDX8HA%3D&reserved=0 > > Thanks, > Piotr > > wt., 23 lip 2019 o 07:31 Alex Harui > napisał(a): > > > Hi Piotr, > > > > The email with the subject "Release Step 003 Succeeded" says: > > > > 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 > > > > It looks like you are not using the -Dutils=true. Please improve the > > email so future RMs will not miss that parameter. > > > > Thanks, > > -Alex > > > > On 7/22/19, 9:06 AM, "Piotr Zarzycki" > wrote: > > > > Hi Alex, > > > > I have made adjustment to documentation. I'm on step 3 where I > need > > build > > on my end sources. I have run on my PC this: > >
Re: Discuss of release steps preparation
Hi Alex, I was able to overcome issue with date for typedefs. Instruction there is saying: MM/dd/yy HH:mm Z > Where MM/dd/yy is the US-formatted date and HH:MM is a faked time to > encode the release version such as: > 2/10/19 9:06 -0800 I have typed 7/24/2019 HH (I don't remember what was that) and -0800 - This part I completely do not understand - what is for there minus ? Can you send exact example of what I should put there ? What's more I have went trough forward and in steps related to royale-asjs I see that typing either 7/24/19 9:06 -0800 or just 7/24/19 9:06 causes an exception with following message: [INFO] COMPC [INFO] Loading configuration: C:\jenkins\workspace\Royale_Release_Step_011\target\checkout\frameworks\themes\Jewel-Dark-NoFlat-Emphasized-Yellow-Theme\target\compile-swf-config.xml [INFO] [INFO] java.text.ParseException: Unparseable date: ""7/24/19 9:06"" [INFO] at java.text.DateFormat.parse(DateFormat.java:366) [INFO] at org.apache.royale.compiler.internal.targets.SWCTarget.processFileEntry(SWCTarget.java:330) [INFO] at org.apache.royale.compiler.internal.targets.SWCTarget.addFileEntriesToSWC(SWCTarget.java:291) It looks like there are some additional parentheses - Maybe it's an issue. Thanks, Piotr wt., 23 lip 2019 o 18:56 Alex Harui napisał(a): > Hi Piotr, > > What differences did you see? I downloaded the two SWCs and the only > difference I saw was the timestamps in the catalog.xml in the SWCs. > > The timestamps are set by the SWCDATE parameter in Step 005. The log > indicates that you did not specify a timezone so maybe that's why the > timestamps are not matching up. Please update the instructions so that > future RMs do not forget to include a timezone. The example pattern that > Jenkins should show should include a timezone. > > You will have to remove the tag and revert any commits from steps 5, 6, > and 7 before re-running step 5. > > HTH, > -Alex > > On 7/23/19, 6:57 AM, "Piotr Zarzycki" wrote: > > Hi Alex, > > Thanks! I have moved forward and in step 7 - related to typedefs during > build on my local machine I got mismatch error [1]. What could actually > happen? I did compare some files inside those two swc and they are > indeed > different - I have used Total Command to compare them. > > When I'm starting steps related to typedefs - first step actually > checkout > fresh sources ? I'm wondering whether Jenkins checkout them earlier > when I > started one of the step before typedefs steps? This those 2 files [2] > > [1] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Fbren2&data=02%7C01%7Caharui%40adobe.com%7C16b7c35e1eb544ec8f5408d70f75bc69%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636994870702395435&sdata=P%2FWxNbjF2DrHY7uDr7cPY9lF6qO4NSOKDlywOkaZfZ0%3D&reserved=0 > [2] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2F1drv.ms%2Fu%2Fs!ApVpLyjpHDC2icJBcCsTMZrzfnTTuQ%3Fe%3DNwidMg&data=02%7C01%7Caharui%40adobe.com%7C16b7c35e1eb544ec8f5408d70f75bc69%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636994870702395435&sdata=sk8SNjjBlbQF8xflFMBJmQEFp0ewY6mgCOxDxAR2Wm0%3D&reserved=0 > > Thanks, > Piotr > > wt., 23 lip 2019 o 07:31 Alex Harui > napisał(a): > > > Hi Piotr, > > > > The email with the subject "Release Step 003 Succeeded" says: > > > > 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 > > > > It looks like you are not using the -Dutils=true. Please improve the > > email so future RMs will not miss that parameter. > > > > Thanks, > > -Alex > > > > On 7/22/19, 9:06 AM, "Piotr Zarzycki" > wrote: > > > > Hi Alex, > > > > I have made adjustment to documentation. I'm on step 3 where I > need > > build > > on my end sources. I have run on my PC this: > > > > ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.6 > > > > It downloads sources and maven artifacts, but it also tried > build them > > automatically as I understa. I got error [1] - it understandable > cause > > there is no 1.0.0 compiler-jburg-types. Should I on my own build > > first compiler-jburg-types with 1.0.0 to have stuff in local > cache or > > should I made something else ? > > > > [1] > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Fa10nq&data=02%7C01%7Caharui%40adobe.com%7C16b7c35e1eb544ec8f5408d70f75bc69%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636994870702395435&sdata=QeV1rkVP9nV7ibPpSESKjwRveLhhTeM%2FLOKhLVM8ChU%3D&reserved=0 > > > > Thanks, > > Piotr > > > > sob., 20 lip 2019 o 06:25 Alex Harui > > napisał(a): > > > > > Please update the wiki in a way that th
Release Step 011 Succeeded
>From the royale-asjs repo: 1. Run ant -f releasesteps.xml Release_Step_011 -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_011_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_011_Upload -Drelease.version=0.9.6 This will upload the signed artifacts to Maven Release Staging. Verify that the compiler and typedefs artifacts are there along with the asjs artifacts, then hit the close to close the staging repo.
Release Step 010 Succeeded
Log in to the server, open a command prompt, change directory to C:\jenkins\workspace\Royale_Release_Step_010 and run the following commands: git push git push origin org.apache.royale.framework-0.9.6-rc1 You will need your Apache/Github username and 2FA token.
Release Step 009 Succeeded
Log in to the server, open a command prompt, change directory to C:\jenkins\workspace\Royale_Release_Step_009 and run the following commands: git push You will need your Apache/Github username and 2FA token.
Release Step 010 Succeeded
Log in to the server, open a command prompt, change directory to C:\jenkins\workspace\Royale_Release_Step_010 and run the following commands: git push git push origin org.apache.royale.framework-0.9.6-rc1 You will need your Apache/Github username and 2FA token.
Release Step 009 Succeeded
Log in to the server, open a command prompt, change directory to C:\jenkins\workspace\Royale_Release_Step_009 and run the following commands: git push You will need your Apache/Github username and 2FA token.
Release Step 008 Succeeded
Log in to the server, open a command prompt, change directory to C:\jenkins\workspace\Royale_Release_Step_008 and run the following commands: git push git checkout release/0.9.6 git push -u origin release/0.9.6 You will need your Apache/Github username and 2FA token.
Release Step 007 Succeeded
>From the royale-typedefs repo: 1. Run ant -f releasesteps.xml Release_Step_007 -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_007_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_007_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.
Royale_Release_Step_007 - Build # 34 - Failure!
Royale_Release_Step_007 - Build # 34 - Failure: Check console output at http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/Royale_Release_Step_007/34/ to view the results.
Release Step 006 Succeeded
Log in to the server, open a command prompt, change directory to C:\jenkins\workspace\Royale_Release_Step_006 and run the following commands: git push git push origin org.apache.royale.typedefs-0.9.6-rc1 You will need your Apache/Github username and 2FA token.
Release Step 005a Succeeded
Log in to the server, open a command prompt, change directory to C:\jenkins\workspace\Royale_Release_Step_005a_If_Utils and run the following commands: git push You will need your Apache/Github username and 2FA token.
Royale_Release_Step_005a_If_Utils - Build # 23 - Still Failing!
Royale_Release_Step_005a_If_Utils - Build # 23 - Still Failing: Check console output at http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/Royale_Release_Step_005a_If_Utils/23/ to view the results.
Royale_Release_Step_005a_If_Utils - Build # 22 - Failure!
Royale_Release_Step_005a_If_Utils - Build # 22 - Failure: Check console output at http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/Royale_Release_Step_005a_If_Utils/22/ to view the results.
