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?
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 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. 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. It sounds like you are basically reverting all of the NPM work I just did. :-( How were you planning to provide nightly builds and not modify approved sources to publish NPM artifacts? 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 >> >>
