Hi Bob, Thank you for your input. I think they are all interesting ideas.
I have decided to use another approach though. So here is how we are standing: Project A (Java) is the common base and holds the layout xmls. Projects B, C, etc (Android) are the regular applications. I will make Eclipse file links in project B, C, etc to all the layout xmls from project A. I will add a prebuild script that will physically copy the files from project A if no hard copy already exists in project B, C, etc (so physically copy the linked files). The aapt will run ok. Then I guess I will also have to delete them on post build. I choose this way because it fits most for what I need. I also like it because I have a visual representation of linked xmls. I can at any time replace the linked xmls with custom ones, and I will immediately get visual feedback - the linked/physical file icons in Eclipse. It is a little bit weird, but I think, as usability, this fits my purposes best. Thank you, BR, Adrian Vintu On Mon, Feb 22, 2010 at 5:11 PM, Bob Kerns <r...@acm.org> wrote: > Yeah, google-fu fails when you are the first to try something -- or > when those who have gone before are too foolish to ask their question > in public! > > This way you get to both pose the question and the answer for the next > person to try this. > > Anyway, the first thing I'd do is to think long and hard about my > reasons for wanting to do this. If there's really not enough benefit, > then don't do it; that's the simplest way. > > Otherwise, I'd write an ant script, and add an ant builder to my > project that copies it in from the source. You'll want to set it up to > run whenever the source changes, and to refresh the output file > whenever the script runs. This way, it'll run the script, do the copy, > and then tell Eclipse that the file has changed. > > But you won't be able to edit the file in res/ in Eclipse, without > losing your changes. That may be a steep price to pay. > > A better solution, in my opinion, is to have them be separate files > with a common ancestor, and use your revision control systems merging > capabilities to merge changes back and forth. For example, with > Subversion, use 'svn copy source/layout/main.xml res/layout/main.xml' > to make the local res/layout copy, such that it is a descendant of the > source/layout file. > > Then use 'svn merge' to merge changes between the two files. > > (Of course, you'll need 'svn commit' after each step, before touching > these files again, but you can combine that with other changes). > > A big advantage of this approach is that you can have changes which > you do NOT merge back, but only exist in one of the projects using the > common source. And yet you can continue to merge other changes back > and forth as needed. It's not as automatic, but it also leaves a > better audit trail. > > On Feb 22, 6:47 am, Adrian Vintu <adrianvi...@gmail.com> wrote: > > Ok, I found it. Seems the resources are built using the aapt.exe command > > line. This means, only physical files are taken into account... > > > > Anyone has an idea on a workarround for this? - to also make the linked > > files be physically included in the RES folder but also be updated if the > > source changes? Without using symlinks and stuff like that? > > > > Thank you, > > BR, > > Adrian Vintu > > > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
