You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Jesse <pu...@gmail.com> on 2016/12/02 05:56:23 UTC
Re: [DISCUSSION] Windows tag, what should it be doing?
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 <kt...@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://issues.apache.org/jira/browse/CB-12163
>
> 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://issues.apache.org/jira/browse/CB-10326)
>
> // 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?
>
Re: [DISCUSSION] Windows tag, what should it be doing?
Posted by Karen Tran <kt...@gmail.com>.
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" <kt...@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 <sh...@gmail.com> wrote:
>
> > +1 sounds good
> >
> > On Thu, Dec 8, 2016 at 4:36 PM, Karen Tran <kt...@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 <kt...@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 <sh...@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
> > > >> > > > <jc...@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
>
>
Re: [DISCUSSION] Windows tag, what should it be
doing?
Posted by Котиков Владимир <ko...@gmail.com>.
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" <kt...@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 <sh...@gmail.com> wrote:
> +1 sounds good
>
> On Thu, Dec 8, 2016 at 4:36 PM, Karen Tran <kt...@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%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636171602363520388&sdata=QYSHbcwPFrPlhItNTNMHYifiuzXo5u9nzOt3Z0tuZ%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%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636171602363520388&sdata=kEEUSKDlHlthoEP0eh6KVJp8KHdxADcaUfWInh7foPU%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 <kt...@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 <Ti...@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%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636171602363520388&sdata=%2BDtRzdpTl8NgiUHknQvVifYq45s8azqXQ9haI0KXNns%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%2B2JBIy5LERs2JJeT6tjaJweSOfX8HAb9kdTvfU%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 <sh...@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
> > >> > > > <jc...@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 <pu...@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
Re: [DISCUSSION] Windows tag, what should it be doing?
Posted by Karen Tran <kt...@gmail.com>.
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 <sh...@gmail.com> wrote:
> +1 sounds good
>
> On Thu, Dec 8, 2016 at 4:36 PM, Karen Tran <kt...@gmail.com> wrote:
>
> > I dug up the old pull request for this behavior change (
> > https://github.com/apache/cordova-windows/pull/139) 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://github.com/ktop/cordova-windows/tree/cb12163>
> >
> > 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 <kt...@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 <Ti...@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.protec
> > >> 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%2B2JBIy5LERs2JJeT6tjaJweSOfX8HAb9kdTvfU%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 <sh...@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
> > >> > > > <jc...@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 <pu...@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
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: [DISCUSSION] Windows tag, what should it be doing?
Posted by Shazron <sh...@gmail.com>.
+1 sounds good
On Thu, Dec 8, 2016 at 4:36 PM, Karen Tran <kt...@gmail.com> wrote:
> I dug up the old pull request for this behavior change (
> https://github.com/apache/cordova-windows/pull/139) 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://github.com/ktop/cordova-windows/tree/cb12163>
>
> 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 <kt...@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 <Ti...@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.protec
> >> 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%2B2JBIy5LERs2JJeT6tjaJweSOfX8HAb9kdTvfU%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 <sh...@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 <ke...@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
> >> > > > <jc...@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 <pu...@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 <kt...@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%2B2JBIy5LERs2JJeT6tjaJweSOfX8HAb9kdTvfU%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
> >> > >
> >> > >
> >> >
> >>
> >
> >
>
Re: [DISCUSSION] Windows tag, what should it be doing?
Posted by Karen Tran <kt...@gmail.com>.
I dug up the old pull request for this behavior change (
https://github.com/apache/cordova-windows/pull/139) 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://github.com/ktop/cordova-windows/tree/cb12163>
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 <kt...@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 <Ti...@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.protec
>> 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%2B2JBIy5LERs2JJeT6tjaJweSOfX8HAb9kdTvfU%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 <sh...@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%7C8aad7996a77c4232984008d41aff194c%7C72f988bf86f141af91ab2
>> > d7cd011db47%7C1%7C0%7C636163130331524841&sdata=UoNsuqqH3EYZjTSZgDQkv1q
>> > 49XuAGwoUXyWp8OfxjyI%3D&reserved=0
>> >
>> > On Fri, Dec 2, 2016 at 11:27 AM, Kerri Shotts <ke...@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
>> > > > <jc...@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 <pu...@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 <kt...@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%7C8aad7996a77c4232984008d41aff194c%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%7C8aad7996a77c4232984008d41aff194c%7C72
>> > > >>> f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636163130331524841&sdat
>> > > >>> a=xMO4L%2B2JBIy5LERs2JJeT6tjaJweSOfX8HAb9kdTvfU%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
>> > >
>> > >
>> >
>>
>
>
Re: [DISCUSSION] Windows tag, what should it be doing?
Posted by Karen Tran <kt...@gmail.com>.
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 <Ti...@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%2Fissues.apache.org%2Fjira%2Fbrowse%2FCB-
> 10326&data=02%7C01%7CTim.Barham%40microsoft.com%
> 7C8aad7996a77c4232984008d41aff194c%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636163130331524841&sdata=xMO4L%
> 2B2JBIy5LERs2JJeT6tjaJweSOfX8HAb9kdTvfU%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 <sh...@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%7C8aad7996a77c4232984008d41aff194c%7C72f988bf86f141af91ab2
> > d7cd011db47%7C1%7C0%7C636163130331524841&sdata=UoNsuqqH3EYZjTSZgDQkv1q
> > 49XuAGwoUXyWp8OfxjyI%3D&reserved=0
> >
> > On Fri, Dec 2, 2016 at 11:27 AM, Kerri Shotts <ke...@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
> > > > <jc...@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 <pu...@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 <kt...@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%7C8aad7996a77c4232984008d41aff194c%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%7C8aad7996a77c4232984008d41aff194c%7C72
> > > >>> f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636163130331524841&sdat
> > > >>> a=xMO4L%2B2JBIy5LERs2JJeT6tjaJweSOfX8HAb9kdTvfU%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
> > >
> > >
> >
>
RE: [DISCUSSION] Windows tag, what should it be
doing?
Posted by Tim Barham <Ti...@microsoft.com>.
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%2Fissues.apache.org%2Fjira%2Fbrowse%2FCB-10326&data=02%7C01%7CTim.Barham%40microsoft.com%7C8aad7996a77c4232984008d41aff194c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636163130331524841&sdata=xMO4L%2B2JBIy5LERs2JJeT6tjaJweSOfX8HAb9kdTvfU%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 <sh...@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%7C8aad7996a77c4232984008d41aff194c%7C72f988bf86f141af91ab2
> d7cd011db47%7C1%7C0%7C636163130331524841&sdata=UoNsuqqH3EYZjTSZgDQkv1q
> 49XuAGwoUXyWp8OfxjyI%3D&reserved=0
>
> On Fri, Dec 2, 2016 at 11:27 AM, Kerri Shotts <ke...@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
> > > <jc...@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 <pu...@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 <kt...@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%7C8aad7996a77c4232984008d41aff194c%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%7C8aad7996a77c4232984008d41aff194c%7C72
> > >>> f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636163130331524841&sdat
> > >>> a=xMO4L%2B2JBIy5LERs2JJeT6tjaJweSOfX8HAb9kdTvfU%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
> >
> >
>
Re: [DISCUSSION] Windows tag, what should it be doing?
Posted by Karen Tran <kt...@gmail.com>.
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://issues.apache.org/jira/browse/CB-10326> "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 <sh...@gmail.com> wrote:
> I fully expect resource-file to copy things over, as advertised in the
> docs.
>
> Somewhat related issue on iOS:
> https://issues.apache.org/jira/browse/CB-12009
>
> On Fri, Dec 2, 2016 at 11:27 AM, Kerri Shotts <ke...@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 <jc...@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 <pu...@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 <kt...@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://issues.apache.org/jira/browse/CB-12163
> > >>>
> > >>> 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://issues.apache.org/jira/browse/CB-10326)
> > >>>
> > >>> // 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
> >
> >
>
Re: [DISCUSSION] Windows tag, what should it be doing?
Posted by Shazron <sh...@gmail.com>.
I fully expect resource-file to copy things over, as advertised in the
docs.
Somewhat related issue on iOS:
https://issues.apache.org/jira/browse/CB-12009
On Fri, Dec 2, 2016 at 11:27 AM, Kerri Shotts <ke...@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 <jc...@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 <pu...@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 <kt...@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://issues.apache.org/jira/browse/CB-12163
> >>>
> >>> 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://issues.apache.org/jira/browse/CB-10326)
> >>>
> >>> // 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
>
>
Re: [DISCUSSION] Windows tag, what should it be doing?
Posted by Kerri Shotts <ke...@gmail.com>.
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 <jc...@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 <pu...@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 <kt...@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://issues.apache.org/jira/browse/CB-12163
>>>
>>> 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://issues.apache.org/jira/browse/CB-10326)
>>>
>>> // 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
Re: [DISCUSSION] Windows tag, what should it be doing?
Posted by julio cesar sanchez <jc...@gmail.com>.
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 <pu...@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 <kt...@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://issues.apache.org/jira/browse/CB-12163
> >
> > 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://issues.apache.org/jira/browse/CB-10326)
> >
> > // 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?
> >
>