Hi Alex I completely agree with you. Adobe will make its business decisions based on profit. Is a business and is like things should be driven by its own nature.
Here we are targeting the best evolution for Flex and like Alex said BSM (specialy maven) are top on the list. This is in fact what are making flex not evolve as expect. Let's make flex maven (and other BSMs) compatible and people will continue using it since there's no better solution to build RIA applications on the market and will play with the rest of technologies in that projects and with the normalized ways for enterprises of build software. Tools (and vendors) are to serve technology and users, not the inverse. If people need maven and a well designed structure, people will support the effort and will claim for this kind of changes, then Adobe, IDEA, FDT and whatever other vendor that would like to continue selling upgrades will be forced to be competitive, or throw the towel. Right now a 4.8 version is needed with parity with with Adobe flex sdk 4.6. After this happen, still many people will continue using Adobe flex sdk 4.5.1.21328. Why? because it will continue to be the latest flex sdk mavenized and deployed and available to build systems with flex, java and other technologies with maven. 2012/5/24 Alex Harui <aha...@adobe.com> > > > > On 5/24/12 12:50 PM, "Carlos Rovira" <carlos.rov...@codeoscopic.com> > wrote: > > > I think IntelliJ will update quickly since they are > > "maven-gradle-whatever-bms-oriented". > > Flash Builder never took into account BMS, but they will update due that > > technology requeriments....or are you saying that they will abandon Flex > > development? > Adobe is improving the next release of Flash Builder to be a bit more > configurable so it can work with Apache Flex SDKs. After that, it is a > business decision as to whether Adobe will do any further work if the > Apache > Flex SDK evolves in a way that is incompatible. > > If other tool vendors are more willing to make changes and therefore > provide > a more compelling tool than Adobe, then we'll see folks move in that > direction, and then we'll see if Adobe chooses to compete or not. > > > > moreover...are you saying that we must stay with what we have now? > > so...that's what we can expect for the future of flex? stay with the same > > problems we ever had during all years? What kind of changes can we > expect? > > only cosmetic changes? > We have to consider factors when proposing changes like installed base, > what > our users know and expect. But I think we can make some big changes over > time. > > > > Michel, you and Alex were talking about agresive changes in the > SDK...i.e: > > a completely new set of flex components and arqutecture, isn't it?...so > > changes like that will not obligate Adobe to update Fb in order to make > it > > Apache Flex compliant? > Flash Builder is not obligated to update to handle changes to the Apache > Flex SDK. One thing we need to do is get some momentum so that there is a > compelling market that would incite Adobe to want to update FB so it can > extract revenue from customer upgrades. But if some other tool vendor ends > up creating a better tool and everyone starts using it and makes FB a thing > of the past, that's fine with me. > > Most important to me is that we have to solve the important problems. > Maven > integration is the top vote getter at Adobe JIRA by far. It is time to > make > adjustments to Apache Flex to make Maven work, but we want to do so without > breaking everyone else's workflow. > > We have been forced by legal reasons to change the package structure. > Apache Flex releases cannot look like the tree of files you get from Adobe. > And since we're doing that, it is time to consider any changes to make > Maven > easier to support. But we are not asking the tool vendors to change with > us. > Instead, we are providing scripts to repackage the files from the various > sources into something the tools can use. > > > -- > Alex Harui > Flex SDK Team > Adobe Systems, Inc. > http://blogs.adobe.com/aharui > > -- Carlos Rovira Director de Tecnología M: +34 607 22 60 05 F: +34 912 35 57 77 <http://www.codeoscopic.com> CODEOSCOPIC S.A. <http://www.codeoscopic.com> Avd. del General Perón, 32 Planta 10, Puertas P-Q 28020 Madrid
