+1 sounds good On Thu, Dec 8, 2016 at 4:36 PM, Karen Tran <ktop...@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 <ktop...@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.bar...@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:ktop...@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 <shaz...@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 <kerrisho...@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 > >> > > > <jcesarmob...@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 <purplecabb...@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 <ktop...@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-unsubscr...@cordova.apache.org > >> > > For additional commands, e-mail: dev-h...@cordova.apache.org > >> > > > >> > > > >> > > >> > > > > >
