incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: AW: AW: AW: AW: AW: AW: [POLL] Maven and Apache Flex
Date Thu, 29 Nov 2012 18:22:04 GMT
Hi Chris,

I can ask, but the non-interactive mode sounds like leaving the key under
the doormat and telling everyone where it is.

It would seem to me that you would never need a non-interactive mode.  Once
anyone from your company runs the mojo, wouldn't the artifacts be in the
local repo after that so for any CI server the mojo wouldn't do anything and
just keep on going?


On 11/29/12 10:02 AM, ""
<> wrote:

> Hi Alex,
> Oh ... I already had completely abandoned all hope of being able to download
> without a custom downloader ... so that's no big deal :-)
> There is no need for the browser plugin. The projector seems to be enough
> (Think it doesn't even have to be the debugger.
> So let us focus on a plugin that takes care of presenting the license
> agreement tot he user and downloading the stuff after the user accepted it.
> Would this be a valid approach?
> I wrote down the workflow of such a plugin in the maven-plugin-brainstorming
> page oft he Flex wiki:
> Would you and Adobe agree to such a solution?
> Chris
> -----Urspr√ľngliche Nachricht-----
> Von: Alex Harui []
> Gesendet: Donnerstag, 29. November 2012 18:19
> An:
> Betreff: Re: AW: AW: AW: AW: AW: [POLL] Maven and Apache Flex
> On 11/28/12 11:22 PM, ""
> <> wrote:
>> Hi Alex,
>> well regarding the Flashplayer ... is is actually needed during the
>> build. Not for actually building the SWF, but more for running the
>> unit-tests.
> Rats, I hadn't noticed that you needed the Flash runtimes in Maven.  It is
> always the standalone projector debuggers?  Or are there browser plugins?
> There is definitely no way I can imagine Adobe allowing the runtime to be
> downloaded without user acceptance, so I guess the maven plugin that accepts
> the license will definitely be required.
>> Ok ... I would then suggest that we decide a fixed url pattern in
>> which I could build a tool to automatically download zip files of
>> flash-runtime (player + playerglobal) and air-runtime (sdk containing
>> airglobal) for the different versions and platforms. The tool would
>> then deal with mavenizing them on the client side. What would be good
>> though, if all the zips had the same structure. Especially the
>> flashplayer did have multiple names in the different Flex SDKs it would be
>> cool if they were all called "flashplayer" ...
>> at least this would make my life a lot easier :-). In this case you
>> don't need any poms at all ... after all writing a pom to download a
>> zip-file that you need to unpack an process before you can use it's
>> content doesn't sound very Maven like to me.
>> Would this be possible?
> Well, I would have to check with the runtime folks if we start messing with
> the packaging they distribute.  Right now I think you are talking about four
> different downloads from the Adobe site (playerglobal, FlashPlayer, AIR SDK,
> AIR Desktop Runtime).  Can we leave it at those four?
> Regarding their names, I would have to see if we can get permission to change
> packaging names.  I'm pretty sure I can choose folder names for storing them
> if that helps.  Would it work if Adobe had an .xml file somewhere that mapped
> some id and version to the actual package names?
> Since you say you could write a tool, that sounds different from the maven
> plugin that is winning in the poll, is that true?
> I'm not sure what you have to process in an AIR SDK after you unpack it.  Do
> you really need to put individual pom.xmls in the AIR SDK tree?  IMO, they are
> all interdependent.  I don't think you should be mixing pieces from different
> versions of the AIR SDK.
> We are all Maven-ignorant at Adobe, so for any extra piece of work we have to
> do, it will help you can explain how it will improve adoption of Apache Flex.
> Thanks,
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.

Alex Harui
Flex SDK Team
Adobe Systems, Inc.

View raw message