incubator-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: Apache Flex structure to be BMS compliant (was Re: Library Versions used in Flex SDK)
Date Fri, 25 May 2012 10:08:18 GMT
There actually are no things preventing us from converting Flex into a mavenized form. There
are only some ugly parts that I thought would be cool to resolve. Most of them relate to hacked
versions of standard libs.

I think the structural changes I was talking about could be performed at deployment time.


Fact is that there are some core-flex libraries, that flex and air need ... lets call them
flex-core.
Then there are libs for air and libs for flex only ... then there is a set of libs for automation
and one set for mobile devices ... I would like to have them deployed separately in individual
maven groups.

Curently I am deploying them allmost the way they are bundled in the SDKs but am generating
some pom-artifacts doing the grouping.

Ive attached my unfinished converter project to this mail (Hopefully it's not stripped out).
If it is and you would like me to send you a copy ... please contact me directly and I'll
send it to you.

What it does, is it looks at a directory containing a set of SDKs and processes each of them
to the output directory. Both directories have to be provided as parameters to the main class.
Inside each SDK it deploys everything in the SDKs lib directory as a compiler bundle, and
everything inside the frameworks/libs as Flex sdk (Except the playerglobal). 

In the compiler it generates checksums of every jar and does a search on Maven central to
see if the artifact is allready deployed. If it is, it uses that artifact instead of re-deploying
it. 

In the Frameworks part it has a look at the rsls first, because these have a version and uses
this version to deploy the libs (osmf and textLayout tend to have a different versioning scheme).
Currently I commented this out and am deploying all swcs with the fixed version number of
the sdk, because I haven't fixed Flexmojos to use a dynamic framework-swc version, but I'm
working on this.

I have tested building my Applications using Flexmojos 5.1 and Flex SDK 4.5.1.21328A and it
worked great. Think I might still have to do some fine-tuning, but I think it would be better
to hand this over to you and only participate in the fine-tuning.

Chris



-----Urspr√ľngliche Nachricht-----
Von: Alex Harui [mailto:aharui@adobe.com] 
Gesendet: Donnerstag, 24. Mai 2012 22:46
An: flex-dev@incubator.apache.org
Betreff: Re: Apache Flex structure to be BMS compliant (was Re: Library Versions used in Flex
SDK)




On 5/24/12 12:50 PM, "Carlos Rovira" <carlos.rovira@codeoscopic.com> wrote:

> I think IntelliJ will update quickly since they are 
> "maven-gradle-whatever-bms-oriented".
> Flash Builder never took into account BMS, but they will update due 
> that technology requeriments....or are you saying that they will 
> abandon Flex development?
Adobe is improving the next release of Flash Builder to be a bit more configurable so it can
work with Apache Flex SDKs.  After that, it is a business decision as to whether Adobe will
do any further work if the Apache Flex SDK evolves in a way that is incompatible.

If other tool vendors are more willing to make changes and therefore provide a more compelling
tool than Adobe, then we'll see folks move in that direction, and then we'll see if Adobe
chooses to compete or not.
> 
> moreover...are you saying that we must stay with what we have now?
> so...that's what we can expect for the future of flex? stay with the 
> same problems we ever had during all years? What kind of changes can we expect?
> only cosmetic changes?
We have to consider factors when proposing changes like installed base, what our users know
and expect.  But I think we can make some big changes over time.
> 
> Michel, you and Alex were talking about agresive changes in the SDK...i.e:
> a completely new set of flex components and arqutecture, isn't 
> it?...so changes like that will not obligate Adobe to update Fb in 
> order to make it Apache Flex compliant?
Flash Builder is not obligated to update to handle changes to the Apache Flex SDK.  One thing
we need to do is get some momentum so that there is a compelling market that would incite
Adobe to want to update FB so it can extract revenue from customer upgrades.  But if some
other tool vendor ends up creating a better tool and everyone starts using it and makes FB
a thing of the past, that's fine with me.

Most important to me is that we have to solve the important problems.  Maven integration is
the top vote getter at Adobe JIRA by far.  It is time to make adjustments to Apache Flex to
make Maven work, but we want to do so without breaking everyone else's workflow.

We have been forced by legal reasons to change the package structure.
Apache Flex releases cannot look like the tree of files you get from Adobe.
And since we're doing that, it is time to consider any changes to make Maven easier to support.
But we are not asking the tool vendors to change with us.
Instead, we are providing scripts to repackage the files from the various sources into something
the tools can use.


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


Mime
View raw message