You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Carlos Rovira <ca...@apache.org> on 2018/12/01 19:29:52 UTC
Re: +configname=flex
Hi Alex, I don't think that's what happen.
My version (always considering that there's my version, your version and
the truth):
1.- You make a commit that introduced IDEs break
2.- I spend Saturday morning trying to find a way to fix that
3.- Instead of revert your commit I make a change of the thing causing the
problem with the comment "to be reverted as we find the solution"
4.- You was upset since you consider it a revert, and I asked you to find a
way a solution so we all can live in peace and armony
5.- You said me that I must to do it myself or pay someone to do it, and
that Alina and others have priority over my needs
6.- Dave told us that we should work on branches, since nobody is a special
case here.
We are on that point where we have a branch with a first commit that is my
commit reverted, in order to find the solution.
Since Royale has different sets no one is more important than other. Basic,
Jewel, and not Mx/Spark must coexist, and should work in conjunction.
I'm using Jewel and MX for RPC part and some other classes (i.e.
CurrencyFormatter, and maybe others). The changes in config files make IDEs
goes crazy.
So I can have a "jewel-config-template.xml", that has jewel, mx,...and
other libs needed, no problem on that, but when I tried to create that, I
couldn't get it work.
That's point 2 in my list. For that reason maybe there's a bug and that
could be done, if that's the case, I think is Alex responsibility to fix
that to leverage his change,
and not make me depend on my time or money to contract other people to do
that. IOW, if we make a change that break something, and others complains,
don't see
a point to make a battle for something like that. I think is more easy to
work on fix that instead of invest time in a large thread and emails.
Since this Friday I release our real work Apache Royale app first
iteration, I plan to work on that this week end, but finaly I must fix
things on our release for Monday, so I can work on that on this on Monday
or Tuesday.
El jue., 29 nov. 2018 a las 10:40, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> As discussed I changed royale-config.xml to list all of our SWCs except
> for MXRoyale and SparkRoyale, and changed flex-config.xml to use all SWCs
> and have different default classes such as mx.events.MouseEvent instead of
> org.apache.royale.events.MouseEvent. I think Carlos has the only project
> using MXRoyale and Jewel and maybe some Basic so neither config is set up
> exactly for his needs. Since all configuration is theoretically
> overridable as compiler options, he should have been able to get going by
> specifying what SWCs he wants to use.
>
> He said he wasn't able to do that, so he committed a change that went back
> to using a wildcard in royale-config.xml and thus pull in all SWCs and
> re-introduce the problem. That doesn't make any technical sense to me and
> brought back the CSS problem that was affecting folks like you. So I asked
> him to revert his wildcard change and so far, he hasn't and instead he
> started in on how I am seeking special treatment.
>
> -Alex
>
> On 11/28/18, 7:19 PM, "Harbs" <ha...@gmail.com> wrote:
>
> I’m still not following.
>
> What did you change and what was the issue that Carlos hit? Am I
> correct that you were fixing the problem that MXRoyale was overriding the
> Basic CSS?
>
> What exactly was the fix and why was it causing problems?
>
> > On Nov 28, 2018, at 5:21 PM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >
> > Carlos reverted a commit I made without technical justification and
> refuses to put back my changes when I asked, instead saying I was acting
> like I should have special treatment. Apparently, Carlos couldn't compile
> his app even though all of our examples build just fine. I've tried to
> help, but cannot get solid data from Carlos.
> >
> > Somehow Dave Fisher thinks is ok for Carlos to act like that. I
> think it sets a dangerous precedent to have committers revert other
> people's changes without technical justification, and also a bad precedent
> to allow people to basically call people names when they disagree about
> something.
> >
> > -Alex
> >
> > On 11/27/18, 4:52 PM, "Harbs" <ha...@gmail.com> wrote:
> >
> > I have not been following the list very well the last week plus.
> (I’ve been busy with some personal things.)
> >
> > I’m not following the issues here. What was changed, and what’s
> the issue here?
> >
>
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: +configname=flex
Posted by Carlos Rovira <ca...@apache.org>.
Hi Harbs,
El mié., 5 dic. 2018 a las 18:42, Harbs (<ha...@gmail.com>) escribió:
> Just to examine these steps and try to communicate how I would have
> handled them:
>
> When I run into a similar problem while using “bleeding edge” code, my
> first step is to write the problem to the list ASAP. I’ll spend the minimum
> time necessary to isolate the problem and then describe the problem as
> concisely as possible. Discussion usually helps flush out what the problem
> is and helps find a course of action.
>
> If I am stuck and must continue working, I will do one of two things:
>
> 1. Locally I will revert to previous code if I can. Usually with compiler
> issues, this is possible.
> 2. Create a temporary branch for my own use. If the change is useful to
> illustrate the problem (or it needs to be shared with others), I will push
> the branch to the remote.
>
>
I'm with you in the global way to proceed.
> As you mentioned, your commit was likely to be reverted. That makes it a
> prime candidate for a temporary branch. Although I’m not sure why you
> couldn’t just revert to prior to Alex’s change locally to keep on working.
>
> I don’t think there was anything wrong with Alex committing his code to
> develop. We discussed the problem he was trying to solve and the change
> fixes it as intended. I don’t think anyone was aware that you were missing
> MXRoyale and Jewel. (I definitely was not.)
>
If the commit doesn't make any regression, that will be ok for all of us.
The problem as you said is maybe nobody was aware about someone using
Jewel+MXRoyale. That is a legit way of use Apache Royale and should not be
anything strange.
So If I were Alex and suppose I make a change, directly in develop, and
found someone found a regression, my first way to proceed is to put my
muscle to try to help in something that was caused by my changes, not say
"is not my problem, do it yourself or pay someone to do it", and start a
long thread of emails.
If that's the way to do this, I'm with Dave and we should move this issue
to a branch and work there to solve the regression.
So we don't bother the rest of developments that are confirmed and working.
IOW, changes that we detect a problem should be done in a branch, no make
the rest of us move to a branch. The use in all projects I now is this, and
seems we are trying to do the opposite.
>
> I can’t imagine why it should not be possible to include the MXRoyale swc
> in a Jewel project (or vice versa). It should just be a matter of figuring
> out the correct configuration. Like Josh, I’d be interested in the details
> to understand the problem better.
>
>
Right, I don't know if is a bug in Royale, in config or in VSCode
extension. I spend several hours on my own trying different configs (that's
what we supposed it should fix the problem), but this comes in a bad time
for me since I'm working hard to get our App ready and our client happy. In
other timeframe I'll be already put some hours on this. But in the other
hand the way Alex is managing this makes me feel not happy and asking me
that I must invest hours or pay persons for something I did't ask for makes
me ask myself if that's the way to operate here or if this is the way to go
in an apache community.
I think I could never ask others to work on something I did and caused some
general issue or recommend pay others to solve things to complete the tasks
I'm working on, does not seems to me the Apache way and I don't see my self
with the power/status to say others to do that...I'm just another
contributor to this project.
> My $0.02,
> Harbs
>
> > On Dec 1, 2018, at 9:29 PM, Carlos Rovira <ca...@apache.org>
> wrote:
> >
> > 1.- You make a commit that introduced IDEs break
> > 2.- I spend Saturday morning trying to find a way to fix that
> > 3.- Instead of revert your commit I make a change of the thing causing
> the
> > problem with the comment "to be reverted as we find the solution"
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: +configname=flex
Posted by Harbs <ha...@gmail.com>.
Just to examine these steps and try to communicate how I would have handled them:
When I run into a similar problem while using “bleeding edge” code, my first step is to write the problem to the list ASAP. I’ll spend the minimum time necessary to isolate the problem and then describe the problem as concisely as possible. Discussion usually helps flush out what the problem is and helps find a course of action.
If I am stuck and must continue working, I will do one of two things:
1. Locally I will revert to previous code if I can. Usually with compiler issues, this is possible.
2. Create a temporary branch for my own use. If the change is useful to illustrate the problem (or it needs to be shared with others), I will push the branch to the remote.
As you mentioned, your commit was likely to be reverted. That makes it a prime candidate for a temporary branch. Although I’m not sure why you couldn’t just revert to prior to Alex’s change locally to keep on working.
I don’t think there was anything wrong with Alex committing his code to develop. We discussed the problem he was trying to solve and the change fixes it as intended. I don’t think anyone was aware that you were missing MXRoyale and Jewel. (I definitely was not.)
I can’t imagine why it should not be possible to include the MXRoyale swc in a Jewel project (or vice versa). It should just be a matter of figuring out the correct configuration. Like Josh, I’d be interested in the details to understand the problem better.
My $0.02,
Harbs
> On Dec 1, 2018, at 9:29 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> 1.- You make a commit that introduced IDEs break
> 2.- I spend Saturday morning trying to find a way to fix that
> 3.- Instead of revert your commit I make a change of the thing causing the
> problem with the comment "to be reverted as we find the solution"
Re: +configname=flex
Posted by Carlos Rovira <ca...@apache.org>.
Hi Harbs,
you're right, sorry. I thought I already pushed it. Just did now.
El jue., 6 dic. 2018 a las 12:26, Harbs (<ha...@gmail.com>) escribió:
> I don’t see the branch. Are you sure you pushed it?
>
> > On Dec 6, 2018, at 12:05 PM, Carlos Rovira <ca...@apache.org>
> wrote:
> >
> > Remember to use "feature/refactor-config-name-changes" branch where my
> > commit is reverted and things are set up like Alex want.
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: +configname=flex
Posted by Harbs <ha...@gmail.com>.
I don’t see the branch. Are you sure you pushed it?
> On Dec 6, 2018, at 12:05 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> Remember to use "feature/refactor-config-name-changes" branch where my
> commit is reverted and things are set up like Alex want.
Re: +configname=flex
Posted by Carlos Rovira <ca...@apache.org>.
Hi Josh,
I rebuild all in the branch and can confirm your fix worked :)
Thanks for taking the time check this and showing the way to fix it! :)
Carlos
El jue., 6 dic. 2018 a las 19:10, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi Josh,
>
> thanks for looking at it, I'll going to check now and report
>
> El jue., 6 dic. 2018 a las 19:03, Josh Tynjala (<jo...@apache.org>)
> escribió:
>
>> Carlos,
>>
>> I wish that you had included the list of problems that you are seeing, as
>> I requested. I wanted to be completely certain that I'm seeing the exact
>> same ones that you are.
>>
>> Regardless, here's my initial attempt to reproduce and fix your issue.
>>
>> In examples/mxroyale/RemoteObjectAMFTest/asconfig.json, I switched to
>> App_Jewel.mxml.
>>
>> Instead of using your branch, I simply modified royale-config.xml in my
>> local SDK. When I did this, I saw the following problems appear in Visual
>> Studio Code:
>>
>> App_Jewel.mxml(30): col: 20 Warning: Definition mx.rpc.AsyncToken could
>> not be found.
>> App_Jewel.mxml(31): col: 20 Warning: Definition mx.rpc.Responder could
>> not be found.
>> App_Jewel.mxml(32): col: 20 Warning: Definition mx.rpc.events.FaultEvent
>> could not be found.
>> App_Jewel.mxml(33): col: 20 Warning: Definition mx.rpc.events.ResultEvent
>> could not be found
>> App_Jewel.mxml(38): col: 33 Error: Type was not found or was not a
>> compile-time constant: FaultEvent.
>> App_Jewel.mxml(44): col: 31 Error: Type was not found or was not a
>> compile-time constant: AsyncToken.
>> App_Jewel.mxml(45): col: 35 Error: Type was not found or was not a
>> compile-time constant: Responder.
>> App_Jewel.mxml(48): col: 33 Error: Call to a possibly undefined method
>> Responder.
>> App_Jewel.mxml(54): col: 49 Error: Type was not found or was not a
>> compile-time constant: ResultEvent.
>> App_Jewel.mxml(70): col: 23 Error: Type was not found or was not a
>> compile-time constant: Responder.
>> App_Jewel.mxml(70): col: 39 Error: Call to a possibly undefined method
>> Responder.
>> App_Jewel.mxml(71): col: 23 Error: Type was not found or was not a
>> compile-time constant: AsyncToken.
>> App_Jewel.mxml(76): col: 55 Error: Type was not found or was not a
>> compile-time constant: ResultEvent.
>> App_Jewel.mxml(142): col: 23 Error: Type was not found or was not a
>> compile-time constant: Responder.
>> App_Jewel.mxml(142): col: 39 Error: Call to a possibly undefined method
>> Responder.
>> App_Jewel.mxml(143): col: 23 Error: Type was not found or was not a
>> compile-time constant: AsyncToken.
>> App_Jewel.mxml(148): col: 60 Error: Type was not found or was not a
>> compile-time constant: ResultEvent.
>> App_Jewel.mxml(170): col: 9 Error: This tag is unexpected. It will be
>> ignored.
>>
>> These problems are expected, of course, since MXRoyaleJS.swc is not in
>> the library path anymore.
>>
>> In asconfig.json, I added the following two compiler options:
>>
>> "library-path": [
>> "${royalelib}/js/libs/MXRoyaleJS.swc"
>> ],
>> "js-library-path": [
>> "${royalelib}/js/libs/MXRoyaleJS.swc"
>> ]
>>
>> This cleared up all of the problems. Does this work for you?
>>
>> - Josh
>>
>> On 2018/12/06 10:05:36, Carlos Rovira <ca...@apache.org> wrote:
>> > Hi Josh
>> >
>> > El mié., 5 dic. 2018 a las 17:59, Josh Tynjala (<joshtynjala@apache.org
>> >)
>> > escribió:
>> >
>> > > Carlos, can you include more details about your issue?
>> > >
>> > > > MX RO test with Jewel
>> > >
>> > > Can you mention the exact project inside royale-asjs that I can load
>> with
>> > > VSCode to see this issue? I'm guessing that it might be one of the
>> > > RemoteObjectAMFTest projects, but there are more than one!
>> > >
>> > >
>> > Check this one:
>> >
>> https://github.com/apache/royale-asjs/blob/develop/examples/mxroyale/RemoteObjectAMFTest/pom.xml
>> >
>> > but notice that App setup by default is not the right one (check lines
>> 49
>> > and 50 here):
>> >
>> >
>> https://github.com/apache/royale-asjs/blob/develop/examples/mxroyale/RemoteObjectAMFTest/pom.xml
>> >
>> > You must use "App_Jewel.mxml"
>> >
>> > Remember to use "feature/refactor-config-name-changes" branch where my
>> > commit is reverted and things are set up like Alex want.
>> >
>> > You should try to make another config (for example:
>> > "jewel-config-template.xml") that can pick up Jewel and MXRoyale SWCs
>> > and VSCode and your extension should not show any errors.
>> >
>> >
>> >
>> > > > Results: you should see the problems in VSCode
>> > >
>> > > Can you list the exact problems that you are seeing in VSCode? I'd
>> like to
>> > > make sure that I'm not running into unrelated issues.
>> > >
>> >
>> > With Alex changes all classes coming from MXRoyale are not recognized
>> hence
>> > show error.
>> > If I try to make a new config file and add MXRoyale, rebuild all and SDK
>> > too, reopen VSCode, nothing changes
>> >
>> > So my bet is that there's some issue in Royale that makes this new
>> config
>> > changes not work far beyond the special configuration Alex did and need
>> to
>> > find where is the issue. Other possibility is that VSCode extension is
>> > failing, but since it already loads different configs, this seems more
>> > strange to me, although possible.
>> >
>> >
>> > >
>> > > I don't think that this is an issue with VSCode or with the changes
>> that
>> > > Alex made. I suspect that it's just some configuration changes that
>> are
>> > > needed.
>> > >
>> > > - Josh
>> > >
>> >
>> > Thanks for looking into this Josh
>> >
>> > --
>> > Carlos Rovira
>> > http://about.me/carlosrovira
>> >
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: +configname=flex
Posted by Carlos Rovira <ca...@apache.org>.
Hi Josh,
thanks for looking at it, I'll going to check now and report
El jue., 6 dic. 2018 a las 19:03, Josh Tynjala (<jo...@apache.org>)
escribió:
> Carlos,
>
> I wish that you had included the list of problems that you are seeing, as
> I requested. I wanted to be completely certain that I'm seeing the exact
> same ones that you are.
>
> Regardless, here's my initial attempt to reproduce and fix your issue.
>
> In examples/mxroyale/RemoteObjectAMFTest/asconfig.json, I switched to
> App_Jewel.mxml.
>
> Instead of using your branch, I simply modified royale-config.xml in my
> local SDK. When I did this, I saw the following problems appear in Visual
> Studio Code:
>
> App_Jewel.mxml(30): col: 20 Warning: Definition mx.rpc.AsyncToken could
> not be found.
> App_Jewel.mxml(31): col: 20 Warning: Definition mx.rpc.Responder could not
> be found.
> App_Jewel.mxml(32): col: 20 Warning: Definition mx.rpc.events.FaultEvent
> could not be found.
> App_Jewel.mxml(33): col: 20 Warning: Definition mx.rpc.events.ResultEvent
> could not be found
> App_Jewel.mxml(38): col: 33 Error: Type was not found or was not a
> compile-time constant: FaultEvent.
> App_Jewel.mxml(44): col: 31 Error: Type was not found or was not a
> compile-time constant: AsyncToken.
> App_Jewel.mxml(45): col: 35 Error: Type was not found or was not a
> compile-time constant: Responder.
> App_Jewel.mxml(48): col: 33 Error: Call to a possibly undefined method
> Responder.
> App_Jewel.mxml(54): col: 49 Error: Type was not found or was not a
> compile-time constant: ResultEvent.
> App_Jewel.mxml(70): col: 23 Error: Type was not found or was not a
> compile-time constant: Responder.
> App_Jewel.mxml(70): col: 39 Error: Call to a possibly undefined method
> Responder.
> App_Jewel.mxml(71): col: 23 Error: Type was not found or was not a
> compile-time constant: AsyncToken.
> App_Jewel.mxml(76): col: 55 Error: Type was not found or was not a
> compile-time constant: ResultEvent.
> App_Jewel.mxml(142): col: 23 Error: Type was not found or was not a
> compile-time constant: Responder.
> App_Jewel.mxml(142): col: 39 Error: Call to a possibly undefined method
> Responder.
> App_Jewel.mxml(143): col: 23 Error: Type was not found or was not a
> compile-time constant: AsyncToken.
> App_Jewel.mxml(148): col: 60 Error: Type was not found or was not a
> compile-time constant: ResultEvent.
> App_Jewel.mxml(170): col: 9 Error: This tag is unexpected. It will be
> ignored.
>
> These problems are expected, of course, since MXRoyaleJS.swc is not in the
> library path anymore.
>
> In asconfig.json, I added the following two compiler options:
>
> "library-path": [
> "${royalelib}/js/libs/MXRoyaleJS.swc"
> ],
> "js-library-path": [
> "${royalelib}/js/libs/MXRoyaleJS.swc"
> ]
>
> This cleared up all of the problems. Does this work for you?
>
> - Josh
>
> On 2018/12/06 10:05:36, Carlos Rovira <ca...@apache.org> wrote:
> > Hi Josh
> >
> > El mié., 5 dic. 2018 a las 17:59, Josh Tynjala (<joshtynjala@apache.org
> >)
> > escribió:
> >
> > > Carlos, can you include more details about your issue?
> > >
> > > > MX RO test with Jewel
> > >
> > > Can you mention the exact project inside royale-asjs that I can load
> with
> > > VSCode to see this issue? I'm guessing that it might be one of the
> > > RemoteObjectAMFTest projects, but there are more than one!
> > >
> > >
> > Check this one:
> >
> https://github.com/apache/royale-asjs/blob/develop/examples/mxroyale/RemoteObjectAMFTest/pom.xml
> >
> > but notice that App setup by default is not the right one (check lines 49
> > and 50 here):
> >
> >
> https://github.com/apache/royale-asjs/blob/develop/examples/mxroyale/RemoteObjectAMFTest/pom.xml
> >
> > You must use "App_Jewel.mxml"
> >
> > Remember to use "feature/refactor-config-name-changes" branch where my
> > commit is reverted and things are set up like Alex want.
> >
> > You should try to make another config (for example:
> > "jewel-config-template.xml") that can pick up Jewel and MXRoyale SWCs
> > and VSCode and your extension should not show any errors.
> >
> >
> >
> > > > Results: you should see the problems in VSCode
> > >
> > > Can you list the exact problems that you are seeing in VSCode? I'd
> like to
> > > make sure that I'm not running into unrelated issues.
> > >
> >
> > With Alex changes all classes coming from MXRoyale are not recognized
> hence
> > show error.
> > If I try to make a new config file and add MXRoyale, rebuild all and SDK
> > too, reopen VSCode, nothing changes
> >
> > So my bet is that there's some issue in Royale that makes this new config
> > changes not work far beyond the special configuration Alex did and need
> to
> > find where is the issue. Other possibility is that VSCode extension is
> > failing, but since it already loads different configs, this seems more
> > strange to me, although possible.
> >
> >
> > >
> > > I don't think that this is an issue with VSCode or with the changes
> that
> > > Alex made. I suspect that it's just some configuration changes that are
> > > needed.
> > >
> > > - Josh
> > >
> >
> > Thanks for looking into this Josh
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: +configname=flex
Posted by Josh Tynjala <jo...@apache.org>.
Carlos,
I wish that you had included the list of problems that you are seeing, as I requested. I wanted to be completely certain that I'm seeing the exact same ones that you are.
Regardless, here's my initial attempt to reproduce and fix your issue.
In examples/mxroyale/RemoteObjectAMFTest/asconfig.json, I switched to App_Jewel.mxml.
Instead of using your branch, I simply modified royale-config.xml in my local SDK. When I did this, I saw the following problems appear in Visual Studio Code:
App_Jewel.mxml(30): col: 20 Warning: Definition mx.rpc.AsyncToken could not be found.
App_Jewel.mxml(31): col: 20 Warning: Definition mx.rpc.Responder could not be found.
App_Jewel.mxml(32): col: 20 Warning: Definition mx.rpc.events.FaultEvent could not be found.
App_Jewel.mxml(33): col: 20 Warning: Definition mx.rpc.events.ResultEvent could not be found
App_Jewel.mxml(38): col: 33 Error: Type was not found or was not a compile-time constant: FaultEvent.
App_Jewel.mxml(44): col: 31 Error: Type was not found or was not a compile-time constant: AsyncToken.
App_Jewel.mxml(45): col: 35 Error: Type was not found or was not a compile-time constant: Responder.
App_Jewel.mxml(48): col: 33 Error: Call to a possibly undefined method Responder.
App_Jewel.mxml(54): col: 49 Error: Type was not found or was not a compile-time constant: ResultEvent.
App_Jewel.mxml(70): col: 23 Error: Type was not found or was not a compile-time constant: Responder.
App_Jewel.mxml(70): col: 39 Error: Call to a possibly undefined method Responder.
App_Jewel.mxml(71): col: 23 Error: Type was not found or was not a compile-time constant: AsyncToken.
App_Jewel.mxml(76): col: 55 Error: Type was not found or was not a compile-time constant: ResultEvent.
App_Jewel.mxml(142): col: 23 Error: Type was not found or was not a compile-time constant: Responder.
App_Jewel.mxml(142): col: 39 Error: Call to a possibly undefined method Responder.
App_Jewel.mxml(143): col: 23 Error: Type was not found or was not a compile-time constant: AsyncToken.
App_Jewel.mxml(148): col: 60 Error: Type was not found or was not a compile-time constant: ResultEvent.
App_Jewel.mxml(170): col: 9 Error: This tag is unexpected. It will be ignored.
These problems are expected, of course, since MXRoyaleJS.swc is not in the library path anymore.
In asconfig.json, I added the following two compiler options:
"library-path": [
"${royalelib}/js/libs/MXRoyaleJS.swc"
],
"js-library-path": [
"${royalelib}/js/libs/MXRoyaleJS.swc"
]
This cleared up all of the problems. Does this work for you?
- Josh
On 2018/12/06 10:05:36, Carlos Rovira <ca...@apache.org> wrote:
> Hi Josh
>
> El mié., 5 dic. 2018 a las 17:59, Josh Tynjala (<jo...@apache.org>)
> escribió:
>
> > Carlos, can you include more details about your issue?
> >
> > > MX RO test with Jewel
> >
> > Can you mention the exact project inside royale-asjs that I can load with
> > VSCode to see this issue? I'm guessing that it might be one of the
> > RemoteObjectAMFTest projects, but there are more than one!
> >
> >
> Check this one:
> https://github.com/apache/royale-asjs/blob/develop/examples/mxroyale/RemoteObjectAMFTest/pom.xml
>
> but notice that App setup by default is not the right one (check lines 49
> and 50 here):
>
> https://github.com/apache/royale-asjs/blob/develop/examples/mxroyale/RemoteObjectAMFTest/pom.xml
>
> You must use "App_Jewel.mxml"
>
> Remember to use "feature/refactor-config-name-changes" branch where my
> commit is reverted and things are set up like Alex want.
>
> You should try to make another config (for example:
> "jewel-config-template.xml") that can pick up Jewel and MXRoyale SWCs
> and VSCode and your extension should not show any errors.
>
>
>
> > > Results: you should see the problems in VSCode
> >
> > Can you list the exact problems that you are seeing in VSCode? I'd like to
> > make sure that I'm not running into unrelated issues.
> >
>
> With Alex changes all classes coming from MXRoyale are not recognized hence
> show error.
> If I try to make a new config file and add MXRoyale, rebuild all and SDK
> too, reopen VSCode, nothing changes
>
> So my bet is that there's some issue in Royale that makes this new config
> changes not work far beyond the special configuration Alex did and need to
> find where is the issue. Other possibility is that VSCode extension is
> failing, but since it already loads different configs, this seems more
> strange to me, although possible.
>
>
> >
> > I don't think that this is an issue with VSCode or with the changes that
> > Alex made. I suspect that it's just some configuration changes that are
> > needed.
> >
> > - Josh
> >
>
> Thanks for looking into this Josh
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: +configname=flex
Posted by Carlos Rovira <ca...@apache.org>.
Hi Josh
El mié., 5 dic. 2018 a las 17:59, Josh Tynjala (<jo...@apache.org>)
escribió:
> Carlos, can you include more details about your issue?
>
> > MX RO test with Jewel
>
> Can you mention the exact project inside royale-asjs that I can load with
> VSCode to see this issue? I'm guessing that it might be one of the
> RemoteObjectAMFTest projects, but there are more than one!
>
>
Check this one:
https://github.com/apache/royale-asjs/blob/develop/examples/mxroyale/RemoteObjectAMFTest/pom.xml
but notice that App setup by default is not the right one (check lines 49
and 50 here):
https://github.com/apache/royale-asjs/blob/develop/examples/mxroyale/RemoteObjectAMFTest/pom.xml
You must use "App_Jewel.mxml"
Remember to use "feature/refactor-config-name-changes" branch where my
commit is reverted and things are set up like Alex want.
You should try to make another config (for example:
"jewel-config-template.xml") that can pick up Jewel and MXRoyale SWCs
and VSCode and your extension should not show any errors.
> > Results: you should see the problems in VSCode
>
> Can you list the exact problems that you are seeing in VSCode? I'd like to
> make sure that I'm not running into unrelated issues.
>
With Alex changes all classes coming from MXRoyale are not recognized hence
show error.
If I try to make a new config file and add MXRoyale, rebuild all and SDK
too, reopen VSCode, nothing changes
So my bet is that there's some issue in Royale that makes this new config
changes not work far beyond the special configuration Alex did and need to
find where is the issue. Other possibility is that VSCode extension is
failing, but since it already loads different configs, this seems more
strange to me, although possible.
>
> I don't think that this is an issue with VSCode or with the changes that
> Alex made. I suspect that it's just some configuration changes that are
> needed.
>
> - Josh
>
Thanks for looking into this Josh
--
Carlos Rovira
http://about.me/carlosrovira
Re: +configname=flex
Posted by Josh Tynjala <jo...@apache.org>.
Carlos, can you include more details about your issue?
> MX RO test with Jewel
Can you mention the exact project inside royale-asjs that I can load with VSCode to see this issue? I'm guessing that it might be one of the RemoteObjectAMFTest projects, but there are more than one!
> Results: you should see the problems in VSCode
Can you list the exact problems that you are seeing in VSCode? I'd like to make sure that I'm not running into unrelated issues.
I don't think that this is an issue with VSCode or with the changes that Alex made. I suspect that it's just some configuration changes that are needed.
- Josh
On 2018/12/05 11:54:13, Carlos Rovira <ca...@apache.org> wrote:
> Hi Alex,
>
> you continue talking of this in a way like like if the change you did is
> right and my fix is not. But don't see you in a point to put your commit in
> question.
> I can say the same as you describe in your email, but applied to your
> changes. Far beyond this concrete issue, I think we have a problem if you
> consider that you can commit a change that breaks current repo (don't need
> to be a build break, but other's like IDEs break), and when others fix the
> failing problem you state that others changes are really the problem. I
> think we're going in circles.
>
> Always I make a change I'm prepared to others critics and as well I don't
> have problems in listen and revert my work or update when others have
> explained things and I see my errors. You see me do this taking into
> account your advices many times. So you can ensure I consider myself
> fallible.
>
> But you way is always state you're right, and does not have a problem with
> your commits. But I'm having. And not's a particular case. Is a case with
> Jewel, that has exactly the same importance that the rest of Royale (to
> avoid you refer to my case, as something that fails in some personal code
> or config in my own)
>
> This days are difficult to me since I'm fixing things in our current real
> world Royale App, so I still couldn't get to the problem in that branch.
> I think as well is important for the Apache Royale, this real project gets
> success, since that will mean one more success for Apache Royale getting a
> new App that works and goes to production. So I think at least this days
> that's priority I had to choose.
>
> About the problem, you said you asked some times in this thread, and I
> think I responded some times in this thread.
>
> Here's another try If you want to check the problem yourself, until I can
> get enough time do my own tries:
>
> 1.- grab VSCode and AS3&MXML extension
> 2.- build SDK in the branch where I reverted my commit and point VSCode to
> that SDK
> 3.- point a project like for example the MX RO test with Jewel example (so
> you have a project that uses Jewel and MXRoyale)
>
> Results: you should see the problems in VSCode
>
> maybe you can start from the current version to see that with an SDK
> generated from current branch problems are 0 and going to the branch with
> your changes, VSCode goes crazy.
>
> I think from now on we can stop to say you don't have enough data to
> reproduce the problem right?
>
> I think the problem could be that you don't use IDEs, but IMHO you should
> setup VSCode or Moonlight (that since uses the same core, should shows the
> same problem). You must have IDEs in mind, since we, are all in real
> projects using real tools for the work, so you can be agnostic of that
> reality, and if something breaks IDEs, the solutions we do must ensure IDEs
> continue to work.
>
> Thanks
>
> Carlos
>
>
>
>
>
>
>
> El mié., 5 dic. 2018 a las 0:13, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
> > When you are writing code for your app, you may or may not care about code
> > re-usability. When writing code for a framework, you must always care
> > about reusability. Thus, every change must be explainable. It isn't good
> > enough to make a change because it was the only way you can get something
> > to work.
> >
> > In this case, the change was to the list of default SWCs. It should be
> > possible to override all of those settings for your needs. I have offered
> > to help and asked for useful data on at least four posts on this thread.
> > So far, I don't have anything to work with. I'm trying to help, but it is
> > not a good use of my time to guess what the problem test case is.
> >
> > We must use sound engineering principles in creating a framework because
> > we want lots of folks to rely on it. I was amazed when Adobe shipped the
> > first generation of AS2 components with Flash MX that some folks spent
> > hours reading the code. We would want folks to do the same for Royale and
> > our code must make sense. Before changing someone else's code, you should
> > be able to explain why the code you are changing is flawed and why your
> > change is better. We have a commits history so you can go back and see
> > changes to help determine why things were changed. If you can't explain
> > your changes, don't push it.
> >
> > If something is a mystery, create a simple test case and add complexity
> > until it fails, or subset your complex test case until it stops failing.
> > Also consider whether the builds are working and whether anyone else is
> > complaining about related issues. Committers should be able to build from
> > sources, so rollback if you are in a hurry, but don't push a change if it
> > is just a guess.
> >
> > My 2 cents,
> > -Alex
> >
> > On 12/1/18, 11:30 AM, "Carlos Rovira" <ca...@apache.org> wrote:
> >
> > Hi Alex, I don't think that's what happen.
> >
> > My version (always considering that there's my version, your version
> > and
> > the truth):
> >
> > 1.- You make a commit that introduced IDEs break
> > 2.- I spend Saturday morning trying to find a way to fix that
> > 3.- Instead of revert your commit I make a change of the thing causing
> > the
> > problem with the comment "to be reverted as we find the solution"
> > 4.- You was upset since you consider it a revert, and I asked you to
> > find a
> > way a solution so we all can live in peace and armony
> > 5.- You said me that I must to do it myself or pay someone to do it,
> > and
> > that Alina and others have priority over my needs
> > 6.- Dave told us that we should work on branches, since nobody is a
> > special
> > case here.
> >
> > We are on that point where we have a branch with a first commit that
> > is my
> > commit reverted, in order to find the solution.
> >
> > Since Royale has different sets no one is more important than other.
> > Basic,
> > Jewel, and not Mx/Spark must coexist, and should work in conjunction.
> > I'm using Jewel and MX for RPC part and some other classes (i.e.
> > CurrencyFormatter, and maybe others). The changes in config files make
> > IDEs
> > goes crazy.
> > So I can have a "jewel-config-template.xml", that has jewel, mx,...and
> > other libs needed, no problem on that, but when I tried to create
> > that, I
> > couldn't get it work.
> > That's point 2 in my list. For that reason maybe there's a bug and that
> > could be done, if that's the case, I think is Alex responsibility to
> > fix
> > that to leverage his change,
> > and not make me depend on my time or money to contract other people to
> > do
> > that. IOW, if we make a change that break something, and others
> > complains,
> > don't see
> > a point to make a battle for something like that. I think is more easy
> > to
> > work on fix that instead of invest time in a large thread and emails.
> >
> > Since this Friday I release our real work Apache Royale app first
> > iteration, I plan to work on that this week end, but finaly I must fix
> > things on our release for Monday, so I can work on that on this on
> > Monday
> > or Tuesday.
> >
> >
> >
> >
> > El jue., 29 nov. 2018 a las 10:40, Alex Harui
> > (<ah...@adobe.com.invalid>)
> > escribió:
> >
> > > As discussed I changed royale-config.xml to list all of our SWCs
> > except
> > > for MXRoyale and SparkRoyale, and changed flex-config.xml to use all
> > SWCs
> > > and have different default classes such as mx.events.MouseEvent
> > instead of
> > > org.apache.royale.events.MouseEvent. I think Carlos has the only
> > project
> > > using MXRoyale and Jewel and maybe some Basic so neither config is
> > set up
> > > exactly for his needs. Since all configuration is theoretically
> > > overridable as compiler options, he should have been able to get
> > going by
> > > specifying what SWCs he wants to use.
> > >
> > > He said he wasn't able to do that, so he committed a change that
> > went back
> > > to using a wildcard in royale-config.xml and thus pull in all SWCs
> > and
> > > re-introduce the problem. That doesn't make any technical sense to
> > me and
> > > brought back the CSS problem that was affecting folks like you. So
> > I asked
> > > him to revert his wildcard change and so far, he hasn't and instead
> > he
> > > started in on how I am seeking special treatment.
> > >
> > > -Alex
> > >
> > > On 11/28/18, 7:19 PM, "Harbs" <ha...@gmail.com> wrote:
> > >
> > > I’m still not following.
> > >
> > > What did you change and what was the issue that Carlos hit? Am I
> > > correct that you were fixing the problem that MXRoyale was
> > overriding the
> > > Basic CSS?
> > >
> > > What exactly was the fix and why was it causing problems?
> > >
> > > > On Nov 28, 2018, at 5:21 PM, Alex Harui
> > <ah...@adobe.com.INVALID>
> > > wrote:
> > > >
> > > > Carlos reverted a commit I made without technical
> > justification and
> > > refuses to put back my changes when I asked, instead saying I was
> > acting
> > > like I should have special treatment. Apparently, Carlos couldn't
> > compile
> > > his app even though all of our examples build just fine. I've
> > tried to
> > > help, but cannot get solid data from Carlos.
> > > >
> > > > Somehow Dave Fisher thinks is ok for Carlos to act like that.
> > I
> > > think it sets a dangerous precedent to have committers revert other
> > > people's changes without technical justification, and also a bad
> > precedent
> > > to allow people to basically call people names when they disagree
> > about
> > > something.
> > > >
> > > > -Alex
> > > >
> > > > On 11/27/18, 4:52 PM, "Harbs" <ha...@gmail.com> wrote:
> > > >
> > > > I have not been following the list very well the last week
> > plus.
> > > (I’ve been busy with some personal things.)
> > > >
> > > > I’m not following the issues here. What was changed, and
> > what’s
> > > the issue here?
> > > >
> > >
> > >
> > >
> > >
> >
> > --
> > Carlos Rovira
> >
> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C3184e1049ffa40fef9d108d657c36bc1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636792894197456300&sdata=Sv5rPuwkJD0uDeRqjWFs27m9AHtJIBU9G%2FdM2iUwqro%3D&reserved=0
> >
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: +configname=flex
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
you continue talking of this in a way like like if the change you did is
right and my fix is not. But don't see you in a point to put your commit in
question.
I can say the same as you describe in your email, but applied to your
changes. Far beyond this concrete issue, I think we have a problem if you
consider that you can commit a change that breaks current repo (don't need
to be a build break, but other's like IDEs break), and when others fix the
failing problem you state that others changes are really the problem. I
think we're going in circles.
Always I make a change I'm prepared to others critics and as well I don't
have problems in listen and revert my work or update when others have
explained things and I see my errors. You see me do this taking into
account your advices many times. So you can ensure I consider myself
fallible.
But you way is always state you're right, and does not have a problem with
your commits. But I'm having. And not's a particular case. Is a case with
Jewel, that has exactly the same importance that the rest of Royale (to
avoid you refer to my case, as something that fails in some personal code
or config in my own)
This days are difficult to me since I'm fixing things in our current real
world Royale App, so I still couldn't get to the problem in that branch.
I think as well is important for the Apache Royale, this real project gets
success, since that will mean one more success for Apache Royale getting a
new App that works and goes to production. So I think at least this days
that's priority I had to choose.
About the problem, you said you asked some times in this thread, and I
think I responded some times in this thread.
Here's another try If you want to check the problem yourself, until I can
get enough time do my own tries:
1.- grab VSCode and AS3&MXML extension
2.- build SDK in the branch where I reverted my commit and point VSCode to
that SDK
3.- point a project like for example the MX RO test with Jewel example (so
you have a project that uses Jewel and MXRoyale)
Results: you should see the problems in VSCode
maybe you can start from the current version to see that with an SDK
generated from current branch problems are 0 and going to the branch with
your changes, VSCode goes crazy.
I think from now on we can stop to say you don't have enough data to
reproduce the problem right?
I think the problem could be that you don't use IDEs, but IMHO you should
setup VSCode or Moonlight (that since uses the same core, should shows the
same problem). You must have IDEs in mind, since we, are all in real
projects using real tools for the work, so you can be agnostic of that
reality, and if something breaks IDEs, the solutions we do must ensure IDEs
continue to work.
Thanks
Carlos
El mié., 5 dic. 2018 a las 0:13, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> When you are writing code for your app, you may or may not care about code
> re-usability. When writing code for a framework, you must always care
> about reusability. Thus, every change must be explainable. It isn't good
> enough to make a change because it was the only way you can get something
> to work.
>
> In this case, the change was to the list of default SWCs. It should be
> possible to override all of those settings for your needs. I have offered
> to help and asked for useful data on at least four posts on this thread.
> So far, I don't have anything to work with. I'm trying to help, but it is
> not a good use of my time to guess what the problem test case is.
>
> We must use sound engineering principles in creating a framework because
> we want lots of folks to rely on it. I was amazed when Adobe shipped the
> first generation of AS2 components with Flash MX that some folks spent
> hours reading the code. We would want folks to do the same for Royale and
> our code must make sense. Before changing someone else's code, you should
> be able to explain why the code you are changing is flawed and why your
> change is better. We have a commits history so you can go back and see
> changes to help determine why things were changed. If you can't explain
> your changes, don't push it.
>
> If something is a mystery, create a simple test case and add complexity
> until it fails, or subset your complex test case until it stops failing.
> Also consider whether the builds are working and whether anyone else is
> complaining about related issues. Committers should be able to build from
> sources, so rollback if you are in a hurry, but don't push a change if it
> is just a guess.
>
> My 2 cents,
> -Alex
>
> On 12/1/18, 11:30 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex, I don't think that's what happen.
>
> My version (always considering that there's my version, your version
> and
> the truth):
>
> 1.- You make a commit that introduced IDEs break
> 2.- I spend Saturday morning trying to find a way to fix that
> 3.- Instead of revert your commit I make a change of the thing causing
> the
> problem with the comment "to be reverted as we find the solution"
> 4.- You was upset since you consider it a revert, and I asked you to
> find a
> way a solution so we all can live in peace and armony
> 5.- You said me that I must to do it myself or pay someone to do it,
> and
> that Alina and others have priority over my needs
> 6.- Dave told us that we should work on branches, since nobody is a
> special
> case here.
>
> We are on that point where we have a branch with a first commit that
> is my
> commit reverted, in order to find the solution.
>
> Since Royale has different sets no one is more important than other.
> Basic,
> Jewel, and not Mx/Spark must coexist, and should work in conjunction.
> I'm using Jewel and MX for RPC part and some other classes (i.e.
> CurrencyFormatter, and maybe others). The changes in config files make
> IDEs
> goes crazy.
> So I can have a "jewel-config-template.xml", that has jewel, mx,...and
> other libs needed, no problem on that, but when I tried to create
> that, I
> couldn't get it work.
> That's point 2 in my list. For that reason maybe there's a bug and that
> could be done, if that's the case, I think is Alex responsibility to
> fix
> that to leverage his change,
> and not make me depend on my time or money to contract other people to
> do
> that. IOW, if we make a change that break something, and others
> complains,
> don't see
> a point to make a battle for something like that. I think is more easy
> to
> work on fix that instead of invest time in a large thread and emails.
>
> Since this Friday I release our real work Apache Royale app first
> iteration, I plan to work on that this week end, but finaly I must fix
> things on our release for Monday, so I can work on that on this on
> Monday
> or Tuesday.
>
>
>
>
> El jue., 29 nov. 2018 a las 10:40, Alex Harui
> (<ah...@adobe.com.invalid>)
> escribió:
>
> > As discussed I changed royale-config.xml to list all of our SWCs
> except
> > for MXRoyale and SparkRoyale, and changed flex-config.xml to use all
> SWCs
> > and have different default classes such as mx.events.MouseEvent
> instead of
> > org.apache.royale.events.MouseEvent. I think Carlos has the only
> project
> > using MXRoyale and Jewel and maybe some Basic so neither config is
> set up
> > exactly for his needs. Since all configuration is theoretically
> > overridable as compiler options, he should have been able to get
> going by
> > specifying what SWCs he wants to use.
> >
> > He said he wasn't able to do that, so he committed a change that
> went back
> > to using a wildcard in royale-config.xml and thus pull in all SWCs
> and
> > re-introduce the problem. That doesn't make any technical sense to
> me and
> > brought back the CSS problem that was affecting folks like you. So
> I asked
> > him to revert his wildcard change and so far, he hasn't and instead
> he
> > started in on how I am seeking special treatment.
> >
> > -Alex
> >
> > On 11/28/18, 7:19 PM, "Harbs" <ha...@gmail.com> wrote:
> >
> > I’m still not following.
> >
> > What did you change and what was the issue that Carlos hit? Am I
> > correct that you were fixing the problem that MXRoyale was
> overriding the
> > Basic CSS?
> >
> > What exactly was the fix and why was it causing problems?
> >
> > > On Nov 28, 2018, at 5:21 PM, Alex Harui
> <ah...@adobe.com.INVALID>
> > wrote:
> > >
> > > Carlos reverted a commit I made without technical
> justification and
> > refuses to put back my changes when I asked, instead saying I was
> acting
> > like I should have special treatment. Apparently, Carlos couldn't
> compile
> > his app even though all of our examples build just fine. I've
> tried to
> > help, but cannot get solid data from Carlos.
> > >
> > > Somehow Dave Fisher thinks is ok for Carlos to act like that.
> I
> > think it sets a dangerous precedent to have committers revert other
> > people's changes without technical justification, and also a bad
> precedent
> > to allow people to basically call people names when they disagree
> about
> > something.
> > >
> > > -Alex
> > >
> > > On 11/27/18, 4:52 PM, "Harbs" <ha...@gmail.com> wrote:
> > >
> > > I have not been following the list very well the last week
> plus.
> > (I’ve been busy with some personal things.)
> > >
> > > I’m not following the issues here. What was changed, and
> what’s
> > the issue here?
> > >
> >
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C3184e1049ffa40fef9d108d657c36bc1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636792894197456300&sdata=Sv5rPuwkJD0uDeRqjWFs27m9AHtJIBU9G%2FdM2iUwqro%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: +configname=flex
Posted by Alex Harui <ah...@adobe.com.INVALID>.
When you are writing code for your app, you may or may not care about code re-usability. When writing code for a framework, you must always care about reusability. Thus, every change must be explainable. It isn't good enough to make a change because it was the only way you can get something to work.
In this case, the change was to the list of default SWCs. It should be possible to override all of those settings for your needs. I have offered to help and asked for useful data on at least four posts on this thread. So far, I don't have anything to work with. I'm trying to help, but it is not a good use of my time to guess what the problem test case is.
We must use sound engineering principles in creating a framework because we want lots of folks to rely on it. I was amazed when Adobe shipped the first generation of AS2 components with Flash MX that some folks spent hours reading the code. We would want folks to do the same for Royale and our code must make sense. Before changing someone else's code, you should be able to explain why the code you are changing is flawed and why your change is better. We have a commits history so you can go back and see changes to help determine why things were changed. If you can't explain your changes, don't push it.
If something is a mystery, create a simple test case and add complexity until it fails, or subset your complex test case until it stops failing. Also consider whether the builds are working and whether anyone else is complaining about related issues. Committers should be able to build from sources, so rollback if you are in a hurry, but don't push a change if it is just a guess.
My 2 cents,
-Alex
On 12/1/18, 11:30 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex, I don't think that's what happen.
My version (always considering that there's my version, your version and
the truth):
1.- You make a commit that introduced IDEs break
2.- I spend Saturday morning trying to find a way to fix that
3.- Instead of revert your commit I make a change of the thing causing the
problem with the comment "to be reverted as we find the solution"
4.- You was upset since you consider it a revert, and I asked you to find a
way a solution so we all can live in peace and armony
5.- You said me that I must to do it myself or pay someone to do it, and
that Alina and others have priority over my needs
6.- Dave told us that we should work on branches, since nobody is a special
case here.
We are on that point where we have a branch with a first commit that is my
commit reverted, in order to find the solution.
Since Royale has different sets no one is more important than other. Basic,
Jewel, and not Mx/Spark must coexist, and should work in conjunction.
I'm using Jewel and MX for RPC part and some other classes (i.e.
CurrencyFormatter, and maybe others). The changes in config files make IDEs
goes crazy.
So I can have a "jewel-config-template.xml", that has jewel, mx,...and
other libs needed, no problem on that, but when I tried to create that, I
couldn't get it work.
That's point 2 in my list. For that reason maybe there's a bug and that
could be done, if that's the case, I think is Alex responsibility to fix
that to leverage his change,
and not make me depend on my time or money to contract other people to do
that. IOW, if we make a change that break something, and others complains,
don't see
a point to make a battle for something like that. I think is more easy to
work on fix that instead of invest time in a large thread and emails.
Since this Friday I release our real work Apache Royale app first
iteration, I plan to work on that this week end, but finaly I must fix
things on our release for Monday, so I can work on that on this on Monday
or Tuesday.
El jue., 29 nov. 2018 a las 10:40, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> As discussed I changed royale-config.xml to list all of our SWCs except
> for MXRoyale and SparkRoyale, and changed flex-config.xml to use all SWCs
> and have different default classes such as mx.events.MouseEvent instead of
> org.apache.royale.events.MouseEvent. I think Carlos has the only project
> using MXRoyale and Jewel and maybe some Basic so neither config is set up
> exactly for his needs. Since all configuration is theoretically
> overridable as compiler options, he should have been able to get going by
> specifying what SWCs he wants to use.
>
> He said he wasn't able to do that, so he committed a change that went back
> to using a wildcard in royale-config.xml and thus pull in all SWCs and
> re-introduce the problem. That doesn't make any technical sense to me and
> brought back the CSS problem that was affecting folks like you. So I asked
> him to revert his wildcard change and so far, he hasn't and instead he
> started in on how I am seeking special treatment.
>
> -Alex
>
> On 11/28/18, 7:19 PM, "Harbs" <ha...@gmail.com> wrote:
>
> I’m still not following.
>
> What did you change and what was the issue that Carlos hit? Am I
> correct that you were fixing the problem that MXRoyale was overriding the
> Basic CSS?
>
> What exactly was the fix and why was it causing problems?
>
> > On Nov 28, 2018, at 5:21 PM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >
> > Carlos reverted a commit I made without technical justification and
> refuses to put back my changes when I asked, instead saying I was acting
> like I should have special treatment. Apparently, Carlos couldn't compile
> his app even though all of our examples build just fine. I've tried to
> help, but cannot get solid data from Carlos.
> >
> > Somehow Dave Fisher thinks is ok for Carlos to act like that. I
> think it sets a dangerous precedent to have committers revert other
> people's changes without technical justification, and also a bad precedent
> to allow people to basically call people names when they disagree about
> something.
> >
> > -Alex
> >
> > On 11/27/18, 4:52 PM, "Harbs" <ha...@gmail.com> wrote:
> >
> > I have not been following the list very well the last week plus.
> (I’ve been busy with some personal things.)
> >
> > I’m not following the issues here. What was changed, and what’s
> the issue here?
> >
>
>
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C3184e1049ffa40fef9d108d657c36bc1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636792894197456300&sdata=Sv5rPuwkJD0uDeRqjWFs27m9AHtJIBU9G%2FdM2iUwqro%3D&reserved=0