Will do :)
On Thu, Oct 4, 2012 at 5:27 PM, Shazron wrote:
> Awesome - thanks Andrew, now to document the new process and update the
> docs ;)
>
> On Tue, Oct 2, 2012 at 11:20 AM, Andrew Grieve
> wrote:
> > Done and done!
> >
> > The update_cordova_subproject script can now take in a 2nd param
THANK YOU! I was getting tired of running both scripts!
:-b
On Thu, Oct 4, 2012 at 4:36 PM, Andrew Grieve wrote:
> This has already started to annoy me as a Cordova developer since now when
> I create a new project and edit some native files, those files are not the
> ones in my git repo, but r
Awesome - thanks Andrew, now to document the new process and update the docs ;)
On Tue, Oct 2, 2012 at 11:20 AM, Andrew Grieve wrote:
> Done and done!
>
> The update_cordova_subproject script can now take in a 2nd param for the
> path to the CordovaLib project, and the create script now copies th
This has already started to annoy me as a Cordova developer since now when
I create a new project and edit some native files, those files are not the
ones in my git repo, but rather they are copies.
So, I added a flag to the create script --shared, that will do the old
behaviour of not using a cop
Ok, I guess one can't be slow in responding to these threads. I would have
preferred to get Shaz's input on these changes as he is most aware of the
issues and for the reasons why things have been done this way. I guess a
change / build script isn't that hard to change if he has issues when he
r
Done and done!
The update_cordova_subproject script can now take in a 2nd param for the
path to the CordovaLib project, and the create script now copies the
CordovaLib into new projects.
On Mon, Oct 1, 2012 at 2:13 PM, Andrew Grieve wrote:
> Started a new new thread about going forward with
Started a new new thread about going forward with option #2. Besides you
both being in favour of this option, it also aligns with the structure
described by https://github.com/filmaj/cordova-client, so I think it's
definitely the way to go :).
On Mon, Oct 1, 2012 at 6:32 AM, Brian LeRoux wrote:
Seems a little bit too brittle requiring users to install Cordova in order
to share code they created with Cordova. (Which could cause good old
fashioned path issues.) Again, would prefer libs live under the project
they are dependencies for (as we do w/ Android).
On Sep 29, 2012 8:32 PM, "Andrew
Andrew I see your point, and yes it may solve the concerns I mentioned
previously, just few additional things I want to throw in:
1) I believe most of the users will download Cordova as a whole
package, zipped as a distribution with all other platforms support
(like it is now @ phonegap.com). This
On Sat, Sep 29, 2012 at 4:57 AM, Piotr Walczyszyn <
piotr.walczys...@gmail.com> wrote:
> I think having a reference just to a project file doesn't solve 2
> common scenarios:
>
> 1) multi developer environment, in this case all application
> developers need to have same directory structure, so the
I think having a reference just to a project file doesn't solve 2
common scenarios:
1) multi developer environment, in this case all application
developers need to have same directory structure, so the relative path
to CordovaLib is the same
2) CordovaLib versioning, often you want to version the
would different versions will work ok?
On Sat, Sep 29, 2012 at 2:33 AM, Andrew Grieve wrote:
> Another options I've now thought of, and I think I like this one the best
> :).
>
> Instead of copying the entire CordovaLib directory into each project, just
> copy the CordovaLib.xcodeproj file. This
Another options I've now thought of, and I think I like this one the best
:).
Instead of copying the entire CordovaLib directory into each project, just
copy the CordovaLib.xcodeproj file. This will allow each project to be open
at the same time, since they will technically reference different pro
thinking a bundled upgrade cli command in all the projects is a good
idea... something that automates whatever we document in the upgrade
guide
On Thu, Sep 27, 2012 at 6:58 PM, Jesse wrote:
> Mis-understood some of the finer points, thanks for the clarification
> and patience all.
>
> I agree
Mis-understood some of the finer points, thanks for the clarification
and patience all.
I agree that option 2 makes the most sense.
On Thu, Sep 27, 2012 at 9:52 AM, Mike Reinstein
wrote:
> an upgrade script would be really helpful as well.
>
> -Mike
>
> On Thu, Sep 27, 2012 at 12:44 PM, Piotr Wa
Well, for upgrades the modified bin/update_cordova_subproject that
I've sent pull request with could work. Only the users would have to
copy CordovaLib to their projects directory.
p.
2012/9/27 Mike Reinstein :
> an upgrade script would be really helpful as well.
>
> -Mike
>
> On Thu, Sep 27, 20
an upgrade script would be really helpful as well.
-Mike
On Thu, Sep 27, 2012 at 12:44 PM, Piotr Walczyszyn <
piotr.walczys...@gmail.com> wrote:
> As I suggested in the pull request comments, this would really make
> sense to update bin/create script either by enhancing it with
> additional argu
As I suggested in the pull request comments, this would really make
sense to update bin/create script either by enhancing it with
additional argument to embed the CordovaLib with newly created
projects or even make this behavior a default one.
p.
2012/9/27 Andrew Grieve :
> Suppose you have 5 pro
Suppose you have 5 projects that depend on 2.1, and 3 that depend on 2.0.
One big difference between the two options is that for the 2nd option,
you'd have 8 copies of Cordova, whereas for the first option you'd have
only two.
I think getting the correct workflow set up with Xcode workspaces will
+1
On Thursday, September 27, 2012, Mike Reinstein wrote:
> Agree on all points with Brian.
>
> On Thu, Sep 27, 2012 at 6:34 AM, Brian LeRoux >
> wrote:
>
> > > Global dependancies? It's a library, why would you not be dependent on
> > it?
> > >
> >
> > We're talking about global deps vs local de
Agree on all points with Brian.
On Thu, Sep 27, 2012 at 6:34 AM, Brian LeRoux wrote:
> > Global dependancies? It's a library, why would you not be dependent on
> it?
> >
>
> We're talking about global deps vs local deps. Not whether or not you'll
> have a dependency!
>
>
> > Standardize on the a
> Global dependancies? It's a library, why would you not be dependent on it?
>
We're talking about global deps vs local deps. Not whether or not you'll
have a dependency!
> Standardize on the apis and not the files.
>
Uh, ok sure, not sure I understand?
It only takes a few weeks of ruby (and/o
Option 1
Global dependancies? It's a library, why would you not be dependent on it?
Standardize on the apis and not the files.
Not to mention the extra complexity of #2, and multiple out of sync
project issues.
I originally moved the codebase to a library and created the template
over 2 years ag
+1 on this. I'm assuming doing this also means being able to upgrade
projects independently of each other?
-Mike
On Wed, Sep 26, 2012 at 11:02 AM, Brian LeRoux wrote:
> Option #2 makes the most sense to me. Global dependencies tend to fall
> into the Bad Idea category from my perspective.
>
> O
Option #2 makes the most sense to me. Global dependencies tend to fall
into the Bad Idea category from my perspective.
On Wed, Sep 26, 2012 at 4:38 PM, Andrew Grieve wrote:
> There are a lot of users that are not loving the fact that Xcode can't open
> two different projects that include the same
There are a lot of users that are not loving the fact that Xcode can't open
two different projects that include the same sub-project (mostly on the
phonegap google group).
This is something that worked before the move to a subproject in 2.0.0.
We've also got an outstanding pull request:
https://g
26 matches
Mail list logo
