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.
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. 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? 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. 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. 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. 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, "[email protected] on behalf of Carlos Rovira" <[email protected] on behalf of [email protected]> 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 <[email protected]>: > 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 <[email protected]> > wrote: > > > Hi Piotr, > > > > 2018-05-09 16:48 GMT+02:00 Piotr Zarzycki <[email protected]>: > > > > > 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 <[email protected]>: > > > > > > > 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%7Ca5e727047b424eccb1ca08d5b5d0272d%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%7Cfa7b1b5a7b34438794aed2c178decee1%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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636614828117263788&sdata=irtWJQuvaU0QCtKjQgGYPmcAjx%2FxuVQPgnWOBSTzWn8%3D&reserved=0
