Jenkins build is back to normal : royale-asjs_jsonly #341

[apacheroyaleci]

See 

Re: About Royale MDL Examples

[Alex Harui]

It occurred to me that if you fix up the licensing of these files, we
could still bundle it in future releases.  The main issue was that the
examples contain modified CC-BY-4.0 content from CSS and HTML files.  IMO,
if you personally publish the modifications under CC-BY-4.0 in your repo,
then Royale will be using unmodified content when bundling these examples.

So, I think that would involve adding comments to CSS and text from the
HTML files to denote that they came from Material and add Google's headers
to those files.

-Alex

On 2/20/18, 2:26 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>That's cool Piotr! :)
>
>Could you upload MDLBlogExample as well, is not yet finished, but I think
>it deserves to be as well in some repo.
>
>thanks!
>
>Carlos
>
>2018-02-20 22:49 GMT+01:00 Piotr Zarzycki :
>
>> MDLExample landed in my repository [1] and live [2]. It will be
>>improved in
>> the next weeks. :)
>>
>> [1]
>> 
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
>>om%2Fpiotrzarzycki21%2FTranspiledActionScript%2Ftree%2F=02%7C01%7Cah
>>arui%40adobe.com%7C7f00f29206244347de3508d578b10213%7Cfa7b1b5a7b34438794a
>>ed2c178decee1%7C0%7C0%7C636547623990953344=kTOIxofe0bT4rIQKRWqQwKPP
>>8Gyh0WiNuQOPEB5ltJU%3D=0
>> examples/Examples/MDLExample
>> [2] 
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftranspil
>>edactionscript.com%2Fexamples%2FMDLExample%2F=02%7C01%7Caharui%40ado
>>be.com%7C7f00f29206244347de3508d578b10213%7Cfa7b1b5a7b34438794aed2c178dec
>>ee1%7C0%7C0%7C636547623990953344=wKYUEx8aoa6z6mjGoPc9ECyDrpIJK9T23o
>>UPwFBdv2o%3D=0
>>
>> Thanks, Piotr
>>
>>
>> 2018-02-19 23:07 GMT+01:00 Carlos Rovira :
>>
>> > that would be great! ;)
>> >
>> > 2018-02-19 20:26 GMT+01:00 Piotr Zarzycki :
>> >
>> > > Ok let's leave it as is. I will take MDL to my repository. I don't
>>want
>> > to
>> > > fight with Legal about that.
>> > >
>> > > Carlos I will look into the Vivid soon. :)
>> > >
>> > > Thanks, Piotr
>> > >
>> > > 2018-02-19 20:23 GMT+01:00 Carlos Rovira :
>> > >
>> > > > Hi,
>> > > >
>> > > > as Alex said, Dave and Piotr understand my word incorrectly.
>>Maybe I
>> > > > express incorrectly. So bad for myself.
>> > > >
>> > > > but anyway, I'm with Alex that we as "Apache Royale" should take
>> > priority
>> > > > for our own UI set, and I prefer all the time that we could spend
>>in
>> > MDL
>> > > > examples will go to make our own set looks beautiful.
>> > > >
>> > > > In the end, whatever we interpret, is that Piotr can upload
>> MDLExample
>> > to
>> > > > their GitHub so make it accesible to anyone.
>> > > >
>> > > > That's my opinion on this, although I invest lot of time in
>> MDLExample
>> > a
>> > > > long with Piotr, my intention was to catch eyes and people for the
>> > > project,
>> > > > but in the end I see clearly that any *imported* UI set (MDL,
>> > Bootstrap,
>> > > > etc...) are not the way we should take. Our future depends in
>>making
>> > our
>> > > > own UI set.
>> > > >
>> > > > @Piotr, after testing with Vivid, I see clearly that we can mimic
>>the
>> > > same
>> > > > MDL looks, maybe not 100%, but very closely...and seems a doable
>>task
>> > if
>> > > > anyone is interesed as a theme, and with only one compilation
>> > parameter,
>> > > we
>> > > > can make the entire app looks completly different...I think that
>> should
>> > > be
>> > > > our goal! :)
>> > > >
>> > > > thanks
>> > > >
>> > > >
>> > > >
>> > > > 2018-02-19 17:33 GMT+01:00 Alex Harui :
>> > > >
>> > > > > @Dave,
>> > > > >
>> > > > > I agree that you could interpret Carlos's words the way you did,
>> but
>> > I
>> > > > > also think it is possible that Carlos was referring that the two
>> MDL
>> > > > > examples we are discussing aren't as important as some other
>>things
>> > on
>> > > VP
>> > > > > Legal's to-do list, which is fair and probably true and why I
>> haven't
>> > > > > pinged VP Legal.
>> > > > >
>> > > > > @Piotr,
>> > > > >
>> > > > > As Dave says, the way to escalate is to add a comment to the
>>JIRA
>> > issue
>> > > > or
>> > > > > ask politely on legal-discuss.  Again, how important is it?
>> > > > >
>> > > > > My 2 cents,
>> > > > > -Alex
>> > > > >
>> > > > > On 2/19/18, 8:23 AM, "Dave Fisher" 
>>wrote:
>> > > > >
>> > > > > >Carlos,
>> > > > > >
>> > > > > >Please stop with the meme that the ASF doesn’t care about
>> projects.
>> > It
>> > > > is
>> > > > > >not helpful and it is not true.
>> > > > > >
>> > > > > >There are hundreds of projects. I suggested that you politely
>> query
>> > on
>> > > > > >legal-discuss@.
>> > > > > >
>> > > > > >Regards,
>> > > > > >Dave
>> > > > > >
>> > > > > >Sent from my iPhone
>> > > > > >
>> > > > > >> On Feb 19, 2018, at 6:52 AM, Carlos Rovira <
>> > carlosrov...@apache.org
>> > > 

Re: How I can use multiple CSS files

[Alex Harui]

Hi Carlos,

It is unlikely that Ant artifacts will affect Maven results.  They have
different jar names.

I synced up and clean my local repo and rebuilt the compiler with the
feature/vivid branch and royale-asjs with the vivid-ui-set branch and
everything works as expected.  In
examples/royale/VividExample/target/javascript/bin/js-debug/App.css is a
TextField selector that has several properties.

The file I changed in royale-compiler is CSSManager.java.  Add a
System.out.println("This is Carlos's local copy"); at the beginning of
getCSSFromThemes.  Delete the compiler jars from your local repo and
rebuild the compiler then the framework and example.  You should see your
println in the output.  If you don't then for some reason you are pulling
the wrong one.  The console output for the compiler should show that it
put the jars in the local repo.  The console output for framework and/or
examples should show where it got the compiler jars.

-Alex

On 2/20/18, 12:13 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>I removed all my maven repo and build all again. As well check that your
>commits are in, and removed all targets to start from a clean point.
>I created a new branch "vivid-ui-set" since the other one had the rebase
>problem.
>When I build Vivid, then BlueTheme and the Example I find that TextField
>css tule is empty and sub rules for label and input are empty as well
>I see TextField.css is in theme SWC but is not applied in final example
>app
>
>I think you should get the same if you build with maven and maybe as you
>first started to build with ANT and then with MAVEN maybe the old ant
>content was affecting the build
>
>Can you take a look?
>
>* Check the new branch and that your changes are there
>* remove as I did targets and royale vivid projects in .m2 repo
>* and try to build from scratch only with maven
>
>If you get it to work, I think something is wrong in royale since we
>should
>get the same output.
>maybe different maven version? (I'm using 3.5.0)
>
>Hope we can reach what's going on since I'm stuck with this problem and
>would like to continue working on this
>
>Thanks in advance!
>
>Carlos
>
>
>
>
>2018-02-20 0:55 GMT+01:00 Alex Harui :
>
>> Hi Carlos,
>>
>> You will just have to debug it on your end.  I would recommend:
>>
>> -Verify that the source changes I made to royale-compiler are in your
>> local working copy.
>> -manually clear your local maven repo of org.apache.royale.compiler
>> artifacts
>> -rebuild royale-compiler.
>> -Scan the console output from the royals-compiler build for undetected
>> errors.  Our Maven integration isn't perfect so there is a chance the
>> compilation could report an error that doesn't return a failure code
>>that
>> stops the Maven build.
>> -Rebuild your example.
>> -Scan the console output for undetected errors. Also verify that Maven
>> pulled the compiler from your local repo instead of the snapshot server
>>or
>> some other server.
>>
>> If none of that helps you find the problem, the next thing I would do is
>> add a System.out.println to the code I modified so you can see if that
>> code gets run or not.
>>
>> HTH,
>> -Alex
>>
>> On 2/19/18, 11:10 AM, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>>  wrote:
>>
>> >Hi Alex,
>> >
>> >2018-02-19 18:06 GMT+01:00 Alex Harui :
>> >
>> >> I just tried it with Maven and it worked.  I didn't run the example,
>>I
>> >> just opened App.css and saw that the contents of TextField.css are in
>> >> there.
>> >>
>> >
>> >Hi Alex, I'm not seeing what you see :?
>> >I opened App.css in target, js-debug and Textfield is empty Only see {}
>> >I updated all repos and rebuild all with maven to ensure I'm with the
>> >latest
>> >
>> >
>> >>
>> >> For some reason, there were some puzzling results on merging in your
>> >> changes.  It wanted me to push commits you had made.  Not sure why
>>or if
>> >> that would affect your results.
>> >>
>> >
>> >Right, I made a rebase but it works bad and try to fix it. The problem
>>was
>> >that SourceTree had "Allow force push" unchecked.
>> >Could you confirm your changes are all ok?
>> >
>> >don't know what's hapening...
>> >
>> >Thanks
>> >
>> >
>> >
>> >>
>> >> HTH,
>> >> -Alex
>> >>
>> >> On 2/19/18, 8:29 AM, "Alex Harui"  wrote:
>> >>
>> >> >I saw it work.  But I was using the Ant build in order to test it
>>since
>> >> >nobody had provided it yet.  I will try with Maven later.
>> >> >
>> >> >-Alex
>> >> >
>> >> >On 2/19/18, 6:55 AM, "carlos.rov...@gmail.com on behalf of Carlos
>> >>Rovira"
>> >> >
>>wrote:
>> >> >
>> >> >>Hi Alex,
>> >> >>
>> >> >>2018-02-19 7:08 GMT+01:00 Alex Harui :
>> >> >>
>> >> >>>   But I saw that it could be easily 

Build failed in Jenkins: royale-asjs_jsonly #338

[apacheroyaleci]

See 


--
[...truncated 516.97 KB...]
[javac] C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\Frame.java:148:
 warning: [rawtypes] found raw type: Entry
[javac] Map.Entry entry = (Map.Entry) i.next();
[javac]^
[javac]   missing type arguments for generic class Entry
[javac]   where K,V are type-variables:
[javac] K extends Object declared in interface Entry
[javac] V extends Object declared in interface Entry
[javac] C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\Movie.java:157:
 warning: [rawtypes] found raw type: Map
[javac] public Map definitionMap;
[javac]^
[javac]   missing type arguments for generic class Map
[javac]   where K,V are type-variables:
[javac] K extends Object declared in interface Map
[javac] V extends Object declared in interface Map
[javac] C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\MovieMetaData.java:144:
 warning: [rawtypes] found raw type: Iterator
[javac] public Iterator getFunctionLines()
[javac]^
[javac]   missing type arguments for generic class Iterator
[javac]   where E is a type-variable:
[javac] E extends Object declared in interface Iterator
[javac] C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\MovieMetaData.java:550:
 warning: [rawtypes] found raw type: Iterator
[javac] Iterator it = 
actions.clipActionRecords.iterator();
[javac] ^
[javac]   missing type arguments for generic class Iterator
[javac]   where E is a type-variable:
[javac] E extends Object declared in interface Iterator
[javac] C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\types\CurvedEdgeRecord.java:25:
 warning: [overrides] Class CurvedEdgeRecord overrides equals, but neither it 
nor any superclass overrides hashCode method
[javac] public class CurvedEdgeRecord extends EdgeRecord
[javac]^
[javac] C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\types\StraightEdgeRecord.java:26:
 warning: [overrides] Class StraightEdgeRecord overrides equals, but neither it 
nor any superclass overrides hashCode method
[javac] public class StraightEdgeRecord extends EdgeRecord
[javac]^
[javac] C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\types\StyleChangeRecord.java:151:
 warning: [cast] redundant cast to FillStyle
[javac] FillStyle style = (FillStyle) it.next();
[javac]   ^
[javac] C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\types\StyleChangeRecord.java:33:
 warning: [overrides] Class StyleChangeRecord overrides equals, but neither it 
nor any superclass overrides hashCode method
[javac] public class StyleChangeRecord extends ShapeRecord
[javac]^
[javac] C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\types\ArrayLists.java:30:
 warning: [rawtypes] found raw type: List
[javac] public static boolean equals(List a1, List a2)
[javac]  ^
[javac]   missing type arguments for generic class List
[javac]   where E is a type-variable:
[javac] E extends Object declared in interface List
[javac] C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\types\ArrayLists.java:30:
 warning: [rawtypes] found raw type: List
[javac] public static boolean equals(List a1, List a2)
[javac]   ^
[javac]   missing type arguments for generic class List
[javac]   where E is a type-variable:
[javac] E extends Object declared in interface List
[javac] C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\swfutils\src\main\java\flash\swf\types\FocalGradient.java:25:
 warning: [overrides] Class FocalGradient overrides equals, but neither it nor 
any superclass overrides hashCode method
[javac] public class FocalGradient extends Gradient
[javac]^
[javac] 69 warnings

main:
 [copy] Copying 1 file to C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\swfutils\target\classes\META-INF
 [copy] Copying 1 file to C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\swfutils\target\classes\META-INF
  [jar] Building jar: C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\lib\swfutils.jar

compiler.oem:

src.depend:

compile:

Re: Maintain Release Notes List of changes(was: Re: [DRAFT][ANNOUNCE] Apache Royale 0.9.1 Released)

[Gabe Harbs]

No I missed it. Pneumonia and all…

FWIW, it’s possible to add commit references to issues after a commit is made. 
You just include a hash in an issue comment.

> On Feb 20, 2018, at 7:13 PM, Alex Harui  wrote:
> 
> I don't know if you saw my commit wizard idea.
> https://lists.apache.org/thread.html/5d94976d277729a8f34b77a0ec09e45678bbf5 
> 
> d2d7111e411fb5fb14@%3Cdev.royale.apache.org 
> %3E
> 
> I guess it won't help if you don't use command line for commits.  It
> should be possible to do any of the 3 you suggested.  The GitHub API seems
> to be relatively easy to use, and I tested the JSON2ASVO utility with some
> of the responses and it seems to work.  We just need to find the time to
> put something together.
> 
> -Alex
> 
> On 2/20/18, 8:28 AM, "Gabe Harbs"  > wrote:
> 
>> +1
>> 
>> Some thoughts:
>> 1. We can have a utility which rewrites entries to a standard format
>> before release.
>> 2. We can have a form which takes the info and adds it to the release
>> notes.
>> 3. It might be interesting to have a Github integration which watches
>> Issues and when a commit closes a ticket, it creates an entry in the
>> release notes.
>> 
>> Harbs
>> 
>>> On Feb 20, 2018, at 6:05 PM, Alex Harui 
>>> wrote:
>>> 
>>> If you want a particular format, help me write a wizard that will manage
>>> that.  I will not remember to get it right every time I commit.  I will
>>> not know what to use for a description unless we take the bug topic
>>> verbatim with any misspellings and other cruft.
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>> On 2/20/18, 5:37 AM, "Piotr Zarzycki" >> >> 
>>> wrote:
>>> 
 I see in release notes links to issues. I'm in favor of having
 description
 + eventually links.
 
 - my description for a bug [Bug Number](link) - it will display nicely
 on
 GitHub.
 
 I'm talking about this commit.
 
 What do other thinks ?
 
 Thanks, Piotr
 
 
 2018-02-14 23:13 GMT+01:00 Carlos Rovira >:
 
> Ok Alex, that's great, so we'll be doing the work on RELEASE_NOTES
> file
> 
> thanks!
> 
> 2018-02-14 17:31 GMT+01:00 Alex Harui  >:
> 
>> We already have this.  It is the RELEASE_NOTES file.  All ASF
>> releases
> are
>> supposed to have one so we should use it.  And as keepachangelog.com 
>> 
> says,
>> it is not the GitHub commit log.
>> 
>> IMO, it is not the Release Manager's job to fill this out.  It needs
> to
> be
>> maintained by every committer.  I know I'm really bad about filling
>> it
> out
>> which is why I proposed a Commit Wizard a few days ago.
>> 
>> IMO, there were some good feature enhancements in 0.9.1, like
>> NestedDataGridColumn, but nothing really notable.  The focus of 0.9.1
> was
>> to get the documentation published by making sure ASDoc and the
> examples
>> worked.  Also, there was only a few weeks between 0.9.0 and 0.9.1.
>> 
>> Also, I added links from the RELEASE_NOTES to our wiki.  That way we
> can
>> add late-breaking news after the release.  I think we should do the
> that
>> for every release.  But we should try to make the RELEASE_NOTES
> contain
>> most or all of the notable changes.
>> 
>> I think there will be major new features in 0.9.2 if it doesn't
> become a
>> hot fix release.  I just pushed "fixed row height virtual lists" and
> will
>> likely get variable row height working as well.  And of course, I did
> not
>> update RELEASE_NOTES when I pushed those changes, so I will go and do
> that
>> now ;-)
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 2/14/18, 5:15 AM, "Olaf Krueger" > > wrote:
>> 
 In Moonshine we are following this ->
 https://na01.safelinks.protection.outlook.com/?url= 
 
>> http%3A%2F%2Fkeepachan
 gelog.com 
 %2Fen%2F1.0.0%2F=02%7C01%7Caharui%40adobe.com 
 
>> %7C4f310c6f286
 04f5391d708d573acfd7d%7Cfa7b1b5a7b34438794aed2c178de
>> cee1%7C0%7C0%7C636542
 109181598814=Epgu%2BBIjQkIbbte9KXBIEFwg1YN2uZZ7a
>> DEr%2BoGyvgU%3D
 erved=0
>>> 
>>> +1, we also start using this format here ;-)
>>> 
>>> Olaf
>>> 
>>> 
>>> 
>>> --
>>> Sent from:
>>> 

Re: [royale-asjs] branch feature/vivid-ui-set created (now ecaab75)

[piotrz]

This is what I'm seeing after framework build:

 



--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: [royale-asjs] branch feature/vivid-ui-set created (now ecaab75)

[Piotr Zarzycki]

Carlos,

I'm on it! Not sure if I do this today fully, but compiler is building
first. Before that I removed from .m2 whole folder royale :)



2018-02-20 23:18 GMT+01:00 Carlos Rovira :

> Piotr,
>
> could you change to the new branch and try to build Vivid - VividBllueTheme
> and VividExample (in that order) and see what you get on the screen?
> I get TextField rules empty and the textfield control in the screen shows
> completely unstyled
>
> Could you try it and report here? I think a third test would be great to
> know what output is more normal if Alex or mine.
>
> thanks!
>
> Carlos
>
> 2018-02-20 21:19 GMT+01:00 Piotr Zarzycki :
>
> > Once you get it and you will stay with that created branch, remove the
> old
> > one.
> >
> > Thanks!!
> >
> > 2018-02-20 21:16 GMT+01:00 Carlos Rovira :
> >
> > > Hi Piotr,
> > > some days ago I make a bad rebase in the old branch, and we are now
> > seeking
> > > for a problem with this projects, so I want to know that the rebase
> > branch
> > > was not the problem.
> > > I'm waiting for Alex to test this branch and see if he get positive
> > output
> > > or not.
> > >
> > >
> > >
> > > 2018-02-20 21:08 GMT+01:00 Piotr Zarzycki :
> > >
> > > > Why did you create new branch ? Is this for something else ? I've
> > created
> > > > especially for previous feature/vivid branch on typedefs with the
> same
> > > name
> > > > in order to have it buildable as part of pipeline.
> > > > What's with the old branch ?
> > > >
> > > > [1] https://builds.apache.org/job/Royale%20Pipeline/
> > > >
> > > >
> > > >
> > > >
> > > > 2018-02-20 21:05 GMT+01:00 :
> > > >
> > > > > This is an automated email from the ASF dual-hosted git repository.
> > > > >
> > > > > carlosrovira pushed a change to branch feature/vivid-ui-set
> > > > > in repository https://gitbox.apache.org/repos/asf/royale-asjs.git.
> > > > >
> > > > >
> > > > >   at ecaab75  fresh branch with all vivid work, still not work
> > > > >
> > > > > This branch includes the following new commits:
> > > > >
> > > > >  new ecaab75  fresh branch with all vivid work, still not work
> > > > >
> > > > > The 1 revisions listed above as "new" are entirely new to this
> > > > > repository and will be described in separate emails.  The revisions
> > > > > listed as "add" were already present in the repository and have
> only
> > > > > been added to this reference.
> > > > >
> > > > >
> > > > > --
> > > > > To stop receiving notification emails like this one, please contact
> > > > > carlosrov...@apache.org.
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Piotr Zarzycki
> > > >
> > > > Patreon: *https://www.patreon.com/piotrzarzycki
> > > > *
> > > >
> > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > *
> >
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

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

Re: About Royale MDL Examples

[Carlos Rovira]

That's cool Piotr! :)

Could you upload MDLBlogExample as well, is not yet finished, but I think
it deserves to be as well in some repo.

thanks!

Carlos

2018-02-20 22:49 GMT+01:00 Piotr Zarzycki :

> MDLExample landed in my repository [1] and live [2]. It will be improved in
> the next weeks. :)
>
> [1]
> https://github.com/piotrzarzycki21/TranspiledActionScript/tree/
> examples/Examples/MDLExample
> [2] https://transpiledactionscript.com/examples/MDLExample/
>
> Thanks, Piotr
>
>
> 2018-02-19 23:07 GMT+01:00 Carlos Rovira :
>
> > that would be great! ;)
> >
> > 2018-02-19 20:26 GMT+01:00 Piotr Zarzycki :
> >
> > > Ok let's leave it as is. I will take MDL to my repository. I don't want
> > to
> > > fight with Legal about that.
> > >
> > > Carlos I will look into the Vivid soon. :)
> > >
> > > Thanks, Piotr
> > >
> > > 2018-02-19 20:23 GMT+01:00 Carlos Rovira :
> > >
> > > > Hi,
> > > >
> > > > as Alex said, Dave and Piotr understand my word incorrectly. Maybe I
> > > > express incorrectly. So bad for myself.
> > > >
> > > > but anyway, I'm with Alex that we as "Apache Royale" should take
> > priority
> > > > for our own UI set, and I prefer all the time that we could spend in
> > MDL
> > > > examples will go to make our own set looks beautiful.
> > > >
> > > > In the end, whatever we interpret, is that Piotr can upload
> MDLExample
> > to
> > > > their GitHub so make it accesible to anyone.
> > > >
> > > > That's my opinion on this, although I invest lot of time in
> MDLExample
> > a
> > > > long with Piotr, my intention was to catch eyes and people for the
> > > project,
> > > > but in the end I see clearly that any *imported* UI set (MDL,
> > Bootstrap,
> > > > etc...) are not the way we should take. Our future depends in making
> > our
> > > > own UI set.
> > > >
> > > > @Piotr, after testing with Vivid, I see clearly that we can mimic the
> > > same
> > > > MDL looks, maybe not 100%, but very closely...and seems a doable task
> > if
> > > > anyone is interesed as a theme, and with only one compilation
> > parameter,
> > > we
> > > > can make the entire app looks completly different...I think that
> should
> > > be
> > > > our goal! :)
> > > >
> > > > thanks
> > > >
> > > >
> > > >
> > > > 2018-02-19 17:33 GMT+01:00 Alex Harui :
> > > >
> > > > > @Dave,
> > > > >
> > > > > I agree that you could interpret Carlos's words the way you did,
> but
> > I
> > > > > also think it is possible that Carlos was referring that the two
> MDL
> > > > > examples we are discussing aren't as important as some other things
> > on
> > > VP
> > > > > Legal's to-do list, which is fair and probably true and why I
> haven't
> > > > > pinged VP Legal.
> > > > >
> > > > > @Piotr,
> > > > >
> > > > > As Dave says, the way to escalate is to add a comment to the JIRA
> > issue
> > > > or
> > > > > ask politely on legal-discuss.  Again, how important is it?
> > > > >
> > > > > My 2 cents,
> > > > > -Alex
> > > > >
> > > > > On 2/19/18, 8:23 AM, "Dave Fisher"  wrote:
> > > > >
> > > > > >Carlos,
> > > > > >
> > > > > >Please stop with the meme that the ASF doesn’t care about
> projects.
> > It
> > > > is
> > > > > >not helpful and it is not true.
> > > > > >
> > > > > >There are hundreds of projects. I suggested that you politely
> query
> > on
> > > > > >legal-discuss@.
> > > > > >
> > > > > >Regards,
> > > > > >Dave
> > > > > >
> > > > > >Sent from my iPhone
> > > > > >
> > > > > >> On Feb 19, 2018, at 6:52 AM, Carlos Rovira <
> > carlosrov...@apache.org
> > > >
> > > > > >>wrote:
> > > > > >>
> > > > > >> Hi Piotr
> > > > > >>
> > > > > >> my bet is that, as that projects are of no interest for ASF, you
> > can
> > > > > >>upload
> > > > > >> to your GitHub account directly without any word about it.
> > > > > >>
> > > > > >> my 2cnt
> > > > > >>
> > > > > >> 2018-02-19 11:48 GMT+01:00 Piotr Zarzycki <
> > > piotrzarzyck...@gmail.com
> > > > >:
> > > > > >>
> > > > > >>> It's been several weeks since w have asked about advice. There
> is
> > > no
> > > > > >>> response. How can we escalate this question higher ?
> > > > > >>>
> > > > > >>> Thanks, Piotr
> > > > > >>>
> > > > > >>> 2018-01-30 19:58 GMT+01:00 Alex Harui  > >:
> > > > > >>>
> > > > >  I created
> > > > > https://na01.safelinks.protection.outlook.com/?url=
> > > > > https%3A%2F%2Fissues
> > > > > .apache.org%2Fjira%2Fbrowse%2FLEGAL-363=02%
> > > > > 7C01%7Caharui%40adobe.c
> > > > > om%7C38e5360cf20847b34cd508d577b572dd%
> > > 7Cfa7b1b5a7b34438794aed2c178de
> > > > > cee
> > > > > 1%7C0%7C0%7C636546543554938163=
> > > cDHQDyV2kJw53r7ZQKODy3Itqx2bjl
> > > > > leb6
> > > > > f28MJeDgE%3D=0
> > > > > 
> > > > >  -Alex
> > > > > 
> > > > > > On 1/30/18, 8:48 AM, "Piotr Zarzycki" <
> > piotrzarzyck...@gmail.com
> > > >
> > > > > >wrote:
> > > > > 

Re: [royale-asjs] branch feature/vivid-ui-set created (now ecaab75)

[Carlos Rovira]

Piotr,

could you change to the new branch and try to build Vivid - VividBllueTheme
and VividExample (in that order) and see what you get on the screen?
I get TextField rules empty and the textfield control in the screen shows
completely unstyled

Could you try it and report here? I think a third test would be great to
know what output is more normal if Alex or mine.

thanks!

Carlos

2018-02-20 21:19 GMT+01:00 Piotr Zarzycki :

> Once you get it and you will stay with that created branch, remove the old
> one.
>
> Thanks!!
>
> 2018-02-20 21:16 GMT+01:00 Carlos Rovira :
>
> > Hi Piotr,
> > some days ago I make a bad rebase in the old branch, and we are now
> seeking
> > for a problem with this projects, so I want to know that the rebase
> branch
> > was not the problem.
> > I'm waiting for Alex to test this branch and see if he get positive
> output
> > or not.
> >
> >
> >
> > 2018-02-20 21:08 GMT+01:00 Piotr Zarzycki :
> >
> > > Why did you create new branch ? Is this for something else ? I've
> created
> > > especially for previous feature/vivid branch on typedefs with the same
> > name
> > > in order to have it buildable as part of pipeline.
> > > What's with the old branch ?
> > >
> > > [1] https://builds.apache.org/job/Royale%20Pipeline/
> > >
> > >
> > >
> > >
> > > 2018-02-20 21:05 GMT+01:00 :
> > >
> > > > This is an automated email from the ASF dual-hosted git repository.
> > > >
> > > > carlosrovira pushed a change to branch feature/vivid-ui-set
> > > > in repository https://gitbox.apache.org/repos/asf/royale-asjs.git.
> > > >
> > > >
> > > >   at ecaab75  fresh branch with all vivid work, still not work
> > > >
> > > > This branch includes the following new commits:
> > > >
> > > >  new ecaab75  fresh branch with all vivid work, still not work
> > > >
> > > > The 1 revisions listed above as "new" are entirely new to this
> > > > repository and will be described in separate emails.  The revisions
> > > > listed as "add" were already present in the repository and have only
> > > > been added to this reference.
> > > >
> > > >
> > > > --
> > > > To stop receiving notification emails like this one, please contact
> > > > carlosrov...@apache.org.
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Piotr Zarzycki
> > >
> > > Patreon: *https://www.patreon.com/piotrzarzycki
> > > *
> > >
> >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>



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

Re: How I can use multiple CSS files

[Alex Harui]

Did you add a system.out.println to prove your local version is being run?

Get Outlook for Android


From: carlos.rov...@gmail.com  on behalf of Carlos 
Rovira 
Sent: Tuesday, February 20, 2018 12:13:09 PM
To: dev@royale.apache.org
Subject: Re: How I can use multiple CSS files

Hi Alex,

I removed all my maven repo and build all again. As well check that your
commits are in, and removed all targets to start from a clean point.
I created a new branch "vivid-ui-set" since the other one had the rebase
problem.
When I build Vivid, then BlueTheme and the Example I find that TextField
css tule is empty and sub rules for label and input are empty as well
I see TextField.css is in theme SWC but is not applied in final example app

I think you should get the same if you build with maven and maybe as you
first started to build with ANT and then with MAVEN maybe the old ant
content was affecting the build

Can you take a look?

* Check the new branch and that your changes are there
* remove as I did targets and royale vivid projects in .m2 repo
* and try to build from scratch only with maven

If you get it to work, I think something is wrong in royale since we should
get the same output.
maybe different maven version? (I'm using 3.5.0)

Hope we can reach what's going on since I'm stuck with this problem and
would like to continue working on this

Thanks in advance!

Carlos




2018-02-20 0:55 GMT+01:00 Alex Harui :

> Hi Carlos,
>
> You will just have to debug it on your end.  I would recommend:
>
> -Verify that the source changes I made to royale-compiler are in your
> local working copy.
> -manually clear your local maven repo of org.apache.royale.compiler
> artifacts
> -rebuild royale-compiler.
> -Scan the console output from the royals-compiler build for undetected
> errors.  Our Maven integration isn't perfect so there is a chance the
> compilation could report an error that doesn't return a failure code that
> stops the Maven build.
> -Rebuild your example.
> -Scan the console output for undetected errors. Also verify that Maven
> pulled the compiler from your local repo instead of the snapshot server or
> some other server.
>
> If none of that helps you find the problem, the next thing I would do is
> add a System.out.println to the code I modified so you can see if that
> code gets run or not.
>
> HTH,
> -Alex
>
> On 2/19/18, 11:10 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi Alex,
> >
> >2018-02-19 18:06 GMT+01:00 Alex Harui :
> >
> >> I just tried it with Maven and it worked.  I didn't run the example, I
> >> just opened App.css and saw that the contents of TextField.css are in
> >> there.
> >>
> >
> >Hi Alex, I'm not seeing what you see :?
> >I opened App.css in target, js-debug and Textfield is empty Only see {}
> >I updated all repos and rebuild all with maven to ensure I'm with the
> >latest
> >
> >
> >>
> >> For some reason, there were some puzzling results on merging in your
> >> changes.  It wanted me to push commits you had made.  Not sure why or if
> >> that would affect your results.
> >>
> >
> >Right, I made a rebase but it works bad and try to fix it. The problem was
> >that SourceTree had "Allow force push" unchecked.
> >Could you confirm your changes are all ok?
> >
> >don't know what's hapening...
> >
> >Thanks
> >
> >
> >
> >>
> >> HTH,
> >> -Alex
> >>
> >> On 2/19/18, 8:29 AM, "Alex Harui"  wrote:
> >>
> >> >I saw it work.  But I was using the Ant build in order to test it since
> >> >nobody had provided it yet.  I will try with Maven later.
> >> >
> >> >-Alex
> >> >
> >> >On 2/19/18, 6:55 AM, "carlos.rov...@gmail.com on behalf of Carlos
> >>Rovira"
> >> > wrote:
> >> >
> >> >>Hi Alex,
> >> >>
> >> >>2018-02-19 7:08 GMT+01:00 Alex Harui :
> >> >>
> >> >>>   But I saw that it could be easily added so I got it working
> >> >>> and pushed compiler changes to a feature/vivid branch in
> >> >>>royale-compiler.
> >> >>>
> >> >>>
> >> >>This means that you get it working? after solve some repo errors, I
> >>build
> >> >>the three projects but I get the same result as yesterday.
> >> >>Don't know if I'm doing something wrong, or I'm interpreting the email
> >> >>incorrectly
> >> >>
> >> >>thanks
> >> >>
> >> >>
> >> >>--
> >> >>Carlos Rovira
> >> >>https://na01.safelinks.protection.outlook.com/?url=http%
> >> 3A%2F%2Fabout.me%
> >> >>2
> >> >>Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C2bee894a
> >> 391f4de0984c08d
> >> >>5
> >> >>77a8de96%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365
> >> 46489524364497&
> >> >>s
> >> >>data=FI%2B2hRup%2ByKMqR0qY0YYeRgt9aBDwTuHEqjSmXmonJw%3D=0
> >> >
> >>
> >> --
> >> Carlos Rovira
> >>
> 

Re: Public Vars

[Alex Harui]

I'll look into it.

Get Outlook for Android


From: Piotr Zarzycki 
Sent: Tuesday, February 20, 2018 12:50:12 PM
To: dev@royale.apache.org
Subject: Re: Public Vars

Alex,

What about with public vars in MXML which have [Bindable] ? - I'm getting
warrnings on such vars.



2018-02-20 20:19 GMT+01:00 Alex Harui :

> That might be an additional check someone could add to the compiler, but I
> don't think it solves the problem at the right time unless you have
> control over all of the code involved.  I think the person who typed
> "public var" should be warned at the time they compile that line, not when
> someone tries to use it, potentially much later.
>
> If we added such a check, would it have helped you migrate your app?
> Especially given the check I just put in.  Remember, you can disable the
> check I just put in for an entire SWC, an entire file, or each occurrence.
>
> -Alex
>
> On 2/20/18, 11:06 AM, "Gabe Harbs"  wrote:
>
> >For framework code which might be used in MXML, we’re probably going to
> >have to stick to setters and getters.
> >
> >For code which will not be used in MXML there’s no reason to not use
> >public vars (unless it needs setter/getter logic). I’m suggesting that if
> >Foo has some public var “baz”, and someone declares 
> > would generate a compiler error that bar is not
> >set-able in MXML.
> >
> >Does that make sense?
> >
> >Harbs
> >
> >> On Feb 20, 2018, at 8:43 PM, Alex Harui 
> >>wrote:
> >>
> >> I may not be understanding you, but the application developer likely
> >> didn't write the "public var" that is going to be a problem, some other
> >> component developer did.  The goal is to get the component developer to
> >> not use public vars.
> >>
> >> Any application developer who uses MXMLComponents (an MXML file used as
> >>a
> >> component in another MXML file) is technically now a component developer
> >> and under the same restrictions.
> >>
> >> And as folks develop Royale apps with modules, they will face similar
> >> restrictions I think.  I think we want to flag that.  I don't think the
> >> contexts are limited to MXML, Binding, and States, nor does the
> >>framework
> >> component developer know the context when they type "public var".
> >>
> >> I did consider a flag that would have the JS output automatically
> >>generate
> >> a getter/setter for every public var.  But that would significantly
> >>fatten
> >> your app for 700 public vars.
> >>
> >> Folks are welcome to try other options in the compiler.  I just did what
> >> was quick and I think will help us help folks migrating.
> >>
> >> -Alex
> >>
> >> On 2/20/18, 10:30 AM, "Gabe Harbs"  >>> wrote:
> >>
> >>> What about a different approach?
> >>>
> >>> Maybe we can *disable* public vars in MXML, Binding and States?
> >>>
> >>> If someone tries to use public vars in those contexts, they would get a
> >>> compiler error. Only setters would show up as sett-able attributes in
> >>> MXML.
> >>>
> >>> If we can do that, we can probably get rid of @exports for pubic vars
> >>> which would probably make apps smaller.
> >>>
> >>> Thoughts?
> >>> Harbs
> >>>
>  On Feb 20, 2018, at 8:23 PM, Alex Harui 
>  wrote:
> 
>  As a said, it mainly matters for MXML, Binding, and States.
> 
>  I believe it will matter in accessing modules and a module accessing
> the
>  thing that loaded the module, and any other access by the original
>  property name.
> 
>  I think it will matter in accessing Value Objects that are
> instantiated
>  in
>  the code instead of externally if that Value Object is not [Bindable].
>  IOW, if you take some JSON and convert it to a plain Objects and tell
>  the
>  compiler that it is one of your Value Objects, that should work, but
> if
>  you then create a new instance of a Value Object and set its
> properties
>  in
>  the code, I think that won't always work.
> 
>  Maybe we'll end up turning this flag off by default in MXMLC and on by
>  default for COMPC or something like that.  The goal is to catch places
>  in
>  the framework where it could matter to increase the chances that the
>  js-release will work on the first try.  The sweep definitely caught
> some
>  things that needed to be changed.  I might have suppressed some
> warnings
>  on things that will need to be changed, not sure.
> 
>  Of course, I could be wrong...
>  -Alex
> 
>  On 2/20/18, 10:07 AM, "Gabe Harbs"   >> wrote:
> 
> > I have over 700 public vars in my app and it handles minification
> >just
> > fine.
> >
> > AFAIK, public vars are 

Re: About Royale MDL Examples

[Piotr Zarzycki]

MDLExample landed in my repository [1] and live [2]. It will be improved in
the next weeks. :)

[1]
https://github.com/piotrzarzycki21/TranspiledActionScript/tree/examples/Examples/MDLExample
[2] https://transpiledactionscript.com/examples/MDLExample/

Thanks, Piotr


2018-02-19 23:07 GMT+01:00 Carlos Rovira :

> that would be great! ;)
>
> 2018-02-19 20:26 GMT+01:00 Piotr Zarzycki :
>
> > Ok let's leave it as is. I will take MDL to my repository. I don't want
> to
> > fight with Legal about that.
> >
> > Carlos I will look into the Vivid soon. :)
> >
> > Thanks, Piotr
> >
> > 2018-02-19 20:23 GMT+01:00 Carlos Rovira :
> >
> > > Hi,
> > >
> > > as Alex said, Dave and Piotr understand my word incorrectly. Maybe I
> > > express incorrectly. So bad for myself.
> > >
> > > but anyway, I'm with Alex that we as "Apache Royale" should take
> priority
> > > for our own UI set, and I prefer all the time that we could spend in
> MDL
> > > examples will go to make our own set looks beautiful.
> > >
> > > In the end, whatever we interpret, is that Piotr can upload MDLExample
> to
> > > their GitHub so make it accesible to anyone.
> > >
> > > That's my opinion on this, although I invest lot of time in MDLExample
> a
> > > long with Piotr, my intention was to catch eyes and people for the
> > project,
> > > but in the end I see clearly that any *imported* UI set (MDL,
> Bootstrap,
> > > etc...) are not the way we should take. Our future depends in making
> our
> > > own UI set.
> > >
> > > @Piotr, after testing with Vivid, I see clearly that we can mimic the
> > same
> > > MDL looks, maybe not 100%, but very closely...and seems a doable task
> if
> > > anyone is interesed as a theme, and with only one compilation
> parameter,
> > we
> > > can make the entire app looks completly different...I think that should
> > be
> > > our goal! :)
> > >
> > > thanks
> > >
> > >
> > >
> > > 2018-02-19 17:33 GMT+01:00 Alex Harui :
> > >
> > > > @Dave,
> > > >
> > > > I agree that you could interpret Carlos's words the way you did, but
> I
> > > > also think it is possible that Carlos was referring that the two MDL
> > > > examples we are discussing aren't as important as some other things
> on
> > VP
> > > > Legal's to-do list, which is fair and probably true and why I haven't
> > > > pinged VP Legal.
> > > >
> > > > @Piotr,
> > > >
> > > > As Dave says, the way to escalate is to add a comment to the JIRA
> issue
> > > or
> > > > ask politely on legal-discuss.  Again, how important is it?
> > > >
> > > > My 2 cents,
> > > > -Alex
> > > >
> > > > On 2/19/18, 8:23 AM, "Dave Fisher"  wrote:
> > > >
> > > > >Carlos,
> > > > >
> > > > >Please stop with the meme that the ASF doesn’t care about projects.
> It
> > > is
> > > > >not helpful and it is not true.
> > > > >
> > > > >There are hundreds of projects. I suggested that you politely query
> on
> > > > >legal-discuss@.
> > > > >
> > > > >Regards,
> > > > >Dave
> > > > >
> > > > >Sent from my iPhone
> > > > >
> > > > >> On Feb 19, 2018, at 6:52 AM, Carlos Rovira <
> carlosrov...@apache.org
> > >
> > > > >>wrote:
> > > > >>
> > > > >> Hi Piotr
> > > > >>
> > > > >> my bet is that, as that projects are of no interest for ASF, you
> can
> > > > >>upload
> > > > >> to your GitHub account directly without any word about it.
> > > > >>
> > > > >> my 2cnt
> > > > >>
> > > > >> 2018-02-19 11:48 GMT+01:00 Piotr Zarzycki <
> > piotrzarzyck...@gmail.com
> > > >:
> > > > >>
> > > > >>> It's been several weeks since w have asked about advice. There is
> > no
> > > > >>> response. How can we escalate this question higher ?
> > > > >>>
> > > > >>> Thanks, Piotr
> > > > >>>
> > > > >>> 2018-01-30 19:58 GMT+01:00 Alex Harui  >:
> > > > >>>
> > > >  I created
> > > > https://na01.safelinks.protection.outlook.com/?url=
> > > > https%3A%2F%2Fissues
> > > > .apache.org%2Fjira%2Fbrowse%2FLEGAL-363=02%
> > > > 7C01%7Caharui%40adobe.c
> > > > om%7C38e5360cf20847b34cd508d577b572dd%
> > 7Cfa7b1b5a7b34438794aed2c178de
> > > > cee
> > > > 1%7C0%7C0%7C636546543554938163=
> > cDHQDyV2kJw53r7ZQKODy3Itqx2bjl
> > > > leb6
> > > > f28MJeDgE%3D=0
> > > > 
> > > >  -Alex
> > > > 
> > > > > On 1/30/18, 8:48 AM, "Piotr Zarzycki" <
> piotrzarzyck...@gmail.com
> > >
> > > > >wrote:
> > > > >
> > > > > I think since release has been done we could raise a JIRA. I
> will
> > > > >try to
> > > > > follow it and see how can I help. Will you raise jira since you
> > > have
> > > > > started legal discussion ?
> > > > >
> > > > > Thanks, Piotr
> > > > >
> > > > > 2018-01-29 7:59 GMT+01:00 Alex Harui  >:
> > > > >
> > > > >> Yes, filing a JIRA is probably the next step.  When do we want
> > to
> > > > >>> spend
> > > > >> more time on this?
> > > > >>
> > > > 

Re: Public Vars

[Piotr Zarzycki]

Alex,

What about with public vars in MXML which have [Bindable] ? - I'm getting
warrnings on such vars.



2018-02-20 20:19 GMT+01:00 Alex Harui :

