cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommy Williams <to...@devgeeks.org>
Subject Re: Plugman behavior with assets
Date Sun, 25 Aug 2013 21:24:04 GMT
My response is very CLI-biased as that is what we use. I haven't used
plugman on its own on old style per-platform projects using the ./bin/*
scripts or an ide like eclipse or xcode.

Certainly on our app, anything related to plugins is irrelevant in ./www as
when working from there,0 plugins aren't loaded anyway (e.g.: debugging non
device functionality in a browser).

We only care about plugin assets when dealing with ./platforms/**/www
(e.g.: debugging/testing on a device or simulator/emulator/VM).

Are there use cases where plugin assets might still be needed when working
from local browser debugging? If so, couldn't you just work from a
./platforms/**/www instead with a quick `cordova prepare <platform>` to get
all assets in place?
On 24 Aug 2013 05:50, "Brian LeRoux" <b@brian.io> wrote:

> This is a deliberate function of Plugman (working w/ native project
> structures) but I agree if you are working w/ Cordova CLI (or variants
> thereof) then it should be copying into merges.
>
> I believe this has been discussed in the past. Would like to hear other
> opinions here. Mike Wolf, Mike Brooks, Anis, Fil, Andrew, and Braden in
> particular would have good thoughts.
>
>
> On Thu, Aug 22, 2013 at 2:56 PM, Gorkem Ercan <gorkem.ercan@gmail.com
> >wrote:
>
> > It looks like plugman copies files or directories specified with the
> asset
> > tag on plugin.xml to the www directory on the platform project (somewhere
> > under $project/platforms/ios/... ). This behaviour may cause things to be
> > broken during development time since most development is happening on the
> > $project/www folder. Does it make sense that these files are copied under
> > $project/www or merges/$platform/ if they are platform specific rather
> than
> > directly into platform projects?
> > --
> > Gorkem
> >
>

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