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)
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
