Hi Carlos,
I don't have a particular problem that you made a commit that broke things.
That happens from time to time. I trust that if you knew up front it would
break things you would have started it in a branch. What is the problem is
what happened afterward.
I think there are at least 4 of us who still are not understanding you, or
don't agree with your conclusions. This means that we are not communicating
well. Either you are right, and you haven't found the words or data to
convince us or vice versa. And the 86 prior emails contained very little
data. Let's see if we can work from more concrete examples and data to try to
close out this discussion.
We are trying to define the patterns that will scale with us forever. Moving
beads from Basic to Core because you want to use them elsewhere is not a
pattern that scales. I think you did not take into consideration the
differences between the old Flex model and this new composition-centric model
in Royale. Separation of one project from another in a composition model
should not be a high priority. What is more important is good organization of
the choices for composition. Otherwise we will end up with another problem
similar to UIComponent in Flex. The Core library will contain thousands of
classes that are similar just because someone wanted to re-use that code.
Instead, we want Basic to contain beads that are simple, Express to contain
"aggregations", and sets like Jewel and MDL can contain beads specific to those
component sets.
A bead like a ToolTip bead can probably never go in Core. It has "an opinion"
about how and when to generate and dismiss a tooltip. Look around and you will
see other ways that ToolTips are handled. The Basic Tooltip bead is a simple
implementation that can be a sufficient default for a lot of component sets.
But it isn't so universal that it should go in Core.
I think I will stop there and see if we can agree on this one point. Maybe
we'll have to end up taking a vote, but this is the pattern I think is best for
Royale and I hope to convince you of that.
Thanks,
-Alex
On 5/10/18, 11:01 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
Hi Alex,
2018-05-10 18:50 GMT+02:00 Alex Harui <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=https%3A%2F%2Fna01.safelinks&data=02%7C01%7Caharui%40adobe.com%7C11b8779036f342addf6e08d5b6a01888%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636615721089819822&sdata=bxWUPeO%2Fg8H0mS9nEBEDpvx1kOJlUM5vVNHy%2F2beFF8%3D&reserved=0.
> 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=https%3A%2F%2Fna01.safelinks&data=02%7C01%7Caharui%40adobe.com%7C11b8779036f342addf6e08d5b6a01888%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636615721089819822&sdata=bxWUPeO%2Fg8H0mS9nEBEDpvx1kOJlUM5vVNHy%2F2beFF8%3D&reserved=0.
> 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=https%3A%2F%2Fna01.safelinks&data=02%7C01%7Caharui%40adobe.com%7C11b8779036f342addf6e08d5b6a01888%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636615721089819822&sdata=bxWUPeO%2Fg8H0mS9nEBEDpvx1kOJlUM5vVNHy%2F2beFF8%3D&reserved=0.
> 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=https%3A%2F%2Fna01.safelinks&data=02%7C01%7Caharui%40adobe.com%7C11b8779036f342addf6e08d5b6a01888%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636615721089819822&sdata=bxWUPeO%2Fg8H0mS9nEBEDpvx1kOJlUM5vVNHy%2F2beFF8%3D&reserved=0.
> 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
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C11b8779036f342addf6e08d5b6a01888%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636615721089819822&sdata=qolRT2SS43TM1bv%2BF92mMJb%2Fd9jD6TltxMXw8hjG6hA%3D&reserved=0
