Your proposal about deprecating the 'pre_package' hook looks good to me. People (or plugins) who have been using the 'pre_package' hooks will have time to adjust their projects/plugins. I think the undecided 'before_browserify' hook could be added in the LIB side instead of the 'new' platform. This way we could have better platform encapsulation and free from hooks. Not sure whether we really need this hook, though. During the deprecation time, we could get some feedback or request for the 'before_browserify' hook from users. Thanks, Vladimir!!
Byoungro So SSG / DPD / Mobile Computing and Compilers Intel Corporation -----Original Message----- From: Vladimir Kotikov (Akvelon) [mailto:[email protected]] Sent: Friday, December 11, 2015 2:27 AM To: [email protected] Subject: RE: Purpose of pre_package hook for windows So, the only problem here is when plugin (or user) decides to modify www files, they won't be BOMed by platform. This can be workarounded by moving 'add_bom' logic from prepare to build in PlatformApi for Windows. This way BOM will still be added _after_ 'pre_package'. Regarding the fact that > There is also the browserify code executed after the pre_package hook I'd say that browserify is executed _before 'after_prepare'_ hook, because other platforms don't have 'pre_package'. If there is a strong necessity for doing something at this moment systematically for all platforms, I'd prefer have something like 'before_browserify' for that. So the proposed plan is: 1. Do not touch 'pre_package' if 'old' platform is used (via PlatformApi polyfill) 2. If the 'new' platform is used, 'pre_package' doesn't emitted by platform, so we need to emit it manually (right before 'after_prepare' - to keep the order of hooks unchanged) 3. Move bomify from prepare to build in Windows PlatformApi, so www sources will be not-yet-bomified in 'pre_package' 4. Add a notice about 'pre_package' deprecation and removal to HookRunner Any thoughts on this? - Best regards, Vladimir -----Original Message----- From: So, Byoungro [mailto:[email protected]] Sent: Friday, December 11, 2015 3:59 AM To: [email protected] Subject: RE: Purpose of pre_package hook for windows There are still some codes executed between pre_package and before_compile. On windows and wp8 platforms, BOM is inserted for text files. There is also the browserify code executed after the pre_package hook. So, we better double-check if we can replace pre_package with before_compile hooks. Byoungro So SSG / DPD / Mobile Computing and Compilers Intel Corporation -----Original Message----- From: Sergey Grebnov (Akvelon) [mailto:[email protected]] Sent: Thursday, December 10, 2015 11:21 AM To: [email protected] Subject: RE: Purpose of pre_package hook for windows Hi guys, the pre_package hook was added before I've started working on new hook model so I don't know much details about its original purpose. There are still plugins[1] on github which reply on it, but not much. I think pre_package is identical to before_compile so this should be an easy fix. So probably we can just make pre_package to be an alias for before_compile and deprecate/remove it after some time. [1] https://github.com/search?p=1&q=pre_package+filename%3Aplugin.xml&ref=searchresults&type=Code&utf8=%E2%9C%93 Thx! Sergey -----Original Message----- From: Jesse [mailto:[email protected]] Sent: Wednesday, December 9, 2015 2:06 PM To: [email protected] Subject: Re: Purpose of pre_package hook for windows I can't find any info on why we needed it ... it seems to be fired right before the files are added to the csproj, though I am not sure why. The only other person I think may know anything about it would be @sgrebnov The earliest JIRA ticket I could find on the issue [1] although the issue is just that it exists in wp7 but not wp8. [1] https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-5261&data=01%7c01%7cv-segreb%40microsoft.com%7c53012f7781224cf8372e08d300e505dc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=c9AEritc1dtKYjRmkqF2mv4Pb4ri9okjq6bV9gPqAFY%3d @purplecabbage https://na01.safelinks.protection.outlook.com/?url=risingj.com&data=01%7c01%7cv-segreb%40microsoft.com%7c53012f7781224cf8372e08d300e505dc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=wW%2bKeY6MmNVcIOVrceLfhfpkMeUTCTbAsBrbCpkkXwg%3d On Wed, Dec 9, 2015 at 11:53 AM, Vladimir Kotikov (Akvelon) < [email protected]> wrote: > Hi, guys. > > Could anyone please shed some light on the subject? > > Looking into PR for 'nohooks' option [1] I realized that we have a > logic in Windows/wp8 parsers that fires a hooks, specific for these > particular platforms. I see 2 problems with this: > > 1. This doesn't fits well into the concept of PlatformApi > > 2. The original purpose of the hook is now lost. It was intended to > be fired in the middle of prepare [2], to allow to modify www folder > before it will be packed into app package, but now it get fired right > before the end of platform preparation, and hence almost equal to > 'after_prepare'. > > So the question is, should we still have these hooks in new windows > platform? Or we can just move it into LIB and fire just after the > prepare and only for windows/wp8? > > [1] https://github.com/apache/cordova-lib/pull/353 > [2] > https://github.com/apache/cordova-lib/commit/bd2c667e947b3fda05541e0d1 > a124d23df60a132 > --------------- > Best regards, Vladimir > > B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB [ X ܚX KK[XZ[ ] ][ X ܚX P ܙݘK \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ ] Z[ ܙݘK \X K ܙ B --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB [ X ܚX KK[XZ[ ] ][ X ܚX P ܙݘK \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ ] Z[ ܙݘK \X K ܙ B --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
