Yes that is the process for now. Hopefully we'll be able to support IDEs in CLI as well in the future.
On Mon, Jul 29, 2013 at 2:58 PM, Filip Maj <[email protected]> wrote: > +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" <[email protected]> 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" <[email protected]> wrote: >> >>> On Mon, Jul 29, 2013 at 1:30 PM, Tyler Wilson >>><[email protected] >>> >wrote: >>> >>> > See below. >>> > >>> > On Jul 29, 2013, at 12:56 PM, Brian LeRoux <[email protected]> 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! >>> >
