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" <aha...@adobe.com.invalid> 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 http://dist.a.o/dev/royale/rc1/<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://stackoverflow.com/questions/21355508/publish- > development-version-of > -npm-package > > On 12/18/17, 9:19 AM, "omup...@gmail.com on behalf of OmPrakash Muppirala" > <omup...@gmail.com on behalf of bigosma...@gmail.com> 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" <aha...@adobe.com.invalid> 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, "omup...@gmail.com on behalf of OmPrakash > Muppirala" > ><omup...@gmail.com on behalf of bigosma...@gmail.com> wrote: > > > >>On Mon, Dec 18, 2017 at 12:41 AM, Alex Harui <aha...@adobe.com.invalid> > >>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, "omup...@gmail.com on behalf of OmPrakash > >>> Muppirala" <omup...@gmail.com on behalf of bigosma...@gmail.com> > wrote: > >>> > >>> >On Sun, Dec 17, 2017 at 10:52 PM, Alex Harui > >>><aha...@adobe.com.invalid> > >>> >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, "omup...@gmail.com on behalf of OmPrakash > >>> >>Muppirala" > >>> >> <omup...@gmail.com on behalf of bigosma...@gmail.com> 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 > >>> >> > >>> >> > >>> > >>> > >
