I find this works fine sometimes, and is a real pain other times. It tends to work fine when you're just developing along on the stuff that's shared.
But later in the project, when you're testing and bug fixing in both branches on both shared and differentiated parts, then you end up having to do a lot of merging. You may even get merge conflicts. What I suggest is putting all the code into one project, and customizing the build process to build two (or more) versions. What my build script does is: 1) Tag via a copy of trunk to /tags/builds/<project>/<buildno> <buildno> is the maximum of the SVN revision of each included component, including the build scripts themselves + any third-party pieces. 2) I switch my build working copy to this branch. (If it's missing, I do a checkout). 3) I then export two copies from the build working copy. 4) I then run a configuration step that adjusts for the differences. Mostly this consists of modifying the package name in the manifest, etc. I have subclasses of each entry point so I can customize each as needed. 5) I then build normally, and export the results to a dist directory. This has several benefits. ZERO merging. It's a bit faster to build both versions together, with only a single checkout/swtich time, though some of that is lost with the extra copy step. All the code is in one place. There's only one Eclipse project, so you never end up pulling up the wrong source, yet both versions of the code are always available. And it's completely automated, so you get consistent results. Also, all the differences are explicit. The code differences are segregated in the respective version-specific packages, while the shared stuff is in the other packages. For resources and the manifest, the differences are explicit in XSLT scripts that configure those resources. My build numbers are completely automated and guaranteed to increment. On Mar 13, 1:51 am, Anders Aagaard <[email protected]> wrote: > Personally I'd use a version control system with branches to do this. > And keep it in one project. > > Doing it with branches you could easily merge changes that go in both > versions, and just do a refresh in eclipse when doing development on > the other version. > > On Mar 11, 10:51 pm, "Matt (preinvent)" <[email protected]> wrote: > > > > > I have a free app out there and am going to write a pro version with > > some extra functionality that I'll charge for. > > > The plan is to use the same code for both apps, although I need > > different Eclipse projects to use different manfiest files. The > > obvious way is to have all my code in a shared library which the free > > and pro projects reference. > > > Is there a recommended way of doing this? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
