I might still be confused but I thought that the goal of getting Adobe to
put pom.xml files with its SDKs is so that there doesn't really need to be a
mavenizer. My understanding is that a mavenizer takes stuff you've
downloaded and packages it up into a local maven repo. Please correct me if
that is not true. I'm still trying to learn all of this stuff.
For every AIR/Flex SDKs from a given directory structure, the mavenizer
compiles, zip, renames, re-organizes the entries
- For the compiler jars and the framework swc, it renames the files, create
a pom.xml and re-organize them in a final directory structure.
- For the themes, if a it's a swc, that's like above, if it's not, it
compiles it and do like above.
- Creates the sources and the config zips and then like above
- Create the pom.xml aggregators for the air-framework, the air
common-framework, flex common-framework and the flex-air common-framework
(and maybe I forgot something, it's late)
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.
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.
Also, Apache Flex is trying to break any tie between the Apache Flex SDK
and
an AIR SDK. Adobe Flex used to only support a specific version of the AIR
SDK, but Apache Flex seems to want to allow an Apache Flex version to work
with as many AIR SDK versions as possible.
You right, but like in current the SDK, there's a default FP/AIR that you
can change with few efforts, it's the same with the mavenized one.
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.
and there wouldn't need to be an "mavenizer" to copy any of these
binaries into your local Maven repo.
If all the SDKs become mavenized and hosted on public repositories, the only
use of the mavenizer gonna be to create those SDKs and push them to these
public repositories and preferably done by the companies who own these SDKs.
Thanks for being patient. I'm still coming up to speed on this stuff.
Welcome :)
- Fred.
-----Message d'origine-----
From: Alex Harui
Sent: Sunday, November 25, 2012 5:15 AM
To: flex-dev@incubator.apache.org
Subject: Re: Who's a flex compiler-configuration pro on this list?
On 11/24/12 5:16 PM, "Frédéric THOMAS" <webdoubl...@hotmail.com> wrote:
Switching SDK, is as easy as changing a property in only one pom.xml,
nothing else to do as soon as the SDK you want to use is mavenized
obviously, the player itself is not needed, we can specify the target
version but there's no dependencies.
During the SDK mavenization process (with the mavenizer), a relation
between
Flex SDK and Air SDK is etablished, it's done by comparing the checksum of
the airglobal.swc inside each Air SDKs and the ones inside each Flex SDKs.
I might still be confused but I thought that the goal of getting Adobe to
put pom.xml files with its SDKs is so that there doesn't really need to be a
mavenizer. My understanding is that a mavenizer takes stuff you've
downloaded and packages it up into a local maven repo. Please correct me if
that is not true. I'm still trying to learn all of this stuff.
Also, Apache Flex is trying to break any tie between the Apache Flex SDK and
an AIR SDK. Adobe Flex used to only support a specific version of the AIR
SDK, but Apache Flex seems to want to allow an Apache Flex version to work
with as many AIR SDK versions as possible.
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, and there wouldn't need to be an "mavenizer" to copy any of these
binaries into your local Maven repo.
Or will there still be a mavenizer that needs to be run? If so, what will
it do?
but when building a .AIR file (and or an AIRI for signing) or a mobile
package,
I'm pretty sure other parts of the AIR SDK are involved and that they
might
change between AIR versions.
AFAIK, airglobal.swc and ADT only are needed for packaging into AIR, AIRI,
ANE, EXE, APK, IPA, ..., at the moment FlexMojos uses a class of the
adt.jar
called AIRPackager and call the createAIR method instead of using the ADT
class, therefore it can package only into AIR (which is already something
appreciated).
If you look in an AIR SDK, there are lots of files in there. Sure you might
only need to call adt.jar, but if you delete every other file in there
besides airglobal.swc, will you really get a valid AIR, AIRI, APK and
especially IPA? I mean, the AIR runtime has to get processed into the IPA
right? And the updater UI swfs in other packages?
And, I would still worry that adt.jar has some dependency
If you are pretty sure no other files are needed, let's actually try it.
Try using your mavenizer on a stripped down AIR SDK with only airglobal.swc
and adt.jar and see if you can create an IPA via maven. Or I will put up a
couple of versions of those two files on a server somewhere and those of you
who use Maven can try to see if they can switch between them.
Not sure I anwsered at everything you want, only the things I understood
you
want, ask again please for more precisions.
Thanks for being patient. I'm still coming up to speed on this stuff.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
