`serve` should automatically call `prepare` before launching the web server (thereby updating the contents of platforms/.../www with contents of /www).
On 8/26/13 9:11 AM, "Gorkem Ercan" <[email protected]> wrote: >Issue with working from $platform/.../www directory, like serve command >does, is development is not supposed to happen in there but in >$project/www. When you make a change on $project/www you need to get cli >to >update the files on $platform/www directories so that serve can pick up >the >latest changes. I guess CLI is not meant to support daily development >cycle, if that is the case this behaviour is fine. > >One question related to version control, is platforms directory meant to >be >version controlled or is it considered generated and should be ignored. >What is the recommended best practice? >-- >Gorkem > > >On Mon, Aug 26, 2013 at 10:16 AM, Braden Shepherdson ><[email protected]>wrote: > >> This was a deliberate decision. We want the $project/www and >> $project/merges/* to be strictly user files only. This makes the user >>code >> easy to version control and prevents all kinds of horrible clobbering >>bugs, >> where we go overwriting user code with files from a plugin. >> >> The CLI takes care of all these issues. You can "cordova serve >>$platform" >> to have it serve files locally from the platforms/$platform/.../www >> directory, and so on. Using plugman solo, while supported, is definitely >> less streamlined. >> >> Braden >> >> >> On Sun, Aug 25, 2013 at 5:24 PM, Tommy Williams <[email protected]> >> wrote: >> >> > 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" <[email protected]> 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 >><[email protected] >> > > >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 >> > > > >> > > >> > >>
