cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karen Tran <ktop...@gmail.com>
Subject Re: [DISCUSSION] Windows <resource-file> tag, what should it be doing?
Date Mon, 12 Dec 2016 17:23:47 GMT
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 <shazron@gmail.com> wrote:

> +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%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-help@cordova.apache.org
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

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