>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 <[email protected]> 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: [email protected] [mailto:[email protected]] 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 <[email protected]> > 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: > [email protected]] > > Sent: Tuesday, August 26, 2014 11:40 AM > > To: [email protected] > > 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:[email protected]] > > Sent: Thursday, August 21, 2014 6:45 AM > > To: [email protected] > > 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: > [email protected]] > > Sent: Wednesday, August 20, 2014 10:17 PM > > To: [email protected] > > 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:[email protected]] > > Sent: Tuesday, August 19, 2014 12:50 PM > > To: [email protected] > > 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 <[email protected]>
