Any thoughts on migrating to Gradle rather than Maven? This should give better tools for capturing the complexity of the existing ant build while still having all the benefits you're after from Maven.
I reckon it would also give a better migration path than Maven: it should be possible to port the current build structure almost as-is, with the first goal being simply to nuke the build_lib, then refactoring the new Gradle scripts over time to be the build of our dreams. Hopefully that helps... I'm reluctant to broaden this discussion so late in the game, but it seemed worth mentioning. On Sun, Jun 23, 2013 at 10:09 AM, Charles Oliver Nutter <head...@headius.com > wrote: > Ok folks...the branching off of 1.7 is coming very soon, and I think > one of the biggest ticket items we need to do before then is reorg the > codebase like we want to see it in the future. Failing to do this > before branching will massively complicated merging changes back. > > I have a few proposals. > > * Mavenizing. > > I know this will elicit groans from many people, but it has become > more and more of a hassle to keep versions in sync and manage the > repository with all our external dependencies. If we were 100% > maven-based for build, all dependencies would live outside the repo > (not as repo-bloating binaries) and we'd always be able to generate a > current snapshot. I think we need to do this. > > Making this change should eliminate build_lib and much of our ant build > scripts. > > * Reorg upgradable extensions into their own src trees or repositories. > > I'm thinking of pieces like openssl, psych, readline. Some extensions > are already in their own repositories and we just copy them in, like > json. We could proceed with this one of two ways: > > Via maven layout: src/main, src/openssl, src/psych, etc. > > Via separate repositories: jruby/openssl, jruby/psych (or just in > psych proper), etc. > > I'd like to get as many exts and stdlib separated out as possible. > > Making this change could move most of org.jruby.ext.* out of the main > repository and would make managing and upgrading ext and stdlib > easier. > > * Remove C ext support to an external repository and gem > > I'm playing with this locally, and there aren't many dependencies from > JRuby proper back into C ext code. It stands alone pretty well. > > Who knows...spinning it off might make it more likely third-party > folks will continue to update and improve it. > > Removing it will eliminate the org.jruby.cext package and the cext > dir, plus any build and test artifacts related to cext. > > ... > > Anything else? > > - Charlie > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
