Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of brian.leroux@gmail.com
 designates 74.125.83.47 as permitted sender)
MIME-Version: 1.0
Sender: brian.leroux@gmail.com
In-Reply-To: 
 <CANpVHHx_fiBhkuwqMF8H6pGmvafyxpO2M5N8ckJZ2Ky4w_UjDA@mail.gmail.com>
References: 
 <CANpVHHy1DSNrEXhB8ttx5FhoKxFNMw3nOeCKBW_UyiSG=bOkxQ@mail.gmail.com>
	<CC7A877B.DD5E%fil@adobe.com>
	<CANpVHHx_fiBhkuwqMF8H6pGmvafyxpO2M5N8ckJZ2Ky4w_UjDA@mail.gmail.com>
Date: Sun, 16 Sep 2012 23:07:05 -0700
Message-ID: 
 <CADVgkyPW++1AAhV1izL44iXBwaT8_Lq489cYVvNfa+3xKXJiJw@mail.gmail.com>
Subject: Re: plugin tooling/specification
From: Brian LeRoux <b@brian.io>
To: callback-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

TL;DR

+1 for building in functionality that clobbers the native bits every
time and treats them as a build artifact.

***
FWIW, this was the cause of bugs in the cordova prototype stuff I did.
Ppl would generate a native project, then modify the native bits,
while using the tools to copy in fresh WWW assets... then when an
upgrade happened everything was fucked.

Our goal should be to make it so that the only path to modifying
generated native bits should be either plugins, or upgrades to cordova
config.xml.


On Sun, Sep 16, 2012 at 4:47 AM, Anis KADRI <anis.kadri@gmail.com> wrote:
> Right. In that case, we could make those cordova command tools slightly
> smarter ;)
>
> On Sat, Sep 15, 2012 at 7:29 PM, Filip Maj <fil@adobe.com> wrote:
>
>> Right. I'm ok with this but wanted to keep the exact cordova-powered
>> platform projects as untouched as possible, so you could cd into those
>> directories and do whatever you want (run usual cordova project commands,
>> compile, etc). So removing the www from there forces everyone to always go
>> through the tool.
>>
>> On 9/15/12 7:23 PM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>>
>> >On Sat, Sep 15, 2012 at 5:32 PM, Filip Maj <fil@adobe.com> wrote:
>> >
>> >>
>> >> >Ohhh I think I understand. So basically it packages the www resources
>> >>into
>> >> >the binary at build time?
>> >>
>> >> Correct. Each platform's underlying implementation has its own "www"
>> >> folder. At build time, the top-level www of your project gets copied
>> >>into
>> >> each platform before doing a compile for that platform.
>> >>
>> >> >> platforms/xxx/www gets destroyed and recreated on every build. See
>> >> >> here<http://bit.ly/PFKQvS>.
>> >> >> It's needed to build packages for every platform. It could arguably
>> >>be
>> >> >> destroyed after every build though. Fil is there a reason why that's
>> >>not
>> >> >> the case ?
>> >>
>> >> That is the case is it not? Line 57?
>> >>
>> >> Or do you mean, we should delete the platforms/<platform>/www (or
>> >> equivalent) after building?
>> >>
>> >
>> >Yes that's what I meant.
>> >
>> >
>> >>
>> >> If the latter, I don't see the point.
>> >>
>> >
>> >To avoid confusion. The reason why we're discussing this is because Mike
>> >got confused after seeing the root www and a www in each platform
>> >subfolder. There is also no reason to keep them around since they get
>> >destroyed before every build anyway. So maybe they should just get
>> >destroyed _after_ every build. You'd just recursively copy the folder
>> >before every build. I don't really care either way. Just trying to avoid
>> >the "Where do I drop my code?" scenario.
>>
>>