On Mon, Jun 24, 2013 at 10:51 AM, Thomas E Enebo <tom.en...@gmail.com> wrote: > yydebug did come from jay but I agree we should probably just publish it. > Probably for jay itself too even though it is not a Java library :)
Ok, so that should be added to the "yet to be mavenized" list. Hopefully we would do it once and never have to touch it again. >> I'd like to get as many exts and stdlib separated out as possible. > > "as many"? Do we really need a new repo for rbconfig or etc so it can be > released independently of JRuby? I totally agree with the ones you list > above, but I need to think about how much I will love having an additional > 29 repositories just for the consistency of how we organize this stuff. At > this point I would probably only move those out and possibly socket. Right, I didn't mean going that far. I mean "as many as makes sense." This includes stuff that should obviously be upgradable (openssl, psych, json), stuff that we don't maintain (rdoc, rake, minitest), and core stuff that's benefits from being sliced out of core (readline, socket maybe, ffi maybe, weakref maybe). This doesn't mean these libraries would not be shipped with JRuby...it just means we'd consider them external libraries, ship a default version, and allow them to be gem-upgradable. I don't want to slice the entire world up a la https://github.com/RubySL :-) >> Some are released via codehaus. It might be worth moving everything to >> sonatype so it's all in the same place. > > > Based on the fact it took sonatype over 3 days to push jnr-posix to maven > central I might question that goal. I at least would like to know what went > wrong. [I am not against moving them off of codehaus, but that issue really > dragged our last release out] That could be a real issue or just a fluke. Pushing to maven central is always going to have some delays. I'd like to know if we did something wrong too, but I still feel like Sonatype has the best setup for what we need (easy creation of new artifacts, good interface for promoting, and responsive friends on the inside if we have issues). I really don't care either way, though, if once we're bootstrapped it's just a couple mvn commands to do everything. > 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. The more libraries we're able to yank out as "external", the easier this will be. Ruboto has no use for readline, but it was bundled in the same jar prior to 1.7.4. Lots of libraries in stdlib and org.jruby.ext fall into the same category. So...it's much less convenient to move exts out to separate projects/repos/dir trees, but it makes upgrading them, managing them independently, and conditionally pulling them into JRuby profiles easier. Tough choice :-\ > 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. Agreed. We have three or four artifacts right now and people are confused about which to use. If we had a dozen, nobody would ever get it right. > 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. Yeah, this is the other possibility, and I'm not a big fan either. Subsystems like jruby-readline, jruby-openssl, jruby-socket, jruby-weakref could be mvn deps we pull in (or others can pull in) as transitive dependencies. But that starts to stink like "bytelist" if we slice it up too fine. You also can't use most of these libraries independent of JRuby...so they *only* make sense in the context of a JRuby profile. Is that an appropriate use of maven? I don't know. - Charlie --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
