>Are users actually using IBM >Worklight IDE interchangeably with cordova-cli tool?
I'd like to take this question to show off the Cordova tools we've built in RAD (sorry for being so pretentious) http://www.ibm.com/developerworks/rational/library/hybrid-mobile-applications-rational-application-developer/index.html Quick summary about the directory within the IDE: We respect it as it is so it can be loaded onto other IDEs as well. You can tell how hard it is to maintain a project structure that constantly changes. If there could be a way to standardize the filesystem structure, that will help IDEs a lot 2014-08-28 11:31 GMT-05:00 Carlos Santana <csantan...@gmail.com>: > >Are users actually using IBM > >Worklight IDE interchangeably with cordova-cli tool? If so, could the > >answer just be to ship a worklight-cli? > > We already have a worklight-cli [1], but current implementation assumes a > proprietary directory structure for hybrid apps. > > Going forward I would like to see our IBM platform adopt the cordova cli > directory structure since a lot of tools already using it, and allow > Worklight customers to use any cordova base tool like ionic, cca, phonegap, > etc.. and just add the worklight plugin into it and continue using their > tool of choice. > > If there are tooling features specific to worklight I will add thru plugin > hooks or enhance the worklight-cli to also support the cordova project > structure > > [1]: > > http://www-01.ibm.com/support/knowledgecenter/api/content/SSZH4A_6.2.0/com.ibm.worklight.dev.doc/dev/c_wl_cli_features.html?locale=en > > > > > On Wed, Aug 27, 2014 at 8:10 PM, Treggiari, Leo <leo.treggi...@intel.com> > wrote: > > > > This would mean that you are either 100% cordova-cli directory > structure > > > compatible, and thus (potentially, at least) tool-interchangeable, or > > your > > > have a different structure and are not interchangeable. > > > > > > Does that not map to user expectations? > > > > Interesting question. So there seems to be two possible use cases for > the > > configurable directory structure: > > > > 1. Allow the user to define the directory structure and have all tools > > honor it. I found your earlier example interesting as well: > > > > > I'd like to see this happen. > > > > > > > > > > Specifically, I would like to see support for a directory structure > > like > > > > > this: > > > > > > > > > > MyApp/ > > > > > cordova_components/ > > > > > platforms/ > > > > > plugins/ > > > > > bower_components/... > > > > > node_modules/... > > > > > ...Rest of contents of MyApp are basically www/ > > Maybe configurable directories help support this? I would hope so. If > > not, then maybe they aren't that useful from a user's perspective. > > This is part of a larger discussion that I would like to see discussed at > > some point. That is, when you want to combine different tooling > > technologies into the hybrid app development workflow, which tool is in > > charge of what? It seems as if Cordova-cli / cordova-lib must be in > charge > > of the plugin selection and the build. To be in charge of the build it > > needs to know everything that has to do with the build - metadata > targeted > > for platform specific manifest files, icons, splash screens, all of the > > plugin code, all of the application's JavaScript code, all of the > > JavaScript libraries being used by the app (I guess these just look like > > application JavaScript code now, and maybe that is how it should be), any > > other native binaries, etc. Another tool could be used for managing > > "components" - e.g. bower/npm. Another tool for generating applications > > (boilerplate, workflow tasks, etc.) - e.g. yo. Another tool for > > application emulation - e.g. Ripple. What do these tools need to know > > about each other to work well together? These tools tend to have their > own > > metadata. Do some tools need to know about each other's metadata? An > IDE > > tends to want to tie these all together and would like to have > well-defined > > metadata and no duplication of information - e.g. what metadata holds the > > true list of plugins used by this app? I certainly don't know the > answers > > here. > > > > 2. A tool needs to impose a particular directory structure but wants to > > be able to use Cordova functionality without modifying it. Maybe your > > suggestion is sufficient for that: > > > If cordova-lib just stopped containing hardcoded paths, and all modules > > > required paths as inputs, then cordova-cli would have one pre-defined > > > expected directory structure (not configurable), exactly as it is now. > > But > > > if you want to build a downstream IDE/tool with a different structure, > > you > > > just pass those values when making calls to cordova-lib. > > > > Leo > > > > -----Original Message----- > > From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal > > Mocny > > Sent: Wednesday, August 27, 2014 2:02 PM > > To: dev > > Subject: Re: Directory Structure - CLI directory config proposal > > > > Hmm, maybe we don't actually need these to be configurable. > > > > If cordova-lib just stopped containing hardcoded paths, and all modules > > required paths as inputs, then cordova-cli would have one pre-defined > > expected directory structure (not configurable), exactly as it is now. > But > > if you want to build a downstream IDE/tool with a different structure, > you > > just pass those values when making calls to cordova-lib. > > > > This would mean that you are either 100% cordova-cli directory structure > > compatible, and thus (potentially, at least) tool-interchangeable, or > your > > have a different structure and are not interchangeable. > > > > Does that not map to user expectations? Are users actually using IBM > > Worklight IDE interchangeably with cordova-cli tool? If so, could the > > answer just be to ship a worklight-cli? > > > > -Michal > > > > > > On Tue, Aug 26, 2014 at 2:55 PM, Treggiari, Leo <leo.treggi...@intel.com > > > > wrote: > > > > > I was reacting to this in your e-mail: > > > > > > > The user may choose to check in the user specific config if the > entire > > > team decides to use that as a project structure. They would not check > the > > > user-config in cases where individual users use different IDEs. > > > > > > There should be one directory structure defined for the project. That > > > metadata is under source code control as well as the sources that are > > > actually using that directory structure. Ideally, Cordova CLI and all > > IDEs > > > use the checked in directory structure. If an IDE can't handle that, > > then > > > it would need to change the metadata, and rearrange the project > sources, > > > and, of course, not check in those modifications. So the use of > multiple > > > IDEs and Cordova CLI will work when they all respect the directory > > > metadata, specifically for the directories that are under source code > > > control. An IDE could do whatever it wants in temporary/working > > > directories. > > > > > > > I could volunteer to take the first stab at that API that cordova-lib > > > suggests. Does that sound good ? > > > > > > Definitely! > > > > > > Thanks, > > > Leo > > > > > > -----Original Message----- > > > From: Parashuram Narasimhan (MS OPEN TECH) [mailto: > > panar...@microsoft.com] > > > Sent: Tuesday, August 26, 2014 11:40 AM > > > To: dev@cordova.apache.org > > > Subject: RE: Directory Structure - CLI directory config proposal > > > > > > It is the latter. The idea is that there is a default directory > structure > > > that shall be defined by Cordova CLI, and the IDE can modify it, call > > tasks > > > like prepare or compile directly from cordova-lib. The IDE could do > > clever > > > things like copy only modified files, use symlinks, etc. From the > > hangouts > > > discussion, it was agree that cordova-lib would expose APIs that shall > be > > > used by build systems, IDEs and the CLI. We need to finalize on that > API. > > > > > > I could volunteer to take the first stab at that API that cordova-lib > > > suggests. Does that sound good ? > > > > > > -----Original Message----- > > > From: Treggiari, Leo [mailto:leo.treggi...@intel.com] > > > Sent: Thursday, August 21, 2014 6:45 AM > > > To: dev@cordova.apache.org > > > Subject: RE: Directory Structure - CLI directory config proposal > > > > > > Is the flexible directory structure being proposed so that the CLI can > > > "conform" to a directory structure defined by the IDE, or so that a > user > > > can define the directory structure and both the CLI and the IDE use it? > > > I'm an IDE developer, but I don't have a lot a sympathy for the former. > > > The latter is useful. I don't understand why an IDE should think IT > > > defines the directory structure, just like the CLI did prior to this > > > proposal. > > > > > > Leo > > > > > > -----Original Message----- > > > From: Parashuram Narasimhan (MS OPEN TECH) [mailto: > > panar...@microsoft.com] > > > Sent: Wednesday, August 20, 2014 10:17 PM > > > To: dev@cordova.apache.org > > > Subject: RE: Directory Structure - CLI directory config proposal > > > > > > Should the platform/plugin save/restore take care of the ability to > > > restore platforms? That way, though the platforms folder is > discernable, > > we > > > do not have to necessarily delete it. The goal of able to re-create a > > > project solely based on the checked-in information still stays. > > > > > > The user may choose to check in the user specific config if the entire > > > team decides to use that as a project structure. They would not check > the > > > user-config in cases where individual users use different IDEs. > > > > > > -----Original Message----- > > > From: Marcel Kinard [mailto:cmarc...@gmail.com] > > > Sent: Tuesday, August 19, 2014 12:50 PM > > > To: dev@cordova.apache.org > > > Subject: Re: Directory Structure - CLI directory config proposal > > > > > > I don't want to dramatically increase the scope of this thread, but I'm > > > wondering if this is the opportunity to get the platforms dir to be > 100% > > > generated and discardable between app builds. The goal being that then > > > there is a clean line of what devs should check into SCM and what is in > > > their .gitignore file. > > > > > > It also feels like there should be a slight difference between > > > user-specific config that doesn't go into a team SCM (my copy of > > > cordova-android is in /home/marcelk/customized), and project-specific > > > config that does go into a team SCM (the layout of this meta config > that > > > describes where the project dirs are). > > > > > > And yes, it should be 100% compatible with today's directory structure. > > > > > > > > > -- > Carlos Santana > <csantan...@gmail.com> > -- Victor Adrian Sosa Herrera IBM Software Engineer Guadalajara, Jalisco
