Hi Carlos,
I see it the same way as you ☺
But I wouldn’t drop support for FB, the thing I was proposing, was to make the
default FlexJS SDK targeted for non-legacy IDEs and tools and to have a
“legacy-ide” profile (in Maven terms) in which someone requiring it could
enable a patch-layer that satisfies the legacy tools.
Similarly, I was suggesting to have the descriptor.xml contain the real version
number “0.7.0” or “0.8.0-SNAPSHOT” and if the “legacy” profile is enabled, then
it gets the prefix of “4.8.” to satisfy FB. I still think we shouldn’t be
shipping our new tool with legacy support enabled per default. I think it
should eventually be something you can enable in the installer and/or the build.
I still think if we start shipping our SDK with legacy things in the default
distribution, tool vendors will start relying on these hacks and we will have
to continue to support them in the future.
Chris
Am 03.02.17, 10:32 schrieb "carlos.rov...@gmail.com im Auftrag von Carlos
Rovira" <carlos.rov...@gmail.com im Auftrag von carlosrov...@apache.org>:
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
