cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karen Tran <ktop...@gmail.com>
Subject Re: [DISCUSSION] Windows <resource-file> tag, what should it be doing?
Date Tue, 13 Dec 2016 17:40:11 GMT
No problem. I'll work on getting the copy functionality and reference flag
in and then I can take a look at your suggestion. Sounds like a useful
feature to me.

On Tue, Dec 13, 2016 at 3:36 AM, Котиков Владимир <
kotikov.vladimir@gmail.com> wrote:

> Hey Karen, sorry for last minute response.
>
> I’m _personally_ +1 for getting back the original behavior (i.e. copy
> instead of referencing the original files), I only think that we’d to make
> sure that the case, described in https://github.com/apache/
> cordova-windows/pull/139 still works with that new flag (I can help with
> verification).
>
> Also, nobody has asked if this would be a reason for a major version
> change? Technically we’re going to break the things, so yes, but from the
> other side it’s kind of regression and unexpected change that needs to be
> fixed. IMO it should be at least minor bump, since we’re going to add a new
> flag
>
> + another suggestion about implementation: IMO the main confusing point
> with the original behavior (copying and then referencing copied file) was
> that if you have two tags:
>
>     <resource-file src="x86/foo.dll" target="foo.dll" arch="x86" />
>     <resource-file src="x64/foo.dll" target="foo.dll" arch="x64" />
>
> the second one would silently overwrite the first one and the user will
> get some cryptic errors at _runtime_. I propose to make copying logic a bit
> smarter and at least emit a warning when one resource would overwrite
> another and suggest using a flag to add a reference, rather than copy files.
>
>
>
> On 12/12/16, 20:23, "Karen Tran" <ktop500@gmail.com> wrote:
>
>     Does anyone have any other objections?
>     Otherwise I'll proceed to work on this tomorrow.
>
>     On Thu, Dec 8, 2016 at 8:03 PM, Shazron <shazron@gmail.com> wrote:
>
>     > +1 sounds good
>     >
>     > On Thu, Dec 8, 2016 at 4:36 PM, Karen Tran <ktop500@gmail.com>
> wrote:
>     >
>     > > I dug up the old pull request for this behavior change (
>     > > https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.com%2Fapache%2Fcordova-windows%
> 2Fpull%2F139&data=02%7C01%7Cv-vlkoti%40microsoft.com%
> 7Cfd5830ed12474774b88d08d422b3a5de%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636171602363520388&sdata=QYSHbcwPFrPlhItNTNMHYifiuzXo5u
> 9nzOt3Z0tuZ%2FQ%3D&reserved=0) and it seems like
>     > the
>     > > main goal for the change was to be able to have .dll files
> specific to
>     > > different architectures without having different target locations
> for
>     > each
>     > > of them and make the .dll files visible in Visual Studio so that
> Visual
>     > > Studio can reference them.
>     > > ^Correct me if I'm wrong here...
>     > >
>     > > I tested the following two sets and now have a better
> understanding of
>     > why
>     > > this behavior was added, but I'm not entirely sure why it had to
> replace
>     > > the copy in the first place as opposed to adding a flag to do
> referencing
>     > > instead of copy. Having both behavior in resource-file is probably
> okay
>     > > since they are kind of similar.
>     > >
>     > > Set 1.
>     > > <resource-file src="x86/foo.dll" target="x86/foo.dll" arch="x86" />
>     > > <resource-file src="x64/foo.dll" target="x64/foo.dll" arch="x64" />
>     > > - With copy, this behaves the exact same as the referencing
> behavior.
>     > > - The only difference between each behavior is the path where
> Visual
>     > Studio
>     > > will point to the file, copy will point to the target and
> reference will
>     > > point to src
>     > >
>     > > Set 2.
>     > > <resource-file src="x86/foo.dll" target="foo.dll" arch="x86" />
>     > > <resource-file src="x64/foo.dll" target="foo.dll" arch="x64" />
>     > > - With copy, only the x64 foo.dll will be used since the second
>     > > <resource-file> would overwrite the first one. In Visual Studio,
> the
>     > > foo.dll when targeting x86 or x64 will point to the same x64
> foo.dll. So
>     > > this is the issue with copy for this specific case.
>     > > - With referencing, Visual Studio will properly reference the
> correct
>     > > foo.dll because it's pointing to the src path and there is no
> overwriting
>     > > here.
>     > >
>     > > I will propose that resource-file should default to copy and the
>     > reference
>     > > behavior should be set by a flag. This is what it should have been
> when
>     > the
>     > > behavior was changed, so I think it's worth making the switch back
> to
>     > copy
>     > > even though it will be breaking a few users (because right now it
> might
>     > > unknowingly be breaking more users who have long since been
> expecting
>     > > resource-file to copy; it was never documented that resource-file
> had
>     > > changed at all). Resource-file wasn't intended for .dll, but for
> actual
>     > > resources like json, images, xml, and my case properties files. So
> this
>     > is
>     > > a big issue if some of these resources aren't available to the app
> at run
>     > > time.
>     > > <https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.com%2Fktop%2Fcordova-windows%
> 2Ftree%2Fcb12163&data=02%7C01%7Cv-vlkoti%40microsoft.com%
> 7Cfd5830ed12474774b88d08d422b3a5de%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636171602363520388&sdata=kEEUSKDlHlthoEP0eh6KVJp8KHdxAD
> caUfWInh7foPU%3D&reserved=0>
>     > >
>     > > TL;DR
>     > > I propose setting copy as default and the reference behavior with
> a flag
>     > > because this is what it should have been in the first place.
>     > >
>     > > On Wed, Dec 7, 2016 at 5:58 PM, Karen Tran <ktop500@gmail.com>
> wrote:
>     > >
>     > > > Sorry I missed this, it was in my spam folder.
>     > > >
>     > > > I think the general consensus is that <resource-file> should
> definitely
>     > > > have the copy function added back. Not sure if it was clear if
> we came
>     > > to a
>     > > > conclusion on whether it should be default behavior though.
>     > > >
>     > > > As for what to do for the reference behavior, I think the easy
> route is
>     > > to
>     > > > do what you suggested Tim and keep the current behavior as the
> default
>     > > and
>     > > > have the copy be an attribute users can set. Intuitively though,
> I
>     > think
>     > > > resource-file should default to copy as expected just like other
>     > > platforms,
>     > > > and any other behavior can be handled with attribute flags or
> moved to
>     > > > another more appropriate tag.
>     > > >
>     > > > I would lean towards the second option because it makes more
> sense to
>     > me
>     > > > as a plugin developer because all <type-file> tags do a copy.
I
> know it
>     > > > would break existing plugins that depend on the current
> behavior, but I
>     > > can
>     > > > say the same for resource-file being changed in the first place
> and
>     > never
>     > > > documented nor mentioned in any blog release (my plugin is
> currently
>     > > > broken). I don't know if many developers are even aware that it
> was
>     > > changed
>     > > > besides the contributor. It's been in cordova-windows since
> v4.4.0.
>     > > >
>     > > > So this falls back on my initial two questions I asked:
>     > > > 1. What should be the default behavior of <resource-file> tag?
> Should
>     > it
>     > > > simply be copy resources as it was originally intended to, or
> should it
>     > > be
>     > > > doing what it is now, which is making a reference to the resource
>     > files.
>     > > > 2. Should <resource-file> tag handle both functionalities, or
> should
>     > one
>     > > > be separated out into another tag?
>     > > >
>     > > >
>     > > > On Fri, Dec 2, 2016 at 9:31 PM, Tim Barham <
> Tim.Barham@microsoft.com>
>     > > > wrote:
>     > > >
>     > > >> It seems to me it would be bad form to simply change the default
>     > > behavior
>     > > >> back to copy, if that will break existing plugins that rely on
> the
>     > > current
>     > > >> behavior. While it would be inconsistent with other platforms,
> perhaps
>     > > we
>     > > >> should leave the current default behavior as-is and add an
> attribute
>     > to
>     > > >> specify copy behavior? And then document the discrepancy.
>     > > >>
>     > > >> Otherwise we shouldn't do it until we know framework can work
> as an
>     > > >> alternative, but will plugin developers be able to implement
> their
>     > > plugin
>     > > >> in such a way that it works for both cases? And how will they
> know
>     > they
>     > > >> need to make this change?
>     > > >>
>     > > >> -----Original Message-----
>     > > >> From: Karen Tran [mailto:ktop500@gmail.com]
>     > > >> Sent: Saturday, December 3, 2016 8:04 AM
>     > > >> To: dev@cordova.apache.org
>     > > >> Subject: Re: [DISCUSSION] Windows <resource-file> tag, what
> should it
>     > be
>     > > >> doing?
>     > > >>
>     > > >> Thanks for the input everyone. resource-file definitely makes
> better
>     > > >> sense to copy files. I can work on getting the copy
> functionality back
>     > > into
>     > > >> resource-file some time next week.
>     > > >>
>     > > >> Sidenote:
>     > > >> The issue with the `framework` tag from the contributor to this
> change
>     > > >> said, from CB-10326 <https://na01.safelinks.
> protection.outlook.com/?url=https%3A%2F%2Fna01.safelinks.
> protec&data=02%7C01%7Cv-vlkoti%40microsoft.com%
> 7Cfd5830ed12474774b88d08d422b3a5de%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636171602363520388&sdata=%2BDtRzdpTl8NgiUHknQvVifYq45s8a
> zqXQ9haI0KXNns%3D&reserved=0
>     > > >> tion.outlook.com/?url=https%3A%2F%2Fissues.apache.org%
>     > > >> 2Fjira%2Fbrowse%2FCB-10326&data=02%7C01%7CTim.Barham%
>     > > >> 40microsoft.com%7C8aad7996a77c4232984008d41aff194c%7C72f988b
>     > > >> f86f141af91ab2d7cd011db47%7C1%7C0%7C636163130331524841&
>     > > >> sdata=xMO4L%2B2JBIy5LERs2JJeT6tjaJweSOfX8H
> Ab9kdTvfU%3D&reserved=0>
>     > > "When
>     > > >> I'm using framework VS14 complains that my dll's don't have a
> manifest
>     > > ".
>     > > >> Which is why he opted to use resource-file tag instead of
> framework
>     > tag.
>     > > >>
>     > > >> I'm not sure if framework tag has since updated to handle this,
>     > > otherwise
>     > > >> like Cesar's suggestion we can add something to the framework
> tag to
>     > > handle
>     > > >> this use case of .dll files without a manifest.
>     > > >>
>     > > >>
>     > > >> On Fri, Dec 2, 2016 at 3:34 PM, Shazron <shazron@gmail.com>
> wrote:
>     > > >>
>     > > >> > I fully expect resource-file to copy things over, as
> advertised in
>     > the
>     > > >> > docs.
>     > > >> >
>     > > >> > Somewhat related issue on iOS:
>     > > >> > https://na01.safelinks.protection.outlook.com/?url=
>     > > https%3A%2F%2Fissue
>     > > >> > s.apache.org%2Fjira%2Fbrowse%2FCB-12009&data=02%7C01%7CTim.
>     > > Barham%40mi
>     > > >> > crosoft.com%7C8aad7996a77c4232984008d41aff
>     > > 194c%7C72f988bf86f141af91ab2
>     > > >> > d7cd011db47%7C1%7C0%7C636163130331524841&sdata=
>     > > UoNsuqqH3EYZjTSZgDQkv1q
>     > > >> > 49XuAGwoUXyWp8OfxjyI%3D&reserved=0
>     > > >> >
>     > > >> > On Fri, Dec 2, 2016 at 11:27 AM, Kerri Shotts <
>     > kerrishotts@gmail.com>
>     > > >> > wrote:
>     > > >> >
>     > > >> > > Interesting; if I were configuring a project, I’d
be pretty
>     > > >> > > surprised
>     > > >> > that
>     > > >> > > resource-file didn’t copy my file over. I prefer the
path
> of least
>     > > >> > surprise
>     > > >> > > here, so I’d think that resource-file should copy
files (if
> we
>     > have
>     > > >> > > to
>     > > >> > keep
>     > > >> > > the existing method, maybe an attribute to switch?).
BUT,
> I’d also
>     > > >> > > prefer to keep things simpler, so I’d lean to using
> <framework>
>     > for
>     > > >> > > things like linking to DLLs and <resource-file>
for copying
>     > > >> > > resources to the project (that don’t fit into other
> categories).
>     > > >> > >
>     > > >> > > So, +1 for @jcesar’s suggestion.
>     > > >> > >
>     > > >> > >
>     > > >> > > > On Dec 2, 2016, at 02:26, julio cesar sanchez
>     > > >> > > > <jcesarmobile@gmail.com>
>     > > >> > > wrote:
>     > > >> > > >
>     > > >> > > > We have the framework tag for the .dll files, so
I think
> the
>     > > >> > > resource-file
>     > > >> > > > should copy as the other platforms do.
>     > > >> > > > If the framework tag is not working as expected,
we can
> change
>     > the
>     > > >> > > > behaviour on windows to work as needed.
>     > > >> > > >
>     > > >> > > >
>     > > >> > > > 2016-12-02 6:56 GMT+01:00 Jesse <purplecabbage@gmail.com
> >:
>     > > >> > > >
>     > > >> > > >> Hi Karen,
>     > > >> > > >>
>     > > >> > > >> I am not sure which is the best approach, but
I agree
> that this
>     > > >> > > >> is an issue.  We need to keep the copy functionality.
>     > > >> > > >> I'll think more and come back.  Hopefully more
people
> weigh in
>     > to
>     > > >> ...
>     > > >> > > >>
>     > > >> > > >> Cheers,
>     > > >> > > >>  Jesse
>     > > >> > > >>
>     > > >> > > >>
>     > > >> > > >>
>     > > >> > > >> @purplecabbage
>     > > >> > > >> risingj.com
>     > > >> > > >>
>     > > >> > > >> On Tue, Nov 29, 2016 at 9:06 AM, Karen Tran
<
> ktop500@gmail.com
>     > >
>     > > >> > wrote:
>     > > >> > > >>
>     > > >> > > >>> I want to get some discussion on what the
plugin.xml
>     > > >> > > >>> <resource-file>
>     > > >> > > tag
>     > > >> > > >>> should be doing in Windows because I didn't
know that
> it had
>     > > >> > > >>> been
>     > > >> > > changed
>     > > >> > > >>> for a while now.
>     > > >> > > >>>
>     > > >> > > >>> jira issue:
>     > > >> > > >>> https://na01.safelinks.protection.outlook.com/?url=
>     > > https%3A%2F%2
>     > > >> > > >>> Fissues.apache.org%2Fjira%2Fbrowse%2FCB-12163&data=02%
>     > > 7C01%7CTim
>     > > >> > > >>> .Barham%40microsoft.com%7C8aad7996a77c4232984008d41aff
>     > > 194c%7C72f
>     > > >> > > >>> 988bf86f141af91ab2d7cd011db47%
> 7C1%7C0%7C636163130331524841&
>     > > sdata
>     > > >> > > >>> =49A%2B8MMPoHudHvDyGRBWmqV27i2%
> 2BldXGrB92g0sbVfA%3D&reserved=
>     > 0
>     > > >> > > >>>
>     > > >> > > >>> Current behavior: Doesn't copy resource
file from src to
>     > target.
>     > > >> > > Instead,
>     > > >> > > >>> it will use a reference to the src location.
This is the
>     > snippet
>     > > >> > > >>> from PluginHandler.js explaining this behavior,
which
> was not
>     > > >> > > >>> added to the
>     > > >> > > >> docs.
>     > > >> > > >>> (https://na01.safelinks.protection.outlook.com/?url=
>     > > https%3A%2F%
>     > > >> > > >>> 2Fissues.apache.org%2Fjira%2Fbrowse%2FCB-10326&data=02%
>     > > 7C01%7CTi
>     > > >> > > >>> m.Barham%40microsoft.com%7C8aad7996a77c4232984008d41aff
>     > > 194c%7C72
>     > > >> > > >>> f988bf86f141af91ab2d7cd011db47
> %7C1%7C0%7C636163130331524841&
>     > > sdat
>     > > >> > > >>> a=xMO4L%2B2JBIy5LERs2JJeT6tjaJweSOfX8H
>     > Ab9kdTvfU%3D&reserved=0)
>     > > >> > > >>>
>     > > >> > > >>> // do not copy, but reference the file
in the plugin
> folder.
>     > > >> > > >>> This allows to// have multiple source files
map to the
> same
>     > > >> > > >>> target and select the appropriate// one
based on the
> current
>     > > >> > > >>> build settings,
>     > > >> > e.g.
>     > > >> > > >>> architecture.// also, we don't check for
existence. This
>     > allows
>     > > >> > > >>> to insert build variables// into the source
file name,
> e.g.//
>     > > >> > > >>> <resource-file src="$(Platform)/My.dll"
target="My.dll"
> />
>     > > >> > > >>>
>     > > >> > > >>>
>     > > >> > > >>> This is greatly different from the original
intent of a
> the
>     > > >> > > >> <resource-file>
>     > > >> > > >>> tag since it doesn't do a copy. I don't
think that this
> new
>     > > >> > > >>> behavior
>     > > >> > > >> really
>     > > >> > > >>> should have replaced the copy functionality.
It's a
> little
>     > > >> > unintuitive
>     > > >> > > to
>     > > >> > > >>> reference resources from outside the application.
Not
> all
>     > > >> > > >>> resource
>     > > >> > > files
>     > > >> > > >>> are .dll, and there's no other reasonable
tag to do a
> copy for
>     > > >> > > >>> files
>     > > >> > > that
>     > > >> > > >>> are not source files, lib files, or assets.
(e.g, I'm
> using
>     > > >> > > resource-file
>     > > >> > > >>> tag with a .properties file, but because
it does not get
>     > copied
>     > > >> > over, I
>     > > >> > > >>> can't reference my properties).
>     > > >> > > >>>
>     > > >> > > >>> These are the points I think we should
come to a
> decision on
>     > 1.
>     > > >> > > >>> What should be the default behavior of
<resource-file>
> tag?
>     > > >> > > >>> Should
>     > > >> > > it
>     > > >> > > >>> simply be copy resources as it was originally
intended
> to, or
>     > > >> > > >>> should
>     > > >> > it
>     > > >> > > >> be
>     > > >> > > >>> doing what it is now, which is making a
reference to the
>     > > >> > > >>> resource
>     > > >> > > files.
>     > > >> > > >>> 2. Should <resource-file> tag handle
both
> functionalities, or
>     > > >> > > >>> should
>     > > >> > > one
>     > > >> > > >> be
>     > > >> > > >>> separated out into another tag?
>     > > >> > > >>>
>     > > >> > > >>
>     > > >> > >
>     > > >> > >
>     > > >> > > ------------------------------
> ------------------------------
>     > > --------
>     > > >> > > - To unsubscribe, e-mail: dev-unsubscribe@cordova.
> apache.org
>     > > >> > > For additional commands, e-mail:
> dev-help@cordova.apache.org
>     > > >> > >
>     > > >> > >
>     > > >> >
>     > > >>
>     > > >
>     > > >
>     > >
>     >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message