On Tue, Jun 25, 2013 at 1:13 PM, Charles Oliver Nutter <head...@headius.com>wrote:
> Great progress, kristian...I'm poking at it a bit right now! > > I agree with the XML getting rather ugly, especially when we have a > lot of custom build steps. The only problems I see with using > ruby-maven are obviously bootstrapping-related (have to install it, > including jruby, to use it to build jruby). > > On the other hand, once this is done we shouldn't have to fiddle with > it anymore. We are also willing to reorg our directory structure and > build process to reduce the amount of customization necessary (e.g. > moving src into src/main/java). > > Other comments below: > > On Tue, Jun 25, 2013 at 10:55 AM, kristian <m.krist...@web.de> wrote: > > this does use only maven central and a few artifacts from ./localrepo > > repository in which I copied those jars from ./build_lib > > Looks great! And if we only have a couple of these, it's not a huge > deal either. I personally will be happy if we can get rid of the bulk > of our in-dist binaries. > > > the tzdata stuff I also implemented up to using joda to compile the > timezone > > files but then I got stuck since the purpose of those files is not really > > clear ! > > The tzdata files get updated more frequently than JodaTime releases > (and we don't want to update JodaTime every time anyway), so we update > it ourselves. > > It could probably be fetched from somewhere, too. Perhaps someone's > pushing official tzdata files to maven? > > > the Constants.java is also patched beside the tzdata value - again some > lack > > of understanding of the tzdata thingy. > > Yeah, when I started poking around maven docs, I was not clear how we > should handle code generation. We generate at least the following: > > * Constants.java > * A pseudo-Unsafe class just for unchecked throws > * *POPULATOR.java for fast binding of Ruby methods (these may go away > once we're Java 7+ only) > * *INVOKER.class files that act as method handles (these will probably > go away once we're Java 7+ only) > Android? -Tom > > Constants.java is done via an ant substitution, as you probably saw. > The latter two items are generated via annotation processing. So the > compile phases are something like: > > * Generate Constants.java and pseudo-Unsafe > * Compile annotation processor > * Compile JRuby; annotation processor spits out populators > * Run invoker generator, which walks annotations and spits out invoker > classes > > The final two phases could *possibly* be done in a single pass, but > the invokers need to aggregate annotation data from multiple methods > to generate properly. > > > currently I will not put time into all the external dependencies like the > > ones from the localrepo and focus on getting the maven working until > jruby > > can be executed. > > That's perfect. Summing up some remaining to-do's: > > * Generating Constants.java, pseudo-Unsafe, populators and invokers. > The invokers are especially important, since they're very expensive to > generate at runtime. > * tzdata, ideally sourced during the build so we know it's always current. > * Shading dependencies into "jruby.jar" we can install in lib dir. I > say we're willing to make changes to the repository layout, but > obviously JRuby still needs to be executable in-place after build. > * jarjar-style mangling where appropriate > > Once we're at that point, we could probably make a changeover in the > main repo. Pretty much everything else could be done from Rake: > > * native library unpacking and juggling > * dist files creation > * test runs > > Looking great so far! > > - Charlie > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- blog: http://blog.enebo.com twitter: tom_enebo mail: tom.en...@gmail.com
