Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
From: "christofer.dutz@c-ware.de" <christofer.dutz@c-ware.de>
To: "'flex-dev@incubator.apache.org'" <flex-dev@incubator.apache.org>
Date: Tue, 22 May 2012 14:41:10 +0200
Subject: AW: AW: AW: Library Versions used in Flex SDK
Thread-Topic: AW: AW: Library Versions used in Flex SDK
Thread-Index: Ac00+SOpIuLkE5WnRsmregOJEexCBgAAMbdQAAV2oMcALKsswAAHEUcBABs0siA=
Message-ID: 
 <66E38C42347D6446BF7FCB22C3D3878072C670A974@ECCR06PUBLIC.exchange.local>
References: 
 <66E38C42347D6446BF7FCB22C3D3878072C5549B45@ECCR06PUBLIC.exchange.local>
 <CBDD1C15.4096F%aharui@adobe.com>
In-Reply-To: <CBDD1C15.4096F%aharui@adobe.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

I allready feared that there could be problems with legal issues in distrib=
uting 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 pl=
ayers 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 t=
heir 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 cal=
led directly instead of having to go the way of simulating the commandline =
call.=20

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 i=
ntegrate the functionality of flexmojos into Flex, or at least have them ma=
intained by the same group, but I think the current SDK has far too many is=
sues that should be adressed first. Trying to create a new Maven integratio=
n layer would just add more to the todo list. So for now I think it would b=
e great to work together. I would be glad to contribute to make Flex work b=
etter. 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 sd=
k 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 s=
tuff 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 version=
s 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, e=
tc.).
Just to name a few.

Chris


-----Urspr=FCngliche Nachricht-----
Von: Alex Harui [mailto:aharui@adobe.com]=20
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.dutz@c-ware.de" <christofer.dutz@c-ware.de>
wrote:

> Currently Flex doesn't work at all with Maven. Even if you distribute=20
> the SDKs content as Maven artifacts, this is by far not enough as=20
> Maven simply doesn't know what to do with a Flex/Air project.
>=20
> Flexmojos is a set of maven plugins that actually tells Maven what to=20
> do with a Maven project of packaging "swf" or "swc" and how a "war"=20
> has to be built to contain a Flex application.
>=20
> Currently those plugins act as a wrapper to the Flex compilers,=20
> optimizers and runntimes so you don't have to wory about how your=20
> Maven dependencies get passed to the Flex compiler.
> So I don't think that Flexmojos is a dead End, it's more the missing=20
> 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 F=
lex 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 ha=
s control over the compiler.  In my mind, FlexMojos is a mapping between Ma=
ven and the Adobe Flex SDKs and I've heard it has some issues.  Given all t=
hat, 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 map=
ping possible and just start over.  And then all the pieces are within Apac=
he.
>=20
> Up till now Velo (The creator of Flexmojos) had to vonvert every Flex=20
> SDK in a mavenized form, and deployed that on the Sonatype Maven repo.=20
> Now I have taken over to continue flexmojos development and as one of=20
> my first tasks I wanted to publish all of those patched SDKs Adobe=20
> released a few months ago. While I am at it, I'm refactoring the=20
> structure of the SDKs to a structure that relates better to the=20
> structure oft he Products (Flashplayer and Air runtime (together with pla=
yerglobal and airglobel) are not part of the SDK.
I think that's great that you are doing that.  At least in February, a coup=
le of large companies were in dire need of getting those patch SDKs deploye=
d and needed Maven artifacts.  That effort is outside of the Apache Flex sc=
ope so you can do whatever you want there (assuming you have legal rights t=
o redistribute the Adobe pieces).  I'm just looking for your input on how t=
hings could be better in Apache Flex as now is an important time as we are =
deciding on our release packaging.
>=20
> I guess as Maven is an Apache project and now Flex is an Apache=20
> project, it would make sense if Apache provided the SDKs as a=20
> donwloadable sdk the same way Adobe did, but would also provide the=20
> official releases in the Maven Central repository.
> The structure of these SDKs however would be the "API" Flexmojos would=20
> have to rely on. That's why I'm asking you guys here about your=20
> Mavenizing plans so I don't have to generate the SDKs and adjust=20
> Flexmojos to that new structure and then do all of that again as soon=20
> as the Flex project starts distributing your SDKs. This would result=20
> in 3 structural different sets of Flex SDKs deployed in Nexuses/Artifacto=
ries/etc. all over the planet. I would like to avoid this.
>=20
> As a suggestion, I could provide you with the SDKs I generated and we=20
> could optimize them together. Then you could simply use the tool I=20
> 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 aspe=
ct of Apache Flex shouldn't be changing to make Maven-izing easier to do an=
d maintain.
>=20


--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui