Re: Testing npm deployment

[Alex Harui]

Royale (JSOnly) has no extra downloads.
Royale-swf needs the non-open stuff (AIR, Flash, Flat).


On 12/18/17, 12:20 PM, "omup...@gmail.com on behalf of OmPrakash
Muppirala"  wrote:

>On Mon, Dec 18, 2017 at 10:41 AM, Alex Harui 
>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, "omup...@gmail.com on behalf of OmPrakash
>> Muppirala"  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" 
>>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 
>> >>
>> >> 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=02%7C01%7Caharui%40adobe.com%
>> 7C3b7528a1b1794
>> >>ae1c2c908d54644ef3f%7Cfa7b1b5a7b34438794aed2c178decee1%
>> 7C0%7C0%7C63649218
>> >>4244391614=d%2FWzPpXZkvvcZHzBBkeadPlM35meS2s4eQnfrmp
>> ctjU%3D
>> >>d=0
>> >>
>> >> 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-=02%7C01%
>> 7Caharui%40adobe
>> >>.com%7C3b7528a1b1794ae1c2c908d54644ef3f%7Cfa7b1b5a7b344387
>> 94aed2c178decee
>> >>1%7C0%7C0%7C636492184244391614=W0Zj1lQd7OYFnZ6tUd9km
>> epdXhJjtJhTpa%2
>> >>Bg03HiPWk%3D=0
>> >> development-version-of
>> >> -npm-package
>> >>
>> >> On 12/18/17, 9:19 AM, "omup...@gmail.com on behalf of OmPrakash
>> >>Muppirala"
>> >>  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" 
>> 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 

Re: Testing npm deployment

[OmPrakash Muppirala]

On Mon, Dec 18, 2017 at 10:41 AM, Alex Harui 
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, "omup...@gmail.com on behalf of OmPrakash
> Muppirala"  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"  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 
> >>
> >> 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=02%7C01%7Caharui%40adobe.com%
> 7C3b7528a1b1794
> >>ae1c2c908d54644ef3f%7Cfa7b1b5a7b34438794aed2c178decee1%
> 7C0%7C0%7C63649218
> >>4244391614=d%2FWzPpXZkvvcZHzBBkeadPlM35meS2s4eQnfrmp
> ctjU%3D
> >>d=0
> >>
> >> 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-=02%7C01%
> 7Caharui%40adobe
> >>.com%7C3b7528a1b1794ae1c2c908d54644ef3f%7Cfa7b1b5a7b344387
> 94aed2c178decee
> >>1%7C0%7C0%7C636492184244391614=W0Zj1lQd7OYFnZ6tUd9km
> epdXhJjtJhTpa%2
> >>Bg03HiPWk%3D=0
> >> development-version-of
> >> -npm-package
> >>
> >> On 12/18/17, 9:19 AM, "omup...@gmail.com on behalf of OmPrakash
> >>Muppirala"
> >>  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" 
> 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 

Re: Testing npm deployment

[Alex Harui]

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.

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, "omup...@gmail.com on behalf of OmPrakash
Muppirala"  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"  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 
>>
>> 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=02%7C01%7Caharui%40adobe.com%7C3b7528a1b1794
>>ae1c2c908d54644ef3f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63649218
>>4244391614=d%2FWzPpXZkvvcZHzBBkeadPlM35meS2s4eQnfrmpctjU%3D
>>d=0
>>
>> 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-=02%7C01%7Caharui%40adobe
>>.com%7C3b7528a1b1794ae1c2c908d54644ef3f%7Cfa7b1b5a7b34438794aed2c178decee
>>1%7C0%7C0%7C636492184244391614=W0Zj1lQd7OYFnZ6tUd9kmepdXhJjtJhTpa%2
>>Bg03HiPWk%3D=0
>> development-version-of
>> -npm-package
>>
>> On 12/18/17, 9:19 AM, "omup...@gmail.com on behalf of OmPrakash
>>Muppirala"
>>  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"  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 >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 

Re: Testing npm deployment

[OmPrakash Muppirala]

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"  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 
>
> 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/
>
> 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"
>  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"  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  >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=02%7C01%7Caharui%40adobe.com
> %7C4e762
> >d4c0a6340f2307408d5463b8432%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6
> >36492143796733169=MF%2FOg7za7B0K0g7aMIoXMn%
> 2BeS41nz4f3Do%2B17u7dzdU%
> >3D=0
> >
> >On 12/18/17, 1:14 AM, "omup...@gmail.com on behalf of OmPrakash
> Muppirala"
> > wrote:
> >
> >>On Mon, Dec 18, 2017 at 12:41 AM, Alex Harui 
> >>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 

