I think this was what Velo was refering to as "FlexMojos Enterprize", his
commercial Branch of FM.
But I agree, when starting from scratch, we should do it the right way so
all the mobile stuff can be done too.
Ok.
-----Message d'origine-----
From: Frédéric THOMAS
Sent: Sunday, November 25, 2012 2:05 PM
To: flex-dev@incubator.apache.org
Subject: Re: AW: Who's a flex compiler-configuration pro on this list?
Hi,
Actually, reading you Chris, my 2.5 scenario, where adobe would deploy their
sdks, is wrong (sorry @Alex, I had to think more about before talking).
target 100% would be cooler, but 80% is better than 0%.
Yes, and that may evolve.
@Chris,
Am I wrong or I read somewhere Velo discontinued its Commercial Flexmojos
Enterprize and now, he provides this feature case by case, being paid for
that, re-integrating some changes in specific versions at demand only ?
Have you already thing about the ADT usage instead of the AIRPackager ?
- Fred
-----Message d'origine-----
From: christofer.d...@c-ware.de
Sent: Sunday, November 25, 2012 1:38 PM
To: flex-dev@incubator.apache.org
Subject: AW: Who's a flex compiler-configuration pro on this list?
Exactly.
Currently noone is providing the FDKs publically, because at least the
dependencies to the two or three Adobe artifacts that are not available via
Maven.
Even if only manually deploying these artifacts isn't such a show-stopper as
having to deploy the entire FDK, I think most users are used not having to
do anything at all and this would prevent a lot of maven newbes from using
flex in maven. At least this is the impression I am having while servicing
the Flexmojos Mailinglist. Most users are consumers and not willing to eaven
read a README file (Think you probably noticed that problem when releasing
the first Apache Flex)
I can see the following scenarios (each step going down the maven road even
further):
1. Using the Mavenizer to locally deploy FDKs.
2. Apache uses the Mavenizer to mavenize a new FDK release and deploys those
artifacts in a public repo.
3. Building Flex with Maven, eliminating the need to use the Mavenizer all
together.
I agree that there might be some issues with the native packaging and mobile
deployment. This is currently only handled by Velos Commercial Flexmojos
Enterprize and these features are not part of the normal FM currently. So I
agree that there might be some issues with the build needing more artifacts.
But I think with the two or three artifacts discussed in this thread, we
should be albe to target about 80% of the normal users use-cases. Being able
to target 100% would be cooler, but 80% is better than 0%.
Chris
-----Ursprüngliche Nachricht-----
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Sonntag, 25. November 2012 08:59
An: flex-dev@incubator.apache.org
Betreff: Re: Who's a flex compiler-configuration pro on this list?
Christopher Dutz gave me the impression that all Adobe would have to do is
place a pom.xml alongside each playerglobal.swc. Is there more to it?
I guess the goal behind that is to be able to get those artefact from a
legal repo, we can not legaly provide them from inside the mavenized apache
flex sdk, I guess what Chris want to do, is to make our sdk public via the
apache repo and get those last artifacts from adobe, doing so, if only the
the apache flex sdk is publicly available, that should not be a problem for
companies to host internaly the new structure of the new sdk and the old
structure of the others, they could use fm<6 and fm 6 on different projects.
The only thing is they shouldn't have to use the mavenizer to convert the
SDKs otherwize they whould break the compatibility with the old flexmojos.
The mavenizer should be use only by us, in this case to mavenized our sdk.
- Fred.
-----Message d'origine-----
From: Alex Harui
Sent: Sunday, November 25, 2012 7:32 AM
To: flex-dev@incubator.apache.org
Subject: Re: Who's a flex compiler-configuration pro on this list?
On 11/24/12 9:28 PM, "Frédéric THOMAS" <webdoubl...@hotmail.com> wrote:
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.
The main issue with Adobe making its stuff Maven friendly is legal. There
is stuff in the AIR SDK that Adobe doesn't want to put in the "open" world.
It appears from my reading that plenty of other Maven apps are built with
closed source code via "mavenizers" that copy downloaded assets into local
repos. Why is this not ok for big companies?
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.
Christopher Dutz gave me the impression that all Adobe would have to do is
place a pom.xml alongside each playerglobal.swc. Is there more to it?
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.
I'm confused where you said in the other response that adt.jar has
everything you need, but here you say the entire AIR SDK is needed.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