> That might be an additional check someone could add to the compiler, but I
> don't think it solves the problem at the right time unless you have
> control over all of the code involved.  I think the person who typed
> "public var" should be warned at the time they compile that line, not when
> someone tries to use it, potentially much later.
>
> If we added such a check, would it have helped you migrate your app?
> Especially given the check I just put in.  Remember, you can disable the
> check I just put in for an entire SWC, an entire file, or each occurrence.
>
> -Alex
>
> On 2/20/18, 11:06 AM, "Gabe Harbs"  wrote:
>
> >For framework code which might be used in MXML, we’re probably going to
> >have to stick to setters and getters.
> >
> >For code which will not be used in MXML there’s no reason to not use
> >public vars (unless it needs setter/getter logic). I’m suggesting that if
> >Foo has some public var “baz”, and someone declares 
> > would generate a compiler error that bar is not
> >set-able in MXML.
> >
> >Does that make sense?
> >
> >Harbs
> >
> >> On Feb 20, 2018, at 8:43 PM, Alex Harui 
> >>wrote:
> >>
> >> I may not be understanding you, but the application developer likely
> >> didn't write the "public var" that is going to be a problem, some other
> >> component developer did.  The goal is to get the component developer to
> >> not use public vars.
> >>
> >> Any application developer who uses MXMLComponents (an MXML file used as
> >>a
> >> component in another MXML file) is technically now a component developer
> >> and under the same restrictions.
> >>
> >> And as folks develop Royale apps with modules, they will face similar
> >> restrictions I think.  I think we want to flag that.  I don't think the
> >> contexts are limited to MXML, Binding, and States, nor does the
> >>framework
> >> component developer know the context when they type "public var".
> >>
> >> I did consider a flag that would have the JS output automatically
> >>generate
> >> a getter/setter for every public var.  But that would significantly
> >>fatten
> >> your app for 700 public vars.
> >>
> >> Folks are welcome to try other options in the compiler.  I just did what
> >> was quick and I think will help us help folks migrating.
> >>
> >> -Alex
> >>
> >> On 2/20/18, 10:30 AM, "Gabe Harbs"  >>> wrote:
> >>
> >>> What about a different approach?
> >>>
> >>> Maybe we can *disable* public vars in MXML, Binding and States?
> >>>
> >>> If someone tries to use public vars in those contexts, they would get a
> >>> compiler error. Only setters would show up as sett-able attributes in
> >>> MXML.
> >>>
> >>> If we can do that, we can probably get rid of @exports for pubic vars
> >>> which would probably make apps smaller.
> >>>
> >>> Thoughts?
> >>> Harbs
> >>>
>  On Feb 20, 2018, at 8:23 PM, Alex Harui 
>  wrote:
> 
>  As a said, it mainly matters for MXML, Binding, and States.
> 
>  I believe it will matter in accessing modules and a module accessing
> the
>  thing that loaded the module, and any other access by the original
>  property name.
> 
>  I think it will matter in accessing Value Objects that are
> instantiated
>  in
>  the code instead of externally if that Value Object is not [Bindable].
>  IOW, if you take some JSON and convert it to a plain Objects and tell
>  the
>  compiler that it is one of your Value Objects, that should work, but
> if
>  you then create a new instance of a Value Object and set its
> properties
>  in
>  the code, I think that won't always work.
> 
>  Maybe we'll end up turning this flag off by default in MXMLC and on by
>  default for COMPC or something like that.  The goal is to catch places
>  in
>  the framework where it could matter to increase the chances that the
>  js-release will work on the first try.  The sweep definitely caught
> some
>  things that needed to be changed.  I might have suppressed some
> warnings
>  on things that will need to be changed, not sure.
> 
>  Of course, I could be wrong...
>  -Alex
> 
>  On 2/20/18, 10:07 AM, "Gabe Harbs"   >> wrote:
> 
> > I have over 700 public vars in my app and it handles minification
> >just
> > fine.
> >
> > AFAIK, public vars are only a problem for classes and properties used
> > in
> > MXML. Am I wrong?
> >
> >> On Feb 20, 2018, at 7:26 PM, Alex Harui  >>>
> >> wrote:
> >>
> >> Hi,
> 

Re: [royale-asjs] branch feature/vivid-ui-set created (now ecaab75)

[Piotr Zarzycki]

Once you get it and you will stay with that created branch, remove the old
one.

Thanks!!

2018-02-20 21:16 GMT+01:00 Carlos Rovira :

> Hi Piotr,
> some days ago I make a bad rebase in the old branch, and we are now seeking
> for a problem with this projects, so I want to know that the rebase branch
> was not the problem.
> I'm waiting for Alex to test this branch and see if he get positive output
> or not.
>
>
>
> 2018-02-20 21:08 GMT+01:00 Piotr Zarzycki :
>
> > Why did you create new branch ? Is this for something else ? I've created
> > especially for previous feature/vivid branch on typedefs with the same
> name
> > in order to have it buildable as part of pipeline.
> > What's with the old branch ?
> >
> > [1] https://builds.apache.org/job/Royale%20Pipeline/
> >
> >
> >
> >
> > 2018-02-20 21:05 GMT+01:00 :
> >
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > carlosrovira pushed a change to branch feature/vivid-ui-set
> > > in repository https://gitbox.apache.org/repos/asf/royale-asjs.git.
> > >
> > >
> > >   at ecaab75  fresh branch with all vivid work, still not work
> > >
> > > This branch includes the following new commits:
> > >
> > >  new ecaab75  fresh branch with all vivid work, still not work
> > >
> > > The 1 revisions listed above as "new" are entirely new to this
> > > repository and will be described in separate emails.  The revisions
> > > listed as "add" were already present in the repository and have only
> > > been added to this reference.
> > >
> > >
> > > --
> > > To stop receiving notification emails like this one, please contact
> > > carlosrov...@apache.org.
> > >
> >
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > *
> >
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

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

Re: [royale-asjs] branch feature/vivid-ui-set created (now ecaab75)

[Carlos Rovira]

Hi Piotr,
some days ago I make a bad rebase in the old branch, and we are now seeking
for a problem with this projects, so I want to know that the rebase branch
was not the problem.
I'm waiting for Alex to test this branch and see if he get positive output
or not.



2018-02-20 21:08 GMT+01:00 Piotr Zarzycki :

> Why did you create new branch ? Is this for something else ? I've created
> especially for previous feature/vivid branch on typedefs with the same name
> in order to have it buildable as part of pipeline.
> What's with the old branch ?
>
> [1] https://builds.apache.org/job/Royale%20Pipeline/
>
>
>
>
> 2018-02-20 21:05 GMT+01:00 :
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > carlosrovira pushed a change to branch feature/vivid-ui-set
> > in repository https://gitbox.apache.org/repos/asf/royale-asjs.git.
> >
> >
> >   at ecaab75  fresh branch with all vivid work, still not work
> >
> > This branch includes the following new commits:
> >
> >  new ecaab75  fresh branch with all vivid work, still not work
> >
> > The 1 revisions listed above as "new" are entirely new to this
> > repository and will be described in separate emails.  The revisions
> > listed as "add" were already present in the repository and have only
> > been added to this reference.
> >
> >
> > --
> > To stop receiving notification emails like this one, please contact
> > carlosrov...@apache.org.
> >
>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>



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

Re: How I can use multiple CSS files

[Carlos Rovira]

Hi Alex,

I removed all my maven repo and build all again. As well check that your
commits are in, and removed all targets to start from a clean point.
I created a new branch "vivid-ui-set" since the other one had the rebase
problem.
When I build Vivid, then BlueTheme and the Example I find that TextField
css tule is empty and sub rules for label and input are empty as well
I see TextField.css is in theme SWC but is not applied in final example app

I think you should get the same if you build with maven and maybe as you
first started to build with ANT and then with MAVEN maybe the old ant
content was affecting the build

Can you take a look?

* Check the new branch and that your changes are there
* remove as I did targets and royale vivid projects in .m2 repo
* and try to build from scratch only with maven

If you get it to work, I think something is wrong in royale since we should
get the same output.
maybe different maven version? (I'm using 3.5.0)

Hope we can reach what's going on since I'm stuck with this problem and
would like to continue working on this

Thanks in advance!

Carlos




2018-02-20 0:55 GMT+01:00 Alex Harui :

> Hi Carlos,
>
> You will just have to debug it on your end.  I would recommend:
>
> -Verify that the source changes I made to royale-compiler are in your
> local working copy.
> -manually clear your local maven repo of org.apache.royale.compiler
> artifacts
> -rebuild royale-compiler.
> -Scan the console output from the royals-compiler build for undetected
> errors.  Our Maven integration isn't perfect so there is a chance the
> compilation could report an error that doesn't return a failure code that
> stops the Maven build.
> -Rebuild your example.
> -Scan the console output for undetected errors. Also verify that Maven
> pulled the compiler from your local repo instead of the snapshot server or
> some other server.
>
> If none of that helps you find the problem, the next thing I would do is
> add a System.out.println to the code I modified so you can see if that
> code gets run or not.
>
> HTH,
> -Alex
>
> On 2/19/18, 11:10 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi Alex,
> >
> >2018-02-19 18:06 GMT+01:00 Alex Harui :
> >
> >> I just tried it with Maven and it worked.  I didn't run the example, I
> >> just opened App.css and saw that the contents of TextField.css are in
> >> there.
> >>
> >
> >Hi Alex, I'm not seeing what you see :?
> >I opened App.css in target, js-debug and Textfield is empty Only see {}
> >I updated all repos and rebuild all with maven to ensure I'm with the
> >latest
> >
> >
> >>
> >> For some reason, there were some puzzling results on merging in your
> >> changes.  It wanted me to push commits you had made.  Not sure why or if
> >> that would affect your results.
> >>
> >
> >Right, I made a rebase but it works bad and try to fix it. The problem was
> >that SourceTree had "Allow force push" unchecked.
> >Could you confirm your changes are all ok?
> >
> >don't know what's hapening...
> >
> >Thanks
> >
> >
> >
> >>
> >> HTH,
> >> -Alex
> >>
> >> On 2/19/18, 8:29 AM, "Alex Harui"  wrote:
> >>
> >> >I saw it work.  But I was using the Ant build in order to test it since
> >> >nobody had provided it yet.  I will try with Maven later.
> >> >
> >> >-Alex
> >> >
> >> >On 2/19/18, 6:55 AM, "carlos.rov...@gmail.com on behalf of Carlos
> >>Rovira"
> >> > wrote:
> >> >
> >> >>Hi Alex,
> >> >>
> >> >>2018-02-19 7:08 GMT+01:00 Alex Harui :
> >> >>
> >> >>>   But I saw that it could be easily added so I got it working
> >> >>> and pushed compiler changes to a feature/vivid branch in
> >> >>>royale-compiler.
> >> >>>
> >> >>>
> >> >>This means that you get it working? after solve some repo errors, I
> >>build
> >> >>the three projects but I get the same result as yesterday.
> >> >>Don't know if I'm doing something wrong, or I'm interpreting the email
> >> >>incorrectly
> >> >>
> >> >>thanks
> >> >>
> >> >>
> >> >>--
> >> >>Carlos Rovira
> >> >>https://na01.safelinks.protection.outlook.com/?url=http%
> >> 3A%2F%2Fabout.me%
> >> >>2
> >> >>Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C2bee894a
> >> 391f4de0984c08d
> >> >>5
> >> >>77a8de96%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365
> >> 46489524364497&
> >> >>s
> >> >>data=FI%2B2hRup%2ByKMqR0qY0YYeRgt9aBDwTuHEqjSmXmonJw%3D=0
> >> >
> >>
> >> --
> >> Carlos Rovira
> >>
> >>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%
> >>2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C639922befb1342faa8cd08
> >>d577cc7b26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C63654664248598988
> >>7=ZacvC4KrbdzDQZoUBE5msgmqpEENookbxNGlVVoBHBo%3D=0
> >>
> >>
> >>
>
>


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

Re: [royale-asjs] branch feature/vivid-ui-set created (now ecaab75)

[Piotr Zarzycki]

Why did you create new branch ? Is this for something else ? I've created
especially for previous feature/vivid branch on typedefs with the same name
in order to have it buildable as part of pipeline.
What's with the old branch ?

[1] https://builds.apache.org/job/Royale%20Pipeline/




2018-02-20 21:05 GMT+01:00 :

> This is an automated email from the ASF dual-hosted git repository.
>
> carlosrovira pushed a change to branch feature/vivid-ui-set
> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git.
>
>
>   at ecaab75  fresh branch with all vivid work, still not work
>
> This branch includes the following new commits:
>
>  new ecaab75  fresh branch with all vivid work, still not work
>
> The 1 revisions listed above as "new" are entirely new to this
> repository and will be described in separate emails.  The revisions
> listed as "add" were already present in the repository and have only
> been added to this reference.
>
>
> --
> To stop receiving notification emails like this one, please contact
> carlosrov...@apache.org.
>



-- 

Piotr Zarzycki

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

Re: Royale and Google Search

[Carlos Rovira]

Hi Alex,

that's a great start for routing in royale. Thanks for sharing! :)

2018-02-20 17:27 GMT+01:00 Alex Harui :

> Hi,
>
> The other day, I requested that Google index the ASDoc at
> http://royale.apache.org/asdoc/
>
> The ASDoc is a Royale app, it is not static HTML pages.  Google was able
> to index it, proving that Google's search crawlers run JavaScript.
> However, it did not seem to follow the links on the page and index the
> rest of the ASDoc.  I'm not sure how fast a crawler crawls so maybe it
> just hasn't gotten around to it.  But I think this proves that you can get
> parts of your Royale apps indexed by Google.  I'm not sure we ever had a
> great solution for that with Flex.
>
> When I find time, I will try to figure out why Google didn't chase the
> links on the page to the various components in the ASDoc.  But others are
> certainly welcome to help.  This is not currently a high-priority task for
> me.  We are using hash-bang anchor links in the ASDoc, but maybe that is
> no longer supported by Google and we need to find another routing scheme.
>
> Thanks,
> -Alex
>
>


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

Re: Public Vars

[Alex Harui]

That might be an additional check someone could add to the compiler, but I
don't think it solves the problem at the right time unless you have
control over all of the code involved.  I think the person who typed
"public var" should be warned at the time they compile that line, not when
someone tries to use it, potentially much later.

If we added such a check, would it have helped you migrate your app?
Especially given the check I just put in.  Remember, you can disable the
check I just put in for an entire SWC, an entire file, or each occurrence.

-Alex

On 2/20/18, 11:06 AM, "Gabe Harbs"  wrote:

>For framework code which might be used in MXML, we’re probably going to
>have to stick to setters and getters.
>
>For code which will not be used in MXML there’s no reason to not use
>public vars (unless it needs setter/getter logic). I’m suggesting that if
>Foo has some public var “baz”, and someone declares 
> would generate a compiler error that bar is not
>set-able in MXML.
>
>Does that make sense?
>
>Harbs
>
>> On Feb 20, 2018, at 8:43 PM, Alex Harui 
>>wrote:
>> 
>> I may not be understanding you, but the application developer likely
>> didn't write the "public var" that is going to be a problem, some other
>> component developer did.  The goal is to get the component developer to
>> not use public vars.
>> 
>> Any application developer who uses MXMLComponents (an MXML file used as
>>a
>> component in another MXML file) is technically now a component developer
>> and under the same restrictions.
>> 
>> And as folks develop Royale apps with modules, they will face similar
>> restrictions I think.  I think we want to flag that.  I don't think the
>> contexts are limited to MXML, Binding, and States, nor does the
>>framework
>> component developer know the context when they type "public var".
>> 
>> I did consider a flag that would have the JS output automatically
>>generate
>> a getter/setter for every public var.  But that would significantly
>>fatten
>> your app for 700 public vars.
>> 
>> Folks are welcome to try other options in the compiler.  I just did what
>> was quick and I think will help us help folks migrating.
>> 
>> -Alex
>> 
>> On 2/20/18, 10:30 AM, "Gabe Harbs" >> wrote:
>> 
>>> What about a different approach?
>>> 
>>> Maybe we can *disable* public vars in MXML, Binding and States?
>>> 
>>> If someone tries to use public vars in those contexts, they would get a
>>> compiler error. Only setters would show up as sett-able attributes in
>>> MXML.
>>> 
>>> If we can do that, we can probably get rid of @exports for pubic vars
>>> which would probably make apps smaller.
>>> 
>>> Thoughts?
>>> Harbs
>>> 
 On Feb 20, 2018, at 8:23 PM, Alex Harui 
 wrote:
 
 As a said, it mainly matters for MXML, Binding, and States.
 
 I believe it will matter in accessing modules and a module accessing
the
 thing that loaded the module, and any other access by the original
 property name.
 
 I think it will matter in accessing Value Objects that are
instantiated
 in
 the code instead of externally if that Value Object is not [Bindable].
 IOW, if you take some JSON and convert it to a plain Objects and tell
 the
 compiler that it is one of your Value Objects, that should work, but
if
 you then create a new instance of a Value Object and set its
properties
 in
 the code, I think that won't always work.
 
 Maybe we'll end up turning this flag off by default in MXMLC and on by
 default for COMPC or something like that.  The goal is to catch places
 in
 the framework where it could matter to increase the chances that the
 js-release will work on the first try.  The sweep definitely caught
some
 things that needed to be changed.  I might have suppressed some
warnings
 on things that will need to be changed, not sure.
 
 Of course, I could be wrong...
 -Alex
 
 On 2/20/18, 10:07 AM, "Gabe Harbs" >> wrote:
 
> I have over 700 public vars in my app and it handles minification
>just
> fine.
> 
> AFAIK, public vars are only a problem for classes and properties used
> in
> MXML. Am I wrong?
> 
>> On Feb 20, 2018, at 7:26 PM, Alex Harui >>
>> wrote:
>> 
>> Hi,
>> 
>> I just pushed compiler changes that will default to reporting a new
>> warning if you have public var in your Royale code.  Public methods,
>> getters and setters are fine, but public vars do not handle
>> minification.
>> 
>> I also just pushed a sweep of the framework code to eliminate public
>> var
>> usage or add a directive to suppress the warning.  At 

Re: Public Vars

[Gabe Harbs]

For framework code which might be used in MXML, we’re probably going to have to 
stick to setters and getters.

For code which will not be used in MXML there’s no reason to not use public 
vars (unless it needs setter/getter logic). I’m suggesting that if Foo has some 
public var “baz”, and someone declares   
would generate a compiler error that bar is not set-able in MXML.

Does that make sense?

Harbs

> On Feb 20, 2018, at 8:43 PM, Alex Harui  wrote:
> 
> I may not be understanding you, but the application developer likely
> didn't write the "public var" that is going to be a problem, some other
> component developer did.  The goal is to get the component developer to
> not use public vars.
> 
> Any application developer who uses MXMLComponents (an MXML file used as a
> component in another MXML file) is technically now a component developer
> and under the same restrictions.
> 
> And as folks develop Royale apps with modules, they will face similar
> restrictions I think.  I think we want to flag that.  I don't think the
> contexts are limited to MXML, Binding, and States, nor does the framework
> component developer know the context when they type "public var".
> 
> I did consider a flag that would have the JS output automatically generate
> a getter/setter for every public var.  But that would significantly fatten
> your app for 700 public vars.
> 
> Folks are welcome to try other options in the compiler.  I just did what
> was quick and I think will help us help folks migrating.
> 
> -Alex
> 
> On 2/20/18, 10:30 AM, "Gabe Harbs"  > wrote:
> 
>> What about a different approach?
>> 
>> Maybe we can *disable* public vars in MXML, Binding and States?
>> 
>> If someone tries to use public vars in those contexts, they would get a
>> compiler error. Only setters would show up as sett-able attributes in
>> MXML.
>> 
>> If we can do that, we can probably get rid of @exports for pubic vars
>> which would probably make apps smaller.
>> 
>> Thoughts?
>> Harbs
>> 
>>> On Feb 20, 2018, at 8:23 PM, Alex Harui 
>>> wrote:
>>> 
>>> As a said, it mainly matters for MXML, Binding, and States.
>>> 
>>> I believe it will matter in accessing modules and a module accessing the
>>> thing that loaded the module, and any other access by the original
>>> property name.
>>> 
>>> I think it will matter in accessing Value Objects that are instantiated
>>> in
>>> the code instead of externally if that Value Object is not [Bindable].
>>> IOW, if you take some JSON and convert it to a plain Objects and tell
>>> the
>>> compiler that it is one of your Value Objects, that should work, but if
>>> you then create a new instance of a Value Object and set its properties
>>> in
>>> the code, I think that won't always work.
>>> 
>>> Maybe we'll end up turning this flag off by default in MXMLC and on by
>>> default for COMPC or something like that.  The goal is to catch places
>>> in
>>> the framework where it could matter to increase the chances that the
>>> js-release will work on the first try.  The sweep definitely caught some
>>> things that needed to be changed.  I might have suppressed some warnings
>>> on things that will need to be changed, not sure.
>>> 
>>> Of course, I could be wrong...
>>> -Alex
>>> 
>>> On 2/20/18, 10:07 AM, "Gabe Harbs" >> >> wrote:
>>> 
 I have over 700 public vars in my app and it handles minification just
 fine.
 
 AFAIK, public vars are only a problem for classes and properties used
 in
 MXML. Am I wrong?
 
> On Feb 20, 2018, at 7:26 PM, Alex Harui  >
> wrote:
> 
> Hi,
> 
> I just pushed compiler changes that will default to reporting a new
> warning if you have public var in your Royale code.  Public methods,
> getters and setters are fine, but public vars do not handle
> minification.
> 
> I also just pushed a sweep of the framework code to eliminate public
> var
> usage or add a directive to suppress the warning.  At some point in
> time I
> will probably sweep the examples, but I'm letting it spit a few
> warnings
> for now.  I hope to remove the * selector this week and that will
> require
> another sweep of the examples.
> 
> Not using public vars should increase the changes that your minified
> code
> will run.  I put some information about public var usage in the wiki.
> I'm
> not sure if or where it should go in the user doc.  Users may be able
> survive with more public vars since it mainly matters for vars used in
> MXML, Binding, and States.  But we want the framework to be clean, so
> if
> you see a warning from your framework code, please clean it up.
> 
> 
> 
> 

Re: Public Vars

[Alex Harui]

I may not be understanding you, but the application developer likely
didn't write the "public var" that is going to be a problem, some other
component developer did.  The goal is to get the component developer to
not use public vars.

Any application developer who uses MXMLComponents (an MXML file used as a
component in another MXML file) is technically now a component developer
and under the same restrictions.

And as folks develop Royale apps with modules, they will face similar
restrictions I think.  I think we want to flag that.  I don't think the
contexts are limited to MXML, Binding, and States, nor does the framework
component developer know the context when they type "public var".

I did consider a flag that would have the JS output automatically generate
a getter/setter for every public var.  But that would significantly fatten
your app for 700 public vars.

Folks are welcome to try other options in the compiler.  I just did what
was quick and I think will help us help folks migrating.

-Alex

On 2/20/18, 10:30 AM, "Gabe Harbs"  wrote:

>What about a different approach?
>
>Maybe we can *disable* public vars in MXML, Binding and States?
>
>If someone tries to use public vars in those contexts, they would get a
>compiler error. Only setters would show up as sett-able attributes in
>MXML.
>
>If we can do that, we can probably get rid of @exports for pubic vars
>which would probably make apps smaller.
>
>Thoughts?
>Harbs
>
>> On Feb 20, 2018, at 8:23 PM, Alex Harui 
>>wrote:
>> 
>> As a said, it mainly matters for MXML, Binding, and States.
>> 
>> I believe it will matter in accessing modules and a module accessing the
>> thing that loaded the module, and any other access by the original
>> property name.
>> 
>> I think it will matter in accessing Value Objects that are instantiated
>>in
>> the code instead of externally if that Value Object is not [Bindable].
>> IOW, if you take some JSON and convert it to a plain Objects and tell
>>the
>> compiler that it is one of your Value Objects, that should work, but if
>> you then create a new instance of a Value Object and set its properties
>>in
>> the code, I think that won't always work.
>> 
>> Maybe we'll end up turning this flag off by default in MXMLC and on by
>> default for COMPC or something like that.  The goal is to catch places
>>in
>> the framework where it could matter to increase the chances that the
>> js-release will work on the first try.  The sweep definitely caught some
>> things that needed to be changed.  I might have suppressed some warnings
>> on things that will need to be changed, not sure.
>> 
>> Of course, I could be wrong...
>> -Alex
>> 
>> On 2/20/18, 10:07 AM, "Gabe Harbs" >> wrote:
>> 
>>> I have over 700 public vars in my app and it handles minification just
>>> fine.
>>> 
>>> AFAIK, public vars are only a problem for classes and properties used
>>>in
>>> MXML. Am I wrong?
>>> 
 On Feb 20, 2018, at 7:26 PM, Alex Harui 
 wrote:
 
 Hi,
 
 I just pushed compiler changes that will default to reporting a new
 warning if you have public var in your Royale code.  Public methods,
 getters and setters are fine, but public vars do not handle
 minification.
 
 I also just pushed a sweep of the framework code to eliminate public
var
 usage or add a directive to suppress the warning.  At some point in
 time I
 will probably sweep the examples, but I'm letting it spit a few
warnings
 for now.  I hope to remove the * selector this week and that will
 require
 another sweep of the examples.
 
 Not using public vars should increase the changes that your minified
 code
 will run.  I put some information about public var usage in the wiki.
 I'm
 not sure if or where it should go in the user doc.  Users may be able
 survive with more public vars since it mainly matters for vars used in
 MXML, Binding, and States.  But we want the framework to be clean, so
if
 you see a warning from your framework code, please clean it up.
 
 
 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub
.c 

 
om%2Fapache%2Froyale-asjs%2Fwiki%2FPublic-Variables=02%7C01%7Cahar
ui
 %40adobe.com 
%7C
93e6c53f985c4a6ae7d408d5788cd84a%7Cfa7b1b5a7b34438794aed2c
 
178decee1%7C0%7C0%7C636547468674049910=Vxx36hMI3fS1q8PT34WnMWlniF
3a
 LNONqTmEGghTUf0%3D=0
 
 Thanks,
 -Alex
>

Re: [royale-asjs] branch develop updated: Revert "Added .md extension to RELEASE_NOTES"

[Alex Harui]

OK, then make sure you update the build scripts to exclude from RAT and
copy the right files and you should be all set.  I don't like it as a
release reviewer, but that might be just me.  Also note that we package
all 3 repos into one package so the RELEASE_NOTES at the top of each repo
is not necessarily the RELEASE_NOTES at the top of the official release
package.  There is a RELEASE_NOTES in royale-asjs/releasemgr that goes in
the top of the source package.  I can't find any rules and regulations on
a RELEASE_NOTES file so I think is is probably ok if the RELEASE_NOTES in
releasemgr remains plain text and points to the other RELEASE_NOTES files.

-Alex

On 2/20/18, 8:23 AM, "Gabe Harbs"  wrote:

>We don’t *have to*, but it looks *WAY* nicer on Github.
>
>From what I’ve seen other projects use wildly different practices when it
>comes to release notes, but it seems pretty common to have “nice” release
>notes. In fact most projects I’ve seen seem to have a styled web page
>which displays release notes.
>
>From what I’ve seen, many projects don’t even seem to be keeping their
>release notes in their repos.
>
>I’m not sure where to read the release notes for Flink.
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>m%2Fapache%2Fflink=02%7C01%7Caharui%40adobe.com%7C1ef1569c54d24fe771b
>308d5787e5b70%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636547406449130
>871=Nr4OzZOoi3UDlw9mt2tvWdJC0jLXCf5QnzTHjxn6mQQ%3D=0
>om%2Fapache%2Fflink=02%7C01%7Caharui%40adobe.com%7C1ef1569c54d24fe771
>b308d5787e5b70%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63654740644913
>0871=Nr4OzZOoi3UDlw9mt2tvWdJC0jLXCf5QnzTHjxn6mQQ%3D=0>
>
>Cloudstack use CHANGES.md which then seems to populate a nicely designed
>web page
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>m%2Fapache%2Fcloudstack=02%7C01%7Caharui%40adobe.com%7C1ef1569c54d24f
>e771b308d5787e5b70%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365474064
>49130871=MF1RDcIskN%2FNdFjwwGoE0hSu%2F%2Fb9rvSqWvIUkogcrXM%3D
>ed=0 
>om%2Fapache%2Fcloudstack=02%7C01%7Caharui%40adobe.com%7C1ef1569c54d24
>fe771b308d5787e5b70%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636547406
>449130871=MF1RDcIskN%2FNdFjwwGoE0hSu%2F%2Fb9rvSqWvIUkogcrXM%3D
>ved=0>
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>m%2Fapache%2Fcloudstack%2Fblob%2Fmaster%2FCHANGES.md=02%7C01%7Caharui
>%40adobe.com%7C1ef1569c54d24fe771b308d5787e5b70%7Cfa7b1b5a7b34438794aed2c1
>78decee1%7C0%7C0%7C636547406449130871=Y8uUg3zXZbsOKdHBrJKbDJJwFe9sY8
>9pCGrX23P8wtM%3D=0
>om%2Fapache%2Fcloudstack%2Fblob%2Fmaster%2FCHANGES.md=02%7C01%7Caharu
>i%40adobe.com%7C1ef1569c54d24fe771b308d5787e5b70%7Cfa7b1b5a7b34438794aed2c
>178decee1%7C0%7C0%7C636547406449130871=Y8uUg3zXZbsOKdHBrJKbDJJwFe9sY
>89pCGrX23P8wtM%3D=0>
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdocs.cloud
>stack.apache.org%2Fprojects%2Fcloudstack-release-notes%2Fen%2F4.6.0%2F
>a=02%7C01%7Caharui%40adobe.com%7C1ef1569c54d24fe771b308d5787e5b70%7Cfa7b1b
>5a7b34438794aed2c178decee1%7C0%7C0%7C636547406449130871=BqZhUoJDgngt
>0GFn%2FY0Wzlik34h0lknRcFueK4D9apU%3D=0
>dstack.apache.org%2Fprojects%2Fcloudstack-release-notes%2Fen%2F4.6.0%2F
>ta=02%7C01%7Caharui%40adobe.com%7C1ef1569c54d24fe771b308d5787e5b70%7Cfa7b1
>b5a7b34438794aed2c178decee1%7C0%7C0%7C636547406449130871=BqZhUoJDgng
>t0GFn%2FY0Wzlik34h0lknRcFueK4D9apU%3D=0>
>
>Arrow uses a CHANGELOG.md file which then gets populated to a web page.
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>m%2Fapache%2Farrow%2Fblob%2Fmaster%2FCHANGELOG.md=02%7C01%7Caharui%40
>adobe.com%7C1ef1569c54d24fe771b308d5787e5b70%7Cfa7b1b5a7b34438794aed2c178d
>ecee1%7C0%7C0%7C636547406449130871=xcY4xDNYXXDX98L%2BNjScnn7GYC6ioJ0
>dLerSl8AgPss%3D=0
>om%2Fapache%2Farrow%2Fblob%2Fmaster%2FCHANGELOG.md=02%7C01%7Caharui%4
>0adobe.com%7C1ef1569c54d24fe771b308d5787e5b70%7Cfa7b1b5a7b34438794aed2c178
>decee1%7C0%7C0%7C636547406449130871=xcY4xDNYXXDX98L%2BNjScnn7GYC6ioJ
>0dLerSl8AgPss%3D=0>
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Farrow.apac
>he.org%2Frelease%2F0.8.0.html=02%7C01%7Caharui%40adobe.com%7C1ef1569c
>54d24fe771b308d5787e5b70%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365
>47406449130871=CS%2BCDEvhZhNVDy7fRAR7XHZbLi3jBBRBuLrbrq%2B0XMw%3D
>served=0 
>che.org%2Frelease%2F0.8.0.html=02%7C01%7Caharui%40adobe.com%7C1ef1569
>c54d24fe771b308d5787e5b70%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636

Re: Public Vars

[Gabe Harbs]

What about a different approach?

Maybe we can *disable* public vars in MXML, Binding and States?

If someone tries to use public vars in those contexts, they would get a 
compiler error. Only setters would show up as sett-able attributes in MXML.

If we can do that, we can probably get rid of @exports for pubic vars which 
would probably make apps smaller.

Thoughts?
Harbs

> On Feb 20, 2018, at 8:23 PM, Alex Harui  wrote:
> 
> As a said, it mainly matters for MXML, Binding, and States.
> 
> I believe it will matter in accessing modules and a module accessing the
> thing that loaded the module, and any other access by the original
> property name.
> 
> I think it will matter in accessing Value Objects that are instantiated in
> the code instead of externally if that Value Object is not [Bindable].
> IOW, if you take some JSON and convert it to a plain Objects and tell the
> compiler that it is one of your Value Objects, that should work, but if
> you then create a new instance of a Value Object and set its properties in
> the code, I think that won't always work.
> 
> Maybe we'll end up turning this flag off by default in MXMLC and on by
> default for COMPC or something like that.  The goal is to catch places in
> the framework where it could matter to increase the chances that the
> js-release will work on the first try.  The sweep definitely caught some
> things that needed to be changed.  I might have suppressed some warnings
> on things that will need to be changed, not sure.
> 
> Of course, I could be wrong...
> -Alex
> 
> On 2/20/18, 10:07 AM, "Gabe Harbs"  > wrote:
> 
>> I have over 700 public vars in my app and it handles minification just
>> fine.
>> 
>> AFAIK, public vars are only a problem for classes and properties used in
>> MXML. Am I wrong?
>> 
>>> On Feb 20, 2018, at 7:26 PM, Alex Harui 
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> I just pushed compiler changes that will default to reporting a new
>>> warning if you have public var in your Royale code.  Public methods,
>>> getters and setters are fine, but public vars do not handle
>>> minification.
>>> 
>>> I also just pushed a sweep of the framework code to eliminate public var
>>> usage or add a directive to suppress the warning.  At some point in
>>> time I
>>> will probably sweep the examples, but I'm letting it spit a few warnings
>>> for now.  I hope to remove the * selector this week and that will
>>> require
>>> another sweep of the examples.
>>> 
>>> Not using public vars should increase the changes that your minified
>>> code
>>> will run.  I put some information about public var usage in the wiki.
>>> I'm
>>> not sure if or where it should go in the user doc.  Users may be able
>>> survive with more public vars since it mainly matters for vars used in
>>> MXML, Binding, and States.  But we want the framework to be clean, so if
>>> you see a warning from your framework code, please clean it up.
>>> 
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c 
>>> 
>>> om%2Fapache%2Froyale-asjs%2Fwiki%2FPublic-Variables=02%7C01%7Caharui
>>> %40adobe.com 
>>> %7C93e6c53f985c4a6ae7d408d5788cd84a%7Cfa7b1b5a7b34438794aed2c
>>> 178decee1%7C0%7C0%7C636547468674049910=Vxx36hMI3fS1q8PT34WnMWlniF3a
>>> LNONqTmEGghTUf0%3D=0
>>> 
>>> Thanks,
>>> -Alex

Jenkins build is back to normal : royale-asjs_jsonly #335

[apacheroyaleci]

See 

Re: Public Vars

[Alex Harui]

As a said, it mainly matters for MXML, Binding, and States.

I believe it will matter in accessing modules and a module accessing the
thing that loaded the module, and any other access by the original
property name.

I think it will matter in accessing Value Objects that are instantiated in
the code instead of externally if that Value Object is not [Bindable].
IOW, if you take some JSON and convert it to a plain Objects and tell the
compiler that it is one of your Value Objects, that should work, but if
you then create a new instance of a Value Object and set its properties in
the code, I think that won't always work.

Maybe we'll end up turning this flag off by default in MXMLC and on by
default for COMPC or something like that.  The goal is to catch places in
the framework where it could matter to increase the chances that the
js-release will work on the first try.  The sweep definitely caught some
things that needed to be changed.  I might have suppressed some warnings
on things that will need to be changed, not sure.

Of course, I could be wrong...
-Alex

On 2/20/18, 10:07 AM, "Gabe Harbs"  wrote:

>I have over 700 public vars in my app and it handles minification just
>fine.
>
>AFAIK, public vars are only a problem for classes and properties used in
>MXML. Am I wrong?
>
>> On Feb 20, 2018, at 7:26 PM, Alex Harui 
>>wrote:
>> 
>> Hi,
>> 
>> I just pushed compiler changes that will default to reporting a new
>> warning if you have public var in your Royale code.  Public methods,
>> getters and setters are fine, but public vars do not handle
>>minification.
>> 
>> I also just pushed a sweep of the framework code to eliminate public var
>> usage or add a directive to suppress the warning.  At some point in
>>time I
>> will probably sweep the examples, but I'm letting it spit a few warnings
>> for now.  I hope to remove the * selector this week and that will
>>require
>> another sweep of the examples.
>> 
>> Not using public vars should increase the changes that your minified
>>code
>> will run.  I put some information about public var usage in the wiki.
>>I'm
>> not sure if or where it should go in the user doc.  Users may be able
>> survive with more public vars since it mainly matters for vars used in
>> MXML, Binding, and States.  But we want the framework to be clean, so if
>> you see a warning from your framework code, please clean it up.
>> 
>> 
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
>>om%2Fapache%2Froyale-asjs%2Fwiki%2FPublic-Variables=02%7C01%7Caharui
>>%40adobe.com%7C93e6c53f985c4a6ae7d408d5788cd84a%7Cfa7b1b5a7b34438794aed2c
>>178decee1%7C0%7C0%7C636547468674049910=Vxx36hMI3fS1q8PT34WnMWlniF3a
>>LNONqTmEGghTUf0%3D=0
>> 
>> Thanks,
>> -Alex
>> 
>

Re: Public Vars

[Gabe Harbs]

I have over 700 public vars in my app and it handles minification just fine.

AFAIK, public vars are only a problem for classes and properties used in MXML. 
Am I wrong?

> On Feb 20, 2018, at 7:26 PM, Alex Harui  wrote:
> 
> Hi,
> 
> I just pushed compiler changes that will default to reporting a new
> warning if you have public var in your Royale code.  Public methods,
> getters and setters are fine, but public vars do not handle minification.
> 
> I also just pushed a sweep of the framework code to eliminate public var
> usage or add a directive to suppress the warning.  At some point in time I
> will probably sweep the examples, but I'm letting it spit a few warnings
> for now.  I hope to remove the * selector this week and that will require
> another sweep of the examples.
> 
> Not using public vars should increase the changes that your minified code
> will run.  I put some information about public var usage in the wiki.  I'm
> not sure if or where it should go in the user doc.  Users may be able
> survive with more public vars since it mainly matters for vars used in
> MXML, Binding, and States.  But we want the framework to be clean, so if
> you see a warning from your framework code, please clean it up.
> 
> https://github.com/apache/royale-asjs/wiki/Public-Variables
> 
> Thanks,
> -Alex
> 

Build failed in Jenkins: royale-asjs_jsonly #334

[apacheroyaleci]

See 


Changes:

[aharui] sweep of frameworks for public var usage.  Suppressed warning at 
project

--
[...truncated 1.30 MB...]
 [java] Compiling file: 
org.apache.royale.net.remoting.messages.AbstractMessage
 [java] Writing file: 
js\out\org\apache\royale\net\remoting\messages\AbstractMessage.js
 [java] Compiling file: org.apache.royale.net.remoting.messages.AsyncMessage
 [java] Writing file: 
js\out\org\apache\royale\net\remoting\messages\AsyncMessage.js
 [java] Compiling file: 
org.apache.royale.net.remoting.messages.AcknowledgeMessage
 [java] Writing file: 
js\out\org\apache\royale\net\remoting\messages\AcknowledgeMessage.js
 [java] Compiling file: org.apache.royale.file.IFileModel
 [java] Writing file: js\out\org\apache\royale\file\IFileModel.js
 [java] Compiling file: org.apache.royale.file.beads.FileUploader
 [java] Writing file: js\out\org\apache\royale\file\beads\FileUploader.js
 [java] Compiling file: org.apache.royale.net.HTTPHeader
 [java] Writing file: js\out\org\apache\royale\net\HTTPHeader.js
 [java] Compiling file: NetworkClasses
 [java] Writing file: js\out\NetworkClasses.js
 [java] Compiling file: 
org.apache.royale.net.remoting.messages.MessageHeader
 [java] Writing file: 
js\out\org\apache\royale\net\remoting\messages\MessageHeader.js
 [java] Compiling file: org.apache.royale.file.beads.FileLoaderAndUploader
 [java] Writing file: 
js\out\org\apache\royale\file\beads\FileLoaderAndUploader.js
 [java] Compiling file: org.apache.royale.file.beads.FileBrowser
 [java] Writing file: js\out\org\apache\royale\file\beads\FileBrowser.js
 [java] Compiling file: org.apache.royale.net.HTTPServiceBase
 [java] Writing file: js\out\org\apache\royale\net\HTTPServiceBase.js
 [java] Compiling file: 
org.apache.royale.net.remoting.messages.ActionMessage
 [java] Writing file: 
js\out\org\apache\royale\net\remoting\messages\ActionMessage.js
 [java] Compiling file: 
org.apache.royale.net.remoting.messages.RemotingMessage
 [java] Writing file: 
js\out\org\apache\royale\net\remoting\messages\RemotingMessage.js
 [java] Compiling file: org.apache.royale.net.beads.CORSCredentialsBead
 [java] Writing file: 
js\out\org\apache\royale\net\beads\CORSCredentialsBead.js
 [java] Compiling file: org.apache.royale.net.URLRequest
 [java] Writing file: js\out\org\apache\royale\net\URLRequest.js
 [java] Compiling file: 
org.apache.royale.net.remoting.messages.CommandMessage
 [java] Writing file: 
js\out\org\apache\royale\net\remoting\messages\CommandMessage.js
 [java] Compiling file: org.apache.royale.net.URLRequestHeader
 [java] Writing file: js\out\org\apache\royale\net\URLRequestHeader.js
 [java] Compiling file: org.apache.royale.file.FileProxy
 [java] Writing file: js\out\org\apache\royale\file\FileProxy.js
 [java] Compiling file: org.apache.royale.file.beads.FileBrowserWithFilter
 [java] Writing file: 
js\out\org\apache\royale\file\beads\FileBrowserWithFilter.js
 [java] Compiling file: org.apache.royale.net.URLStream
 [java] Writing file: js\out\org\apache\royale\net\URLStream.js
 [java] Compiling file: org.apache.royale.net.URLLoader
 [java] Writing file: js\out\org\apache\royale\net\URLLoader.js
 [java] Compiling file: org.apache.royale.net.URLBinaryLoader
 [java] Writing file: js\out\org\apache\royale\net\URLBinaryLoader.js
 [java] Compiling file: org.apache.royale.net.URLBinaryUploader
 [java] Writing file: js\out\org\apache\royale\net\URLBinaryUploader.js
 [java] Compiling file: org.apache.royale.net.remoting.amf.AMFBinaryData
 [java] Writing file: 
js\out\org\apache\royale\net\remoting\amf\AMFBinaryData.js
 [java] Compiling file: org.apache.royale.net.Responder
 [java] Writing file: js\out\org\apache\royale\net\Responder.js
 [java] Compiling file: org.apache.royale.net.remoting.messages.ErrorMessage
 [java] Writing file: 
js\out\org\apache\royale\net\remoting\messages\ErrorMessage.js
 [java] Compiling file: org.apache.royale.file.beads.FileModel
 [java] Writing file: js\out\org\apache\royale\file\beads\FileModel.js
 [java] Compiling file: org.apache.royale.net.RemoteObject
 [java] Writing file: js\out\org\apache\royale\net\RemoteObject.js
 [java] Compiling file: org.apache.royale.net.HTTPConstants
 [java] Writing file: js\out\org\apache\royale\net\HTTPConstants.js
 [java] Compiling file: org.apache.royale.net.BinaryUploader
 [java] Writing file: js\out\org\apache\royale\net\BinaryUploader.js
 [java] Compiling file: org.apache.royale.net.events.ResultEvent
 [java] Writing file: js\out\org\apache\royale\net\events\ResultEvent.js
 [java] Compiling file: org.apache.royale.net.remoting.amf.AMFNetConnection
 [java] 

Re: Public Vars

[Alex Harui]

Yes, you are correct.  So I suppose it will be a migration issue.  I'll be
interested to see how prevalent it is "in the wild".  If you have a public
var with [Bindable], that should be ok and the Royale compiler will not
warn on [Bindable] public vars.  They are converted to getter/setters and
thus are immune from minification.  In theory most folks used public vars
in Value Objects and made them [Bindable], but I have seen that folks just
ignored the warning from the compiler that there was a binding to a
non-bindable variable.

Thanks,
-Alex

On 2/20/18, 9:39 AM, "Andrew Wetmore"  wrote:

>Am I right that public vars were no problem in apps compiled for Flash or
>AIR use, and that this improvement relates to creating a Royale app for JS
>production?
>
>t.com%2Fsig-email%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%
>3Dsig-email%26utm_content%3Dwebmail=02%7C01%7Caharui%40adobe.com%7C00
>be1125ff064036f91908d57888f3d8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>7C636547451960499643=srgB4g25gGyTHTw4CTBGloaYISc7TngykapuNBObECY%3D&
>reserved=0>
>Virus-free.
>https://na01.safelinks.protection.outlook.com/?url=www.avast.com=02%7
>C01%7Caharui%40adobe.com%7C00be1125ff064036f91908d57888f3d8%7Cfa7b1b5a7b34
>438794aed2c178decee1%7C0%7C0%7C636547451960499643=2lJGLP%2FTb6jmmuot
>pAciekV%2BV6R50G3XTYDq%2BctZMKQ%3D=0
>t.com%2Fsig-email%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%
>3Dsig-email%26utm_content%3Dwebmail=02%7C01%7Caharui%40adobe.com%7C00
>be1125ff064036f91908d57888f3d8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>7C636547451960499643=srgB4g25gGyTHTw4CTBGloaYISc7TngykapuNBObECY%3D&
>reserved=0>
><#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>On Tue, Feb 20, 2018 at 1:26 PM, Alex Harui 
>wrote:
>
>> Hi,
>>
>> I just pushed compiler changes that will default to reporting a new
>> warning if you have public var in your Royale code.  Public methods,
>> getters and setters are fine, but public vars do not handle
>>minification.
>>
>> I also just pushed a sweep of the framework code to eliminate public var
>> usage or add a directive to suppress the warning.  At some point in
>>time I
>> will probably sweep the examples, but I'm letting it spit a few warnings
>> for now.  I hope to remove the * selector this week and that will
>>require
>> another sweep of the examples.
>>
>> Not using public vars should increase the changes that your minified
>>code
>> will run.  I put some information about public var usage in the wiki.
>>I'm
>> not sure if or where it should go in the user doc.  Users may be able
>> survive with more public vars since it mainly matters for vars used in
>> MXML, Binding, and States.  But we want the framework to be clean, so if
>> you see a warning from your framework code, please clean it up.
>>
>> 
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
>>om%2Fapache%2Froyale-asjs%2Fwiki%2FPublic-Variables=02%7C01%7Caharui
>>%40adobe.com%7C00be1125ff064036f91908d57888f3d8%7Cfa7b1b5a7b34438794aed2c
>>178decee1%7C0%7C0%7C636547451960499643=NsEnVpwiOc9bR6TSbwJ%2FKmJLLs
>>WvhMRN83uLj0JuK3A%3D=0
>>
>> Thanks,
>> -Alex
>>
>>
>
>
>-- 
>Andrew Wetmore
>
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.
>blogspot.com%2F=02%7C01%7Caharui%40adobe.com%7C00be1125ff064036f91908
>d57888f3d8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636547451960499643
>=7tfthDnaui6tpk0JIbAi3%2BN3JTELdLw%2Bgjo7Rf0o%2Fts%3D=0

Re: Public Vars

[Andrew Wetmore]

Am I right that public vars were no problem in apps compiled for Flash or
AIR use, and that this improvement relates to creating a Royale app for JS
production?


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, Feb 20, 2018 at 1:26 PM, Alex Harui 
wrote:

> Hi,
>
> I just pushed compiler changes that will default to reporting a new
> warning if you have public var in your Royale code.  Public methods,
> getters and setters are fine, but public vars do not handle minification.
>
> I also just pushed a sweep of the framework code to eliminate public var
> usage or add a directive to suppress the warning.  At some point in time I
> will probably sweep the examples, but I'm letting it spit a few warnings
> for now.  I hope to remove the * selector this week and that will require
> another sweep of the examples.
>
> Not using public vars should increase the changes that your minified code
> will run.  I put some information about public var usage in the wiki.  I'm
> not sure if or where it should go in the user doc.  Users may be able
> survive with more public vars since it mainly matters for vars used in
> MXML, Binding, and States.  But we want the framework to be clean, so if
> you see a warning from your framework code, please clean it up.
>
> https://github.com/apache/royale-asjs/wiki/Public-Variables
>
> Thanks,
> -Alex
>
>


-- 
Andrew Wetmore

http://cottage14.blogspot.com/

Public Vars

[Alex Harui]

Hi,

I just pushed compiler changes that will default to reporting a new
warning if you have public var in your Royale code.  Public methods,
getters and setters are fine, but public vars do not handle minification.

I also just pushed a sweep of the framework code to eliminate public var
usage or add a directive to suppress the warning.  At some point in time I
will probably sweep the examples, but I'm letting it spit a few warnings
for now.  I hope to remove the * selector this week and that will require
another sweep of the examples.

Not using public vars should increase the changes that your minified code
will run.  I put some information about public var usage in the wiki.  I'm
not sure if or where it should go in the user doc.  Users may be able
survive with more public vars since it mainly matters for vars used in
MXML, Binding, and States.  But we want the framework to be clean, so if
you see a warning from your framework code, please clean it up.

https://github.com/apache/royale-asjs/wiki/Public-Variables

Thanks,
-Alex

Re: Maintain Release Notes List of changes(was: Re: [DRAFT][ANNOUNCE] Apache Royale 0.9.1 Released)

[Alex Harui]

I don't know if you saw my commit wizard idea.
https://lists.apache.org/thread.html/5d94976d277729a8f34b77a0ec09e45678bbf5
d2d7111e411fb5fb14@%3Cdev.royale.apache.org%3E

I guess it won't help if you don't use command line for commits.  It
should be possible to do any of the 3 you suggested.  The GitHub API seems
to be relatively easy to use, and I tested the JSON2ASVO utility with some
of the responses and it seems to work.  We just need to find the time to
put something together.

-Alex

On 2/20/18, 8:28 AM, "Gabe Harbs"  wrote:

>+1
>
>Some thoughts:
>1. We can have a utility which rewrites entries to a standard format
>before release.
>2. We can have a form which takes the info and adds it to the release
>notes.
>3. It might be interesting to have a Github integration which watches
>Issues and when a commit closes a ticket, it creates an entry in the
>release notes.
>
>Harbs
>
>> On Feb 20, 2018, at 6:05 PM, Alex Harui 
>>wrote:
>> 
>> If you want a particular format, help me write a wizard that will manage
>> that.  I will not remember to get it right every time I commit.  I will
>> not know what to use for a description unless we take the bug topic
>> verbatim with any misspellings and other cruft.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 2/20/18, 5:37 AM, "Piotr Zarzycki" >> wrote:
>> 
>>> I see in release notes links to issues. I'm in favor of having
>>>description
>>> + eventually links.
>>> 
>>> - my description for a bug [Bug Number](link) - it will display nicely
>>>on
>>> GitHub.
>>> 
>>> I'm talking about this commit.
>>> 
>>> What do other thinks ?
>>> 
>>> Thanks, Piotr
>>> 
>>> 
>>> 2018-02-14 23:13 GMT+01:00 Carlos Rovira :
>>> 
 Ok Alex, that's great, so we'll be doing the work on RELEASE_NOTES
file
 
 thanks!
 
 2018-02-14 17:31 GMT+01:00 Alex Harui :
 
> We already have this.  It is the RELEASE_NOTES file.  All ASF
>releases
 are
> supposed to have one so we should use it.  And as keepachangelog.com
 says,
> it is not the GitHub commit log.
> 
> IMO, it is not the Release Manager's job to fill this out.  It needs
 to
 be
> maintained by every committer.  I know I'm really bad about filling
>it
 out
> which is why I proposed a Commit Wizard a few days ago.
> 
> IMO, there were some good feature enhancements in 0.9.1, like
> NestedDataGridColumn, but nothing really notable.  The focus of 0.9.1
 was
> to get the documentation published by making sure ASDoc and the
 examples
> worked.  Also, there was only a few weeks between 0.9.0 and 0.9.1.
> 
> Also, I added links from the RELEASE_NOTES to our wiki.  That way we
 can
> add late-breaking news after the release.  I think we should do the
 that
> for every release.  But we should try to make the RELEASE_NOTES
 contain
> most or all of the notable changes.
> 
> I think there will be major new features in 0.9.2 if it doesn't
 become a
> hot fix release.  I just pushed "fixed row height virtual lists" and
 will
> likely get variable row height working as well.  And of course, I did
 not
> update RELEASE_NOTES when I pushed those changes, so I will go and do
 that
> now ;-)
> 
> My 2 cents,
> -Alex
> 
> On 2/14/18, 5:15 AM, "Olaf Krueger"  wrote:
> 
>>> In Moonshine we are following this ->
>>> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fkeepachan
>>> gelog.com%2Fen%2F1.0.0%2F=02%7C01%7Caharui%40adobe.com
> %7C4f310c6f286
>>> 04f5391d708d573acfd7d%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636542
>>> 109181598814=Epgu%2BBIjQkIbbte9KXBIEFwg1YN2uZZ7a
> DEr%2BoGyvgU%3D
>>> erved=0
>> 
>> +1, we also start using this format here ;-)
>> 
>> Olaf
>> 
>> 
>> 
>> --
>> Sent from:
>> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fapache-roy
>> ale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%
 40adobe.com
