Hi Piotr, for further changes of this kind I'll be commenting first for sure. But I think the problem is that will be many discussion for nothing, since I'm seeing a problem changing things at 0.9.2, only because an Application that was build in 0.8 is being broken. I remember Jumbo (Flex4 days), where we was working with alpha sdk and by the time Flex4 comes with all the API fixed, people had to move their code bases to comply with the release version.
We at this group seems to stick with things done 2-3 years ago, and that's for me what makes me feel bad, since I'm investing lots of time to get this kind of response. 2018-05-10 8:08 GMT+02:00 Piotr Zarzycki <[email protected]>: > 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 <[email protected]>: > > > 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%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>* > -- Carlos Rovira http://about.me/carlosrovira
