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 <shaz...@gmail.com> wrote: > +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%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-unsubscr...@cordova.apache.org > > >> > > For additional commands, e-mail: dev-h...@cordova.apache.org > > >> > > > > >> > > > > >> > > > >> > > > > > > > > >
