Posted by Nick Sieger
Thu, 17 May 2007 17:35:00 GMT
Just a quick update. Firstly, I just released ci_reporter 1.3; it should be available in the gem index shortly. Thanks to Bret Pettichord, Jeremy Beheler, and Charlie Kunz for reporting issues and prodding me to fix a couple of bugs. The two new items in this release are:
- RSpec 0.9/trunk-compatible. You can now
describe/it all you want with ci_reporter.
- Errors and failure stack traces now include the full error message and exception type.
Secondly, JRuby 1.0RC2 has been released. Although there is no official release announcement at the moment, it is available for download and has been propagated to the central Maven repository also. Please do check it out and let us know on the mailing lists or in JIRA if you come across any blocker issues or regressions. Just a couple more weeks of stabilization; expect a rockin’ 1.0 release in June!
Lastly, expect an ActiveRecord-JDBC 0.3.2 release Real Soon Now.
Tags continuousintegration, jruby, railsconf, railsconf2007, ruby | no comments | no trackbacks
Posted by Nick Sieger
Fri, 20 Apr 2007 15:01:08 GMT
So, on somewhat late notice due to a miscommunication, I’ve been asked to step in and give a talk on JRuby at the SDForum Silicon Valley Ruby Conference this Sunday the 22nd. This, in addition to my already-scheduled talk at GoRuCo! JRuby makes an appearance on both coasts in a single busy weekend!
Due to schedule shuffling, I’ll be sharing a 75-minute time slot in the morning with Tor Norbye, who will be giving a talk on Ruby tooling featuring NetBeans.
Tags goruco, jruby, ruby, sdforum, svrc | 1 comment | no trackbacks
Posted by Nick Sieger
Sat, 24 Mar 2007 04:41:00 GMT
Hey! I’ve been so excited and busy at the same time I forgot to mention I’ll be speaking at the Gotham Ruby Conference on April 21st in NYC located at the Googleplex in Chelsea. Hopefully you’ve got your ticket by now, as last I heard there were only a couple of tickets left. You’ll hear me giving the JRuby pitch: Ruby on the best VM on the planet, performance updates, deploying Rails by dropping a file in a Java webserver, and more. Looking forward to carousing with the fine Rubyists in the Tri-State Metro area! Manhattan was my provenance in 1997-1999, where I had my first programming gig out of college, so I feel like I’m coming back to where I got started, in a way.
Only downer -- I’ll miss the second incarnation of Minnebar, which was a blast last year. If you’re near the Twin Cities that weekend you owe it to yourself to attend.
Tags goruco, jruby, minnebar, ruby | 1 comment | no trackbacks
Posted by Nick Sieger
Fri, 16 Mar 2007 16:55:00 GMT
On the heels of my last post, Robert announced the 1.0 release of Rails Integration, the bits that allow JRuby on Rails to be run out of a Java web archive (war). If you have any interest at all in trying out JRuby on Rails, do yourself a favor and try out the integration bits. Even though this is 1.0, we’re still moving rapidly and would appreciate any and all feedback. (And Robert is doing his best to keep up with changes in core.)
Related to this, Stuart Halloway recently announced his J plugin which is a drop-in collection of Rake tasks that bridge the inherent differences between Rails running on C Ruby vs. JRuby. We still have some work to do in some areas, such as database driver configuration, test database bootstrapping and launching unit tests. For example, instead of the big, ugly, database-specific case statement that’s in Rails’ databases.rake today:
desc "Recreate the test databases from the development structure"
task :clone_structure => [ "db:structure:dump", "db:test:purge" ] do
abcs = ActiveRecord::Base.configurations
case abcs["test"]["adapter"]
when "mysql"
ActiveRecord::Base.establish_connection(:test)
ActiveRecord::Base.connection.execute('SET foreign_key_checks = 0')
IO.readlines("db/#{RAILS_ENV}_structure.sql").join.split("
").each do |table|
ActiveRecord::Base.connection.execute(table)
end
when "postgresql"
ENV['PGHOST'] = abcs["test"]["host"] if abcs["test"]["host"]
ENV['PGPORT'] = abcs["test"]["port"].to_s if abcs["test"]["port"]
ENV['PGPASSWORD'] = abcs["test"]["password"].to_s if abcs["test"]["password"]
`psql -U "#{abcs["test"]["username"]}" -f db/
when "sqlite", "sqlite3"
dbfile = abcs["test"]["database"] || abcs["test"]["dbfile"]
`
when "sqlserver"
`osql -E -S
when "oci", "oracle"
ActiveRecord::Base.establish_connection(:test)
IO.readlines("db/#{RAILS_ENV}_structure.sql").join.split(";
").each do |ddl|
ActiveRecord::Base.connection.execute(ddl)
end
when "firebird"
set_firebird_env(abcs["test"])
db_string = firebird_db_string(abcs["test"])
sh "isql -i db/#{RAILS_ENV}_structure.sql #{db_string}"
else
raise "Task not supported by '#{abcs["test"]["adapter"]}'"
end
end
we can use migrations to create the test database:
desc "Recreate the test databases from migrations"
task :migrate_test_db do
ActiveRecord::Base.establish_connection(ActiveRecord::Base.configurations['test'])
ActiveRecord::Schema.verbose = t.application.options.trace
ActiveRecord::Migrator.migrate("db/migrate/")
end
Over time, I hope to see all these efforts coalesce and make the Rails developer experience virtually identical on either interpreter. What would be most excellent is to eventually push some of these improvements back to the Rails core.
Tags jruby, rails | 2 comments | no trackbacks
Posted by Nick Sieger
Fri, 16 Mar 2007 04:18:00 GMT
While cleaning up the subprocess launching code in JRuby recently, I pulled a fast one. See, JRuby has this little trick we call an in-process script that allows launching of a separate JRuby runtime in the same process. Basically, we look for the command-line passed to Kernel#system or Kernel#backtick, and if the program name contains “ruby” or ends in “.rb”, we assume the caller wants to launch another JRuby interpreter and launch the command in the same process instead of spawning a new one. Set aside for a moment the question of whether this is “the right thing” to do.
In my desire to dry up this code a bit, but also to extend the same behavior for IO.popen, I needed the in-process script to behave like a real process. So hey, why not extend java.lang.Process? The details are in the ShellLauncher code, but it turns out, oddly enough, this actually works.
I think this points out an interesting feature of JRuby -- that it’s process-agnostic. You can map JRuby runtimes M:N with processes in any combination you like. In fact, this is what’s currently being done with the Rails Integration (Rails-in-a-war-file) code -- a pool of JRuby runtimes preloaded with Rails are used to run the Rails application from a Java servlet. Robert Egglestone’s been doing some great work with Rails Integration and the possibilities are only starting to reveal themselves.
Tags jruby | no comments | no trackbacks
Posted by Nick Sieger
Fri, 16 Mar 2007 03:47:17 GMT
JRuby development pace has been fast and furious for the past few months, and, at times dangerous. While the overall gains have been significant, occasional regressions to various parts of the interpreter and applications such as rubygems have been frustrating for people trying to track the bleeding edge.
Well, no longer. I’ve now got Bamboo up and running, continuously building JRuby itself, as well as test suites of third-party software. Right now, there is a gem install smoke test (for ensuring basic gem install continues to work) as well as the ActiveSupport tests (which are run with CI::Reporter of course so we can track test failures -- now you see the method to my earlier madness).
On the short list for new builds to be added to the CI server are:
- Testing the rest of the Rails components
- ActiveRecord-JDBC
- Nightly snapshots for those who want to track development but don’t want to build from source
If you have a favorite pure-Ruby package or code that exercises JRuby in a public source repository, let me know and we’ll consider adding it to Bamboo so you (and we) know if and when it breaks, or how badly it’s broken.
On a side note, I’ve quietly released CI::Reporter 1.1; you should be able to get it from gems soon. Quietly, because there was only a small, non-essential change -- an assertions attribute was added to the testsuite element in each XML file. Custom applications wishing to count the number of assertions per test suite can parse it out of the XML. Maybe there’ll be a non-XML output format in the future, but I don’t need it now, so it’s not going to be built.
Tags continuousintegration, jruby | 1 comment | no trackbacks
Posted by Nick Sieger
Tue, 06 Mar 2007 03:58:00 GMT
ActiveRecord-JDBC version 0.2.3 has been released!
Install
Use JRuby to install the gem into your JRuby installation as follows. Currently, Rails is not a dependency of ActiveRecord-JDBC; it is assumed you’re going to have Rails installed already.
$ jruby --command gem install ActiveRecord-JDBC
Successfully installed ActiveRecord-JDBC-0.2.3
Installing ri documentation for ActiveRecord-JDBC-0.2.3...
Installing RDoc documentation for ActiveRecord-JDBC-0.2.3...
See the new RDoc documentation on Rubyforge for more information on how to use ActiveRecord-JDBC. If you’re grabbing the new JRuby 0.9.8 release, be sure you get this one as well if you plan to try out JRuby on Rails.
Changes
- Release coincides (and compatible) with JRuby 0.9.8 release
- 8 bugs fixed
- Improvements and compatibility fixes for Rails 1.2.x
Comments, questions, test cases, patches and all that are welcome over on the jruby-extras mailing list.
Tags jruby, ruby, rubygems | 6 comments | no trackbacks
Posted by Nick Sieger
Tue, 06 Mar 2007 02:51:35 GMT
JRuby 0.9.8 is hot! With the release of JRuby 0.9.8, the countdown begins. The reason we jumped from 0.9.2 up to 0.9.8 are several:
- Now there are only two more releases to 1.0, with 1.0 landing in May.
- This release fixes more issues, has more changesets, improves performance, etc. etc. etc., more than all the other 0.9.x releases combined.
- Rails support is something to feel good about, more than a single point release for sure
Stay tuned for details on the new release in the coming days. Be sure to download JRuby 0.9.8 today (source) and let us know how it goes!
Tags jruby, ruby | no comments | no trackbacks
Posted by Nick Sieger
Tue, 30 Jan 2007 01:52:04 GMT
This is part 5 in our ongoing conversation tracking the development of JRuby.
As part of the Worldwide Groovy 1.0 Release Party Day, we at the JRuby team tip our hats in celebration and give our thoughts on our sibling JVM dynlang.
Another recent announcement is that of Groovy finally hitting the 1.0 milestone. What do you make of this -- what goals do you have in common with the Groovy effort, but also, where do you diverge?
Thomas Enebo: I think it is great that Groovy released their 1.0. That number is an important mystical number that affects people in various ways and probably most importantly tells the world that you think it is ready for production work. I am sure Groovy has been at this point for quite a while so it is good to see the project endorse themselves like this.
Groovy, like JRuby, is about providing another choice on the JVM for solving problems. I think the ramifications of this statement yield most of what we have in common.
We differ largely by the fact that we are making an alternative implementation of a language while they started their language from scratch. The fact that we need to bridge two languages that were designed in isolation from each other generally reflects our differences. We get a set of libraries and applications from this other community while they need to create their own community and value-adds. They had the freedom to make integration with Java jive better while we need to cope with the various differences between Ruby and Java. Both directions yield postives and negatives.
Ola Bini: Well, it’s very nice to see JVM-languages mature. I’m not sure exactly what this 1.0-release actually entails, but we in the JVM language league are in this together, and the progress of one language is good for everyone. The goals that we have in common is first and foremost to improve the Java integration aspect in such ways that it will be easy for both Ruby and Java developers to use it intuitively, preferably in a more succinct and readable way than corresponding Java-code. But we diverge in what we’re willing to do to achieve that. JRuby is a Ruby implementation first and foremost, which means the only things we add are things that can be implemented in Ruby (except for those base Java primitives needed to get it up and running).
Charles Nutter: I think one are we hold in common is that neither of us believe Java is enough of a language to solve all problems. Groovy offers a different perspective on language design, adding many dynamic-style language features on top of a syntax that’s mostly just Java. You can use types or not, use semicolons or not. They have similar literal syntax for lists and maps, similar closure semantics, and in some ways a similar feel to other dynamic languages. For folks that fear moving away from Java or need to know their code compiles down to Java classes and integrates intimately with Java class hierarchies, Groovy is a great way to go. It’s excellent that they finally got their 1.0 release out, and as Ola mentioned it shows that dynamic languages are making their presence known in a big way.
We diverge in that Groovy is certainly not Ruby.
In our work on JRuby, we’ve taken an alternative approach from Groovy, in that we believe Ruby is a better language than we could design ourselves (or design based on Java with dynlang features) and so we aim to support pure Ruby as closely as possible. This limits us somewhat in our ability to tightly integrate with Java classes and Java’s type hierarchies, but it also frees us to do all the amazing things you can do with open classes, metaprogramming, DSLs, and the like.
Another area we differ from Groovy is in the size of the greater Ruby community. There are many thousands of people worldwide using Ruby right now, dozens of conferences devoted to Ruby and Ruby on Rails, and a growing library of books on the same. The Groovy guys have a challenge ahead of them to build a community around a very young language; I hope we can help them get there!
Tags groovy, jruby, jrubyserialinterview, ruby | no comments | no trackbacks
Posted by Nick Sieger
Thu, 25 Jan 2007 04:23:00 GMT
This is part 4 in our ongoing conversation tracking the development of JRuby.
This episode we’re pleased to have Tor Norbye and Martin Krauskopf from Sun with us to discuss NetBeans.
If you’re a Rubyist, why should you care about NetBeans? Isn’t that one of those big honkin’ Java IDEs? Well, due to the hard work of Tor and Martin, NetBeans will soon be a world-class Ruby and Rails editor and development environment. All made possible by JRuby underneath the hood. Don’t believe me? Then read on...
So, what are you hoping to accomplish with NetBeans Ruby support? Any lofty goals? Is your target audience Ruby hackers, or Java programmers looking to try something new?
Tor Norbye: Anybody writing code using Ruby. That would include both experienced Ruby developers as well as newbies trying out the language.
The lofty goal is to provide First Class Support for Ruby such that where possible, the Ruby support is as good as the Java support. There are obviously areas where Ruby’s dynamic nature makes it hard to provide the same features as those available for Java, such as the various refactoring operations and quickfix features that rely on static typing. But that doesn’t mean we won’t try. I think a Rename refactoring operation that has some limitations is still better than just Search/Replace.
That’s the area I’m most excited about getting into. Until now I’ve been working on getting all the basic IDE infrastructure in place such that the vital parts are there and we can start building more smarts on top.
Martin Krauskopf: Simply the target is the full debugging support in NetBeans like it is in RDT. I contacted Chris (Williams), Markus (Barchfeld) and murphee (Werner Schuster) from RDT regarding cooperation on the backends. Realize that actually backends are currently their effort on which they’ve spent a lot of time. I’ve started with some mini-fixes and would like to continue on the cooperation more and more so they will also get something back. But the cooperation is very young so I’ll have more to say later, I think. So however there are still a lot of work on NetBeans frontend I want to get as much as possible also in the backends works.
Thomas Enebo: Martin just sent an interesting email to the RDT list on a debugging specification and a cross IDE debugger project on Rubyforge....Fun times.
NetBeans Ruby support (click through the image for a full-screen shot). There is test/unit output, and you can see completion of class names with an RDoc popup.
When will we see a public release of NetBeans Ruby support? What are some of the features we can expect to see? Will there be Rails support?
Tor Norbye: I wish I could answer when it’s going to be released, but that’s not in my hands. I started the work in closed source, as part of the Project Semplice work. And when code doesn’t start in open source in the first place, there’s a Sun process to be followed to release it, such as a legal review, etc. etc. It’s going through that process now - and has been for quite a while, so I’m hoping it will be released soon, very soon. Without promising anything obviously, think weeks.
As I said earlier, the goal for the feature list is to offer the same features that are available for Java: good editing, projects support, debugging, web application support, etc. Yes, there will be Rails support.
The current feature set, which is what you’d see if I got the green light to commit into NetBeans CVS today, is heavy on editing support. There is semantic highlighting, code completion, various other editing features such as pair-matching, smart indent, etc. There is also some basic projects support and Rails support. My coworker Martin Krauskopf is working on a debugger and that work is coming along nicely.
NetBeans Rails support (click through the image for a full-screen shot). RHTML editing, project tree and generator access are shown.
I’ve got this killer feature idea for a Ruby editor. How can I get it into NetBeans?
Tor Norbye: Well, it will all be open source, so the easiest way to do it would be to join the NetBeans open source project and enhance the Ruby editor directly. NetBeans itself obviously has lots of extensibility APIs, and the Ruby editor may offer its own to register additional quickfixes etc. At this point that has not been my focus.
Thanks to Tor and Martin for joining us! For up-to-date progress on Ruby support in NetBeans, follow along on Tor’s blog. And if you have further questions, please leave a comment. What would you like to see in NetBeans Ruby support?
Tags jruby, jrubyserialinterview, netbeans, ruby | no comments | no trackbacks
