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