Fil, that sounds extremely sensible.
On Thu, May 23, 2013 at 12:32 PM, Filip Maj <f...@adobe.com> wrote: > https://npmjs.org/package/cordova > > > While CLI is not a documented flow, it is deployed and has > 1000 > downloads per month. > > That's my only concern: not fucking those people over. > > I'm in favor of that structure I just don't want it to change without > warning in this next release. Ideally set up deprecation messages, be > noisy about the change, and sure, possibly supporting a transitioning > automatically in our tooling, and then land it in full and remove > deprecation messages about it in 3.0. > > On 5/23/13 9:27 AM, "Michal Mocny" <mmo...@chromium.org> wrote: > > >Clarification of typing mistake, below.. > > > >Also, curious why this breaks things in the first place? I thought this > >is > >the first time we are releasing these tools? The current create script > >workflow is totally different, and I know there is a npm package for > >cordova cli already, but that was never a promoted flow (matter of fact, > >why was it released? Are we supporting current users of that, is that it?) > > > >-Michal > > > >On Thu, May 23, 2013 at 12:22 PM, Michal Mocny <mmo...@chromium.org> > >wrote: > > > >> Brian, > >> I do not really understand your previous point, but I'll take a stab. > >> > >> First some clarification: I think there are two logical "roots", (1) > >>the > >> root of your web app (holds merges/ and www/ and maybe more), and (2) > >>the > >> root of your cordova workspace (holds platforms/ plugins/ and maybe > >>more). > >> > >> With the app/ folder, (1) is a subdirectory (2). With the current > >> situation, they overlap inside the same folder. > >> > >> I think it should be a goal to version control, share, and perhaps > >>bundle > >> auxiliary resources with app/'s. > >> I think it should also be a goal to not limit the future structure of > >>the > >> cordova workspace (ie, build artifacts). > >> > >> The current situation makes these goals harder. > >> > >> As one data point, our team here has a workflow where we share several > >> apps (containing only the contents(2)), and we share the common plugins > >>we > >> work on. > >> The contents of (1) are never committed, shared, etc, and are just > >> recreated on a regular basis as cordova versions change and as we test > >>for > >> different platforms. Sidenote: yes, I have multiple different cordova > >> workspaces pointing to one common app to test with different versions. > >> This is a bit of a cordova-developer necessity, but it would be > >> interesting if external devs could trial out new cordova releases on the > >> side, trivially.. > >> > >Sigh, of course I got the numbers reversed here.. my bad. Of course I > >mean > >we only commit (1). > > > > > >> > >> > >> So, like you Brian, we are just trying to get all the > >>requirements/wishes > >> on the table so we can make a conscious decision here. It looks like > >>you > >> are not seeing sufficient motivation for making the change, and we are > >>not > >> seeing any reason to not make it. > >> > >> Another observation: the transition path even easier than we have > >>outlined > >> above. > >> > >> If your existing project is: > >> - app_name/ > >> - platforms/ > >> - plugins/ > >> - www/ > >> - merges/ > >> > >> All you need to do is rm -rf platforms/ plugins/ www/config.xml -- which > >> you need to do anyway to upgrade to 3.0 -- create a new config.xml at > >>the > >> root and you now have a shareable app, and you can create as many > >>cordova > >> different workspaces using it as you want. > >> > >> -Michal > >> > >> > >> On Thu, May 23, 2013 at 11:47 AM, Brian LeRoux <b...@brian.io> wrote: > >> > >>> Not buying that either. The `./app` directory lives in the root so > >>> everything will have to change when we hit the reality you describe > >>> where `./app` IS the root. > >>> > >>> What you are really saying this is a transition step until such time > >>> as `./app` becomes top level and things return to the same as they are > >>> today but we do not require native bits to be revisioned. Essentially > >>> this is an aesthetic forcing function to get back to the original > >>> structure. =P > >>> > >>> This is a very complicated way to achieve the goal of native bits > >>> being build artifacts. A goal I share, many do, and I think we can > >>> achieve it by NOT breaking things today. > >>> > >>> > >>> On Thu, May 23, 2013 at 8:21 AM, Braden Shepherdson > >>><bra...@chromium.org> > >>> wrote: > >>> > cd app > >>> > git init > >>> > > >>> > Now my app directory - everything that makes this app mine and isn't > >>> just a > >>> > cordova-cli artifact - is version controlled. I can easily check out > >>>a > >>> new > >>> > copy with a cordova create ...; rm -rf app; git clone https:// > >>> .../myrepo.git > >>> > app > >>> > > >>> > Once we have app-level dependencies (which is planned regardless), I > >>>can > >>> > add cordova fetch-deps or whatever we decide the command should be, > >>>and > >>> now > >>> > my app is fully set up. No need to juggle .gitignore or anything > >>>else. > >>> It's > >>> > hardly a killer feature, but I think it is an improvement. > >>> > > >>> > Michal asked what change we would regret more a year from now. I > >>>think > >>> this > >>> > style makes the separation of CLI artifacts and my app more clear, > >>>and > >>> if > >>> > we add more pieces to either it won't require changing people's > >>> .gitignore > >>> > files or knowing about the architecture. > >>> > > >>> > Braden > >>> > > >>> > > >>> > On Thu, May 23, 2013 at 11:15 AM, Brian LeRoux <b...@brian.io> wrote: > >>> > > >>> >> I want to be very clear that my tone here is emotionless! I'm > >>>totally > >>> >> indifferent. > >>> >> > >>> >> Now, please explain: how is a new directory make version control > >>> >> easier? I don't buy it. > >>> >> > >>> >> > >>> >> On Thu, May 23, 2013 at 8:02 AM, Braden Shepherdson < > >>> bra...@chromium.org> > >>> >> wrote: > >>> >> > The change is not purely aesthetic; it means that the "my app" > >>> portions > >>> >> of > >>> >> > the structure are now contained in a single directory, and easier > >>>to > >>> >> > version control. > >>> >> > > >>> >> > This change gets more expensive every day. If we're ever going to > >>>do > >>> it, > >>> >> it > >>> >> > should be done now, I believe. > >>> >> > > >>> >> > It seems like the (not universally supported) consensus from the > >>> first > >>> >> pass > >>> >> > at this thread was to keep the app/ dir but have automatic > >>>detection > >>> and > >>> >> > ask-then-automatic conversion. > >>> >> > > >>> >> > If that approach is still acceptable, I will implement that > >>>support > >>> today > >>> >> > before we tag CLI for 2.8. > >>> >> > > >>> >> > Braden > >>> >> > > >>> >> > > >>> >> > On Thu, May 23, 2013 at 12:30 AM, Michal Mocny > >>><mmo...@chromium.org> > >>> >> wrote: > >>> >> > > >>> >> >> Fil, good summary, thanks for that. I also agree with your > >>> proposal. > >>> >> >> Would it be possible to just support both options starting now, > >>>and > >>> >> >> "deprecate" www/ at the top level in 3.0? > >>> >> >> > >>> >> >> Brian, this isn't just aesthetics, but its true that either > >>>option > >>> can, > >>> >> >> with varying difficulty, be made to work for all use cases. > >>> >> >> > >>> >> >> Migration path is trivial but will be paid by all users, still, > >>> >> workflows > >>> >> >> will change completely with 3.0 anyway, this being the least of > >>>the > >>> >> >> changes. Which decision is more likely to be regretted a year > >>>from > >>> now? > >>> >> >> > >>> >> >> -Michal > >>> >> >> > >>> >> >> > >>> >> >> On Wed, May 22, 2013 at 10:11 PM, Andrew Grieve < > >>> agri...@chromium.org > >>> >> >> >wrote: > >>> >> >> > >>> >> >> > I don't really think this directory change is a big deal. We > >>>break > >>> >> things > >>> >> >> > in almost every release (e.g. loading pages of http), yet we're > >>> >> having so > >>> >> >> > much debate over alpha tool. > >>> >> >> > > >>> >> >> > The migration path is: mkdir app && git mv www merges app && > >>>git > >>> mv > >>> >> >> > app/www/config.xml app > >>> >> >> > > >>> >> >> > I think the least amount of work here is to just console.log an > >>> error > >>> >> >> > message with this command if the app/ directory is not found. > >>> >> >> > > >>> >> >> > > >>> >> >> > On Wed, May 22, 2013 at 9:28 PM, Tommy-Carlos Williams > >>> >> >> > <to...@devgeeks.org>wrote: > >>> >> >> > > >>> >> >> > > 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:j76 > >>>xli > >>> >> >> > > >> 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 > >>> >> >> > > >>>>>>>> > >>> >> >> > > >>>>>>> > >>> >> >> > > >>>>>> > >>> >> >> > > >>>>> > >>> >> >> > > >>>> > >>> >> >> > > >>>> > >>> >> >> > > >> > >>> >> >> > > > >>> >> >> > > > >>> >> >> > > >>> >> >> > >>> >> > >>> > >> > >> > >
