I guess what we are proposing doesn’t mean: Drop Legacy IDEs, but just force
people who need the legacy stuff to enable the legacy layer with a simple
switch.
I mentioned the descriptor thing often enough, but for example having
self-contained SWCs definitely makes it easier for people with new IDEs or
build tools, but doesn’t make things harder for ones using new IDEs. If I was
thinking in Maven for example, a dev using a non-legacy IDE should just build
and he gets the Single-SWC libs and descriptors with real versions. If someone
with an old one wants to give it a try, he activates the legacy-profile and the
generated descriptor has all the required changes and additionally the
flexjs-maven-plugin produces the “extern” files and packages them in the
distribution so FlashBuilder is happy.
I don’t think this would make things more difficult for you and Legacy users -
besides someone having to implement the logic to include things in the SWC and
how to get stuff from the SWCs additional js-library.
I think we will lower the boundaries for new users greatly, who we don’t have
to explain the details of swf-swcs and js-swcs and how to manage the
dependencies. And we don’t confuse migrators with this hard to wrap your head
around thing. As you said, we don’t want to change to much for migrators. If
the files were self-contained, we wouldn’t have to explain anything to them. If
they are not using a legacy IDE and if they are then we still have to explain
it to them, so nothing is lost.
Also I think we will be needing a lot of people working on the low-level things
… because we are still missing quite a number of controls. I’d really like to
keep things as simple as possible for them.
Unfortunately, I am still not that into the details of the compiler to trust
myself in doing that change on my own … I am willing to learn, but I thing
right now I’m not that into it as you are. But I guess me and the others should
manage to work on the other parts you mentioned. So I think it would actually
be best if you implemented that change and we concentrate on continuing work on
the framework.
Then I could also continue work on the features of the flexjs-maven-plugin
because I would no longer have to wait for changes in the maven resolver
library to be released in order to cleanly continue (Right now I’m waiting and
monitoring the maven list for the confirmation that I can continue).
Chris
Am 03.02.17, 18:29 schrieb "Alex Harui" <aha...@adobe.com>:
I don't claim to know the right answer so other folks should certainly
give their thoughts. IMO, if you want to encourage migration, you change
as few things as possible.
We don't spend a ton of time on supporting the old IDEs. Not mucking with
the contents of the SWCs saves me time to work on other things.
Everything is a trade-off. If someone needs help on modules or AMF,
should I not help because I am spending time rewriting the compiler and
build scripts for packing more stuff into the SWCs? We've sort of dropped
the ball on Trevor's proposals for a new look. Should I spend time on
that or on this SWC packaging?
-Alex
On 2/3/17, 1:32 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
>Hi,
>
>(coming from the other thread and removing test and renaming thread)
>
>in all this conversation I have the sense that Alex is always looking to
>be
>compliant with old IDEs (I'm specially talking about FB) and don't
>understand the reason behind. I think this is making us far to get a
>solution for the real problem and even could be counterproductive.
>
>Let me try to explain my way of thinking: People using FB today are people
>using Flex SDK, no other people is using it (or at least should be
>residual) since is a product without maintenance for 6-7 years and stuck
>in
>the past. Many people coming to FlexJS already made a transition from FB
>to
>other IDEs (mainly IntelliJ IDEA) for many reasons, better refactoring, a
>great tech stack, maven support for Flex,...
>
>Now let's try to think in FlexJS...we are creating a technology from
>scratch. There's almost no legacy internals in what we are doing, but
>since
>there was so many great things in the old Flex philosophy we are importing
>it into FlexJS, but integrating with many new ones. Remember how many work
>we need in the past to get rid of SVN and adopt GIT? Thanks to god we did
>it. Remember how hard was to get Maven building? (only Chris knows the
>deep
>implications of this one). Those are only two examples of things with lot
>of impact in what we are today. All this things has bring us the
>possibilities that we have now. Talking now about me, without Git and
>Maven, I'll be not here, since it would be so hard to me think in older
>terms than that.
>
>So please, people working on Flex SDK, should has FB in mind, that's ok
>for
>me...is legacy sdk maintenance and many of them sure is still using FB,
>break that will be bad from a maintenance perspective.
>
>But all of us working on a modern technology that we call "FlexJS", should
>be running away from FB since instead doing something for us is penalizing
>us. Each time I read some explanation based on what would be in FB terms,
>or how should do it to make FB happy I think we are in the opposite
>direction. For me those kind of things are very dangerous since not doing
>the right change at a time can kill us before we reach the goal.
>
>If we need to change something that will need some IDE change, we should
>think in new IDEs and talk with their devs to support it. For commercial
>products, like IntelliJ, knowing their politic, I'll let it to them, and
>will concentrate in get as many costumers as we can with our open source
>tools (included OS IDEs), so we get the interest to support us.
>
>FlexJS is not Flex SDK, and even more, people doing Flex apps can't
>migrate
>to FlexJS with the same code base. People will need to start from scratch,
>but they could use their Flex codebase as a guide to implement their new
>codebase. So there are absolutely no points to stand with FB in 2017 for
>crafting a state of the art technology like FlexJS that tries to compite
>with the main ones out there.
>
>So we'll need to look forward always. Hope people here that is using FB
>for
>FlexJS could consider to move to other IDEs (specially open source), so
>this will make us truly open source in all means (only can think in flash
>player output dependency, but as a flavor, I think that's not bad and is
>optional) and get rid of any chains that some commercial product could
>impose to us.
>
>All of you working with old tooling, please consider this, since I think
>is
>very serious thing to take into account.
>
>Thanks!
>
>
>--
>Carlos Rovira
>http://about.me/carlosrovira
