flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "christofer.dutz@c-ware.de" <christofer.d...@c-ware.de>
Subject AW: AW: Library Versions used in Flex SDK
Date Sat, 19 May 2012 13:39:24 GMT
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

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. 

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 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

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.


-----Urspr√ľngliche Nachricht-----
Von: Alex Harui [mailto:aharui@adobe.com] 
Gesendet: Freitag, 18. Mai 2012 18:04
An: flex-dev@incubator.apache.org
Betreff: Re: AW: Library Versions used in Flex SDK

On 5/18/12 6:28 AM, "christofer.dutz@c-ware.de" <christofer.dutz@c-ware.de>

> Yeah ... I found out that this would be a messy task ... even the guys 
> from Adobe didn't want to submit their patches as they considered them 
> far to messy to contribute :-( Think I'll just stick to reuse versions 
> of oder sdks if they haven't changed.
> Chris
Hi, thanks for looking into this.  Some possibly useful information:

0) I don't know much about Maven, so I could be completely off.
1) I think it is more important to make Flex usable in Maven than to make it work with FlexMojos.
 IOW, FlexMojos may also be burdened with legacy of having to work with Flex's idiosyncracies
and we actually now have the ability to change some aspects of Flex to make them work better
with Maven.
Starting over might be the best bet and eliminates a dependency on something that is not part
of Apache Flex
2) Flex's use of Batik might really require a copy-and-rename. I'm pretty sure there are some
non-standard extensions to Batik CSS which is why our changes never got contributed back.
 Not sure about Xerces.  So, we might fork Batik, give it a new package (org.apache.flex)
and use our forked copy.
Especially if that makes Maven integration easier.

Alex Harui
Flex SDK Team
Adobe Systems, Inc.

View raw message