Hi Carlos, I’d like to be clear about one thing:
I have had my app break *many* times while we’ve been developing Royale and changing things. That’s OK. That’s part of the cost of working on the bleeding edge. I’m fine adjusting things to invest in improving our framework. I only have trouble if the changes are not warranted. I’m not convinced that these changes were warranted. We also agreed about a half a year ago that all breaking changes should be done in a feature branch. That’s something we’ve been pretty good at in general lately. We all agree that it was a mistake to make these changes on the develop branch, but mistakes happen and and let’s work with that. Instead of pointing fingers, let’s try to focus on the technical reasons for refactoring and figuring out how and where refactoring should be done (if at all). If a refactor breaks my app(s), I’ll deal with it. But, let’s please first come to an agreement on what is best to do on technical merit. I’m making an effort to be quiet now to get input from others. I think I’ve already said pretty much what I’ve had to say. If you want my response on specific points, please let me know and I’ll respond to them. Thanks, Harbs > On May 10, 2018, at 9:01 PM, Carlos Rovira <carlosrov...@apache.org> wrote: > > Hi Alex, > > 2018-05-10 18:50 GMT+02:00 Alex Harui <aha...@adobe.com.invalid > <mailto:aha...@adobe.com.invalid>>: > >> Wow! Good thing I slept through this... >> >> Let's try to calm things down a bit. I think we have agreement that this >> work should have been handled differently, but I really think this >> disagreement, like many disagreements is being escalated by poor >> communication. Sometimes it is hard to realize that you haven't really >> explained yourself well. You know the problem so well, and are probably >> trying to write a shorter email and/or have limited time to write, but it >> makes things worse instead of better. >> > > I don't really think communication was bad. I'm in this project and FlexJS > form its beginning and I think I follow it always and I think my thinking > about what is basic was right. My opinion about this refactor, is that > maybe I did huge commit and for such commit I should be done some > emailing, but other time we all commit without asking, so while it would be > better, really I didn't do nothing bad, but maybe wanting to make this > project advance as fast as possible. > > Then as a refactor like this suppose changes in applications that use the > framework, Harbs instead of think in the positive thing of remove > dependencies between libraries, was worried about his application not > compiling. And here we are 86 emails asserting that we are not > understanding right the essence of Core and Basic. And what I think is that > team mates here instead of work for continue moving things to make this > project progress are trying to divert the attention talking about > philosophical point of view, and I think the refactor gets technical things > done clearly (separation and less size), while the philosophical seems more > to me in stay in what we had and not wanting to move due to applications > breaking. I'll understand that position with a framework more finished, but > in a 0.9.3 version, I think we have room, and we discussed a lot of this in > the past weeks, but I think many of the people not agreeing was the same > that didn't follow that discussion and now they think all this is wrong, > again due to personal interests. > > As I did the refactor I was very close to the email to see if something was > broken, since although maven was ok in all aspect, I though something more > could be happen, and as you all see I was hard working to fix things as > people let me know. But what I think is a bad practice in a project is > talking about revert unilaterally a huge work that had many hours behind, > since I'll never dare to propose something like this. Moreover when we all > can have all the things we want at the same time. Or I don't see any > overlapping interest here. > > > >> >> So, couple of things to consider (actually more than a couple of things): >> >> -I still think we are missing a clear, detailed, technical analysis of the >> claim of less code linked in by not having a dependency on Basic. For >> sure, if you subclass a Basic component, you will get many more things >> linked in, but I hope that using a bead from Basic does not result in lots >> of additional unused classes. If it does, that is probably worth fixing. >> Carlos, since this is your claim, please provide the data. Include a bead >> from Basic and tell us what additional classes were added. >> > > Alex, I didn't say that a bead from Basic will link additional classes, > what I say is that linking Basic was inserting 40% of more size, while apps > work the same. Let me first ask about what's the point on doing this? I > have clear that Jewel doesn't need to depend on Basic since cover the same > things, since for me both are UI sets, only that Basic was the library more > developed since until now was the focus. For me what Harbs call "building > blocks" are what a UI Set needs to have. > > >> >> -With composition, a tree/hierarchy of classes becomes much less >> important. You should be able to mix and match beads from different SWCs >> if they conform to expected interface contracts. Those >> contracts/interfaces, and a few base implementations of those contracts are >> what is supposed to go in Core (and in the ".core." package. But the beads >> can go where it organizationally makes sense and it does not make a bead >> "Core" by having some other SWC us it. Basic beads are supposedly the >> simplest versions that work cross-platform. >> > > for example in Basic a concrete bead can add an attribute to a Basic > Component. In Jewel the same bead can solve the problem adding a class to > the positioner. For that reason, normaly Jewel needs its own ecosystem. I > already worked many weeks (and before many months when creating MDL) and > have the experience that others doesn't have here to know the problems I > found, and remember that we discussed some weeks ago about if Jewel will be > better subclassing UIBase instead its counter part control or component in > Basic, and then my conclusion in that thread was that it was better to > subclass UIBase. > > Antoher thing is that I don't want a future change in a control in Basic > could introduce a bad behavior in Jewel. For this reason I think the basic > building block or Core is UIBase. > > > >> >> -If you need to extend a bead, subclassing or utility functions are >> preferred in order to reduce maintenance overhead of having copies of code. >> > > I subías core things (like GroupView that before was in Basic) or > implemente core interfaces (IBeadView), I think that's core, but I don't > believe in subclass final functionality (control, component, bead or > whatever) since as final implementations, can change over time and break > Jewel functionality. For me that's not a good practice. > > >> >> -I still think we are missing a clear, detailed, example of a Jewel bead >> that is a different implementation of a Basic bead that required copying >> code from the Basic bead. >> >> > As UI Sets are siblings and they are not related anymore, If I start > copying a code from Basic to start, I think is the good way to go although > finaly the class remains with the same code. Think that Jewel would never > link Basic, so there's no other way to have that functionality than create > is own. > > >> -A good teammate tries to maximize his/her positive impact on the rest of >> the team, and minimize the negative impact, and cares less about personal >> goals. >> > > That was my code of conduct until I saw people in this team with the > opinion that they can dictate the things to do and revert a complete work. > Or talk about that I should move from the project and fork it. Just when I > think this year I'm donating all my time to this project while the people > proposing that are only appearing from time to time. I never saw that in > any other project and I think we are repeating things of the past we other > now gone mates. So maybe we should think about why people abandone this > project or we want ro remove them. If I'm a bit upset I think I have > complete valid reasons. > So in the first emails of this thread, I was working hard to understand > problems arise, and working hard to solve them. But what I see is people > not only not helping to fix builds or fix the points that could be having > problems, but discussing if my way of thinking about the new Jewel UI Set > is right or wrong, while I only want to isolate from other libraries. Those > people should not opposite that and only left Royale can do that since is > beneficial to the project and since from now on, we will see less problems > with shared resources (another thing is if shared resources makes people > discuss many times, maybe should not be shared ) > > >> >> So, let's get some real data, and see if we can reach agreement on the >> semantics of what Core is. Then we can discuss how we'd reorganize the >> SWCs. >> > > Alex, IMHO, I think we should: > > 1.- Fix JSONLY, I don't know why is falling, don't know how I can build > that localy with maven. If you give some clues on this I can work on fix > that. > 2.- With all fixed, we can think more about what goes in Core and what in > Basic. My only point is that Jewel doesn't have to depend on Basic. > > I think we need 1. fixed ASAP, since I think Harbs App maybe depends on > that (don't know if he is using maven build or what, but for what I see he > can not build or maybe is ANT failing, I think we need to catch those > deficiencies in the build since are more important that change classes from > a library to another) ...and then 2. can be do it in a more relaxed way > since all people will have the current build fixed (JSONLY, since the > normal works) > > Thanks > > >> >> Thanks, >> -Alex >> >> >> On 5/10/18, 7:09 AM, "carlos.rov...@gmail.com on behalf of Carlos >> Rovira" <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> >> wrote: >> >> Hi Harbs >> >> 2018-05-10 15:55 GMT+02:00 Harbs <harbs.li...@gmail.com>: >> >>> Carlos, >>> >>> It’s impossible to move the entire Basic (non-components) into Core. >>> Besides the fact that there’s no reason to inflate Core that much, >> there’s >>> many pieces (in beads, renderers, etc.) which rely on things which >> are >>> *not* Core. >>> >>> Core has 0 dependencies on other projects (except Language — I >> think). >>> Many pieces of Basic have dependencies on other pieces such as >> Collections, >>> Binding, Network, etc. >>> >>> Ideally, the library swcs should be as small as possible. You are >>> proposing making Core bigger. I oppose that idea. Basic is quite >> large. I >>> would support an idea of breaking Basic into smaller pieces although >> I have >>> higher priority things on my list personally. >>> >> >> I really prefer to stick like its now and simple fix the JSOnly build. >> I >> think is the fastest thing we can do. I was talking about this since >> you >> propose to break basic in two. and maybe is not needed at least at this >> time. If I continue to work on Jewel and find more things that I need >> from >> Basic (and that should be basic we can talk about that) >> >> >>> >>> When Alex and others have been saying that Basic is just another >> component >>> set, I believe that was just referring to the components in Basic. >> The >>> building blocks in Basic are another story altogether. The vast >> majority of >>> Basic is the building blocks and not the components. If folks like >> the idea >>> of moving the Basic components into their own swc, that’s something >> I’d >>> support. Moving building blocks into Core to prevent dependencies is >> *not* >>> something I support. Your refactor is by no means comprehensive and >> I don’t >>> want to go down the path of making it so. >>> >> >> but not doing so will left the Jewel project again with the same >> problems, >> just because you have a philosophical point of view. Since in this >> concrete >> point, mine is technical in its totality. >> >> >>> >>> You also changed package names and that deserves a separate >> discussion. If >>> changing the package names makes things clearer, I’d support that. >> I’m not >>> sure that it does. Besides moving things from html to core, you >> removed >>> beads from package names. Many pieces still have the html path and >> there’s >>> currently no consistency that I can see. >>> >> >> package names can be reverted, I think that's not completely needed. I >> did >> to avoid the actual mess of "core" and "html" packages around Basic and >> Core. My opinion is that Core should have only "core" package and Basic >> should have only "basic" (and not "core" nor "html") >> But this is not critical for me, and I can live with it, but this rise >> one >> clear thing, that if the build works, you only need to change you >> Application in a few places where the package changed. And that should >> be >> possible so Royale has a better organization of packages. >> >> >> >>> >>> My $0.02, >>> Harbs >>>> On May 10, 2018, at 4:33 PM, Carlos Rovira < >> carlosrov...@apache.org> >>> wrote: >>>> >>>> 2018-05-10 14:30 GMT+02:00 Harbs <harbs.li...@gmail.com <mailto: >>> harbs.li...@gmail.com>>: >>>> >>>>> Top posting to make it easier on the eyes: >>>>> >>>>>> For me 3,5,7 are not something about "philosophy", are pure >> technical >>>>>> structuration of code. If you want to left as is, is because >> you're >>>>> talking >>>>>> from an Application ser not from an archictecture point of view >> or with >>>>> the >>>>>> team member hat. >>>>> >>>>> Maybe philosophical was not the best word, but my point remains. >> Your >>>>> arguments are centered around the fact that you believe Basic to >> be a >>>>> component set similar to Jewel. Others have been disagreeing with >> this >>>>> point of view. >>>>> >>>>> I have been working on the assumption that Core is really >> bare-bones >>>>> functionality which is not directly related to any specific way of >>>>> implementing anything. >>>>> >>>> >>>> Until now the concept was that Basic was an UI set, and for that >> reason >>>> HTML was separated, since was the set of html tags like span, >> h1-h6, div. >>>> So Core and Basic words in your understanding wants to refer to >> the same >>>> and if what you want to left in Basic is not UI components, then >> that >>> seems >>>> to be Core classes that in fact other sets like Jewel could need, >> so as I >>>> said, I think is better to have one single Core library for all >> that is >>>> core or basic (in the means of core) >>>> >>>> >>>>> >>>>> Basic is “core” in the same way that DataBinding, Network >> Collection, >>> etc. >>>>> is “core”. The assumption is that almost all applications - no >> matter >>> which >>>>> component set is being used will require Basic. To me, Basic means >>> “basic >>>>> functionality” and not “basic components”. Maybe it was a mistake >> to >>> have >>>>> Basic include Components at all because that’s what seems to be >> causing >>> the >>>>> disconnect here. I don’t think it’s practical or desirable to >> move all >>> the >>>>> “core” pieces of Basic to Core. >>>>> >>>> >>>> notice that "basic functionality" can be easily think about it as >> "core >>>> functionality", I think we are talking about the same. >>>> >>>> >>>> >>>>> >>>>>>> #2 AFAICT includes #4. As I mentioned the fact that there can be >>>>>>> conflicting typenames is a problem. Removing Basic as a >> dependency >>> will >>>>> not >>>>>>> solve that problem because clients can (and likely will) bring >> in >>> Basic >>>>> as >>>>>>> part of their application. >>>>>>> >>>>>> >>>>>> There's much difference in obligation to link a library and >> decision to >>>>>> make part of your solution. We as Royale PMCs should make the >> best for >>>>> not >>>>>> obligate, the user is how could want then to use Jewel, MDL and >> Basic >>> all >>>>>> together. Is up to them. >>>>> >>>>> I’m not sure what you are trying to say here. My point is that an >>>>> application bringing in Basic should not cause Jewel components to >>> break. I >>>>> assume you’d agree with me on that. >>>>> >>>> >>>> I agree that If I link Basic that should not make a difference. >>>> But the point is that not only makes a difference linking things I >> don't >>>> want, but that I'm obligated to link that library, and I shouldn't >> since >>>> right now Basic is more than a Core library is a library that has >> core+ui >>>> components+css, so that is completely wrong by design. >>>> >>>> >>>>> >>>>>>> I really don’t understand your point with #6. Why do application >>>>>>> developers need to think about dependencies? Is it because of >> Maven >>>>>>> dependencies? If so, that seems to be a Maven problem which >> should be >>>>> fixed >>>>>>> there. >>>>>>> >>>>>> >>>>>> Not App developers, We are how need to be careful on this. In >> the same >>>>> way >>>>>> we are pushing hard on PAYG, to avoid mistake of the past like >> 15k >>> lines >>>>>> UIComponent class, We need to always be careful and don't make >> unneeded >>>>>> relations. And Basic -Jewel is totally unneeded. >>>>> >>>>> Well, Basic *was* needed before you made your changes and the >> assumption >>>>> is that it usually *will* be needed because it’s the basic >> building >>> blocks >>>>> of applications. Moving things to Core as component sets need >> them seems >>>>> like a bad thing to do. Why do we need to be careful about >> including >>> Basic? >>>>> This seems more like a philosophical argument than a technical >> one. >>>>> >>>> >>>> I found in my refactor that many examples have Basic dependency >> missing >>> ( I >>>> think that can be mainly the problem with JSONLY build failing), >> that was >>>> due to HTML pulling Basic. That means that the build was a wrong >>>> configuration and as HTML left away its Basic dependency projects >> that >>>> really need Basic was failing, so I added it specifically. So here >>> there's >>>> nothing philosophical, but a problem about structure and >> organizations. >>>> >>>> >>>>> >>>>>>> >>>>>>> Please explain why you think $8 is true. What about the >> refactoring >>> will >>>>>>> reduce the size of applications? >>>>>>> >>>>>> >>>>>> I explained just in a Yshay response. copying the entire email >> response >>>>>> here. But rather to make me repeat or copy I though you read all >> this >>>>>> thread carefully: >>>>> >>>>> OK. So this goes back to the CSS. I thought you were talking >> about code. >>>>> >>>>> I already agreed with you that unnecessary copying of CSS is bad. >> I just >>>>> think it’s something which should be solved in the compiler. Can >> you >>> think >>>>> of a reason why it can’t/shouldn’t be a compiler problem? >>>>> >>>> >>>> As I said in my explanation to Yishay, before the refactor I was >> using >>> the >>>> "building blocks" in Basic, and that was pulling all dependencies, >> so as >>> I >>>> break Jewel dependency, and remove the dependency from Basic >> components >>> and >>>> building blocks so don't know if there's a compiler problem or >> not, but >>>> what I know for sure is that this kind of linkage of unused or not >> needed >>>> libraries with the time makes people mix inheritance chains since >> the >>>> classes are avaialble and then that caused that kind of >> dependencies. So >>>> for me one thing to do to prevent this kind of problems is simply >> not >>> link >>>> the libraries that should not be used >>>> >>>> Thanks >>>> >>>> Carlos >>>> >>>> >>>> >>>>> >>>>> Thanks, >>>>> Harbs >>>>> >>>>>> On May 10, 2018, at 3:02 PM, Carlos Rovira < >> carlosrov...@apache.org >>> <mailto:carlosrov...@apache.org>> >>>>> wrote: >>>>>> >>>>>> 2018-05-10 13:41 GMT+02:00 Harbs <harbs.li...@gmail.com <mailto: >>> harbs.li...@gmail.com> <mailto: >>>>> harbs.li...@gmail.com <mailto:harbs.li...@gmail.com>>>: >>>>>> >>>>>>> Hi Carlos, >>>>>>> >>>>>>> Thank you for summarizing your reasons. I appreciate it. >>>>>>> >>>>>>> Please allow me to categorize your reasons. Please let me know >> if I’m >>>>> not >>>>>>> categorizing them correctly. >>>>>>> >>>>>>> When I mentioned reason #1, I think it includes: >>>>>>> #3, #5 and #7 >>>>>>> >>>>>> >>>>>> For me 3,5,7 are not something about "philosophy", are pure >> technical >>>>>> structuration of code. If you want to left as is, is because >> you're >>>>> talking >>>>>> from an Application ser not from an archictecture point of view >> or with >>>>> the >>>>>> team member hat. >>>>>> >>>>>> >>>>>>> >>>>>>> #2 AFAICT includes #4. As I mentioned the fact that there can be >>>>>>> conflicting typenames is a problem. Removing Basic as a >> dependency >>> will >>>>> not >>>>>>> solve that problem because clients can (and likely will) bring >> in >>> Basic >>>>> as >>>>>>> part of their application. >>>>>>> >>>>>> >>>>>> There's much difference in obligation to link a library and >> decision to >>>>>> make part of your solution. We as Royale PMCs should make the >> best for >>>>> not >>>>>> obligate, the user is how could want then to use Jewel, MDL and >> Basic >>> all >>>>>> together. Is up to them. >>>>>> >>>>>> >>>>>>> >>>>>>> I really don’t understand your point with #6. Why do application >>>>>>> developers need to think about dependencies? Is it because of >> Maven >>>>>>> dependencies? If so, that seems to be a Maven problem which >> should be >>>>> fixed >>>>>>> there. >>>>>>> >>>>>> >>>>>> Not App developers, We are how need to be careful on this. In >> the same >>>>> way >>>>>> we are pushing hard on PAYG, to avoid mistake of the past like >> 15k >>> lines >>>>>> UIComponent class, We need to always be careful and don't make >> unneeded >>>>>> relations. And Basic -Jewel is totally unneeded. >>>>>> >>>>>> >>>>>>> >>>>>>> Please explain why you think $8 is true. What about the >> refactoring >>> will >>>>>>> reduce the size of applications? >>>>>>> >>>>>> >>>>>> I explained just in a Yshay response. copying the entire email >> response >>>>>> here. But rather to make me repeat or copy I though you read all >> this >>>>>> thread carefully: >>>>>> >>>>>> "I think the problem is that Basic UI set links things through >> CSS, so >>>>> If I >>>>>> have Application, Group, View, Button all this components and >> more has >>>>> CSS >>>>>> that links beads (ViewBeads, ModelBeads, ControllerBeads, and >> more) >>>>>> >>>>>> In Jewel until the refactor the components where sublcassing >> Basic >>> ones, >>>>>> and this made all this classes go in the Jewel Application, and >> that >>> not >>>>>> only introduced more size but makes the behaviour unexpected >> since I >>> find >>>>>> css styles and linked classes modifying the Jewel Behavior. >>>>>> >>>>>> Now that Jewel is not depending on Basic anymore, since it >> should be, >>> all >>>>>> works perfect. >>>>>> >>>>>> I think this is key, in a tree graph we should envision, Core as >> the >>> root >>>>>> of the tree, and when coming to UI sets that in royale we >> coincide in >>>>>> having many of them, one should not depend from the other. And by >>> design >>>>>> that's important, and will prevent people in the future to come >> back to >>>>>> make relations between them. In fact Alex, said many times the >> errors >>>>>> coming from 15k lines of code in UIComponent in Flex. If we left >> UI >>> sets >>>>>> depend at library level, people can start to make that kind of >>> extension, >>>>>> and that should not be doable by design." >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> As I mentioned earlier, Basic is not simply a component set. >> It’s >>> also a >>>>>>> set of building-blocks which can and should be used in other >> component >>>>>>> sets. Devision between Core and Basic is not as clear-cut as >> you seem >>>>> to be >>>>>>> asserting that it is. After your refactor the building blocks >> seem to >>> be >>>>>>> split between Core and Basic. >>>>>>> >>>>>> >>>>>> That's not what I talked in the past in this mailing list. Alex >> said >>> that >>>>>> people would want to use Basic for things very basic and more >> complex >>> UI >>>>>> sets for other things. In fact Jewel born to be more visual >> attractive, >>>>> so >>>>>> for Jewel, all building block regarding UI should be from >> itself, and >>>>>> prevent to mix with things in Basic that will (or could) evolve >> in >>> other >>>>>> way. >>>>>> >>>>>> My refactor was searching a goal, separation. But as many things >> can >>> not >>>>> be >>>>>> final. After it, we can think a bit more on how things are >> settle now, >>>>> and >>>>>> continue to improve it, to make Core real core, and Basic a UI >> set that >>>>>> could be has it's own essence without make it to mix in other >> libraries >>>>>> that should not need it. >>>>>> I think we should continue improving this instead of wanting >> again to >>>>> have >>>>>> a mess between all this libraries and packages mixed in >> libraries like >>>>> core >>>>>> and html. >>>>>> >>>>>> But for this to happen, we must focus in why the JSONLY build is >>>>> different >>>>>> from the main one, and if ANT fails, that shouldn't, that I'm >> still >>> don't >>>>>> know if we have a problem there >>>>>> >>>>>> thanks >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Harbs >>>>>>> >>>>>>>> On May 10, 2018, at 2:13 PM, Carlos Rovira < >> carlosrov...@apache.org >>> <mailto:carlosrov...@apache.org>> >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Harbs >>>>>>>> >>>>>>>> after 75 emails on this thread, understand that I don't want >> to again >>>>>>> write >>>>>>>> it, since this is making me waste lots of time in this >> discussion. >>>>>>>> >>>>>>>> 3) Having the need to link a library that should not be used, >> is that >>>>>>>> something is wrong, so it's not about 1) it's about things are >> not >>>>>>> setting >>>>>>>> correctly, and this refactor tries to fix that at least to put >> a >>> point >>>>> in >>>>>>>> wich we can make things better. >>>>>>>> 4) aside 2, some classes are linked via CSS as well >> (Application, >>>>> Group, >>>>>>>> Container, Button, Slider, and many more >>>>>>>> 5) Having Basic to be a core dependency, makes it Core in >> itself, so >>>>> why >>>>>>>> the separation Core- Basic if I'm obligated to link it? >>>>>>>> 6) Making Basic not present in libraries that doesn't need it, >> makes >>>>>>> people >>>>>>>> obligated by design to avoid extend Basic classes making the >> effect >>> but >>>>>>>> time that things mess between libraries, and obligates SDK >> developers >>>>> to >>>>>>>> think about the using of classes, since if we need some, maybe >> that >>>>> will >>>>>>> be >>>>>>>> Core and not Basic >>>>>>>> 7) Basic is only another UI set at the same level or sibling >> like >>>>> Jewel, >>>>>>>> MDL, CreateJS, Flat, and more we want to do, until now was very >>> needed, >>>>>>> but >>>>>>>> if we want to make Royale to serve general purpose, making it >> to be >>>>>>> present >>>>>>>> always is not the right way to go. >>>>>>>> 8) reduced size in final jewel applications. >>>>>>>> >>>>>>>> I think for sure I put more things on the plate, but can't >> invest now >>>>> the >>>>>>>> time to go all 75 emails to retrieve it >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2018-05-10 12:48 GMT+02:00 Harbs <harbs.li...@gmail.com >> <mailto: >>> harbs.li...@gmail.com>>: >>>>>>>> >>>>>>>>> The only reasons I seem to have seen are: >>>>>>>>> 1. A philosophical opposition to having Basic as a dependency. >>>>>>>>> 2. Not wanting Basic CSS included in a Jewel project. >>>>>>>>> >>>>>>>>> Unless I’m missing something, #1 I simply disagree with. >>>>>>>>> #2 sounds like a valid argument, but it seems to me more like >>>>> something >>>>>>>>> which needs to be fixed in the compiler. CSS not used by an >> app >>> should >>>>>>> not >>>>>>>>> be included and I think we need a way of avoiding typename >> conflicts >>>>>>>>> between component sets. >>>>>>>>> >>>>>>>>> Are there other arguments which I missed? >>>>>>>>> >>>>>>>>> Since Carlos does not seem to want to explain himself again, >> I’m >>>>> asking >>>>>>>>> others on the list: >>>>>>>>> >>>>>>>>> Do others understand why Carlos feels the refactor is >> important? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Harbs >>>>>>>>> >>>>>>>>>> On May 10, 2018, at 1:32 PM, Carlos Rovira < >>> carlosrov...@apache.org <mailto:carlosrov...@apache.org>> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Can we please keep this discussion about the technical >> reasons >>> for a >>>>>>>>>>> refactor and whether or not it’s the right thing to do? If >> you >>> have >>>>>>>>> strong >>>>>>>>>>> technical reasons why Basic should not be a dependency >> please >>>>> explain >>>>>>>>> them. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Harbs, I'll explained lots of time, and you keep ask the >> same. What >>>>> did >>>>>>>>> you >>>>>>>>>> not understand of the things I expressed so many time? >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Carlos Rovira >>>>>>>> https://na01.safelinks.protection.outlook.com/?url= >> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636615581733737384&sdata=%2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ >> xBeR27Le1U3toE%3D&reserved=0 <https://na01.safelinks. >> protection.outlook.com/?url=http%3A%2F%2Fabout.me% >> 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636615581733737384&sdata=%2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ >> xBeR27Le1U3toE%3D&reserved=0> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Carlos Rovira >>>>>> https://na01.safelinks.protection.outlook.com/?url= >> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636615581733737384&sdata=%2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ >> xBeR27Le1U3toE%3D&reserved=0 <https://na01.safelinks. >> protection.outlook.com/?url=http%3A%2F%2Fabout.me% >> 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636615581733737384&sdata=%2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ >> xBeR27Le1U3toE%3D&reserved=0> < >>> https://na01.safelinks.protection.outlook.com/?url= >> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636615581733737384&sdata=%2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ >> xBeR27Le1U3toE%3D&reserved=0 <https://na01.safelinks. >> protection.outlook.com/?url=http%3A%2F%2Fabout.me% >> 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636615581733737384&sdata=%2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ >> xBeR27Le1U3toE%3D&reserved=0>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Carlos Rovira >>>> https://na01.safelinks.protection.outlook.com/?url= >> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636615581733737384&sdata=%2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ >> xBeR27Le1U3toE%3D&reserved=0 <https://na01.safelinks. >> protection.outlook.com/?url=http%3A%2F%2Fabout.me% >> 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636615581733737384&sdata=%2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ >> xBeR27Le1U3toE%3D&reserved=0> >>> >> >> >> >> -- >> Carlos Rovira >> https://na01.safelinks.protection.outlook.com/?url= >> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636615581733737384&sdata=%2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ >> xBeR27Le1U3toE%3D&reserved=0 >> >> >> > > > -- > Carlos Rovira > http://about.me/carlosrovira <http://about.me/carlosrovira>
