In that point I'm feeling that Even if couple of PMC members or committers have some resistance, changes are being done no matter what. I'm starting to be a bit farther from the project because of that. Really valid points in Alex's response.
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. > > 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, "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 > > > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