> %7
>> C4f310c6f28604f5391d708d573acfd7d%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7
>> C0%7C636542109181598814=n4CqdIGyGoEp2hanhb%
> 2FtTrL8UvC8jWWmiEH%2FTWHb
>> sIY%3D=0
> 
> 
 
 
 --
 Carlos Rovira
 
 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.m
e% 

 2Fcarlosrovira=02%7C01%7Caharui%40adobe.com

Re: Maintain Release Notes List of changes(was: Re: [DRAFT][ANNOUNCE] Apache Royale 0.9.1 Released)

[Gabe Harbs]

+1

Some thoughts:
1. We can have a utility which rewrites entries to a standard format before 
release.
2. We can have a form which takes the info and adds it to the release notes.
3. It might be interesting to have a Github integration which watches Issues 
and when a commit closes a ticket, it creates an entry in the release notes.

Harbs

> On Feb 20, 2018, at 6:05 PM, Alex Harui  wrote:
> 
> If you want a particular format, help me write a wizard that will manage
> that.  I will not remember to get it right every time I commit.  I will
> not know what to use for a description unless we take the bug topic
> verbatim with any misspellings and other cruft.
> 
> My 2 cents,
> -Alex
> 
> On 2/20/18, 5:37 AM, "Piotr Zarzycki"  > wrote:
> 
>> I see in release notes links to issues. I'm in favor of having description
>> + eventually links.
>> 
>> - my description for a bug [Bug Number](link) - it will display nicely on
>> GitHub.
>> 
>> I'm talking about this commit.
>> 
>> What do other thinks ?
>> 
>> Thanks, Piotr
>> 
>> 
>> 2018-02-14 23:13 GMT+01:00 Carlos Rovira :
>> 
>>> Ok Alex, that's great, so we'll be doing the work on RELEASE_NOTES file
>>> 
>>> thanks!
>>> 
>>> 2018-02-14 17:31 GMT+01:00 Alex Harui :
>>> 
 We already have this.  It is the RELEASE_NOTES file.  All ASF releases
