Hi Chris, great work and effort so far. I think is a great way to handle the actual situation, and in the meanwhile would be very helpful to deploy new flex sdks (4.6 from Adobe, 4.8 from Apache) to a maven repository.
But we should not lost the target and see that this is a palliative solution until the structural refactor could take place and make things direct and easier. What do you think about it? btw, have you tried to package Adobe Flex 4.6.0.23201 with your tool and deploy to a maven repository (local or remote)? C. PD: one more thing, I saw that some versions has an A or an B at the end of the build number...what are this letters and what means? I suppose that this is something that not came from Adobe and something related to the flexmojos packaging, isn't it? 2012/5/25 christofer.d...@c-ware.de <christofer.d...@c-ware.de> > There actually are no things preventing us from converting Flex into a > mavenized form. There are only some ugly parts that I thought would be cool > to resolve. Most of them relate to hacked versions of standard libs. > > I think the structural changes I was talking about could be performed at > deployment time. > > Fact is that there are some core-flex libraries, that flex and air need > ... lets call them flex-core. > Then there are libs for air and libs for flex only ... then there is a set > of libs for automation and one set for mobile devices ... I would like to > have them deployed separately in individual maven groups. > > Curently I am deploying them allmost the way they are bundled in the SDKs > but am generating some pom-artifacts doing the grouping. > > Ive attached my unfinished converter project to this mail (Hopefully it's > not stripped out). If it is and you would like me to send you a copy ... > please contact me directly and I'll send it to you. > > What it does, is it looks at a directory containing a set of SDKs and > processes each of them to the output directory. Both directories have to be > provided as parameters to the main class. Inside each SDK it deploys > everything in the SDKs lib directory as a compiler bundle, and everything > inside the frameworks/libs as Flex sdk (Except the playerglobal). > > In the compiler it generates checksums of every jar and does a search on > Maven central to see if the artifact is allready deployed. If it is, it > uses that artifact instead of re-deploying it. > > In the Frameworks part it has a look at the rsls first, because these have > a version and uses this version to deploy the libs (osmf and textLayout > tend to have a different versioning scheme). Currently I commented this out > and am deploying all swcs with the fixed version number of the sdk, because > I haven't fixed Flexmojos to use a dynamic framework-swc version, but I'm > working on this. > > I have tested building my Applications using Flexmojos 5.1 and Flex SDK > 4.5.1.21328A and it worked great. Think I might still have to do some > fine-tuning, but I think it would be better to hand this over to you and > only participate in the fine-tuning. > > Chris > > > > -----Ursprüngliche Nachricht----- > Von: Alex Harui [mailto:aha...@adobe.com] > Gesendet: Donnerstag, 24. Mai 2012 22:46 > An: flex-dev@incubator.apache.org > Betreff: Re: Apache Flex structure to be BMS compliant (was Re: Library > Versions used in Flex SDK) > > > > > 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
