+1 Lets start a fresh thread that describes the problem discreetly and work out a solution together. I suspect we'll arrive at a different solution than moving folders around.
On Thu, May 23, 2013 at 11:04 AM, Filip Maj <f...@adobe.com> wrote: > So for the sake of moving the RC release along, Michal/Braden/Andrew are > you guys cool if we: > > A) revert to www/ as root folder > B) proceed with 2.8.0rc1 tagging > C) continue with this discussion to try to get to a resolution. Worst-case > we call a vote next week? > > On 5/23/13 10:56 AM, "Michal Mocny" <mmo...@chromium.org> wrote: > >>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 >>> >>> >> >> > > >>>>>>>> >>> >>> >> >> > > >>>>>>> >>> >>> >> >> > > >>>>>> >>> >>> >> >> > > >>>>> >>> >>> >> >> > > >>>> >>> >>> >> >> > > >>>> >>> >>> >> >> > > >> >>> >>> >> >> > > >>> >>> >> >> > > >>> >>> >> >> > >>> >>> >> >> >>> >>> >> >>> >>> >>> >> >>> >> >>> >>> >