>>> are
 supposed to have one so we should use it.  And as keepachangelog.com
>>> says,
 it is not the GitHub commit log.
 
 IMO, it is not the Release Manager's job to fill this out.  It needs
>>> to
>>> be
 maintained by every committer.  I know I'm really bad about filling it
>>> out
 which is why I proposed a Commit Wizard a few days ago.
 
 IMO, there were some good feature enhancements in 0.9.1, like
 NestedDataGridColumn, but nothing really notable.  The focus of 0.9.1
>>> was
 to get the documentation published by making sure ASDoc and the
>>> examples
 worked.  Also, there was only a few weeks between 0.9.0 and 0.9.1.
 
 Also, I added links from the RELEASE_NOTES to our wiki.  That way we
>>> can
 add late-breaking news after the release.  I think we should do the
>>> that
 for every release.  But we should try to make the RELEASE_NOTES
>>> contain
 most or all of the notable changes.
 
 I think there will be major new features in 0.9.2 if it doesn't
>>> become a
 hot fix release.  I just pushed "fixed row height virtual lists" and
>>> will
 likely get variable row height working as well.  And of course, I did
>>> not
 update RELEASE_NOTES when I pushed those changes, so I will go and do
>>> that
 now ;-)
 
 My 2 cents,
 -Alex
 
 On 2/14/18, 5:15 AM, "Olaf Krueger"  wrote:
 
>> In Moonshine we are following this ->
>> https://na01.safelinks.protection.outlook.com/?url=
 http%3A%2F%2Fkeepachan
>> gelog.com%2Fen%2F1.0.0%2F=02%7C01%7Caharui%40adobe.com
 %7C4f310c6f286
>> 04f5391d708d573acfd7d%7Cfa7b1b5a7b34438794aed2c178de
 cee1%7C0%7C0%7C636542
>> 109181598814=Epgu%2BBIjQkIbbte9KXBIEFwg1YN2uZZ7a
 DEr%2BoGyvgU%3D
>> erved=0
> 
> +1, we also start using this format here ;-)
> 
> Olaf
> 
> 
> 
> --
> Sent from:
> https://na01.safelinks.protection.outlook.com/?url=
 http%3A%2F%2Fapache-roy
> ale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%
>>> 40adobe.com
 %7
> C4f310c6f28604f5391d708d573acfd7d%7Cfa7b1b5a7b34438794aed2c178de
 cee1%7C0%7
> C0%7C636542109181598814=n4CqdIGyGoEp2hanhb%
 2FtTrL8UvC8jWWmiEH%2FTWHb
> sIY%3D=0
 
 
>>> 
>>> 
>>> --
>>> Carlos Rovira
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me% 
>>> 
>>> 2Fcarlosrovira=02%7C01%7Caharui%40adobe.com 
>>> %7C74e5ff2b882c46c7cfdf08
>>> d578672402%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63654730674335656
>>> 9=cebcj%2BzMEiHGeB6K3kI%2Fi4rtDc4w%2BCjWPAf%2FnfjGSX4%3D=0
>>> 
>> 
>> 
>> 
>> -- 
>> 
>> Piotr Zarzycki
>> 
>> Patreon: 
>> *https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr 
>> 
>> eon.com %2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com 
>> %7C74e5ff2b882c46
>> c7cfdf08d578672402%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365473067
>> 43356569=aM%2FQpF7A6bDHtDARJM4wUWaA9oE7OHMNbGaNEIe9wbA%3D=0
>> > 
>> eon.com %2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com 
>> %7C74e5ff2b882c46
>> 

Royale and Google Search

[Alex Harui]

Hi,

The other day, I requested that Google index the ASDoc at
http://royale.apache.org/asdoc/

The ASDoc is a Royale app, it is not static HTML pages.  Google was able
to index it, proving that Google's search crawlers run JavaScript.
However, it did not seem to follow the links on the page and index the
rest of the ASDoc.  I'm not sure how fast a crawler crawls so maybe it
just hasn't gotten around to it.  But I think this proves that you can get
parts of your Royale apps indexed by Google.  I'm not sure we ever had a
great solution for that with Flex.

When I find time, I will try to figure out why Google didn't chase the
links on the page to the various components in the ASDoc.  But others are
certainly welcome to help.  This is not currently a high-priority task for
me.  We are using hash-bang anchor links in the ASDoc, but maybe that is
no longer supported by Google and we need to find another routing scheme.

Thanks,
-Alex

