On Mon, Dec 18, 2017 at 10:41 AM, Alex Harui <[email protected]> wrote:
> Hi Om, > > I have not tested the royale-swf package and I wouldn't be surprised if > that package needs help since it does have a script that downloads other > stuff, so it would be a great help if you could make sure that package is > working and that npm installs of the nightly builds works in general. > So, with the new folder structure of the binary artifacts, what exactly needs to be downloaded? Today we download these: Adobe Air Falcon FlexJS (I know this is not required anymore) FlashPlayerGlobal FlatUI SWFObject. Thanks, Om > > I also wondered as I was copying the old FlexJS scripts into the Royale > repo how those post-install scripts handle the difference between Mac and > Windows for downloading AIR SDKs. Verifying that works for Mac and Win > would be helpful as well, especially now that Mac AIR SDKs are DMG files. > > Thanks, > -Alex > > On 12/18/17, 10:26 AM, "[email protected] on behalf of OmPrakash > Muppirala" <[email protected] on behalf of [email protected]> wrote: > > >Okay, this is one way to do it which I am not too opposed to. > > > >So, at this point, I assume there is nothing else to do to as far as npm > >goes? > > > >How can I help? > > > >I will leave my branch as is in case we decide to go that route at a later > >point of time. > > > >Thanks, > >Om > > > >On Dec 18, 2017 10:04 AM, "Alex Harui" <[email protected]> wrote: > > > >> That is the question I've been asking for several posts now. AIUI, when > >> you publish a package in NPM, the package is copied to NPM's servers. > >> > >> This post [3] implies that we should not use "npm publish" on anything > >> that isn't released. > >> > >> So my conclusion, and what I checked in, was two NPM packages (royale > >>and > >> royale-swf) that are the same as the binary convenience package > >>generated > >> by Ant, since I think the NPM package must be generated by a build of > >>the > >> source package. To get a nightly, you use: > >> > >> npm install <url to nightly> > >> > >> The royale and royale-swf packages have different URLs up on the CI > >>server. > >> > >> To get the RC versions some day, you would run: > >> > >> npm install > >>https://na01.safelinks.protection.outlook.com/?url=http% > 3A%2F%2Fdist.a.o% > >>2Fdev%2Froyale%2Frc1%2F&data=02%7C01%7Caharui%40adobe.com% > 7C3b7528a1b1794 > >>ae1c2c908d54644ef3f%7Cfa7b1b5a7b34438794aed2c178decee1% > 7C0%7C0%7C63649218 > >>4244391614&sdata=d%2FWzPpXZkvvcZHzBBkeadPlM35meS2s4eQnfrmp > ctjU%3D&reserve > >>d=0<binary-convenience-package> > >> > >> It is my understanding that when the vote passes, the release manager > >> script will move the bits from dist.a.o/dev to dist.a.o/release and can > >> just run "npm publish" for both royale and royale-swf and it will copy > >>the > >> convenience packages to NPM's servers and then when folks do: > >> > >> npm install royale (or royale-swf) > >> > >> It will download that package and no mirrors are involved at all (which > >> reduces a point of failure for us). > >> > >> Again, I am an NPM newbie, so maybe I am making a bad assumption, but > >>this > >> is my understanding based on the links I've presented. > >> > >> Thanks, > >> -Alex > >> > >> [3] > >> > >>https://na01.safelinks.protection.outlook.com/?url=https% > 3A%2F%2Fstackove > >>rflow.com%2Fquestions%2F21355508%2Fpublish-&data=02%7C01% > 7Caharui%40adobe > >>.com%7C3b7528a1b1794ae1c2c908d54644ef3f%7Cfa7b1b5a7b344387 > 94aed2c178decee > >>1%7C0%7C0%7C636492184244391614&sdata=W0Zj1lQd7OYFnZ6tUd9km > epdXhJjtJhTpa%2 > >>Bg03HiPWk%3D&reserved=0 > >> development-version-of > >> -npm-package > >> > >> On 12/18/17, 9:19 AM, "[email protected] on behalf of OmPrakash > >>Muppirala" > >> <[email protected] on behalf of [email protected]> wrote: > >> > >> >We need multiple versions of package json: release jsonly, nightly > >>jsonly, > >> >rc jsonly, release jsandswf, nightly jsandswf, rc jsandswf. > >> > > >> >Nightly and rc builds need to be loaded from static urls, wheras > >>releases > >> >need to be loaded from a mirror. Where will mirror url resolution > >>take > >> >place? > >> > > >> >How are you planning to support this in your approach? > >> > > >> >Thanks, > >> >Om > >> > > >> > > >> >On Dec 18, 2017 8:45 AM, "Alex Harui" <[email protected]> > wrote: > >> > > >> >Hi Om, > >> > > >> >My logic is that package.json goes into a binary artifact for NPM, so > >>at > >> >some point, we are supposed to vote on package.json being correct. If > >>you > >> >modify package.json after the vote, or don't put in in a source > >>artifact, > >> >we are technically releasing an unapproved file. > >> > > >> >If we find something wrong with any of our binary artifacts, we > >>probably > >> >have to cut another release if it requires a change to any file in our > >> >source package to fix it. Why is NPM a bigger risk for problems than > >> >Maven or Ant? > >> > > >> >Testing changes to NPM packaging shouldn't require waiting for the CI > >> >server. You run the build locally, and run "npm install <path to > >>output > >> >folder or gzip>" See [2] > >> > > >> >Scripting string replacement to change the package URL from the CI > >>server > >> >to the mirror system is potentially tricky. We did that for Flex and > >>the > >> >Installer and sometimes I had to manually correct it, and I was glad to > >> >see that we didn't need it in Royale if we had NPM distribute the > >>binary > >> >package. > >> > > >> >It looks to me that NPM has a "convention" to use URLs for nightly > >>builds > >> >and that we should use it, and not create our own, or have to rely on > >>the > >> >mirror system either. That's what I had checked in. The thing I liked > >> >about it was that when you installed the js-only package, no further > >> >scripts needed to be run. The package is self contained and didn't > >>need > >> >to go out to another server. > >> > > >> >What I checked in I thought was more conforming to NPM's conventions > >>and > >> >reduced a point of failure by not relying on the mirror system. But > >>I'm > >> >an NPM newbie, so I may be missing something. > >> > > >> >-Alex > >> > > >> >[2] > >> >https://na01.safelinks.protection.outlook.com/?url= > >> https%3A%2F%2Fdocs.npmj > >> >s.com%2Fhow-npm-works%2Fpackages&data=02%7C01%7Caharui%40adobe.com > >> %7C4e762 > >> >d4c0a6340f2307408d5463b8432%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C0%7C0%7C6 > >> >36492143796733169&sdata=MF%2FOg7za7B0K0g7aMIoXMn% > >> 2BeS41nz4f3Do%2B17u7dzdU% > >> >3D&reserved=0 > >> > > >> >On 12/18/17, 1:14 AM, "[email protected] on behalf of OmPrakash > >> Muppirala" > >> ><[email protected] on behalf of [email protected]> wrote: > >> > > >> >>On Mon, Dec 18, 2017 at 12:41 AM, Alex Harui > >><[email protected]> > >> >>wrote: > >> >> > >> >>> Hi Om, > >> >>> > >> >>> I'm not sure what your definition of "direct dependency" is, but we > >> >>> already have Maven stuff in the source package so we can directly > >> >>>publish > >> >>> Maven artifacts to Maven central. What is wrong with having NPM > >>stuff > >> >>>in > >> >>> the source package as well? > >> >>> > >> >> > >> >>If something went wrong with an npm release, we will need a new > >>release > >> >>of > >> >>the Source and Binary artifacts. That takes a much longer time. We > >> >>should > >> >>avoid a scenario like the dependency between the SDK and the > >>Installer, > >> >>which sometimes requires a new release of SDK for pushing out changes > >>to > >> >>the Installer. > >> >> > >> >> > >> >>> > >> >>> The plan is currently to run the Maven release steps, which will > >>create > >> >>>a > >> >>> set of 3 source artifacts (one per-repo), then run an Ant script > >>that > >> >>> turns those 3 source artifacts into one source artifact that we vote > >> >>>on, > >> >>> along with two IDE-friendly binary artifacts (with and without SWF > >> >>> support), and dozens of Maven SWCs and JARs, and, as the scripts > >> >>>are/were > >> >>> currently setup, the two IDE-friendly binary artifacts should have > >>been > >> >>> valid NPM artifacts. Once the vote is approved, the Maven > >>artifacts go > >> >>>to > >> >>> Maven Central, the IDE-friendly artifacts go to dist.a.o, and > >> >>> theoretically, those same artifacts get published to NPM > >>(unmodified). > >> >>> And that can all be scripted. > >> >>> > >> >> > >> >>I don't get the part where it has to be unmodified. Right now, if I > >>need > >> >>to change the package.json, I need to push a fix, wait for a nightly > >> >>build > >> >>before I can test it out. If we do it my way, composing the npm > >>package > >> >>is > >> >>a completely separate process without having to wait for sdk changes > >>to > >> >>be > >> >>propagated. > >> >> > >> >> > >> >>> > >> >>> I don't know NPM that well, so maybe something does have to change > >>in > >> >>> package.json before actual publication, but if not, I don't > >>understand > >> >>>why > >> >>> the RM should need to do more than just run "npm publish" once or > >> >>>twice. > >> >>> IMO, it is sort of cheating to modify package.json or any other > >>files > >> >>> after a vote on those files to create the NPM artifacts. > >> >>> > >> >> > >> >>Only if package.json is part of the source artifact. I don't see the > >> >>need > >> >>to have package.json file and other npm related scripts in the source > >>or > >> >>binary artifacts. > >> >> > >> >> > >> >>> > >> >>> Also, I think I proved that the Ant script on the CI server can > >>create > >> >>> valid NPM artifacts for nightly builds. I would think we would want > >> >>>that > >> >>> instead of needing some manual step to make nightly builds available > >> >>>for > >> >>> NPM users. > >> >>> > >> >> > >> >>Anything that is manual can be scripted. My goal is to make an > >>"publish > >> >>to > >> >>npm" script available that can be tacked on to the current release > >> >>process. > >> >> > >> >> > >> >>> > >> >>> It sounds like you are basically reverting all of the NPM work I > >>just > >> >>>did. > >> >>> :-( > >> >> > >> >> > >> >>I'm sorry about that. I was not paying attention to your commits in > >>this > >> >>area. What exactly am I reverting? The stuff I am doing right now is > >>in > >> >>addition to what you have already done. > >> >> > >> >> > >> >>> How were you planning to provide nightly builds and not modify > >> >>> approved sources to publish NPM artifacts? > >> >> > >> >> > >> >>I sent a couple of emails about this a while ago. > >> >>https://na01.safelinks.protection.outlook.com/?url= > >> https%3A%2F%2Flists.ap > >> >>a > >> >>che.org%2Fthread.html%2F86253b3e04f138d7c4ed6f1769c2 > >> 654da6d47b8ca10c88b7d > >> >>c > >> >>582d91%40%253Cdev.royale.apache.org%253E&data=02%7C01%7Caharui% > >> 40adobe.co > >> >>m > >> >>%7C6d10fd8a41454eda3c2c08d545f7e592%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C > >> >>0 > >> >>%7C0%7C636491853411797328&sdata=lDClXqNwbfMlYzDMjdu% > >> 2BonaFDU45N6NppoVHfsY > >> >>r > >> >>q70%3D&reserved=0 > >> >>https://na01.safelinks.protection.outlook.com/?url= > >> https%3A%2F%2Flists.ap > >> >>a > >> >>che.org%2Fthread.html%2F66e1ee3ce5ce0294b18913c83c79 > >> 4a8819893ba9bb73e77f5 > >> >>5 > >> >>b5cfce%40%253Cdev.royale.apache.org%253E&data=02%7C01%7Caharui% > >> 40adobe.co > >> >>m > >> >>%7C6d10fd8a41454eda3c2c08d545f7e592%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C > >> >>0 > >> >>%7C0%7C636491853411797328&sdata=iCM20R4mlH52eIWURoWvYzNregXW7P > >> eZJCM7KRhbs > >> >>U > >> >>0%3D&reserved=0 > >> >> > >> >>I am yet to get to this part. But we need to sort off agree on a path > >> >>before I can proceed. > >> >> > >> >> > >> >>> I'm shutting down for tonight > >> >>> so I'll pick this up in the morning. > >> >>> > >> >>> Thanks, > >> >>> -Alex > >> >>> > >> >>> On 12/17/17, 11:42 PM, "[email protected] on behalf of OmPrakash > >> >>> Muppirala" <[email protected] on behalf of [email protected]> > >> wrote: > >> >>> > >> >>> >On Sun, Dec 17, 2017 at 10:52 PM, Alex Harui > >> >>><[email protected]> > >> >>> >wrote: > >> >>> > > >> >>> >> Om, > >> >>> >> > >> >>> >> One thing I'm confused about: When I read about NPM publishing > >>[1], > >> >>>it > >> >>> >> sounds like you can publish a folder of stuff (and/or a gzip of > >>that > >> >>> >> folder) and thus the binaries shouldn't need to be downloaded > >>off of > >> >>>one > >> >>> >> of our servers. But it looks like the old FlexJS script and now > >> >>>these > >> >>> >> scripts are trying to download the binaries off of one of our > >> >>>servers. > >> >>> >> > >> >>> >> Thoughts? > >> >>> >> -Alex > >> >>> >> > >> >>> >> [1] > >> >>> >>https://na01.safelinks.protection.outlook.com/?url= > >> >>> https%3A%2F%2Fdocs.npm > >> >>> >>js.com%2Fgetting-started%2Fpublishing-npm-packages& > >> >>> data=02%7C01%7Caharui% > >> >>> >>40adobe.com%7Cc45ced0b53984ddecf5208d545eb06c2% > >> >>> 7Cfa7b1b5a7b34438794aed2c1 > >> >>> >>78decee1%7C0%7C0%7C636491798101208728&sdata= > >> >>> T3Ym%2BwQPX15EKsN7rWAZhtttSDv > >> >>> >>KxYARMMi3KiZqTd4%3D&reserved=0 > >> >>> > > >> >>> > > >> >>> >I am a bit unclear on your how you are thinking of publishing to > >>npm. > >> >>>You > >> >>> >want to simply publish the binary release artifact to npm? > >> >>> > > >> >>> >When will the properties in package.json be updated? When creating > >> >>>the > >> >>> >binary artifact or when we are publishing to npm? > >> >>> > > >> >>> >In my mind, the release artifact should not contain any npm related > >> >>>stuff. > >> >>> >As a release manager, I would like to download the release > >>artifact, > >> >>>add > >> >>> >in > >> >>> >all the npm related stuff and then publish to npm. I am adding > >>this > >> >>>logic > >> >>> >into a script so that the release manager can simply run it as > >>part of > >> >>>the > >> >>> >release process. > >> >>> > > >> >>> >This way, we don't have a direct dependency between the royale > >> >>>codebase > >> >>> >and > >> >>> >the npm related stuff. > >> >>> > > >> >>> >Thanks, > >> >>> >Om > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> >> > >> >>> >> > >> >>> >> On 12/17/17, 1:56 PM, "[email protected] on behalf of OmPrakash > >> >>> >>Muppirala" > >> >>> >> <[email protected] on behalf of [email protected]> wrote: > >> >>> >> > >> >>> >> >I have pushed a few changes to my branch: > >> >>> >> >https://na01.safelinks.protection.outlook.com/?url= > >> >>> >> https%3A%2F%2Fgithub.co > >> >>> >> >m%2Fapache%2Froyale-asjs%2Fcommits%2Ffeature%2Fnpm- > >> >>> >> scripts&data=02%7C01%7C > >> >>> >> >aharui%40adobe.com%7Cd583a0036a204c481bde08d54599 > >> >>> >> 0bde%7Cfa7b1b5a7b34438794 > >> >>> >> >aed2c178decee1%7C0%7C0%7C636491446017963669&sdata= > >> >>> >> DhjL2mrknpft7aEadZpgXnaV > >> >>> >> >g2w4AKcvSt8K1nQj9R4%3D&reserved=0 > >> >>> >> >Can someone give it a look over before I merge it into develop? > >> >>> >> > > >> >>> >> >Once it gets merged into develop, I can test out the build from > >>the > >> >>> >> >lastSuccessfulBuild from the jenkins build. > >> >>> >> > > >> >>> >> >I've given the package a dummy name till we test it out so that > >>we > >> >>> >>don't > >> >>> >> >accidentally push a build out. > >> >>> >> > > >> >>> >> >Thanks, > >> >>> >> >Om > >> >>> >> > >> >>> >> > >> >>> > >> >>> > >> > >> > >
