Hi Alex, > IIRC, the Mavenizer's main goal is to install Adobe and other third-party assets to a on a build machine. Is that correct?
Yes in the meaning a company where devs use Maven has generally a CI and No because even though it is not a corporate use, we still gave the possibility to the dev to install the SDK (third-party included) into its local repo (and generally a dev machine is not used as a CI even though usually, the dev runs the Maven builds and tests from its machine before to upload its code to the VCS which trigger the CI) But usually the dev should get the SDK from its company repo, not from a third-party software or even directly from internet and the first time the SDK is requested, the company repo hasn't got it yet but because it proxies a public repo which host the SDK, the first time there's a request for it, the company repo download the SDK and then serves it their devs. Until now, the problem was we couldn't host the SDK in a public repo because it would let those who download it, to download the third-party as well without accept the Adobe licenses. Now, if I lock the repo with a credential that can be obtain officially only via the installer accepting the third-party licenses, a user or a company that would have accepted those licenses from the installer (and only once) could then get the credential and so, the SDK. Thanks, -Fred -----Message d'origine----- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : lundi 28 octobre 2013 17:19 À : dev@flex.apache.org Objet : Re: AW: AW: AW: Add Mavenizer functionality to Installer As usual, I'm not sure I understand Maven and Maven-izing, so apologies if I'm way off base: IIRC, the Mavenizer's main goal is to install Adobe and other third-party assets to a on a build machine. Is that correct? I can certainly see the Installer doing that, but yes, there was a recent discussion to make the Installer more like a mini-Ant so that more of the logic will happen in an xml-based script instead of in the installer itself. The Installer would then be an engine for performing certain operations in a cross-platform way. If nobody else gets to it, I'll probably be trying to make that happen in order to roll out an alpha-level FlexJS release around the end of year. I would not advise to distribute the Adobe artifacts from Sonatype unless you establish Sonatype as a licensed distributor for those artifacts, which is definitely possible. -Alex On 10/28/13 8:22 AM, "christofer.d...@c-ware.de" <christofer.d...@c-ware.de> wrote: >Well at sonatype they do distinguish between SNAPSHOT and Release >Versions. So the process of updating SNAPSHOTS is far less complicated >than that of deploying Releases. But I still think that your process of >creating individual users will introduce some Problems (Settings.xml >sharing) > >Nevertheless ... I think I should make Flexmojos use the Apache GID ... >I doubt I will find the time to work much on the new plugin in the near >future and I would like to have promote the Apachiness of Flex ;-) > >Chris > >________________________________________ >Von: Frédéric THOMAS [webdoubl...@hotmail.com] >Gesendet: Montag, 28. Oktober 2013 16:07 >An: dev@flex.apache.org >Betreff: RE: AW: AW: Add Mavenizer functionality to Installer > >Chris, > >Do you think Sonatype would allows the creation of specific user >granted to download the SDK ? It would be nice but I'm not sure, plus I >would need to deal with their heavy process to deal with snapshot and >release on non-maven built projects, I don't today, I just upload a zip >and tomorrow, I will just tell jenkins to deploy the build (mavenized >SDK) to Artifactory, not sure it is as easy as that with sonatype, at >least from what I remember. > >What do you think ? > >Frédéric THOMAS > >> From: christofer.d...@c-ware.de >> To: dev@flex.apache.org >> Date: Mon, 28 Oct 2013 14:18:50 +0100 >> Subject: AW: AW: Add Mavenizer functionality to Installer >> >> Well in that case, I would opt for creating an Apache Flex account at >>sonatype and to Stage and Deploy stuff there ... (The way Velo did it) >>... I guess there is legally no real difference between a Company repo >>and the big sonatype repo. Actually we don't have permission to >>publish stuff in either solution. >> >> This is also where I deploy the Flexmojos Libs as well as I helped >>deploy the latest FlexUnit release. >> >> On the cool side this is probably allready in the list of allmost all >>Major Nexus/Artifactory/Whatsoever instances and therefore there would >>probably not be any Problems with accessing the artifacts. But if such >>an Approach would be taken, I guess I would create a new Major Version >>of Flexmojos, which runs on Apache Flex's GID org.apache.flex instead >>of the current com.adobe.flex. >> >> Chris >> >> ________________________________________ >> Von: Frédéric THOMAS [webdoubl...@hotmail.com] >> Gesendet: Montag, 28. Oktober 2013 13:42 >> An: dev@flex.apache.org >> Betreff: RE: AW: Add Mavenizer functionality to Installer >> >> You're right, that's my exp too but from the company I'm working for >>at the moment, this is the only way as the installer doesn't work from >>here plus,I don't think an ApacheFlex VM managed by PMCs and almost >>dedicated to it will be "no-name" for long time :-) >> >> Frédéric THOMAS >> >> > From: christofer.d...@c-ware.de >> > To: dev@flex.apache.org >> > Date: Mon, 28 Oct 2013 12:18:48 +0100 >> > Subject: AW: Add Mavenizer functionality to Installer >> > >> > But from my experiance it is usually more difficult to convince the >>Company-Repo admins to add a "no-name" repo as source. At least most >>of the companies I've worked for. And deploying of a new Flex Version >>would probably not be done by any ordinary developer, but by one >>Special Person that is permitted to do so. >> > >> > Chris >> > >> > ________________________________________ >> > Von: Frédéric THOMAS [webdoubl...@hotmail.com] >> > Gesendet: Montag, 28. Oktober 2013 10:53 >> > An: dev@flex.apache.org >> > Betreff: RE: Add Mavenizer functionality to Installer >> > >> > 1- I'm short of time at the moment and that's a long run even >> > without thinking to integrate with the actual code >> > 2- Anyway, before I integrate anything in the actual code of the >>installer, >> > its code needs to be refactored >> > 3- There's no jar produced at the moment for the converter, that >>something >> > to be considered too. >> > 4- It's not allowed in every company the user can manage the repo >> > he >>wants >> > to access, in big ones, he has to go by the company one which in >>return, >> > proxied the repo they choose. >> > >> > -Fred >> > >> > -----Message d'origine----- >> > De : christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de] >> > Envoyé : lundi 28 octobre 2013 10:43 À : dev@flex.apache.org Objet >> > : AW: Add Mavenizer functionality to Installer >> > >> > Still I can't really see what would be the Problem to add the >>mavenizer to >> > the Installer? I guess this would resolve any legal Problems. I do >>see some >> > Major Speed improvement Option to Switch the Deployer to use Mavens >>wagon >> > instead of making hundreds of mvn-calls, but adding the mavenizer >> > to >>the >> > installer still seems to be the best Option from my Point of view. >> > >> > Chris >> > >> > ________________________________________ >> > Von: Frédéric THOMAS [webdoubl...@hotmail.com] >> > Gesendet: Montag, 28. Oktober 2013 10:17 >> > An: dev@flex.apache.org >> > Betreff: RE: Add Mavenizer functionality to Installer >> > >> > Hi Justin, >> > >> > >What to stop users sharing that URL and/or user credentials around? >> > >> > I thought about it too and ended to think I don't want to add more >> > restrictions than what exists today, I mean today, once you >> > accepted a license and downloaded an Adobe Artifact, you can share >> > it as you >>like, >> > that's not even nominative. >> > I just want to replicate the actual security, so, yes, if an user >>wants to >> > share the credentials, it can do it, as it can do it with the >> > artifact itself. >> > >> > > As long as you make it clear that these are not official releases >>and >> > > for >> > development use only as per Apache policy. >> > >> > Np, it will be suffixed with "-SNAPSHOT " with means in Maven, >>non-released >> > >> > > Could it cope with it load and the costs that is likely to incur >> > > (assume >> > 100 or 200 installs a day)? Who owns and maintains the server? >> > Could >>the >> > apache Flex PMC be given access to it? >> > >> > From what I understand, I'm not charged or should be very low rate, >> > I >>will >> > verify anyway, can't do it now, windowsazure has a 401. >> > I own and maintain the server, it is the same kind than the Erik >>ones, it >> > will serve me for some of my devs too (probably) or / and to test >> > the >>SDK >> > RCs and I can give access to PMCs who ask me. >> > >> > Thanks, >> > -Fred >> > >> > -----Message d'origine----- >> > De : Justin Mclean [mailto:jus...@classsoftware.com] Envoyé : lundi >> > 28 octobre 2013 10:03 À : dev@flex.apache.org Objet : Re: Add >> > Mavenizer functionality to Installer >> > >> > Hi, >> > >> > > From the Installer, users already have to accept licenses for the >> > > third party artifacts, for those users I can grant access to a >>online >> > > maven repo which serves the Mavenized SDKs >> > What to stop users sharing that URL and/or user credentials around? >> > >> > > I can even add the lasts nightly mavenized build versions. >> > As long as you make it clear that these are not official releases >> > and >>for >> > development use only as per Apache policy. >> > >> > > The server exist today as it serves me, it serves up to the 4.11 >> > > version >> > Could it cope with it load and the costs that is likely to incur >>(assume 100 >> > or 200 installs a day)? Who owns and maintains the server? Could >> > the >>apache >> > Flex PMC be given access to it? >> > >> > Thanks, >> > Justin
