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.vladi...@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" <ktop...@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 <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://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 <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. > 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 <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-unsubscribe@cordova. > apache.org > > > >> > > For additional commands, e-mail: > dev-h...@cordova.apache.org > > > >> > > > > > >> > > > > > >> > > > > >> > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
