Hi Alex, 2018-05-10 1:19 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>:
> Hi Carlos, > > IMO, you are getting resistance from other committers because you are > recommending changes that don't have sufficient technical merit. What is > the technical advantage to the Jewel project not having a dependency on the > Basic project? I continue to think you are too fixated on project > dependencies when the only thing that matters is class dependencies. Get > the class dependencies right and don't worry about project dependencies. > It is pretty rare that copying code is a recommended practice, especially > for Royale where we are trying to use composition. Also, you are > recommending copying "just-in-case" a Jewel class diverges from a Basic > class. In Royale, those divergences should be managed via composition, > refactoring, and subclassing, and not copying, and only when divergence is > actually required, not just-in-case. > Through this thread I exposed lots of technical advantages. I think I should not express once again all said, but from what I read I see some things that I said are not truth. I copied some classes, not to left *as is*, there's changes that was made, or are on the way. In other way I don't say any "just-in-case" in Jewel, just the opposite, I want to separate from Basic since that dependency, brings more code to the mixture and is not needed, so I think is just the opposite to "just-in-case" here. Jewel is like Basic in terms of design, all based on composition, beads, and strands. and simply since it is a UI library, should not depend on another UI library that does exactly the same. The whys, where explained all through this thread as I said. > > I don't have any problem with changing package names of some classes at > this point in time, but we still want the organization of the libraries to > make sense. So if you put Group in the Core library regardless of which > package it is in, you are saying that just about every implementation of a > random group of child objects will want to just the implementation in > Group.as. I'm not sure that's true, and that kind of thing deserves > discussion before it happens. Just because some other project wants to use > a class that is currently in Basic does not mean that class should be in > Core. > I think one of my errors was change some classes not from library, but from package, that made some confusion, but did it due that we still have many few users, and this changes should be very easy to apply as I experiment with examples. This make me think that Harbs or Piotr, like the things are settled and instead of going forward and make some little adaptation in their code, prefer to go back. I think that's not the solution for a project in 0.9 that clearly needs still to handle some problems as you guys are discussing in nexts emails. > > On the other hand, I don't agree with Yishay's and Harb's concerns about > the NodeElementBase having to subclass Group in order to get MXML > children. The ability to specify children in MXML can be added to any > class. What else does NodeElementBase.as use from Group/GroupBase? > For what I see, have a GroupBase and Group doesn't make to much, since as Harbs will explain in following emails states and nesting are all needed. So maybe the solution is to have a class in core that serves Group and will serve HTML components. > > I also want to remind folks that all of the classes that are in Basic but > in the org.apache.royale.core package used to be in the Core project before > we had to fork them for the element-wrapping experiment. So, IMO, it is > fine to move every class from Basic that is in org.apache.royale.core back > to Core if we still agree that almost every implementation will leverage > that contract or functionality. But Group isn't one of those classes. > Should it be? I don't have a set opinion right now, but I'm leaning > towards no. Group has a particular opinion about its lifecycle. We'd have > to agree that it would be rare for someone to not want that lifecycle. > That's what I saw while refactoring. I think we have things not settle correctly at 100%, since as I said we have "core" packages in Basic, and "html" packages in Core, what seems those two libraries are crossing things and hence the difficult to make other code not depend on Basic. > > Another thing to note is that some aspects of what is in GroupBase is due > to trying to save time by avoiding making changes to the compiler's > handling of states and transitions. > Right, but as states are very close to mxml, maybe GroupBase should fusion to Group, or even better, extract that code to a class and make Group use it and HTML too. > > We could stop and do a major refactor/reorganization. I'd rather not > spend the time on that right now, but I'd also rather not spend the time > dealing with confusion and disagreement over what goes in what > project/library. I think due to how this is affecting to this project is critical to spend time on this to solve now all the problems. I think this is now priority one over the rest of things. I can't continue investing time with Jewel, and making blog post, and moving social networks, pushing code and things if people are disagreeing with things I'm doing, but for me that things are critical. So My opinion is that we need to get both of both worlds. Maybe put in place what any one expect from a refactor and then go with it. > Just because we reference libraries like Collections and Network from > other libraries as fundamental building blocks does not make them Core, > just "shared" or "reused". I hesitate to use the word "common" because too > many things fall under that word. Collections and Network are just an > implementation tuned towards Flex-familiar users. It is not clear that > every Royale app will need or want to use their code. > Thanks, > -Alex > > On 5/9/18, 10:13 AM, "carlos.rov...@gmail.com on behalf of Carlos > Rovira" <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> > wrote: > > Now, all that makes more sense... > > So is ANT what is failing, but that should not be that way, since > there's > no changes to interdependencies of libraries. If ANT was working > before now > should work as well. If not I think is time to get what could be wrong > in > ANT building. I could remove some Basic dependencies in Maven and saw > that > by removing Group dependency from NodeBaseElement, some other projects > need > Basic. I think that's what you should look at. Add Basic to those > projects > that was getting the code due to HTML Basic dependency. > > What we have here is not a problem of a refactor, but a hidden problem > in > the way we build with ANT. > > Or at least is what I see for what Piotr says in his email. I don't > have > ANT setting up in my system, and I always build with maven to ensure > all is > working. > > Carlos > > > 2018-05-09 18:58 GMT+02:00 Piotr Zarzycki <piotrzarzyck...@gmail.com>: > > > We are building by ant IDE packages. This is what is failing. It's > failing > > for several days already. > > > > On Wed, May 9, 2018, 6:32 PM Carlos Rovira <carlosrov...@apache.org> > > wrote: > > > > > Hi Piotr, > > > > > > 2018-05-09 16:48 GMT+02:00 Piotr Zarzycki < > piotrzarzyck...@gmail.com>: > > > > > > > Carlos, > > > > > > > > From all of discussion I see only one advantage splitting Jewel > from > > > Basic. > > > > Results in size of package. That's why I'm asking about copied > classes. > > > It > > > > looks like we will have many copies of everything. If I create > useful > > > Bead > > > > and you need it you will copy it. > > > > > > > > > > just explain a bit more in my response to Yishay email few seconds > ago, > > > you'll see is not only about size > > > Thre's much more involved. > > > > > > > > > > > > > > After all you did the changes, so discussion is closed. > > > > > > > > It will be good if you could look into the failing build after > those > > > > changes if they were the cause. > > > > > > > > > > I'm watching closely that builds doesn't break. Seems right now > the build > > > is broke, but just the previous one was successful and there's not > code > > > changes between, so I suppose is something not related to the > code. I > > > always pass maven to all framework and examples when something that > > implies > > > moving classes or changing names or packages are in place, > ensuring that > > > all compiles without problems. > > > > > > > > > > In my opinion if we reach 1.0 some day - Every changes in Core > should > > be > > > > voted or waited till review on separate branch. > > > > > > > > > > That's completely right. 1.0 means a before and after. We are > working > > hard > > > to make all things assemble nicely and work flawlessly. And as we > think > > we > > > get that point, for me will be the right moment to make a 1.0 > release. > > And > > > that means that any change should be more difficult to do, and > will need > > > more consensus. Anyway, in that case, that would means for all of > us the > > > same that is happen now. Changes use to imply that applications > should > > > update to work accordingly to those ones. But in our case the > changes are > > > very easy to do. Think in Java, and how difficult is change from > Java 5 > > > -6-7-8... or Spring Framework... it's very very difficult compared > to a > > few > > > changes here. But our code is still beta quality, and we can > expect to > > stay > > > without change a single line of code, and expect our user base > grows. > > > That's utopic from all points of view. > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > Thanks, > > > > Piotr > > > > > > > > > > > > 2018-05-09 16:37 GMT+02:00 yishayw <yishayj...@hotmail.com>: > > > > > > > > > Hi Carlos, > > > > > > > > > > Just to get one thing out of the way, I changed > NodeElementBase to > > > extend > > > > > Group, not because I'm sure that's the way it should be > permanently, > > > but > > > > > because leaving your change as it was, was breaking our app > which had > > > > > previously worked. > > > > > > > > > > Changes in base classes are always tricky, so I think it's a > good > > thing > > > > > that > > > > > there's discussion and people feel obliged to voice their > opinions > > and > > > > ask > > > > > questions. I think this should be encouraged. > > > > > > > > > > Personally, I don't feel I have a clear understanding of your > > > motivation > > > > > here. What difference does it actually make to you which > packages > > > depend > > > > on > > > > > which? Can you give a specific example from Jewel where this > makes a > > > > > difference? > > > > > > > > > > Excellent progress so far with Jewel, I think it's a difference > > maker. > > > > > > > > > > Yishay > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Sent from: https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fapache-royale-development.20373.n8.nabble. > com%2F&data=02%7C01%7Caharui%40adobe.com%7Ca5e727047b424eccb1ca08d5b5d0 > 272d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > 7C636614828117263788&sdata=4euFIkXDFIkYiC2DGVYnxRasucY7g% > 2FqOLO8hJrRvvkg%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Piotr Zarzycki > > > > > > > > Patreon: *https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01% > 7Caharui%40adobe.com%7Ca5e727047b424eccb1ca08d5b5d0272d% > 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636614828117263788&sdata= > O1XtCyx91E7xAAlyPkwbldTzuVIAtEmvHbVPxfvE84A%3D&reserved=0 > > > > <https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01% > 7Caharui%40adobe.com%7Ca5e727047b424eccb1ca08d5b5d0272d% > 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636614828117263788&sdata= > O1XtCyx91E7xAAlyPkwbldTzuVIAtEmvHbVPxfvE84A%3D&reserved=0>* > > > > > > > > > > > > > > > > -- > > > Carlos Rovira > > > https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > 7Ca5e727047b424eccb1ca08d5b5d0272d%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636614828117263788&sdata=irtWJQuvaU0QCtKjQgGYPmcAjx% > 2FxuVQPgnWOBSTzWn8%3D&reserved=0 > > > > > > > > > -- > Carlos Rovira > https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > 7Ca5e727047b424eccb1ca08d5b5d0272d%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636614828117263788&sdata=irtWJQuvaU0QCtKjQgGYPmcAjx% > 2FxuVQPgnWOBSTzWn8%3D&reserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira
