cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Treggiari, Leo" <leo.treggi...@intel.com>
Subject RE: Directory Structure - CLI directory config proposal
Date Thu, 28 Aug 2014 17:13:45 GMT
Sounds like there is a 3rd use case for a configurable directory structure?:

1 - Allow the user to define the directory structure and have all tools honor it.  Maybe because
it allows them to more easily use additional tools with Cordova CLI.
2 - A tool needs to impose a particular directory structure but wants to be able to use Cordova
functionality without modifying it.
3 - Cordova CLI wants to change THEIR directory structure.

I haven't personally experienced the pain of #3 but I can well imagine it.  If the Cordova
CLI team can't promise to never change the directory structure again, then this is a good
reason!

Leo

-----Original Message-----
From: Victor Sosa [mailto:sosah.victor@gmail.com] 
Sent: Thursday, August 28, 2014 9:42 AM
To: dev@cordova.apache.org
Subject: Re: Directory Structure - CLI directory config proposal

>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 <csantana23@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.treggiari@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: mmocny@google.com [mailto:mmocny@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.treggiari@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:
> > panarasi@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.treggiari@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:
> > panarasi@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:cmarcelk@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
> <csantana23@gmail.com>
>



-- 
Victor Adrian Sosa Herrera
IBM Software Engineer
Guadalajara, Jalisco
Mime
View raw message