Well I wouldn't deploy them quite yet ... I think It would be great to sort out some issues first. 1. I would like to have the libs deployed with the correct version numbers (currently commented out) because the way the Flexmojos versions were deployed you could not load the rsls and signed rsls from adobe that way (ther was no osmf-4.5.1...).
2. I think my structure might sill need some fine-tuning (I actually don't use the AIR sdk or the Android stuff, so I don't know if my deployment descriptors make sense the way I generated them. Just to mention the basic concepts I used in my deployment descriptors: - The flex sdk is deployed in the group "com.adobe.flex.framework" - I have one artifact "com.adobe.flex:framework" which contains a dependencyManagement section defining the versions of artifacts the flex framework it belongs to have (This way you can import the dependencyManagement stuff) - I have a common-framework artifact which contains dependencies to most of the flex stuff - I hace a flex-framework which actually contains a dependency to common-framework and the newest playerglobal that was found in the sdk (Would it make sense to use the minimum instead?) - I haven't created an "air-framework" as I actually don't know what I would have to add to this. - Still need an "automation-framework" (Don't know if this makes sense) - Still need a "mobile-framework" (Don't know if this makes sense) Chris -----Ursprüngliche Nachricht----- Von: carlos.rov...@gmail.com [mailto:carlos.rov...@gmail.com] Im Auftrag von Carlos Rovira Gesendet: Freitag, 25. Mai 2012 12:32 An: flex-dev@incubator.apache.org Betreff: Re: Apache Flex structure to be BMS compliant (was Re: Library Versions used in Flex SDK) 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
