+1, totally agree, this was the main use case for separating our plugman vs cli tooling in the first place I thought..
On 7/29/13 12:05 PM, "Brian LeRoux" <b...@brian.io> wrote: >Woah woah, not my perception at all. If you want to work in native projs >then use plugman directly. CLI tools are designed to avoid IDE land and >associated pain from cat/mouse release antics. Combined usage will be too >leaky an abstraction. >On Jul 29, 2013 3:02 PM, "Andrew Grieve" <agri...@chromium.org> wrote: > >> On Mon, Jul 29, 2013 at 1:30 PM, Tyler Wilson >><twil...@pulse-robotics.com >> >wrote: >> >> > See below. >> > >> > On Jul 29, 2013, at 12:56 PM, Brian LeRoux <b...@brian.io> wrote: >> > >> > > Hey Tyler, thanks for capturing this. And yup filing relevant issues >> > > very welcome! I have some responses below inline: >> > > >> > > >> > >> You would need to create a new project to get the updated template >> > files, correct? >> > > >> > > This is correct. I believe we have a backlog item for implementing >>an >> > > `upgrade` command. >> > >> > Great >> > > >> > > >> > > >> > >> - When initially doing a 'cordova create' and the first 'cordova >> > platform add', it downloads the latest template files, but does not >> display >> > any progress information. If on a slow connection, it can look like it >> has >> > hung, and the user might cancel the operation, leaving the system in a >> > broken state. >> > > >> > > Yes, this is a docs issue too. If you run the command with the -d >>flag >> > > you'll see detailed output. >> > >> > Got that now. Still think it ought to say something if it is >>performing a >> > possible time-consuming operation. >> > >> >> Agree. I'd like to see -d be the default. >> >> >> > > >> > > >> > >> - When doing a platform add iOS, we end up with two 'www' folders. >>One >> > at the root of the project, and one within the platform/ios folder. In >> step >> > 3 of the upgrading iOS page here >> > >> >>http://cordova.apache.org/docs/en/3.0.0/guide_platforms_ios_upgrading.md. >>html#Upgrading%20iOSitsays to copy the contents of the www folder to the >>www folder at the >> > root. But the Xcode project still refers to the www folder within the >>iOS >> > folder, not the one at the project root. >> > > >> > > This is deliberate. We copy the root www into the platform folder. >>Our >> > > goal in 4.0 is to make ./platforms just build artifacts. >> > >> > Okay, this was not clear to me: I just did a test with 'cordova build' >> > which - as you say - did copy from the root www to the iOS platform. >>But >> > what about the case where the user simply creates the project, adds >>the >> iOS >> > platform, and then uses Xcode? You cannot edit the www in the Xcode >> project >> > since it will be overwritten the next time they do a cordova build. I >> think >> > this would be a common use-case, and I do not see an levant solution >>to >> it. >> > My initial thought is that the Xcode project should point to the root >>www >> > and there are custom build options to copy then build within Xcode. >>Same >> > for Android if using Eclipse with an imported platform/androidŠ >> > >> >> Agree here too. It's on the roadmap to do exactly as you said. >> >> >> > >> > > >> > > >> > > >> > >> - Adding plugins: I know we only have to do do the plugin add once >>per >> > project, but I think is tedious. >> > > >> > > Plugin discovery didn't land in time for 3.0 but its there now. You >> > > can just run `cordova plugin add geolocation` to get plugins from >>our >> > > plugin repo that is based on npm. Documentation for this is >> > > forthcoming too. >> > >> > Nice to know. Thanks! >>
