Build failed in Jenkins: royale-asjs_jsonly #795

[apacheroyaleci]

See 


Changes:

[noreply] AdvancedDataGridEvent.as Added

--
[...truncated 1.76 MB...]
[mxmlc] org.apache.royale.html.ButtonBar depends on 
org.apache.royale.html.List
[mxmlc] 

 removing require: org.apache.royale.core.IRollOverModel
[mxmlc] 

 removing require: org.apache.royale.core.ISelectionModel
[mxmlc] Dependencies calculated for 'org.apache.royale.html.List'
[mxmlc] org.apache.royale.html.List depends on 
org.apache.royale.html.DataContainer
[mxmlc] 

 removing require: org.apache.royale.core.IDataProviderModel
[mxmlc] 

 removing require: org.apache.royale.core.IListPresentationModel
[mxmlc] 

 removing require: org.apache.royale.html.beads.models.ListPresentationModel
[mxmlc] Dependencies calculated for 'org.apache.royale.html.DataContainer'
[mxmlc] org.apache.royale.html.DataContainer depends on 
org.apache.royale.core.DataContainerBase
[mxmlc] 

 removing require: org.apache.royale.core.DataItemRenderer
[mxmlc] 

 removing require: org.apache.royale.core.IChild
[mxmlc] 

 removing require: org.apache.royale.core.IDataProviderItemRendererMapper
[mxmlc] 

 removing require: org.apache.royale.core.IFactory
[mxmlc] 

 removing require: org.apache.royale.core.IItemRenderer
[mxmlc] 

 removing require: org.apache.royale.core.IItemRendererClassFactory
[mxmlc] 

 removing require: org.apache.royale.core.IListView
[mxmlc] 

 removing require: org.apache.royale.core.ValuesManager
[mxmlc] 

 removing require: org.apache.royale.events.Event
[mxmlc] 

 removing require: org.apache.royale.events.ItemAddedEvent
[mxmlc] 

 removing require: org.apache.royale.events.ItemRemovedEvent
[mxmlc] 

 removing require: org.apache.royale.utils.loadBeadFromValuesManager
[mxmlc] 

 removing require: org.apache.royale.utils.Language
[mxmlc] Dependencies calculated for 
'org.apache.royale.core.DataContainerBase'

Build failed in Jenkins: royale-asjs_jsonly #794

[apacheroyaleci]

See 


--
[...truncated 1.77 MB...]
[mxmlc] org.apache.royale.html.ButtonBar depends on 
org.apache.royale.html.List
[mxmlc] 

 removing require: org.apache.royale.core.IRollOverModel
[mxmlc] 

 removing require: org.apache.royale.core.ISelectionModel
[mxmlc] Dependencies calculated for 'org.apache.royale.html.List'
[mxmlc] org.apache.royale.html.List depends on 
org.apache.royale.html.DataContainer
[mxmlc] 

 removing require: org.apache.royale.core.IDataProviderModel
[mxmlc] 

 removing require: org.apache.royale.core.IListPresentationModel
[mxmlc] 

 removing require: org.apache.royale.html.beads.models.ListPresentationModel
[mxmlc] Dependencies calculated for 'org.apache.royale.html.DataContainer'
[mxmlc] org.apache.royale.html.DataContainer depends on 
org.apache.royale.core.DataContainerBase
[mxmlc] 

 removing require: org.apache.royale.core.DataItemRenderer
[mxmlc] 

 removing require: org.apache.royale.core.IChild
[mxmlc] 

 removing require: org.apache.royale.core.IDataProviderItemRendererMapper
[mxmlc] 

 removing require: org.apache.royale.core.IFactory
[mxmlc] 

 removing require: org.apache.royale.core.IItemRenderer
[mxmlc] 

 removing require: org.apache.royale.core.IItemRendererClassFactory
[mxmlc] 

 removing require: org.apache.royale.core.IListView
[mxmlc] 

 removing require: org.apache.royale.core.ValuesManager
[mxmlc] 

 removing require: org.apache.royale.events.Event
[mxmlc] 

 removing require: org.apache.royale.events.ItemAddedEvent
