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 ago, so I may be blind to the benefits of #2, but to me this makes our library become a boilerplate... am I wrong? Cheers, Jesse On 2012-09-26, at 8:55 AM, Mike Reinstein <reinstein.m...@gmail.com> wrote: > +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 <b...@brian.io> wrote: > >> 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 <agri...@google.com> 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 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://github.com/apache/incubator-cordova-ios/pull/52 >>> >>> Which addresses bug: https://issues.apache.org/jira/browse/CB-1526 >>> >>> So... I'm hoping we can a bit of a discussion of how to address these >>> concerns. >>> >>> Work-arounds I can think of: >>> 1. Encourage users to use XCode workspaces so that multiple projects can >> be >>> open at the same time that use the *same* version of CordovaLib. We could >>> change our project template to use a workspace, but that just has them >> end >>> up with multiple workspaces they can't open at the same time... >>> >>> 2. Copy the entire CordovaLib directory into their project, so that each >>> project uses a different copy of CordovaLib. >>
