incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject AW: AW: AW: AW: AW: AW: AW: AW: [POLL] Maven and Apache Flex
Date Thu, 29 Nov 2012 19:48:50 GMT
Hi Alex,

a local maven repo is on the machine the build is running ... that's one repo per machine.
Think of it as a Maven-Cache. So if I run the build on my machine, the artifacts are available
on that machine, but not on any other one. 

My idea was that if the build is set to "non-interactive" and the mojo detects missing runtime
artifacts from Adobe, that it would output the license agreement and at the bottom output
a message, that if the user accepts this agreement he has to run the build again and provide
a system-property "-DIAcceptTheAdobeLicense=34854395704857204572098457024870" (The number
is generated every time the mojo is run and no IAcceptTheAdobeLicense property is prvided).
The generated token is saved in a place the plugin can find it again the next time it runs
(temp-dir). If the token is provided in the next run, the mojo will download the stuff and
deploy it on the local machine only.

Ok so this is not 100% fool-proof but at least as fool-proof as creating an automated http-downloader
that checks the "i agree" checkbox on the Adobe download.


-----Ursprüngliche Nachricht-----
Von: Alex Harui [] 
Gesendet: Donnerstag, 29. November 2012 20:39
Betreff: Re: AW: AW: AW: AW: AW: AW: AW: [POLL] Maven and Apache Flex

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

> No you would not leave the key under the doormat ... the token would 
> be generated for every request and would be different every time you 
> use it. If the token wouldn't change, there would be no point in 
> implementing this that way.
Maybe I'm not understanding how the token works. We will have to document the non-interactive
mode.  Why wouldn't everyone use it to bypass the license acceptance?

> I was more thinking of headless CI servers. Such as the Apache Flex 
> Build-Servers. I couln't see a way to allow interaction in those cases.
I'm also thinking of headless CI servers.  But I would expect that before a Maven script gets
submitted to a CI server some developer has run a Maven script on his own computer which forced
him to accept the license and then downloaded the artifacts to the same local repo the CI
server will be using.
Then the CI server will never need to accept a license, so there should be no need for a non-interactive
> Chri
> -----Ursprüngliche Nachricht-----
> Von: Alex Harui []
> Gesendet: Donnerstag, 29. November 2012 19:22
> An:
> Betreff: Re: AW: AW: AW: AW: AW: AW: [POLL] Maven and Apache Flex
> 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?
> Thanks,
> -Alex
> 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:
>> o 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
>> 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.

Alex Harui
Flex SDK Team
Adobe Systems, Inc.

View raw message