One thing I'd like to say in response to some of the negatives of Gradle is that by using the gradle wrapper ( http://www.gradle.org/docs/current/userguide/gradle_wrapper.html) you get the very nice benefit of being able to version your build tool along with your code. You won't have to deal with individuals needing a particular version of ant or maven installed locally, gradle is smart enough to just download itself and then use that version going forward. The whole build tool doesn't get saved in your SCM tool, just enough for gradle to be able to bootstrap itself. All you need installed is Java and you are good to go, it even comes with OS specific bootstrap wrappers to get everyone started.
I use it on several projects and I would never want to go back to the days of needing to install a build tool separate from the codebase that uses it and having to try and coordinate upgrades of build tools between developers. The other reasons for not using gradle may be enough to not use it, I just don't want the decision based on the lack of packages for various OS'es. Joe On Mon, Jun 24, 2013 at 11:08 AM, Thomas E Enebo <tom.en...@gmail.com>wrote: > Yoko, > > There are two goals I would like to see for 9k with these platforms in > mind. I would like looser coupling so that conditionally only part of our > codebase can be compiled. So if you are on a limited platform with no > socket support you should be able to omit it and our codebase will still > compile. > > Secondly, I would like to see our build system capable of conditionally > packaging a subset of all the files we have. Hopefully in 9k we will only > have a single stdlib, but if we ever had that situation again, I would like > it to be easy to exclude one of the copies. > > One thing I don't want is for us to package and release these hybrid > distributions. Putting out additional releases takes effort and also > confuses people trying to figure out which jar they need. So in that > respect, I would like to make changes to our source/packaging to empower > others to do this. This also makes sense if you consider that Ruboto would > never want to release on our schedule. > > Speaking against myself earlier ( :) ) making hundreds of maven artifacts > is actually a solution to this (definitely on packaging so long as they are > two-way hard dependencies) but I half feel the cure is worse than the > disease. > > -Tom > > > On Sun, Jun 23, 2013 at 2:03 PM, Yoko Harada <yoko...@gmail.com> wrote: > >> Hi Charlie, >> >> Mavenizing is a good idea. It is IDE friendly. (Probably Gradlizing as >> well) >> >> When JRuby will be mavenized, is it possible to divide into sub modules? >> and, for some users, make it customizable? >> For example, Ruboto cuts down unnecessary packages from JRuby and make it >> small to fit in the devices. >> As far as I remember, JRuby for Google App Engine needs to be cut up in >> two pieces to fit in to upload-able size limit. >> >> "Upgradable extensions" is somehow curious, but I don't have a clear >> image about that. >> For example, pure Java Nokogiri will have some good effects from this? >> >> Best, >> -Yoko >> >> >> On Sun, Jun 23, 2013 at 1:09 PM, 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 >>> >>> >>> >> > > > -- > blog: http://blog.enebo.com twitter: tom_enebo > mail: tom.en...@gmail.com >
