cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kerri Shotts <>
Subject Re: [DISCUSSION] Windows <resource-file> tag, what should it be doing?
Date Fri, 02 Dec 2016 19:27:51 GMT
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 <> 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 <>:
>> 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
>> On Tue, Nov 29, 2016 at 9:06 AM, Karen Tran <> 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:
>>> 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.
>>> (
>>> // 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:
For additional commands, e-mail:

View raw message