Yes, if we don't have to touch the Adobe packages we will be much better off.
I just got tentative approval from legal, but still need approval from runtime product management. One important thing, legal may want you to develop this plug-in without checking it into any public source code repository until they have a chance to see it work. They may change their minds later and let us develop the plug-in in the open, but that's their position for now. I guess you'd give me the plug-in and I would get Maven working on my computer and screen-share with them. So, I think you can get started on this, but don't check in into Apache SVN or GitHub just yet. Thanks, -Alex On 11/29/12 1:59 PM, "christofer.d...@c-ware.de" <christofer.d...@c-ware.de> wrote: > In maven if you want to use a library or a ressource, you define a dependency > to a groupId, artifactId and version (Optionally even a classifier). These 4 > attributes define the identity of the ressource. Think of the pom.xml as being > something similar to the tags soldiers wear around their necks. They identify > the person whos waering the tag. Just in case of maven there is no chain > around the neck of the ressource, but the link is the naming convention. I > guess you will not have to do anything to mavenize the Air SDKs, I allrady did > most of the coding needed to mavenize the content, so I would simply re-use > that code and do the mavenizing on the client side (I got the impression that > Adobe wouldn't like me providing you with a mavenized zip ... even if it were > nothing else than a zip containing the original ,but renamed, libs just > accompanied by a set of pom.xml files) > > Chris > > -----Ursprüngliche Nachricht----- > Von: Alex Harui [mailto:aha...@adobe.com] > Gesendet: Donnerstag, 29. November 2012 22:37 > An: flex-dev@incubator.apache.org > Betreff: Re: AW: AW: AW: AW: AW: AW: AW: AW: [POLL] Maven and Apache Flex > > > > > On 11/29/12 11:48 AM, "christofer.d...@c-ware.de" > <christofer.d...@c-ware.de> wrote: > >> 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. > Ah ok. I get it now. >> >> 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. > I will try to get this approved. > > One more question about the AIR SDK zip: Why do you need pom.xml files in the > subfolders of the AIR SDK to run the tools in there? > > 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