[mxmlc] 

 removing require: org.apache.royale.events.ItemRemovedEvent
[mxmlc] 

 removing require: org.apache.royale.utils.loadBeadFromValuesManager
[mxmlc] 

 removing require: org.apache.royale.utils.Language
[mxmlc] Dependencies calculated for 
'org.apache.royale.core.DataContainerBase'
[mxmlc] org.apache.royale.core.DataContainerBase depends on 

Re: Apache Royale Pure AS3 without MXML

[mshaffer12882]

Thanks for your quick response!  I checked out all of your suggestions and it
works very well.  I've been playing with MXML for a while now and it is very
simple and fast! I'm looking forward to Jewel and have been following the
refactoring that is being done.

The reason for my post is I noticed in this starling post:
https://forum.starling-framework.org/topic/starling-23-available-for-typescript-haxe-and-javascript
that the user singmajesty had finished a port of Starling to Haxe.  Which
now makes Starling 2.3 be able to run in HTML 5 but only with Haxe.  I
posted to check out Apache Royale and Sprite Flex JS.  He private messaged
me and was able to get a prof of concept running so we can use Starling in
HTML5 using pure AS3.  
See here: https://github.com/jgranick/ApacheRoyaleDemo









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

Build failed in Jenkins: royale-asjs_jsonly #793

[apacheroyaleci]

See 


--
[...truncated 1.80 MB...]
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/html/beads/layouts/DataGridLayout.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IItemRendererProvider.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IList.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IListWithPresentationModel.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/ILayoutView.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IStrand.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IStrandWithModel.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IStyleableObject.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IChild.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IUIBase.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/ILayoutChild.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IParentIUIBase.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IRoyaleElement.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/HTMLElementWrapper.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/UIBase.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IStatesObject.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/ILayoutParent.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IContainer.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/GroupBase.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/ContainerBase.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IItemRendererParent.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/DataContainerBase.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/html/DataContainer.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/html/List.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/html/ButtonBar.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IBeadModel.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IRollOverModel.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IDataProviderModel.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/ISelectionModel.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/html/beads/models/SingleSelectionCollectionViewModel.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IDataGridModel.js
[mxmlc] C:/Program Files 

Re: [DISCUSS] Explanation of the changes

[Harbs]

I’m glad to hear it. There is a lot of text in your email, and I need the time 
to read it properly and address the points. I hope to do that tomorrow. I think 
there is still some unclarity on some of the points (both ways).

I’m glad the discussion is back on track. I would like to just say that I (and 
I think others) have really been trying to understand the motivation the whole 
time. We have been trying to clarify the technical motivations (for and 
against) and getting to the point where we all understand each other. The 
perceived tone might be different, but I’m not projecting anything different 
than what I meant to project the entire time. I am taking more care with my 
words and I’m making every attempt to use Greg’s rule about not using pronouns. 
It seems to be working well… ;-)

More tomorrow.

Best,
Harbs

> On May 13, 2018, at 10:02 PM, Carlos Rovira  wrote:
> 
> I said about to make a vote thread, since I was not hearing many things in
> favor of my work, but reading your email, Om, and other feedback, I think
> we are moving to a really different scenario. This is more a community
> discussion, with a really different tone, so if you (and others) finally
> doesn't want to vote, for me will be ok. I was only doing since seems what
> all of you demand at that point.

Build failed in Jenkins: royale-asjs_jsonly #792

[apacheroyaleci]

See 


Changes:

[carlosrovira] add more AMF cases to the example. - Add sub typed object to 
typed

--
[...truncated 1.76 MB...]
[mxmlc] org.apache.royale.html.ButtonBar depends on 
org.apache.royale.html.List
[mxmlc] 

 removing require: org.apache.royale.core.IRollOverModel
[mxmlc] 

 removing require: org.apache.royale.core.ISelectionModel
[mxmlc] Dependencies calculated for 'org.apache.royale.html.List'
[mxmlc] org.apache.royale.html.List depends on 
org.apache.royale.html.DataContainer
[mxmlc] 

 removing require: org.apache.royale.core.IDataProviderModel
[mxmlc] 

 removing require: org.apache.royale.core.IListPresentationModel
[mxmlc] 

 removing require: org.apache.royale.html.beads.models.ListPresentationModel
[mxmlc] Dependencies calculated for 'org.apache.royale.html.DataContainer'
[mxmlc] org.apache.royale.html.DataContainer depends on 
org.apache.royale.core.DataContainerBase
[mxmlc] 

 removing require: org.apache.royale.core.DataItemRenderer
[mxmlc] 

 removing require: org.apache.royale.core.IChild
[mxmlc] 

 removing require: org.apache.royale.core.IDataProviderItemRendererMapper
[mxmlc] 

 removing require: org.apache.royale.core.IFactory
[mxmlc] 

 removing require: org.apache.royale.core.IItemRenderer
[mxmlc] 

 removing require: org.apache.royale.core.IItemRendererClassFactory
[mxmlc] 

 removing require: org.apache.royale.core.IListView
[mxmlc] 

 removing require: org.apache.royale.core.ValuesManager
[mxmlc] 

 removing require: org.apache.royale.events.Event
[mxmlc] 

 removing require: org.apache.royale.events.ItemAddedEvent
[mxmlc] 

 removing require: org.apache.royale.events.ItemRemovedEvent
[mxmlc] 

 removing require: org.apache.royale.utils.loadBeadFromValuesManager
[mxmlc] 

 removing require: org.apache.royale.utils.Language
[mxmlc] Dependencies calculated for 

Re: [DISCUSS] Explanation of the changes

[Carlos Rovira]

Hi Harbs,

2018-05-13 10:40 GMT+02:00 Harbs :

> I specifically waited to respond to this until some of the heat cooled
> off. I have no question that there is a bit of a language barrier here and
> both sides are not making themselves completely understood.
>

I could in the previous hours get some information that's important, but I
prefer to not mix things here, so hope to share as I can, so avoiding to
introduce more noise.


>
> I’m a bit disappointed that we’re moving towards a vote before I believe
> we’ve gotten to the bottom of the technical motivations. I was hoping we
> could get to the point where we understand each other and make a vote
> unnecessary.
>
>
I said about to make a vote thread, since I was not hearing many things in
favor of my work, but reading your email, Om, and other feedback, I think
we are moving to a really different scenario. This is more a community
discussion, with a really different tone, so if you (and others) finally
doesn't want to vote, for me will be ok. I was only doing since seems what
all of you demand at that point.


> Let me try and summarize the technical reasons as I see them for and
> against a refactor:
>
> Reasons for the refactor:
> 1. As it stands, referencing Basic brings in all of the Basic CSS. This
> causes a number of issues:
>a. Another component set (i.e. Jewel) needs to override any CSS
> specified in the Basic CSS.
>b. The CSS which is compiled from the Basic CSS adds unnecessary bulk
> to the final application if Basic components are not being used.
>c. Although this point was not clear (to me) from the previous
> discussion, all classes referenced in Basic CSS are actually imported into
> the final application. For example: DateControlsExample does not use
> ButtonBar, but ButtonBar and all related classes are included in the final
> application. By not relying on Basic, these classes are not imported.
>
> 2. Basic and Jewel are separate component sets, and as such should not
> rely on each other. Any part of Basic which Jewel needs is not “basic”, but
> “core” and should be moved to the Core project. Doing so has the following
> benefits:
>a. There’s a clear separation of dependencies.
>b. Someone working on Jewel does not need to be concerned with the
> architecture of Basic.
>
> I’m not aware of any other arguments which are not variations on the
> above. Please correct me if there are more reasons.
>

I think is mostly the technical reasons. I exposed many of the collateral
damages of all of this, but I think is basically the problem. Great to see
finaly I could make it understand :)


>
> Reasons against the refactor:
> 1. Royale favors composition. As such, it was designed so functionality
> can be pieced together. Much of this functionality was created in the Basic
> project and as such, it’s natural for component sets to borrow pieces from
> each other. This reduces code duplication.
>

