He said, that he is sort of discontinuing everything regarding FM ... the thing he did mention was that if he was offered a certain amount of money, hey would merge the stuff from FM Enterprize back to normal FM.
Currently I am not really deep into AIR. I think there is a lot to be done before being able to work on the mobile packaging and stuff like that. The thing I will start on in the next weeks will definitely be the Compiler. As I am really interested in Falcon and Falcon will be the new official compiler, I would probably start with a plugin supporting this. Unfortuneately I guess the Compiler will probably be 75% of the work of the entire plugin suite. So I guess there will be some time until we can start on the packaging. As I mentioned before ... I did sort of delay a lot of my job-work while getting FM and the Mavenizer running. I have to first sattisfy the needs of some of my customers, or I'll be having some serious trouble ... so don't expect a 0.1-beta to soon ;-) Chris -----Ursprüngliche Nachricht----- Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com] Gesendet: Sonntag, 25. November 2012 14:05 An: flex-dev@incubator.apache.org Betreff: Re: AW: Who's a flex compiler-configuration pro on this list? Hi, Actually, reading you Chris, my 2.5 scenario, where adobe would deploy their sdks, is wrong (sorry @Alex, I had to think more about before talking). > target 100% would be cooler, but 80% is better than 0%. Yes, and that may evolve. @Chris, Am I wrong or I read somewhere Velo discontinued its Commercial Flexmojos Enterprize and now, he provides this feature case by case, being paid for that, re-integrating some changes in specific versions at demand only ? Have you already thing about the ADT usage instead of the AIRPackager ? - Fred -----Message d'origine----- From: christofer.d...@c-ware.de Sent: Sunday, November 25, 2012 1:38 PM To: flex-dev@incubator.apache.org Subject: AW: Who's a flex compiler-configuration pro on this list? Exactly. Currently noone is providing the FDKs publically, because at least the dependencies to the two or three Adobe artifacts that are not available via Maven. Even if only manually deploying these artifacts isn't such a show-stopper as having to deploy the entire FDK, I think most users are used not having to do anything at all and this would prevent a lot of maven newbes from using flex in maven. At least this is the impression I am having while servicing the Flexmojos Mailinglist. Most users are consumers and not willing to eaven read a README file (Think you probably noticed that problem when releasing the first Apache Flex) I can see the following scenarios (each step going down the maven road even further): 1. Using the Mavenizer to locally deploy FDKs. 2. Apache uses the Mavenizer to mavenize a new FDK release and deploys those artifacts in a public repo. 3. Building Flex with Maven, eliminating the need to use the Mavenizer all together. I agree that there might be some issues with the native packaging and mobile deployment. This is currently only handled by Velos Commercial Flexmojos Enterprize and these features are not part of the normal FM currently. So I agree that there might be some issues with the build needing more artifacts. But I think with the two or three artifacts discussed in this thread, we should be albe to target about 80% of the normal users use-cases. Being able to target 100% would be cooler, but 80% is better than 0%. Chris -----Ursprüngliche Nachricht----- Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com] Gesendet: Sonntag, 25. November 2012 08:59 An: flex-dev@incubator.apache.org Betreff: Re: Who's a flex compiler-configuration pro on this list? > Christopher Dutz gave me the impression that all Adobe would have to do is place a pom.xml alongside each playerglobal.swc. Is there more to it? I guess the goal behind that is to be able to get those artefact from a legal repo, we can not legaly provide them from inside the mavenized apache flex sdk, I guess what Chris want to do, is to make our sdk public via the apache repo and get those last artifacts from adobe, doing so, if only the the apache flex sdk is publicly available, that should not be a problem for companies to host internaly the new structure of the new sdk and the old structure of the others, they could use fm<6 and fm 6 on different projects. The only thing is they shouldn't have to use the mavenizer to convert the SDKs otherwize they whould break the compatibility with the old flexmojos. The mavenizer should be use only by us, in this case to mavenized our sdk. - Fred. -----Message d'origine----- From: Alex Harui Sent: Sunday, November 25, 2012 7:32 AM To: flex-dev@incubator.apache.org Subject: Re: Who's a flex compiler-configuration pro on this list? On 11/24/12 9:28 PM, "Frédéric THOMAS" <webdoubl...@hotmail.com> wrote: > The mavenizer replace at the moment the lack of public repositories, even > if > it's good enough for individuals and small companies, it is not for big > ones. The main issue with Adobe making its stuff Maven friendly is legal. There is stuff in the AIR SDK that Adobe doesn't want to put in the "open" world. It appears from my reading that plenty of other Maven apps are built with closed source code via "mavenizers" that copy downloaded assets into local repos. Why is this not ok for big companies? > > > If Adobe and Apache decide to finaly host and deploy these frameworks in a > maven repository, they will have to mavenized them and the mavenizer is > THE > TOOL for. Christopher Dutz gave me the impression that all Adobe would have to do is place a pom.xml alongside each playerglobal.swc. Is there more to it? > > >> So, with my limited understanding of Maven, the goal was to have Apache >> Flex > releases have a pom.xml and live in the Apache Maven repo, and have Adobe > playerglobal.swc and airglobal.swc (and maybe more) on the Adobe download > server > > > Yes, you're right, it's just that for Air, the entire sdk is needed. I'm confused where you said in the other response that adt.jar has everything you need, but here you say the entire AIR SDK is needed. > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
