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