I allready feared that there could be problems with legal issues in distributing the runtimes. I guess the only solution would be do publish the tool to enable people to generate their own SDK versions (including the flash players and playerglobals).
Flexmojos is not only a link between Flex and Maven, but integrates several other tools, that make it extremely valuable: - Apparat Integration to optimize the SWFs and SWCs - GraniteDS to automatically generate the ActionScript model classes from their Java counterparts. So simply integrating the basic compiler feature would strip a lot of it's functionality. It would be great however if the compiler would could be called directly instead of having to go the way of simulating the commandline call. I know that Flexmojos still has quite some issues, but most of the Issues I had to resolve were mainly related to problems in the Flex compiler code (Just to mention one: Try using ASDoc with code comments containing the "@" character ;-) ). I toally agree that the general perspective should be to integrate the functionality of flexmojos into Flex, or at least have them maintained by the same group, but I think the current SDK has far too many issues that should be adressed first. Trying to create a new Maven integration layer would just add more to the todo list. So for now I think it would be great to work together. I would be glad to contribute to make Flex work better. As soon as the main issues are resolved I would also be glad to help you create something similar or to integrate flexmojos to flex. I'm also not requesting to change flex in any way to make mavenizing the sdk easier. Currently I was only suggesting to clean up the structure of the SDK to more reflect the parts natures and to generate some helpfull other stuff that makes life of people using it a lot easier: - Generate a special pom containing only dependencyManagement section. This can be imported into other maven projects to automatically set the versions of the sdk artifacts. - Generate a special jar containing metadata that can be used by flexmojos to perform validation (minimum SFW-version, minimum playerglobal version, etc.). Just to name a few. Chris -----Ursprüngliche Nachricht----- Von: Alex Harui [mailto:aha...@adobe.com] Gesendet: Samstag, 19. Mai 2012 18:45 An: flex-dev@incubator.apache.org Betreff: Re: AW: AW: Library Versions used in Flex SDK On 5/19/12 6:39 AM, "christofer.d...@c-ware.de" <christofer.d...@c-ware.de> wrote: > Currently Flex doesn't work at all with Maven. Even if you distribute > the SDKs content as Maven artifacts, this is by far not enough as > Maven simply doesn't know what to do with a Flex/Air project. > > Flexmojos is a set of maven plugins that actually tells Maven what to > do with a Maven project of packaging "swf" or "swc" and how a "war" > has to be built to contain a Flex application. > > Currently those plugins act as a wrapper to the Flex compilers, > optimizers and runntimes so you don't have to wory about how your > Maven dependencies get passed to the Flex compiler. > So I don't think that Flexmojos is a dead End, it's more the missing > link to bringing Maven and Flex together. I understand (I think). This list is about Apache Flex and to me, lots of packaging changes are now possible, if not required. For example, Apache Flex cannot ship the same folder structure as Adobe does because it doesn't have the right to distribute the Flash/AIR pieces. Apache Flex also now has control over the compiler. In my mind, FlexMojos is a mapping between Maven and the Adobe Flex SDKs and I've heard it has some issues. Given all that, I am just raising the question of whether it is better to continue on with FlexMojos which is currently an external dependency, or whether it is better to adjust packaging and compilers and whatever to make a simpler mapping possible and just start over. And then all the pieces are within Apache. > > Up till now Velo (The creator of Flexmojos) had to vonvert every Flex > SDK in a mavenized form, and deployed that on the Sonatype Maven repo. > Now I have taken over to continue flexmojos development and as one of > my first tasks I wanted to publish all of those patched SDKs Adobe > released a few months ago. While I am at it, I'm refactoring the > structure of the SDKs to a structure that relates better to the > structure oft he Products (Flashplayer and Air runtime (together with > playerglobal and airglobel) are not part of the SDK. I think that's great that you are doing that. At least in February, a couple of large companies were in dire need of getting those patch SDKs deployed and needed Maven artifacts. That effort is outside of the Apache Flex scope so you can do whatever you want there (assuming you have legal rights to redistribute the Adobe pieces). I'm just looking for your input on how things could be better in Apache Flex as now is an important time as we are deciding on our release packaging. > > I guess as Maven is an Apache project and now Flex is an Apache > project, it would make sense if Apache provided the SDKs as a > donwloadable sdk the same way Adobe did, but would also provide the > official releases in the Maven Central repository. > The structure of these SDKs however would be the "API" Flexmojos would > have to rely on. That's why I'm asking you guys here about your > Mavenizing plans so I don't have to generate the SDKs and adjust > Flexmojos to that new structure and then do all of that again as soon > as the Flex project starts distributing your SDKs. This would result > in 3 structural different sets of Flex SDKs deployed in > Nexuses/Artifactories/etc. all over the planet. I would like to avoid this. > > As a suggestion, I could provide you with the SDKs I generated and we > could optimize them together. Then you could simply use the tool I > created to officially distribute the new SDKs from then on. That would be a useful data point, but I really want to make sure some aspect of Apache Flex shouldn't be changing to make Maven-izing easier to do and maintain. > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
