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%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
