cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: [DISCUSSION] Windows <resource-file> tag, what should it be doing?
Date Fri, 09 Dec 2016 01:03:45 GMT
+1 sounds good

On Thu, Dec 8, 2016 at 4:36 PM, Karen Tran <ktop500@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 <ktop500@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.Barham@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:ktop500@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 <shazron@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 <kerrishotts@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
> >> > > > <jcesarmobile@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 <purplecabbage@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 <ktop500@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%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-unsubscribe@cordova.apache.org
> >> > > For additional commands, e-mail: dev-help@cordova.apache.org
> >> > >
> >> > >
> >> >
> >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message