Re: Testing npm deployment

[Alex Harui]

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 

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/

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"
 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"  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 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=02%7C01%7Caharui%40adobe.com%7C4e762
>d4c0a6340f2307408d5463b8432%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6
>36492143796733169=MF%2FOg7za7B0K0g7aMIoXMn%2BeS41nz4f3Do%2B17u7dzdU%
>3D=0
>
>On 12/18/17, 1:14 AM, "omup...@gmail.com on behalf of OmPrakash Muppirala"
> wrote:
>
>>On Mon, Dec 18, 2017 at 12:41 AM, Alex Harui 
>>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 

Re: Testing npm deployment

[OmPrakash Muppirala]

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"  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 "  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://docs.npmjs.com/how-npm-works/packages

On 12/18/17, 1:14 AM, "omup...@gmail.com on behalf of OmPrakash Muppirala"
 wrote:

>On Mon, Dec 18, 2017 at 12:41 AM, Alex Harui 
>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 

Re: Testing npm deployment

[Alex Harui]

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 "  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://docs.npmjs.com/how-npm-works/packages

On 12/18/17, 1:14 AM, "omup...@gmail.com on behalf of OmPrakash Muppirala"
 wrote:

>On Mon, Dec 18, 2017 at 12:41 AM, Alex Harui 
>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.apa

Re: Testing npm deployment

[OmPrakash Muppirala]

On Mon, Dec 18, 2017 at 12:41 AM, Alex Harui 
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://lists.apache.org/thread.html/86253b3e04f138d7c4ed6f1769c2654da6d47b8ca10c88b7dc582d91@%3Cdev.royale.apache.org%3E
https://lists.apache.org/thread.html/66e1ee3ce5ce0294b18913c83c794a8819893ba9bb73e77f55b5cfce@%3Cdev.royale.apache.org%3E

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"  wrote:
>
> >On Sun, Dec 17, 2017 at 10:52 PM, Alex Harui 
> >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=
> T3Ym%2BwQPX15EKsN7rWAZhtttSDv
> >>KxYARMMi3KiZqTd4%3D=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 

Re: Testing npm deployment

[Alex Harui]

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, "omup...@gmail.com on behalf of OmPrakash
Muppirala"  wrote:

>On Sun, Dec 17, 2017 at 10:52 PM, Alex Harui 
>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=02%7C01%7Caharui%
>>40adobe.com%7Cc45ced0b53984ddecf5208d545eb06c2%7Cfa7b1b5a7b34438794aed2c1
>>78decee1%7C0%7C0%7C636491798101208728=T3Ym%2BwQPX15EKsN7rWAZhtttSDv
>>KxYARMMi3KiZqTd4%3D=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"
>>  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=02%7C01%7C
>> >aharui%40adobe.com%7Cd583a0036a204c481bde08d54599
>> 0bde%7Cfa7b1b5a7b34438794
>> >aed2c178decee1%7C0%7C0%7C636491446017963669=
>> DhjL2mrknpft7aEadZpgXnaV
>> >g2w4AKcvSt8K1nQj9R4%3D=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
>>
>>

Re: Testing npm deployment

[OmPrakash Muppirala]

On Sun, Dec 17, 2017 at 10:52 PM, Alex Harui 
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://docs.npmjs.com/getting-started/publishing-npm-packages


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"
>  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=02%7C01%7C
> >aharui%40adobe.com%7Cd583a0036a204c481bde08d54599
> 0bde%7Cfa7b1b5a7b34438794
> >aed2c178decee1%7C0%7C0%7C636491446017963669=
> DhjL2mrknpft7aEadZpgXnaV
> >g2w4AKcvSt8K1nQj9R4%3D=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
>
>

Re: Testing npm deployment

[Alex Harui]

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://docs.npmjs.com/getting-started/publishing-npm-packages

On 12/17/17, 1:56 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala"
 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=02%7C01%7C
>aharui%40adobe.com%7Cd583a0036a204c481bde08d545990bde%7Cfa7b1b5a7b34438794
>aed2c178decee1%7C0%7C0%7C636491446017963669=DhjL2mrknpft7aEadZpgXnaV
>g2w4AKcvSt8K1nQj9R4%3D=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