Right. But IMHO, this should be chosen for user users. If he wants
functionality, he can "optionally" take it, and not "obligated" to.
In the other hand think about functionality that is not exactly the same.
If I have a bead that in Jewel put a className and in Basic the
implementation puts an attribute on the tag. The user will find both with
CTRL+SPACE (code hintting feature), or using a Button will find obligatory
more than a Button, that will comes to confussion. What is the right Bead?
the right control?...If he optionally wants to add functionality, is up to
him to use one or another.


> 2. Moving pieces of Basic to Core does not scale. We need to define what
> Core is, and claiming that something is required by a component set makes
> it Core is not a good definition. For example, Collections is not Core, but
> it is required by component sets. As it stands, Core defines the core
> architecture of a Royale application, but says very little about
> implementation details. That’s why there are lots of interfaces, but not so
> many implementation classes. It’s possible that little bits of Basic might
> make sense to be in Core instead (and vice versa), but I think the general
> difference between Core and Basic is well defined (although possibly not
> well understood).
>

I must say that don't see why moving pieces to Core will not scale. The
pieces are the same, the extensions are the same. There's a change of
location for some classes to get a better decoupling. One thing to notice
is that we are dealing with *final implementations* or *leaf
implementations*: this means the same like when we mark a method in java
like final...this seems we expect a final use. A button, for example, can
be aggregate in a "ButtonWithDisableBead", but this works more like a
"macro" than an extension. So AFAICT, subclass other's UI Set controls or
beads, seems to be not desirable in a huge percentage of cases, at least in
my experience with MDL and Jewel (and I think that's a huge experience).
MDL was done subclassing, 

Re: [DISCUSS] Explanation of the changes

[Carlos Rovira]

Hi Om,

2018-05-13 9:11 GMT+02:00 OmPrakash Muppirala :

> It took a while for me to catch up on the series of threads on this topic.
> From what I see, on a high level, https://snag.gy/KW36yn.jpg seems to be a
> better setup than https://snag.gy/JqO2ZI.jpg.  That is , Jewel must extend
> from Core and not extend Basic.
>
> Ideally we would follow these sets of principles:
>
> 1.  Backwards compatibility is important.
> Even though Royale is very early in its development cycle, there are apps
> using Royale in the wild.  If Basic component set is refactored, the
> expectation should be that current apps should not break.  There is a
> reason we use Semver.  An upgrade from 0.9.2 to 0.9.3 should NOT break
> existing contracts and APIs.
>
>
That's essential, and for this reason I put many hours to get Basic doesn't
be affected since in that case the problem would be huge and clearly not an
option. If I change for example how Basic Button works, that would be
unacceptable. The only thing that really caused problems was that some
classes changed package, and this means update imports in every application
using that classes. I thought that is acceptable if we want to better
organize APIs. I said previously that seems confusing to have core packages
in Basic and html packages in Core. For me even now, after refactor, the
package structure seems confusing. But for me this part is not essential at
all, since is something we can live on. Although I think people here should
be predisposed to this "package location changes" in our path to 1.0. After
1.0, I consider we can't do this, so this should be something very
convenient to schedule.



> 2.  Royale should be more flexible.
> I understand the strong viewpoints some folks have about Royale.  But what
> good is an SDK with which we cannot easily build component sets.  Carlos
> has been involved in building two completely different component sets (MDL,
> Jewel) along with other things.  If he is raising concerns about the
> framework, we all need to listen to him.  It doesn't matter if no one else
> agrees with him.  I think he has earned enough credit here to voice his
> opinion however unpopular it may be.
>
>
That's essentially the issue. I'm doing a work that almost no others do, so
one thing is theory and other put in practice. The later is failing in some
points since the beginning and should be more easy for me or for others to
address the issues without making such noise.


> 3.  DRY is not that important.
> Again, given where we are with Royale's maturity, we must expect more of
> such complex changes.  Insisting that we always need to be DRY leads to
> more rigidity while building up the SDK.  Let folks like Carlos who are
> trying out new things some leeway.  Once the main goal is achieved we can
> go back and figure out the best way to keep things DRY.
>

I think what's important is PAYG. I as well think that I'm supporting DRY
since if I copy a file is since I want to modify it, or is an
implementation of a Core functionality (is the same that "Application"
class in all UI Set libraries. But what we can extract from Om point is far
more important that the actual case: At this point we have a real good
foundation, but we need to get it as real and usable as possible, or will
have the less used better technology in the world. If we put so many
brakes, we are making people abandoning and going Angular (for example).
There's lots of things to improve in Royale, and we can't loose the time in
some particular thing, if people working does his work right and is careful
in no breaking things. If that's not the case, instead of a solution is a
problem.

Thanks for you thought Om, very appreciate.

Carlos



>
> Thanks,
> Om
>
>
>
> On Sat, May 12, 2018 at 1:09 AM, Carlos Rovira 
> wrote:
>
> > Hi,
> >
> > I'm trying here to explain with more tools the problems we had until now
> > and the solution I did he past Friday.
> >
> > Disclaimer: This solution doesn't intend to end in the current state, and
> > we can evolve to get other shape more convenient for others in this
> > project. I'm sure Alex or Harbs can add up to enhance what I did greatly
> as
> > always do.
> >
> > So let's go:
> >
> > Until now we had this kind of relation between libraries :
> >
> > https://snag.gy/JqO2ZI.jpg
> >
> > In this schema. Basic is needed always to construct an Application. That
> > causes that all applications will end aggregating the used styles of the
> > CSS in basic and all the classes that are linked in that way plus the
> tree
> > of dependent classes.
> >
> > Until now that wasn't a problem, since we didn't care of it. That extra
> > size all applications incorporated was not in out target since we only
> had
> > Basic to construct applications. A side case was MDL but as is a
> "wrapper"
> > around an external library, again we didn't care too much about this.
> >
> > Now with the new Jewel UI set, we have another UI 

Build failed in Jenkins: royale-asjs_jsonly #791

[apacheroyaleci]

See 


--
[...truncated 1.77 MB...]
[mxmlc] org.apache.royale.html.ButtonBar depends on 
org.apache.royale.html.List
[mxmlc] 

 removing require: org.apache.royale.core.IRollOverModel
[mxmlc] 

 removing require: org.apache.royale.core.ISelectionModel
[mxmlc] Dependencies calculated for 'org.apache.royale.html.List'
[mxmlc] org.apache.royale.html.List depends on 
org.apache.royale.html.DataContainer
[mxmlc] 

 removing require: org.apache.royale.core.IDataProviderModel
[mxmlc] 

 removing require: org.apache.royale.core.IListPresentationModel
[mxmlc] 

 removing require: org.apache.royale.html.beads.models.ListPresentationModel
[mxmlc] Dependencies calculated for 'org.apache.royale.html.DataContainer'
[mxmlc] org.apache.royale.html.DataContainer depends on 
org.apache.royale.core.DataContainerBase
[mxmlc] 

 removing require: org.apache.royale.core.DataItemRenderer
[mxmlc] 

 removing require: org.apache.royale.core.IChild
[mxmlc] 

 removing require: org.apache.royale.core.IDataProviderItemRendererMapper
[mxmlc] 

 removing require: org.apache.royale.core.IFactory
[mxmlc] 

 removing require: org.apache.royale.core.IItemRenderer
[mxmlc] 

 removing require: org.apache.royale.core.IItemRendererClassFactory
[mxmlc] 

 removing require: org.apache.royale.core.IListView
[mxmlc] 

 removing require: org.apache.royale.core.ValuesManager
[mxmlc] 

 removing require: org.apache.royale.events.Event
[mxmlc] 

 removing require: org.apache.royale.events.ItemAddedEvent
[mxmlc] 

 removing require: org.apache.royale.events.ItemRemovedEvent
[mxmlc] 

 removing require: org.apache.royale.utils.loadBeadFromValuesManager
[mxmlc] 

 removing require: org.apache.royale.utils.Language
[mxmlc] Dependencies calculated for 
'org.apache.royale.core.DataContainerBase'
[mxmlc] org.apache.royale.core.DataContainerBase depends on 

Re: [DISCUSS] Explanation of the changes

[Harbs]

I specifically waited to respond to this until some of the heat cooled off. I 
have no question that there is a bit of a language barrier here and both sides 
are not making themselves completely understood.

I’m a bit disappointed that we’re moving towards a vote before I believe we’ve 
gotten to the bottom of the technical motivations. I was hoping we could get to 
the point where we understand each other and make a vote unnecessary.

Let me try and summarize the technical reasons as I see them for and against a 
refactor:

Reasons for the refactor:
1. As it stands, referencing Basic brings in all of the Basic CSS. This causes 
a number of issues:
   a. Another component set (i.e. Jewel) needs to override any CSS specified in 
the Basic CSS.
   b. The CSS which is compiled from the Basic CSS adds unnecessary bulk to the 
final application if Basic components are not being used.
   c. Although this point was not clear (to me) from the previous discussion, 
all classes referenced in Basic CSS are actually imported into the final 
application. For example: DateControlsExample does not use ButtonBar, but 
ButtonBar and all related classes are included in the final application. By not 
relying on Basic, these classes are not imported.

2. Basic and Jewel are separate component sets, and as such should not rely on 
each other. Any part of Basic which Jewel needs is not “basic”, but “core” and 
should be moved to the Core project. Doing so has the following benefits:
   a. There’s a clear separation of dependencies.
   b. Someone working on Jewel does not need to be concerned with the 
architecture of Basic.

I’m not aware of any other arguments which are not variations on the above. 
Please correct me if there are more reasons.

Reasons against the refactor:
1. Royale favors composition. As such, it was designed so functionality can be 
pieced together. Much of this functionality was created in the Basic project 
and as such, it’s natural for component sets to borrow pieces from each other. 
This reduces code duplication.
2. Moving pieces of Basic to Core does not scale. We need to define what Core 
is, and claiming that something is required by a component set makes it Core is 
not a good definition. For example, Collections is not Core, but it is required 
by component sets. As it stands, Core defines the core architecture of a Royale 
application, but says very little about implementation details. That’s why 
there are lots of interfaces, but not so many implementation classes. It’s 
possible that little bits of Basic might make sense to be in Core instead (and 
vice versa), but I think the general difference between Core and Basic is well 
defined (although possibly not well understood).
3. Not every class in Basic *can* be moved to Core. For example, 
DataItemRendererFactoryForArrayList has a dependency on Collections. Core was 
designed to have no dependencies on any other projects other than Language, so 
that class cannot belong to Core. I would imagine that other component sets 
other than Basic might need ItemRendererFactories.


Possibly the strongest argument against the refactor is that I believe the 
refactor doesn’t actually solve the problems it’s meant to solve. Please allow 
me to explain:

1b and 1c are actually bugs. I’m glad Carlos brought them to light, because 
they need to be fixed. These problems have nothing to do with the fact that one 
component set relies on another. Even if a single component set is used, all 
the css and classes mentioned in the css file are imported. That should not 
happen. If the compiler does a better job of only using the css and classes 
where are *actually* used, these two issue go away.

I think the refactor really masks 1a and does not solve that one either. 
There’s actually a fourth problem related to CSS. What happens if a single app 
uses a Basic Button, an MDL Button and a Jewel Button? (As to why that might 
happen — components can be used within other components and not all component 
sets might be as complete as others.) What will each of the buttons look like? 
As it stands the typenames will conflict with each other and the CSS will step 
on each other. I’m not even sure which CSS will win. It seems to me that 
typenames really should be qualified to prevent namespace conflicts. I’m not 
sure how to best solve this, but I think it deserves discussion.

As far as 2a and 2b go: Here’s my thoughts: I don’t see 2a as a goal for 
Royale. I think functionality sharing across component sets is an advantage to 
Royale and not an architectural problem. Regarding 2b: complete separation from 
Basic seems to me like it only helps splinter the community and puts everyone 
into their own little isolated corner. As difficult as it might be to deal with 
others’ opinions and it causes things to drag on longer than it otherwise 
might, I think it’s ultimately the better path. I really do recognize the 
frustration of trying to do something and have the brakes 

Re: [DISCUSS] Explanation of the changes

[OmPrakash Muppirala]

It took a while for me to catch up on the series of threads on this topic.
>From what I see, on a high level, https://snag.gy/KW36yn.jpg seems to be a
better setup than https://snag.gy/JqO2ZI.jpg.  That is , Jewel must extend
from Core and not extend Basic.

Ideally we would follow these sets of principles:

1.  Backwards compatibility is important.
Even though Royale is very early in its development cycle, there are apps
using Royale in the wild.  If Basic component set is refactored, the
expectation should be that current apps should not break.  There is a
reason we use Semver.  An upgrade from 0.9.2 to 0.9.3 should NOT break
existing contracts and APIs.

2.  Royale should be more flexible.
I understand the strong viewpoints some folks have about Royale.  But what
good is an SDK with which we cannot easily build component sets.  Carlos
has been involved in building two completely different component sets (MDL,
Jewel) along with other things.  If he is raising concerns about the
framework, we all need to listen to him.  It doesn't matter if no one else
agrees with him.  I think he has earned enough credit here to voice his
opinion however unpopular it may be.

3.  DRY is not that important.
Again, given where we are with Royale's maturity, we must expect more of
such complex changes.  Insisting that we always need to be DRY leads to
more rigidity while building up the SDK.  Let folks like Carlos who are
trying out new things some leeway.  Once the main goal is achieved we can
go back and figure out the best way to keep things DRY.

Thanks,
Om



On Sat, May 12, 2018 at 1:09 AM, Carlos Rovira 
wrote:

> Hi,
>
> I'm trying here to explain with more tools the problems we had until now
> and the solution I did he past Friday.
>
> Disclaimer: This solution doesn't intend to end in the current state, and
> we can evolve to get other shape more convenient for others in this
> project. I'm sure Alex or Harbs can add up to enhance what I did greatly as
> always do.
>
> So let's go:
>
> Until now we had this kind of relation between libraries :
>
> https://snag.gy/JqO2ZI.jpg
>
> In this schema. Basic is needed always to construct an Application. That
> causes that all applications will end aggregating the used styles of the
> CSS in basic and all the classes that are linked in that way plus the tree
> of dependent classes.
>
> Until now that wasn't a problem, since we didn't care of it. That extra
> size all applications incorporated was not in out target since we only had
> Basic to construct applications. A side case was MDL but as is a "wrapper"
> around an external library, again we didn't care too much about this.
>
> Now with the new Jewel UI set, we have another UI set that although is
> based in the work in Basic is a first citizen, so for example, a Button in
> Jewel extends UIBase and not basic Button like before. So changes in Button
> or in other Basic infrastructure classes not affect Jewel at all. So
> final/leaf components are dependent of UIBase (in Core) and not anything we
> have in Basic. The same happens with Jewel TextInput, Jewel Slider, and
> more.
> For example Jewel Slider is based on input range, while Basic Slider is
> build with two buttons. So even ISlider interfaces are different in Basic
> than in Jewel.
> So key point here: final implementations should not depend one from another
> since any changes in the code of the parent will affect the children.
>
> As you can see in the schema, we have various libraries that are top level,
> some of them are optional, and for this reason are separated in library
> units (Network, Binding, Collections, and more), but Core is not optional,
> must be in all Royale Applications.
>
> Basic until now although it was a concrete final implementation of an UI
> set, was in fact needed in all Royale Applications, and that cause that
> always its CSS and its classes was baked into the final App. Only if you
> don't use visual elements you'll get rid of basic need, but that in a front
> end app is very strange right?
>
> This design caused from the begging lots of problems that started to rise
> when I first started MDL library. We have styles and behaviours that was
> not required due to the presence of unwanted CSS and classes from Basic.
>
> So for this reason a key point is that we need to bake into final app the
> resources we really need to avoid unwanted content that is not required and
> only increases size and the presence of potential bugs and not wanted
> behaviors.
>
> With the refactor we get to the following graph
>
> https://snag.gy/KW36yn.jpg
>
> Now in the final picture, we don't have the presence of all the things that
> comes with Basic when we create a Jewel application, the final developer
> don't need to be worried of any unwanted behavior that comes from Basic
> since Jewel no more requies it.
>
> But this is completely compatible with the older scenarios. People using
> Basic,