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