Re: [royale-asjs] branch develop updated: Revert "Added .md extension to RELEASE_NOTES"

[Gabe Harbs]

We don’t *have to*, but it looks *WAY* nicer on Github.

From what I’ve seen other projects use wildly different practices when it comes 
to release notes, but it seems pretty common to have “nice” release notes. In 
fact most projects I’ve seen seem to have a styled web page which displays 
release notes.

From what I’ve seen, many projects don’t even seem to be keeping their release 
notes in their repos.

I’m not sure where to read the release notes for Flink.
https://github.com/apache/flink 

Cloudstack use CHANGES.md which then seems to populate a nicely designed web 
page
https://github.com/apache/cloudstack 
https://github.com/apache/cloudstack/blob/master/CHANGES.md 

http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.6.0/ 


Arrow uses a CHANGELOG.md file which then gets populated to a web page.
https://github.com/apache/arrow/blob/master/CHANGELOG.md 

http://arrow.apache.org/release/0.8.0.html 


etc.

I think we can do whatever works nicely…

Thanks,
Harbs

> On Feb 20, 2018, at 6:03 PM, Alex Harui  wrote:
> 
> Why do we have to use markdown in RELEASE_NOTES.  Are other ASF projects
> doing that?
> 
> -Alex
> 
> On 2/20/18, 5:43 AM, "Piotr Zarzycki"  > wrote:
> 
>> Maybe we can exclude from RAT check this file. It is failed because it
>> doesn't have Apache header license.
>> 
>> Let me look today evening into options of exclusion some files from RAT
>> check.
>> 
>> Thanks, Piotr
>> 
>> 2018-02-20 14:08 GMT+01:00 Gabe Harbs :
>> 
>>> Can someone more familiar with the maven build look into this?
>>> 
>>> Thanks,
>>> Harbs
>>> 
 On Feb 20, 2018, at 3:06 PM, ha...@apache.org wrote:
 
 This is an automated email from the ASF dual-hosted git repository.
 
 harbs pushed a commit to branch develop
 in repository 
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.a 
>>> 
>>> pache.org 
>>> %2Frepos%2Fasf%2Froyale-asjs.git=02%7C01%7Caharui%40adobe.c
>>> om%7C50a4e8f572da474086c808d57867f756%7Cfa7b1b5a7b34438794aed2c178decee1%
>>> 7C0%7C0%7C636547310280500614=H4lG3NGh3Q2B0wGVk25nqxHlZWc0bGd0TqrTUV
>>> 9fqd8%3D=0
 
 
 The following commit(s) were added to refs/heads/develop by this push:
new aa03fac  Revert "Added .md extension to RELEASE_NOTES"
 aa03fac is described below
 
 commit aa03fac44b84f7f07a18682cb5bf456f24b7ef05
 Author: Harbs >
 AuthorDate: Tue Feb 20 15:06:11 2018 +0200
 
   Revert "Added .md extension to RELEASE_NOTES"
 
   This reverts commit bb5499b394cf6c9f36515c3f6883202116d49e3f.
 
   It looks like the MAVEN build does not like this name change.
   I think the maven build should be fixed and we should use the .md
>>> extension.
 ---
 RELEASE_NOTES.md => RELEASE_NOTES | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 
 diff --git a/RELEASE_NOTES.md b/RELEASE_NOTES
 similarity index 100%
 rename from RELEASE_NOTES.md
 rename to RELEASE_NOTES
 
 --
 To stop receiving notification emails like this one, please contact
 ha...@apache.org .
>>> 
>>> 
>> 
>> 
>> -- 
>> 
>> Piotr Zarzycki
>> 
>> Patreon: 
>> *https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr 
>> 
>> eon.com %2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com 
>> %7C50a4e8f572da47
>> 4086c808d57867f756%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365473102
>> 80500614=0iB06Uoq8M3Nj%2BMViiIB9AZqxEdIVSKkSKBuDurNKt8%3D=0
>> > 
>> eon.com %2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com 
>> %7C50a4e8f572da47
>> 4086c808d57867f756%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365473102
>> 80500614=0iB06Uoq8M3Nj%2BMViiIB9AZqxEdIVSKkSKBuDurNKt8%3D=0
>>> *

Re: Maintain Release Notes List of changes(was: Re: [DRAFT][ANNOUNCE] Apache Royale 0.9.1 Released)

[Alex Harui]

If you want a particular format, help me write a wizard that will manage
that.  I will not remember to get it right every time I commit.  I will
not know what to use for a description unless we take the bug topic
verbatim with any misspellings and other cruft.

My 2 cents,
-Alex

On 2/20/18, 5:37 AM, "Piotr Zarzycki"  wrote:

>I see in release notes links to issues. I'm in favor of having description
>+ eventually links.
>
>- my description for a bug [Bug Number](link) - it will display nicely on
>GitHub.
>
>I'm talking about this commit.
>
>What do other thinks ?
>
>Thanks, Piotr
>
>
>2018-02-14 23:13 GMT+01:00 Carlos Rovira :
>
>> Ok Alex, that's great, so we'll be doing the work on RELEASE_NOTES file
>>
>> thanks!
>>
>> 2018-02-14 17:31 GMT+01:00 Alex Harui :
>>
>> > We already have this.  It is the RELEASE_NOTES file.  All ASF releases
>> are
>> > supposed to have one so we should use it.  And as keepachangelog.com
>> says,
>> > it is not the GitHub commit log.
>> >
>> > IMO, it is not the Release Manager's job to fill this out.  It needs
>>to
>> be
>> > maintained by every committer.  I know I'm really bad about filling it
>> out
>> > which is why I proposed a Commit Wizard a few days ago.
>> >
>> > IMO, there were some good feature enhancements in 0.9.1, like
>> > NestedDataGridColumn, but nothing really notable.  The focus of 0.9.1
>>was
>> > to get the documentation published by making sure ASDoc and the
>>examples
>> > worked.  Also, there was only a few weeks between 0.9.0 and 0.9.1.
>> >
>> > Also, I added links from the RELEASE_NOTES to our wiki.  That way we
>>can
>> > add late-breaking news after the release.  I think we should do the
>>that
>> > for every release.  But we should try to make the RELEASE_NOTES
>>contain
>> > most or all of the notable changes.
>> >
>> > I think there will be major new features in 0.9.2 if it doesn't
>>become a
>> > hot fix release.  I just pushed "fixed row height virtual lists" and
>>will
>> > likely get variable row height working as well.  And of course, I did
>>not
>> > update RELEASE_NOTES when I pushed those changes, so I will go and do
>> that
>> > now ;-)
>> >
>> > My 2 cents,
>> > -Alex
>> >
>> > On 2/14/18, 5:15 AM, "Olaf Krueger"  wrote:
>> >
>> > >>In Moonshine we are following this ->
>> > >>https://na01.safelinks.protection.outlook.com/?url=
>> > http%3A%2F%2Fkeepachan
>> > >>gelog.com%2Fen%2F1.0.0%2F=02%7C01%7Caharui%40adobe.com
>> > %7C4f310c6f286
>> > >>04f5391d708d573acfd7d%7Cfa7b1b5a7b34438794aed2c178de
>> > cee1%7C0%7C0%7C636542
>> > >>109181598814=Epgu%2BBIjQkIbbte9KXBIEFwg1YN2uZZ7a
>> > DEr%2BoGyvgU%3D
>> > >>erved=0
>> > >
>> > >+1, we also start using this format here ;-)
>> > >
>> > >Olaf
>> > >
>> > >
>> > >
>> > >--
>> > >Sent from:
>> > >https://na01.safelinks.protection.outlook.com/?url=
>> > http%3A%2F%2Fapache-roy
>> > >ale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%
>> 40adobe.com
>> > %7
>> > >C4f310c6f28604f5391d708d573acfd7d%7Cfa7b1b5a7b34438794aed2c178de
>> > cee1%7C0%7
>> > >C0%7C636542109181598814=n4CqdIGyGoEp2hanhb%
>> > 2FtTrL8UvC8jWWmiEH%2FTWHb
>> > >sIY%3D=0
>> >
>> >
>>
>>
>> --
>> Carlos Rovira
>> 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%
>>2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C74e5ff2b882c46c7cfdf08
>>d578672402%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63654730674335656
>>9=cebcj%2BzMEiHGeB6K3kI%2Fi4rtDc4w%2BCjWPAf%2FnfjGSX4%3D=0
>>
>
>
>
>-- 
>
>Piotr Zarzycki
>
>Patreon: 
>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>eon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com%7C74e5ff2b882c46
>c7cfdf08d578672402%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365473067
>43356569=aM%2FQpF7A6bDHtDARJM4wUWaA9oE7OHMNbGaNEIe9wbA%3D=0
>eon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com%7C74e5ff2b882c46
>c7cfdf08d578672402%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365473067
>43356569=aM%2FQpF7A6bDHtDARJM4wUWaA9oE7OHMNbGaNEIe9wbA%3D=0
>>*

Re: [royale-asjs] branch develop updated: Revert "Added .md extension to RELEASE_NOTES"

[Piotr Zarzycki]

Maybe we can exclude from RAT check this file. It is failed because it
doesn't have Apache header license.

Let me look today evening into options of exclusion some files from RAT
check.

Thanks, Piotr

2018-02-20 14:08 GMT+01:00 Gabe Harbs :

> Can someone more familiar with the maven build look into this?
>
> Thanks,
> Harbs
>
> > On Feb 20, 2018, at 3:06 PM, ha...@apache.org wrote:
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > harbs pushed a commit to branch develop
> > in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
> >
> >
> > The following commit(s) were added to refs/heads/develop by this push:
> > new aa03fac  Revert "Added .md extension to RELEASE_NOTES"
> > aa03fac is described below
> >
> > commit aa03fac44b84f7f07a18682cb5bf456f24b7ef05
> > Author: Harbs 
> > AuthorDate: Tue Feb 20 15:06:11 2018 +0200
> >
> >Revert "Added .md extension to RELEASE_NOTES"
> >
> >This reverts commit bb5499b394cf6c9f36515c3f6883202116d49e3f.
> >
> >It looks like the MAVEN build does not like this name change.
> >I think the maven build should be fixed and we should use the .md
> extension.
> > ---
> > RELEASE_NOTES.md => RELEASE_NOTES | 0
> > 1 file changed, 0 insertions(+), 0 deletions(-)
> >
> > diff --git a/RELEASE_NOTES.md b/RELEASE_NOTES
> > similarity index 100%
> > rename from RELEASE_NOTES.md
> > rename to RELEASE_NOTES
> >
> > --
> > To stop receiving notification emails like this one, please contact
> > ha...@apache.org.
>
>


-- 

Piotr Zarzycki

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

Re: Maintain Release Notes List of changes(was: Re: [DRAFT][ANNOUNCE] Apache Royale 0.9.1 Released)

[Piotr Zarzycki]

I see in release notes links to issues. I'm in favor of having description
+ eventually links.

- my description for a bug [Bug Number](link) - it will display nicely on
GitHub.

I'm talking about this commit.

What do other thinks ?

Thanks, Piotr


2018-02-14 23:13 GMT+01:00 Carlos Rovira :

> Ok Alex, that's great, so we'll be doing the work on RELEASE_NOTES file
>
> thanks!
>
> 2018-02-14 17:31 GMT+01:00 Alex Harui :
>
> > We already have this.  It is the RELEASE_NOTES file.  All ASF releases
> are
> > supposed to have one so we should use it.  And as keepachangelog.com
> says,
> > it is not the GitHub commit log.
> >
> > IMO, it is not the Release Manager's job to fill this out.  It needs to
> be
> > maintained by every committer.  I know I'm really bad about filling it
> out
> > which is why I proposed a Commit Wizard a few days ago.
> >
> > IMO, there were some good feature enhancements in 0.9.1, like
> > NestedDataGridColumn, but nothing really notable.  The focus of 0.9.1 was
> > to get the documentation published by making sure ASDoc and the examples
> > worked.  Also, there was only a few weeks between 0.9.0 and 0.9.1.
> >
> > Also, I added links from the RELEASE_NOTES to our wiki.  That way we can
> > add late-breaking news after the release.  I think we should do the that
> > for every release.  But we should try to make the RELEASE_NOTES contain
> > most or all of the notable changes.
> >
> > I think there will be major new features in 0.9.2 if it doesn't become a
> > hot fix release.  I just pushed "fixed row height virtual lists" and will
> > likely get variable row height working as well.  And of course, I did not
> > update RELEASE_NOTES when I pushed those changes, so I will go and do
> that
> > now ;-)
> >
> > My 2 cents,
> > -Alex
> >
> > On 2/14/18, 5:15 AM, "Olaf Krueger"  wrote:
> >
> > >>In Moonshine we are following this ->
> > >>https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fkeepachan
> > >>gelog.com%2Fen%2F1.0.0%2F=02%7C01%7Caharui%40adobe.com
> > %7C4f310c6f286
> > >>04f5391d708d573acfd7d%7Cfa7b1b5a7b34438794aed2c178de
> > cee1%7C0%7C0%7C636542
> > >>109181598814=Epgu%2BBIjQkIbbte9KXBIEFwg1YN2uZZ7a
> > DEr%2BoGyvgU%3D
> > >>erved=0
> > >
> > >+1, we also start using this format here ;-)
> > >
> > >Olaf
> > >
> > >
> > >
> > >--
> > >Sent from:
> > >https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fapache-roy
> > >ale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%
> 40adobe.com
> > %7
> > >C4f310c6f28604f5391d708d573acfd7d%7Cfa7b1b5a7b34438794aed2c178de
> > cee1%7C0%7
> > >C0%7C636542109181598814=n4CqdIGyGoEp2hanhb%
> > 2FtTrL8UvC8jWWmiEH%2FTWHb
> > >sIY%3D=0
> >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

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

Re: [royale-asjs] branch develop updated: Revert "Added .md extension to RELEASE_NOTES"

[Gabe Harbs]

Can someone more familiar with the maven build look into this?

Thanks,
Harbs

> On Feb 20, 2018, at 3:06 PM, ha...@apache.org wrote:
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> harbs pushed a commit to branch develop
> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
> 
> 
> The following commit(s) were added to refs/heads/develop by this push:
> new aa03fac  Revert "Added .md extension to RELEASE_NOTES"
> aa03fac is described below
> 
> commit aa03fac44b84f7f07a18682cb5bf456f24b7ef05
> Author: Harbs 
> AuthorDate: Tue Feb 20 15:06:11 2018 +0200
> 
>Revert "Added .md extension to RELEASE_NOTES"
> 
>This reverts commit bb5499b394cf6c9f36515c3f6883202116d49e3f.
> 
>It looks like the MAVEN build does not like this name change.
>I think the maven build should be fixed and we should use the .md 
> extension.
> ---
> RELEASE_NOTES.md => RELEASE_NOTES | 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> 
> diff --git a/RELEASE_NOTES.md b/RELEASE_NOTES
> similarity index 100%
> rename from RELEASE_NOTES.md
> rename to RELEASE_NOTES
> 
> -- 
> To stop receiving notification emails like this one, please contact
> ha...@apache.org.