Out of curiosity, what Maven support are you looking for that Flex-Mojos doesn't provide, other than being natively integrated into the compiler, perhaps?
Nick Collins On Mon, Jan 9, 2012 at 10:15 AM, Carlos Rovira < carlos.rov...@codeoscopic.com> wrote: > Hi, > > I would want to share my thoughts about what changes would like to see in > forthcoming Apache Flex releases (far beyond 4.6.1 that would bring nothing > new AFAIK and will be only serve to put the project in the new Apache > rails). I'm referring to Apache Flex 4.7, 4.8, 4.9...and so on. > > This is only my opinion and as I said I can't help right now in this issues > until I get the time to support Apache Flex with my own work, so it's only > my desired changes or new features that I would like to share here to give > you some points that I think it would be great to have in Apache Flex: > > * Dinamic View States > > we have fully support of "dinamic skin parts" in Flex 4 and work great, but > one thing we need too is "dinamic view states". Right now view states need > to be declared in the AS3 class and in the skin. So this is all very > "declarative". We need the capability to create states on the fly and let > other parts handle this dinamic view states (transitions,...). Without > this, view states are a bit limited. > > * AOP > > With all new avances in this field in the last year (see James Ward / > Michael Labriola -Planet of AOP's or Swiz 2 beta AOP feature), I think Flex > should provide AOP in its core framework. We need to make it more > transparent to the end user and stablish the preloading hooks to > instrumentalize the classes when we load the bytecode in order to be able > to change that code before it loads in the AVM. I think this is completly a > Flex framework responsability. > > * Flex Core refactor (SystemManager, Managers -PopUpManager,...-) > > The Flex core framework has many out date code that brings many problems > nowadays due to monolitic code or poorly designed code. This is normal in a > framework that has now 6-7 years (I talking since Flex 2 since Flex 1.x was > AS2), and has code from that period. Today we know more techniques and > things evolved so we should refactor many internal things that today are > obsolete and are limiting the way to growing and introduces several bugs. > I'm referring to all the code that glues all the framework: SystemManager, > PopUpManager, and so on... > > * Maven support > > I commented this already, but as I think this is really importante to > succed in the enterprise market (and this is the main Flex use case) I > state this again... Maven support, Gradle support...are really important if > we want Flex to survive. We can't handle huge applications repositories if > we don't have this kind of tool that ensure that our builds are well formed > and constructed with the right external and internal library versions. > > * Metada Evolution and DI frameworks support > > Metadata should continue to evolve and support current DI frameworks like > Swiz or Parsely. > > > This is some of the things I list here and now, but I think I would come > with more as I have time. > > And you? what are the things that you would want to see in Apache Flex > (change, new features,...) , I think this kind of thread is needed now that > the list are working for a week or so... I think we need to start to see > some future horizont, although the first step would be to get the source > code in Apache, and all initial commiters taking over the project to > generate the 4.6.1 initial version). > > What do you think? Make sense this key points proposals for future Apache > Flex evolution? > > Thanks! > > > -- > Carlos Rovira > Director de Tecnología > M: +34 607 22 60 05 > F: +34 912 35 57 77 > > CODEOSCOPIC S.A. <http://www.codeoscopic.com> > Avd. del General Perón, 32 > Planta 10, Puertas P-Q > 28020 Madrid >
