incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Reinstein <reinstein.m...@gmail.com>
Subject Re: plugin tooling/specification
Date Mon, 17 Sep 2012 14:58:03 GMT
Hi Brian,

> They then add, and subsequently modify, the
> generated native bits in the platforms folder.

Can you please give me more specifics here? Are you describing a cordova
plugin writer's use case here, where they are continually updating native
files in their project, or something else? Or is "they" referring to the
SDK maintainers changing things like Android or ios team? It's not clear to
me how these native bits are being changed.

-Mike

On Mon, Sep 17, 2012 at 5:09 AM, Brian LeRoux <b@brian.io> wrote:

> Consider this scenario. A developer generates a new Cordova project.
> They then add, and subsequently modify, the generated native bits in
> the platforms folder. Google changes something, perhaps how
> AndroidManifest works. Or maybe Apple deprecates a library. The
> developer now needs to regenerate their native bits in the platforms
> folder. But they modified stuff---now, we could track their changes
> but this would lead us down a path of either depending on or
> implementing a revision control system (which we do not want to do).
> Easiest path for us here, and open to alternatives of course, is that
> we treat the native bits as throwaway compile junk.
>
> This means more work for us. We have to stay on top of the stuff we're
> painting over. But nobody said this project was easy! Interestingly,
> none of Cordova is really all that technically hard (in hindsight).
> Its just pain in the ass hard.
>
>
> On Mon, Sep 17, 2012 at 12:03 AM, Mike Reinstein
> <reinstein.mike@gmail.com> wrote:
> > Brian I'm confused. Can you elaborate a bit more?
> >
> > On Mon, Sep 17, 2012 at 2:07 AM, Brian LeRoux <b@brian.io> wrote:
> >
> >> 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.
> >> >>
> >> >>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message