[
https://issues.apache.org/jira/browse/CB-10193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Kotikov updated CB-10193:
----------------------------------
Description:
We have a logic in Windows/wp8 parsers that fires a hooks, specific for these
particular platforms. There is some problems with this:
# This doesn't fits well into the concept of PlatformApi
# The original purpose of the hook is now lost. It was intended to be fired in
the [middle of
prepare|https://github.com/apache/cordova-lib/commit/bd2c667e947b3fda05541e0d1a124d23df60a132],
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'.
The only problem with using 'after_prepare' instead of 'pre_package' 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'.
So the proposed plan is:
# Do not touch 'pre_package' if 'old' platform is used (via PlatformApi
polyfill)
# 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)
# Move bomify from prepare to build in Windows PlatformApi, so www sources will
be not-yet-bomified in 'pre_package'
# Add a notice about 'pre_package' deprecation and removal to HookRunner
was:
We have a logic in Windows/wp8 parsers that fires a hooks, specific for these
particular platforms. There is some 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|https://github.com/apache/cordova-lib/commit/bd2c667e947b3fda05541e0d1a124d23df60a132],
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'.
The only problem with using 'after_prepare' instead of 'pre_package' 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'.
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
> Deprecate 'pre_package' hook for wp8/windows phone platform
> -----------------------------------------------------------
>
> Key: CB-10193
> URL: https://issues.apache.org/jira/browse/CB-10193
> Project: Apache Cordova
> Issue Type: Task
> Components: CordovaLib, Windows, WP8
> Reporter: Vladimir Kotikov
> Assignee: Jesse MacFadyen
> Labels: deprecation, pre_package
>
> We have a logic in Windows/wp8 parsers that fires a hooks, specific for these
> particular platforms. There is some problems with this:
> # This doesn't fits well into the concept of PlatformApi
> # The original purpose of the hook is now lost. It was intended to be fired
> in the [middle of
> prepare|https://github.com/apache/cordova-lib/commit/bd2c667e947b3fda05541e0d1a124d23df60a132],
> 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'.
> The only problem with using 'after_prepare' instead of 'pre_package' 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'.
> So the proposed plan is:
> # Do not touch 'pre_package' if 'old' platform is used (via PlatformApi
> polyfill)
> # 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)
> # Move bomify from prepare to build in Windows PlatformApi, so www sources
> will be not-yet-bomified in 'pre_package'
> # Add a notice about 'pre_package' deprecation and removal to HookRunner
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
