Is it bad that I both agree vehemently with Brian's calling it not beneficial enough to justify, but also really really like the proposed structure better that the current one? hehe.
*so… conflicted...* - tommy On 23/05/2013, at 7:35 AM, Brian LeRoux <b...@brian.io> wrote: > There are two paths. I argue there is no functional benefit and that > this change is purely aesthetic. Aesthetics are important but I'd > argue folder structure is the last part of the developer aesthetics we > should worry about and especially not beneficial enough to justify a > breaking change. > > Today: > > ./ > |- merges/ > |- platforms/ > |- plugins/ > '- www/ > |- index.html > '- config.xml > > Proposed: > > ./ > |- platforms/ > |- plugins/ > '- app/ > |- merges/ > |- www/ > | '- index.html > '- config.xml > > > > > On Wed, May 22, 2013 at 1:47 PM, Filip Maj <f...@adobe.com> wrote: >> I'm reviving this discussion re: additional app/ folder in the >> cli-generated project structure. >> >> To recap, there were two main discussions: >> >> A) >> http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76xli >> hsfjmvwtoi+state:results >> B) http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html >> >> Arguments for moving to app/: >> >> - easier to version control relevant / non-build-artifact app bits >> - aesthetics >> >> Arguments against it: >> >> - we break shit for users >> - config.xml location and PhoneGap Build compatibility (but I don't see >> this as a valid argument against. This is an easy problem to solve for us >> Adobe folk and the tooling can handle the trivial steps of going up one >> directory to grab the right file before interfacing with Build) >> >> Also worth noting: people we're not against it for architectural reasons, >> in fact, most people were favorable for the change to app/. >> >> So, with plugman stabilizing and my focus moving to cli work, I feel I >> have a good grasp of both projects and the direction they are going, here >> is my suggestion on how to move forward with this: >> >> 1. cordova-cli's master branch, which will soon merge future work in, will >> revert to the old /www-based structure, then >> 2. In 3.0 we make the change, where landing such a breaking change is >> easier and we'll have a bunch of press/noise about the release out there >> too so communicating this change would be easier. >> >> If there are any other arguments for/against the app/ based structure, now >> is the time to bring it up. We can give this some more time to bake, but >> after 2.8 is released, I'd like to call a vote on whether we should move >> to this structure or not in 3.0. >> >> On 4/16/13 8:31 AM, "Michal Mocny" <mmo...@chromium.org> wrote: >> >>> I should also add. I appreciate that this is a change, and every change >>> has some learning overhead and we shouldn't stuff everything possible in >>> all the time. >>> >>> However, I think 3.0 and cli are a big change, and we should do the big >>> re-org all at once, so lets decide this now in a way we wont regret. >>> Thats >>> why we are being picky, I guess. I like knowing that the root of the >>> project has cordova-only artifacts and your app-repo is just a >>> subdirectory >>> somewhere. Then, the exact location and exact contents are way more >>> flexible. >>> >>> -Michal >>> >>> >>> On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <mmo...@chromium.org> >>> wrote: >>> >>>> Okay, we've got options, so lets try to distill the details. >>>> >>>> First, some of the other (perceived) benefits of an app folder are: >>>> * we do a raw cp -r of the www/ folder, and so that should have only >>>> platform agnostic and "necessary" files. >>>> * merges folder was removed from www/ because it did not meet above >>>> criteria, and config.xml is another candidate >>>> * there also potentially exist docs/ (useful for shared apps, like >>>> mobile-spec), platform specific resource files (icons, splash screen), >>>> etc >>>> * a git repository is already basically mirroring the concept of the >>>> "app >>>> folder" >>>> >>>> So, I've come up with the following potential workflows for starting >>>> with >>>> an existing app: >>>> >>>> #1: "your app repo is moved into some subdirectory of a cordova project >>>> -- >>>> its exact location is basically a cordova artifact" >>>> cordova create Foo >>>> cd Foo >>>> cordova app add [--link] git-repo/local-repo (nicely akin to plugin >>>> add) >>>> cordova plugin/platforms add ... >>>> >>>> #2: "your app repo becomes a cordova project in-place" >>>> git clone FooApp (this repo contains merges/ and www/) >>>> cordova create FooApp Foo (cli should not clobber existing folders) >>>> cd FooApp >>>> set up .gitignore for cordova artifacts (cordova should try not to >>>> introduce new artifacts) >>>> cordova plugin/platforms add ... >>>> >>>> #3: "what we have now" >>>> git clone FooApp >>>> cordova create Foo >>>> cp -R FooApp/{www,merges,...} Foo (or ln -s) >>>> cd Foo >>>> cordova plugin/platforms add ... >>>> >>>> (Please let me know of more workflows) >>>> >>>> Workflow #1 I think is very clean, and requires an app folder concept >>>> (we >>>> could maybe use a temporary intermediate folder to get around this, but >>>> why). >>>> Workflow #2 essentially your app repo is the app folder concept, but now >>>> the cordova artifacts also go inside it. Would require minimal changes >>>> to >>>> cordova-cli to not clobber, and requires gitignore. >>>> Workflow #3 is what we have now, which I think is the worst option for >>>> app >>>> management, but can work with or without an app folder. >>>> >>>> >>>> Also, I think it would be great if apps had both plugin and platform >>>> dependancies, such that you could distill workflow #1 down to: >>>> >>>> cordova create Foo >>>> cd Foo >>>> cordova app add git-repo >>>> >>>> .. and it would run the plugin/platform add automatically. Can even get >>>> that down to a single "cordova create git-repo" line. That would make >>>> sharing apps, such as mobile-spec-test, really trivial. >>>> >>>> -Michal >>>> >>>> >>>> On Tue, Apr 16, 2013 at 9:19 AM, Andrew Grieve >>>> <agri...@chromium.org>wrote: >>>> >>>>> So, reading through the thread Braden linked to: >>>>> http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html >>>>> >>>>> There are two advantage that were brought up: >>>>> 1. config.xml (configuration) does not live along side of app resources >>>>> 2. It will make it easier to package apps >>>>> - E.g. zip the app/ directory and install it into the app-harness >>>>> (instead of zipping www + merges). Likewise for phonegap build. >>>>> - E.g. cordova-mobile-spec would contain the contents of app/. With >>>>> our >>>>> current setup, it would contain www/ merges/, and have the CLI place >>>>> build >>>>> artifacts within the repo's directory instead of as a sibling to it. >>>>> >>>>> I think everyone acknowledged the benefits, but there was still >>>>> not consensus over whether it was "worth it". >>>>> >>>>> I don't really feel strongly about it. Braden says it's easy to change >>>>> code-wise. Does anyone want to go to bat for it? >>>>> >>>>> >>>>> >>>>> On Mon, Apr 15, 2013 at 6:59 PM, Brian LeRoux <b...@brian.io> wrote: >>>>> >>>>>> I'd rather we did not go ahead w/ the new directory structure. It >>>>> offers no >>>>>> functional benefit, and comes at an upgrade cost for ppl using the >>>>> CLI >>>>>> tools today. >>>>>> >>>>>> >>>>>> On Mon, Apr 15, 2013 at 12:46 PM, Andrew Grieve <agri...@chromium.org >>>>>>> wrote: >>>>>> >>>>>>> Just catching up on the past week of emails and it's not clear that >>>>> there >>>>>>> was a consensus here. By the sounds of it though: >>>>>>> >>>>>>> 1. Lots of users are using Cordova-CLI (master branch) >>>>>>> 2. Cordova-CLI's "future" branch has non-backwards-compatible >>>>> changes. >>>>>>> 3. One of these changes is the directory structure. >>>>>>> >>>>>>> The main debate is on how to message these changes to users. What >>>>> we >>>>>> should >>>>>>> do is: >>>>>>> >>>>>>> 1. Have an upgrade guide. (e.g. paths are now relative to >>>>> plugin.xml) >>>>>>> 2. Ensure that our error handling shows useful messages when they >>>>> result >>>>>>> from an old-way-of-doing-things (e.g. your app's structure doesn't >>>>>> match.) >>>>>>> >>>>>>> Rather than printing out the commands to run to convert their >>>>> project, >>>>>>> maybe we could have them in the upgrade guide and have the error >>>>> messages >>>>>>> point to the guide? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 10, 2013 at 5:47 PM, Tim Kim <timki...@gmail.com> >>>>> wrote: >>>>>>> >>>>>>>> Braden I have merged master and the future branch: >>>>>>>> https://github.com/timkim/plugman/tree/future_master_merge >>>>>>>> >>>>>>>> I think it's about ready to merge back in to future. I've gotten >>>>> the >>>>>>>> android-one-install and the ios-config-xml-install (minus one >>>>> weird >>>>>> test >>>>>>> I >>>>>>>> don't understand) working. >>>>>>>> >>>>>>>> >>>>>>>> On 10 April 2013 14:42, Anis KADRI <anis.ka...@gmail.com> wrote: >>>>>>>> >>>>>>>>> As far as I am concerned I don't really have a strong opinion >>>>> on >>>>> this >>>>>>>>> topic. As I said in the previous thread, I do like this new >>>>> directory >>>>>>>>> structure and if you have it there and tested then fine. We >>>>> break >>>>>> shit >>>>>>>> all >>>>>>>>> the time it's not like this change is one too many. What >>>>> matters >>>>> is >>>>>> to >>>>>>>>> communicate it to our users and give them an upgrade path to >>>>> this >>>>> new >>>>>>> app >>>>>>>>> structure (the Cordova docs are a good place for that). >>>>>>>>> >>>>>>>>> However, I agree with Brian that there are more important >>>>> things >>>>> to >>>>>>>> tackle >>>>>>>>> right now. Now sure what you had on your list but since js only >>>>>> modules >>>>>>>> are >>>>>>>>> in Plugman right now (untested) The next big thing that is >>>>> going >>>>> to >>>>>> be >>>>>>>>> non-trivial is: plugin dependencies (which will in some ways >>>>> involve >>>>>>>>> discovery I think). We should have a discussion about that >>>>> (hangout, >>>>>>> IRC, >>>>>>>>> connect...whatever). I have a couple of ideas about that. >>>>>>>>> >>>>>>>>> Tim is working on fixing/adding/updating plugman tests and it >>>>> looks >>>>>>> like >>>>>>>>> he's making good progress on it. >>>>>>>>> >>>>>>>>> -a >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Apr 10, 2013 at 11:53 AM, Michael Wolf < >>>>>>> michael.w...@cynergy.com >>>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>> I get the intention, however anything we can do to reduce >>>>> this >>>>> type >>>>>>> of >>>>>>>>>> breaking change should be done. These type of changes >>>>> should >>>>> be >>>>>>>>>> considered for major releases only so users can plan for >>>>> them. >>>>>>>>>> >>>>>>>>>> mw >>>>>>>>>> >>>>>>>>>> On 4/9/13 5:05 PM, "Jesse" <purplecabb...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> +1 to the sanity plea of devgeek Tommy >>>>>>>>>>> >>>>>>>>>>> Also, if it didn't happen on this list, .... >>>>>>>>>>> 'Consensus' should always be tracked back to a thread here, >>>>>>> regardless >>>>>>>>> of >>>>>>>>>>> meetings, hangouts, irc, bbs, ... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> @purplecabbage >>>>>>>>>>> risingj.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Apr 9, 2013 at 1:48 PM, tommy-carlos Williams >>>>>>>>>>> <to...@devgeeks.org>wrote: >>>>>>>>>>> >>>>>>>>>>>> Sorry, but as someone that helps users everyday, the >>>>> almost >>>>>> "it's >>>>>>>>> alpha, >>>>>>>>>>>> they shoulda seen it coming" tone of this is a bit >>>>> upsetting. >>>>>>>>>>>> >>>>>>>>>>>> It reminds me of before the deprecation policy, etc when >>>>>> PhoneGap >>>>>>>>> would >>>>>>>>>>>> completely break everything whenever a new version came >>>>> out. >>>>>>>>>>>> >>>>>>>>>>>> I feel like we have come a long way since then (with a >>>>> ways >>>>>> still >>>>>>> to >>>>>>>>> go, >>>>>>>>>>>> no question about it). I would hate to be the one in IRC >>>>> and on >>>>>>> the >>>>>>>>>>>> Google >>>>>>>>>>>> Group list having to explain this to everyone using the >>>>> cli. >>>>>>>>>>>> >>>>>>>>>>>> I was under the impression that the cli was "shipping" >>>>> now, >>>>> not >>>>>>>> just a >>>>>>>>>>>> little side thing. I know that quite a few people are >>>>> using >>>>> it >>>>>> for >>>>>>>>> real >>>>>>>>>>>> apps (myself included). If that is true, then we have a >>>>> duty >>>>> to >>>>>> at >>>>>>>>> least >>>>>>>>>>>> think very carefully before breaking something and come up >>>>> with >>>>>> a >>>>>>>> good >>>>>>>>>>>> plan >>>>>>>>>>>> for easing that transition. >>>>>>>>>>>> >>>>>>>>>>>> - tommy >>>>>>>>>>>> >>>>>>>>>>>> On 10/04/2013, at 1:40, Braden Shepherdson < >>>>> bra...@chromium.org >>>>>>> >>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> This mailing list post is, or will shortly be, indexed >>>>> by >>>>>> Google >>>>>>>> and >>>>>>>>>>>>> others. Any newcomers will see the new docs and create >>>>> new >>>>>>>> projects. >>>>>>>>>>>>> >>>>>>>>>>>>> As I mentioned on IRC, existing users are either >>>>> accepting >>>>> or >>>>>>>>> ignoring >>>>>>>>>>>> the >>>>>>>>>>>>> "alpha" warnings that this software is new and under >>>>> heavy >>>>>>>>>>>> development, >>>>>>>>>>>> and >>>>>>>>>>>>> if they want to jump on it early they're going to have >>>>> to >>>>>> expect >>>>>>>>> some >>>>>>>>>>>> pain. >>>>>>>>>>>>> >>>>>>>>>>>>> That said, I don't really know of any better way to >>>>> socialize >>>>>>> it. >>>>>>>> Is >>>>>>>>>>>> there >>>>>>>>>>>>> anywhere where a brief blog post on this would make >>>>> sense? >>>>>>>>>>>>> >>>>>>>>>>>>> I don't know how many people are using these tools and >>>>> not >>>>> on >>>>>>> the >>>>>>>>>>>> mailing >>>>>>>>>>>>> list, though certainly some turn up on IRC occasionally. >>>>>>>>>>>>> >>>>>>>>>>>>> Braden >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Apr 9, 2013 at 11:24 AM, Filip Maj >>>>> <f...@adobe.com> >>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> How will we communicate this change to our existing >>>>> users? >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" < >>>>> bra...@chromium.org >>>>>>> >>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've just pushed a change to the future branch that >>>>> changes >>>>>>> the >>>>>>>>>>>> directory >>>>>>>>>>>>>>> structure to: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> app/ >>>>>>>>>>>>>>> merges/ >>>>>>>>>>>>>>> android/ >>>>>>>>>>>>>>> ios/ >>>>>>>>>>>>>>> www/ >>>>>>>>>>>>>>> config.xml >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As was discussed at our video conference meeting a >>>>> couple of >>>>>>>> weeks >>>>>>>>>>>> ago, >>>>>>>>>>>>>>> this has a number of advantages: >>>>>>>>>>>>>>> - config.xml is no longer in the www/ directory >>>>>>>>>>>>>>> - One can easily version control the whole app/ >>>>> directory, >>>>>> and >>>>>>>> get >>>>>>>>>>>> their >>>>>>>>>>>>>>> web assets, merges and so on into the repo. >>>>>>>>>>>>>>> - That repo can contain additional information: a >>>>> README.md, >>>>>>>>>>>> supplementary >>>>>>>>>>>>>>> documentation, tests, whatever. The CLI will ignore >>>>> anything >>>>>>>>>>>> outside of >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> merges and www directories. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The downside is that this is a breaking change: >>>>> running >>>>> the >>>>>>> new >>>>>>>>>>>> version of >>>>>>>>>>>>>>> the tools on an old project will fail (but I think in >>>>> a >>>>>>> harmless >>>>>>>>>>>> way) >>>>>>>>>>>>>>> until >>>>>>>>>>>>>>> you rearrange the directories. You can do that with >>>>> the >>>>>>>> following >>>>>>>>>>>>>>> commands: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> $ mkdir app >>>>>>>>>>>>>>> $ mv www/config.xml app >>>>>>>>>>>>>>> $ mv www app >>>>>>>>>>>>>>> $ mv merges app >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> All docs and tests are updated as well. Any problems >>>>> should >>>>>> be >>>>>>>>>>>> reported on >>>>>>>>>>>>>>> JIRA and assigned to me. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Braden >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Timothy Kim >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>
