On 11/29/12 11:11 AM, "christofer.d...@c-ware.de" <christofer.d...@c-ware.de> 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 mode. > > Chri > > > -----Ursprüngliche Nachricht----- > Von: Alex Harui [mailto:aha...@adobe.com] > Gesendet: Donnerstag, 29. November 2012 19:22 > An: flex-dev@incubator.apache.org > 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, "christofer.d...@c-ware.de" > <christofer.d...@c-ware.de> 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: >> https://cwiki.apache.org/confluence/display/FLEX/deploy-artifacts-mojo >> Would you and Adobe agree to such a solution? >> >> Chris >> >> -----Ursprüngliche Nachricht----- >> Von: Alex Harui [mailto:aha...@adobe.com] >> Gesendet: Donnerstag, 29. November 2012 18:19 >> An: flex-dev@incubator.apache.org >> Betreff: Re: AW: AW: AW: AW: AW: [POLL] Maven and Apache Flex >> >> >> >> >> On 11/28/12 11:22 PM, "christofer.d...@c-ware.de" >> <christofer.d...@c-ware.de> 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. >> http://blogs.adobe.com/aharui >> > > -- > Alex Harui > Flex SDK Team > Adobe Systems, Inc. > http://blogs.adobe.com/aharui > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
