I didn't suggest writing any Java code. I didn't suggest writing any ant tasks in Java.
I said to create an antlib (though I should have said "library of ant definitions to be used with <include/>"), which is entirely in XML. That's part of why I suggested this approach, as it would avoid the need for coding the commands in some language or other, and leverage the coding already done for the EXISTING ant tasks. I've written Ant tasks in Java. I see no need for it in this project; I think we're on the same page there. Anyway, my point was primarily implementation -- I think the implementation will work out more simply and portably if the bulk of it is done with existing ant tasks. There might be need for some code to handle things like resource conflicts. I suspect this could be handled well with XSLT scripts called from ant, though if it gets complex, I'd recommend against doing the complex logic parts in XSLT. XSLT makes manipulating XML very easy, but general computation very hard! But you could produce an XML file of mappings and drive the XSLT using that. Now of course, you're about to tell me you have no patience for ant, either! But you've got to have patience for SOMETHING... On Apr 5, 4:45 am, "Mark Murphy" <mmur...@commonsware.com> wrote: > > But one thought is that making this be a command may not be the best > > approach for integration into build systems. I'm thinking that > > packaging it as an ant macro in an antlib may be a better approach, > > with the underlying technology being a .zip file with the various > > pieces. > > > Then, if you feel the need for a command, you could create an ant > > script, and simple shell scripts to invoke it. > > You assume I have the patience for Java. I put up with it for Android > development, but that's about as far as I want to, at least for the > initial versions. > > Part of the goal is to fully document all of the file structures and > whatnot such that if somebody else wants to create a native Ant task, or a > Rake task for use with JRuby, or whatever, they have all the info they > need. And I will be happy to help with testing and coordination and all > that. > > Tactically, I will be demonstrating Ant tasks that call out to the > command, much like they call out to javac, jar, aapt, etc. today. > > And I'm not saying I'd never write an Ant task or Maven thingamajig or > whatever myself someday, just that I'm not starting there. > > > Overall, I think it's cleaner to consider injection to be a build > > step, rather than a project configuration step. > > I am up for trying to support both modes. This is the sort of thing -- > like commands vs. Ant vs. Maven -- that really embodies the expression > "beauty lies in the eye of the beholder". Where possible, on those sorts > of things, I'd like to let the developer make the call. > > > You also need to consider how to avoid and/or handle file name > > conflicts. > > And resource ID conflicts. And dealing with the fact that you can't use > R.layout with those resources. And a whole host of other annoyances that, > individually, aren't particularly huge, but collectively represent a > significant amount of sand in the gears. > > Thanks for the input! -- 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 To unsubscribe, reply using "remove me" as the subject.
