After adding JRuby 1.0.0 RC2 to the tree, I began poking around using it to run a little blog I've been writing in rails. Surprisingly, the process was quite easy. I just had to package the JDBC wrapper for ActiveRecord.

So here are the details, assuming you are using mysql:

# emerge >=jruby-1.0.1_rc2-r1 activerecord-jdbc jdbc-mysql

I added quite a few changes to -r1, including the ability to use gems and other ruby packages already installed on the system. To do this, there is now a symlink from /usr/share/jruby/lib/ruby/gems to /usr/lib/ruby/gems, and the same for site_ruby as well. If you had an earlier version of jruby, they used to be a separate directories, where you'd have to install gems again. If that's the case, you'll see a warnings, and eventually an error that you need to move /usr/share/jruby/lib/ruby/gems and /usr/share/jruby/lib/ruby/site_ruby out of the way before you can continue.

After things have successfully merged, we are ready to add the appropriate configuration. I'm going to assume here that you have already have a rails app to work on, and using mysql for a database. If not, there may be a trillion or so places on the interwebs that explain how to get going.

First, we add need to add a bit to the config/environment.rb:

def using_jruby?
  RUBY_PLATFORM =~ /java/
end

if using_jruby? 
  require 'rubygems'
  RAILS_CONNECTION_ADAPTERS = %w(jdbc)
end

This can be placed after the require File.join(File.dirname(__FILE__), 'boot') line. If there's a better place using_jruby? should be defined, please let me know.

Now we wander over to config/database.yml. Here is what was originally there:

development:
  adapter: mysql
  socket: /var/run/mysqld/mysqld.sock
  database: yourapp_development
  username: root
  password:

Now we update it to use:

development:
  <% if using_jruby? %>
  adapter: jdbc
  driver: com.mysql.jdbc.Driver
  url: jdbc:mysql://localhost/yourapp_development
  <% else  %>
  adapter: mysql
  socket: /var/run/mysqld/mysqld.sock
  <% end %>
  database: yourapp_development
  username: root
  password:

So, if we're using jruby, we use the JDBC adapter, with the appropriate driver, and point it at the right URL. Otherwise, it'll use what we had before.

You'll likely also want to apply this to the test and/or production databases.

One last thing we need to do is make sure that the jruby gets jdbc-mysql on the classpath. The simplistic way to do this would be to just:

$ export CLASSPATH=$(java-config --classpath jdbc-mysql)

That works for testing, but I want something a little more permanent. So now, we use a relatively undocumented feature of java-config.

$ mkdir -p ~/.gentoo/java-config-2/launcher.d/
echo CLASSPATH=\$(java-config --classpath jdbc-mysql) \
> ~/.gentoo/java-config-2/launcher.d/jruby

/usr/bin/jruby, and most Java applications on Gentoo use a launcher utility we wrote, to help with building classpaths, invoking the right class, and so on. What this snippet did was create some custom configuration for the jruby launcher, which would get used whenever you invoke jruby. In this case, we add jdbc-mysql to the classpath.

Now we should be all ready to actually use it.

$ jruby script/server

You should now be able to hit your application at the usual location. Keep in mind that unless you invoke Note: you'll always have to invoke it with jruby, or alternatively, you can update the #! line in script/server to be "#!/usr/bin/env jruby".

One issue I have run into is that things freak out when running unit tests, because it "can't find an appropriate driver", which doesn't make sense when it works fine for development. Here's a snippet:

$ jruby /usr/bin/rake  test
-----SNIP-----
1) Error:
test_create(BlogPostsControllerTest):
RuntimeError: The driver encountered an error: java.sql.SQLException: No suitable driver
    /usr/share/jruby/lib/ruby/gems/1.8/gems/ActiveRecord-JDBC-0.3.1/lib/active_record/connection_adapters/jdbc_adapter.rb:208:in `initialize'
    /usr/share/jruby/lib/ruby/gems/1.8/gems/ActiveRecord-JDBC-0.3.1/lib/active_record/connection_adapters/jdbc_adapter.rb:10:in `new'
    /usr/share/jruby/lib/ruby/gems/1.8/gems/ActiveRecord-JDBC-0.3.1/lib/active_record/connection_adapters/jdbc_adapter.rb:10:in `jdbc_connection'
    /usr/share/jruby/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/connection_specification.rb:262:in `send'
    /usr/share/jruby/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/connection_specification.rb:262:in `connection='
    /usr/share/jruby/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/query_cache.rb:54:in `connection='
    /usr/share/jruby/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/connection_specification.rb:230:in `retrieve_connection'
    /usr/share/jruby/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/connection_specification.rb:78:in `connection'
    /usr/share/jruby/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/fixtures.rb:247:in `create_fixtures'
    /usr/share/jruby/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/fixtures.rb:593:in `load_fixtures'
    /usr/share/jruby/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/fixtures.rb:538:in `setup_with_fixtures'
    /usr/share/jruby/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/fixtures.rb:575:in `setup'
    ./test/functional/blog_posts_controller_test.rb:17:in `setup'
-----SNIP-----

Lastly, here are some resources that may be useful:

• http://www.headius.com/jrubywiki/index.php/Main_Page
• http://www.headius.com/jrubywiki/index.php/JRuby_on_Rails
• http://www.headius.com/jrubywiki/index.php/Running_Rails_with_ActiveRecord-JDBC

I must admit, I've been experimenting with Ruby on Rails with increased frequency of late. Being heavily invested both in Java on the Gentoo and professional fronts, this seems almost like... treachery

I must say, it has been quite refreshing. It is quite a lovely development platform. I won't go into details about a comparison to developing on the typical Java platform, as I'm sure there are plenty of those on the interblarg already

I decided this past weekend that would try to help out with Ruby on Gentoo, and so joined the ruby herd.

My first act was to bump dev-ruby/rails from 1.2.1 to 1.2.2. If you happen to be using it in any projects, you'll likely want to update RAILS_GEM_VERSION to 1.2.2 in your config/environment.rb.

Lastly, pingu and I are trying to get some interest in #gentoo-ruby going. According to Flameeyes, people have tried in the past, but apparently it didn't quite stick. Let's give it another try, shall we? If you're working with Ruby on Gentoo, feel free to stop by #gentoo-ruby on irc.freenode.net.

To follow up my previous post about unmasking Xfce 4.4...

Since then, I went through the process of upgrading from 4.2 to 4.4. Found a few kinks, mostly with files collisions caused by files moving from one package to another. These have been since worked out.

The major roadblock now is a number of broken dependencies for a few archs. These issues were conveniently glossed over while things are masked, but making repoman pretty upset the second they are unmasked.

So right now, all these issues have bugs filed for them, and now we play the waiting game. See the tracker for the latest breaking news.

The question of when Xfce 4.4 will be unmasked has been coming up with increasing frequency.

The default answer is... wait, for it, when it's ready

A more elaborate answer follows:

We have established a 'tracker' bug here. The team has been pretty good about keeping on top of bugs that come up with it, as in, there are no known issues currently.

So that means it's ready, right? Not quite. Below are the outstanding issues I see:

In making haste to get a 0-day release of 4.4, some corners may have been cut. In particular, some of the xfce-extra packages are lacking the appropriate keywords, even though xfce-base/xfce4-extras depend on them. This is only for new xfce-extra packages, which have been added only relatively recently.

Icons seemed to have moved around a bit, as in, which packages owns them. This is a bit problematic, as it causes file collisions (enabled by FEATURES="collision-protect"). While not critical to unmasking, it is pretty key for stabilizing, and the sooner it can be fixed the better.

The other things I'm concerned about is the upgrade path from 4.2 to 4.4. Some things that were extras in 4.2 are now part of 4.4. As a result, some xfce-extra packages have blockers against them. In other cases, xfce-extra packages haven't been updated for 4.4, or otherwise are no longer maintained. These xfce-extra packages have blockers against them as well. The consequence of these point is that you will have to unmerge the packages that are reported as being blocked.

After being in beta and release candidates for several months, XFCE 4.4 is finally released. Not only that, but ebuilds for them are willing and ready to go. woot.

All the extra panel plugins and extra utilities have been updated as well. In addition, there have been some new additions for 4.4. Use xfce-base/xfce4-extras to get them all, or choose them piece meal out of xfce-extra/.

We're also in the process of establishing an XFCE project for reals, instead of just being having a herd. With the creation of a project, you need a project lead. Who will it be? Well, the consensus seems seems to be your truly.

I'm currently working on making use of a Groovy on a project of mine which uses Hibernate and Spring among other things.

My code wasn't particularly well tested in terms of unit tests. By this, of course, I mean there were no unit tests.

So like a good code monkey, I decided to get some unit tests going, verify they work, then move code over to use Groovy. The benefit here being that by having these tests, I can verify that things still work as expected after the migration.

I figured on trying out rMock, one of the many mocking libraries out there for Java. I get my first test case written, cross my fingers, and hit the run button (this is in Eclipse)... and what do I get, but the infamous red bar. NoClassDefFound... WTFBBQ?!? For whatever reason, it wasn't finding certain classes from dev-java/asm.

I won't go into further detail about how I found this problem, and found the cause, but here are my findings (versions here refer to slots):

• dev-java/groovy uses dev-java/asm-2.2
• dev-java/hibernate uses dev-java/cglib-2.1
• dev-java/rmock uses dev-java/cglib-2.1
• dev-java/cglib-2.1 uses dev-java/asm-1.5

The issue here is that asm apparently changed it's API quite a bit between 1.x and 2.x. This problem seems to have cropped up a few times at least according to google (search for 'NoClassDefFoundError: org/objectweb/asm/CodeVisitor').

The asm tutorial even goes so far as to the changes... kind of. See here under the "Changes in the ASM 2.0 API Since ASM 1.x" section. A few things bother me about this.

• I don't see why the major changes, like renamed classes, and changed method signatures, couldn't have been deprecated at first, and do some twiddling to proxy calls to deprecated things to the newer ones.
• The line that goes like "In general, it would be a good idea to run tool like JDiff and review the differences between the ASM 1.x and 2.0 APIs." Maybe it's just me, but this seems a bit presumptious. I mean, while such a tool is probably useful, it is far from thorough. It might point out where the API changed, but would have no clue as to the significance of those changes, or how you would account for them.

A question that might come out is why would rmock expose this problem, when hibernate is using the same version of asm? Presumably it is because hibernate isn't exercising the parts of the cglib API that use the offending parts of asm, so I must have lucked out before now.

Regretfully, this seems somewhat common in the Java world. Maybe not very common, or even common, but common enough that they stick out in my mind, causing a handful of angst and frustration.

There is some good news though. cglib-2.2_beta1 seems to have been updated to use the asm-2.x's API. Another bit of fortune is that it's unlikely that anything in the tree will run into this particular snaggle, just code monkeys like me using these various libraries.

For the record, I don't get the ClassDefNotFound anymore, but instead I get a lovely NullPointerException from down in Groovy. Oh well, one step forward, one step back.

This news is a bit belated by a few days but.... over the weekend, I spent some time getting the recently released Groovy 1.0 into the tree.

In case you hadn't heard about it, Groovy is, among other things, a dynamic language that runs on the the Java VM. Some interesting data points about it:

• It's dynamic, for reals.
• It's about 98% syntax compatible with Java code (I made that number up, but really, it's pretty durn close).
• Java bytecode gets generated at runtime, no need to compile.
• Groovy can generate Java bytecode to your typical .class files

A consequence of these points is that you can easily migrate from Java to Groovy, and have your project running exactly as it was. Then slowly, you can get into the swing of things, and take advantage of everything that Groovy has to offer as you get the hang of it.

One fear I've noticed of Java developers of jumping into a more dynamic language like python or ruby is late binding. You can't really be sure the type of your objects until runtime. Sure, you can read the documentation (assuming it's up to date) or peek at the code to be sure. With Java, binding occurs at compile time, so you can be sure that foo method expects a Bar, or that Bar has the aieeeee() method. I suspect some of this comes from defensive coding, where you become concerned about how your code will be (ab)used by others.

To combat this, a coworker and I have this idea... You use Java to define interfaces for the, uh, interfaces you care about. You can then use Groovy to implement these interfaces. By doing this, you get the best of both worlds: clients of your code get their strongly typed interface, and you get to do implementations with a more expressive syntax.

Overall, I've been pretty impressed with Groovy so far. Granted, I haven't used it as deeply as possible yet, but it certainly has a lot of potential.

In case any of this sounds interesting, here's some resources:

• The Groovy homepage, get your documentation on
• The recently released Groovy in Action
• The Disco Blog, by Andrew Glover, one of the authors of above mentioned book.

And in other Java dynamicism news, I've added the freshly minted JRuby 0.9.2 to the tree this past weekend as well. I haven't played with it yet, so I can't speak much on its behalf other than it's an implementation of Ruby written on the Java VM. Perhaps that can be the topic for a future blog post.

[Note: I'm actually referring to open source Java software and libraries, not Java itself]

I've been maintaining and working with Java packages for pretty close to a year and a half now. And I hate to say it, but it is only becoming more apparent that things are less than ideal.

Sure, there are a multitude of projects out there, great projects. Eclipse, Tomcat, Netbeans, Azureus, all of the Apache Jakarta project, and many more. For a developer, it's great.

For a packager... it's not so nice of a picture. Builds packages vary from project to project with some kind of unholy glow. While there are some defactor standards out ther e, ie using ant or maven, it ain't pretty.

How do you build your javadocs? Is the target named doc, docs, javadocs, javadoc, or api?
How do you manage your dependencies on third party libraries? Include every jar under the sun, bundle the source in with your own, or download the from the interweb?

The latter of these is particularly irksome. As I said, the standard practice is generally to include all your dependencies. I recall reading an O'Reilly book on ant at some point, and they actually encourage this behavior. I seem to think they said something along the lines of "You can't trust your user to use the right dependencies, so you should include them so that things will definitely work."

I'm fairly sure most of this be traced back to influences of the Windows world. I mean, there really isn't a concept of dependencies on other packages. You just distribute your application in a giant blob, and be done with it.

While I'm sure it's convenient if your developing the application or distributing a single blob to a user, it certainly is a pain to package.

So for all the dependencies, we want to package the dependencies, and then package the dependencies' dependencies, and so on. Then we want to make the application use our copy of the dependency that we just packaged. Easy enough, right?

Not quite. Here are a few of the many problems we come up against all too regularly:

1. The API of the dependencies are unstable, as in, they break between minor revisions.
2. The dependency has been patched in fun and exciting ways that are specific to the application.
3. The origin of the dependency is unknown, and no upstream can be found.

Quite dreary, eh?

Fortunately, it is not always this bad. There are, of course, good applications and libraries which are sane enough to package. Maven, in some senses, has been helping improve things, by standardizing the way things are being built, and by providing a standard mechanism for getting dependencies. A step in the right direction, at the very least.

Stay tuned next time for some ideas for addressing these concerns...

It is with great pride that I am able to announce the 'new' Java system is now stable on all archs where we support Java! That means amd64, ia64, ppc, ppc64, and x86.

In case you've been stuck in a cave somewhere, and hadn't heard anything about the new system, here are some features highlights:

• Changes to user and system VM happens instantly. No more need to run env-update && source /etc/profile!
• One-time changes to the VM by using GENTOO_VM, ie GENTOO_VM=kaffe ant would run ant using kaffe, instead of the user or system VM
• Packages no longer depend on the system VM being set properly. This means that an appropriate VM will be used for building for packages. A package needs 1.5 or later? No sweat! Only builds with 1.4? You got it!
• Now you can use all the Java 1.5 goodness you want with impunity!
• We'll be able to support Java 1.6 when it comes out in Decemeber in a much more reasonable amount of time.
• Support for configuring your Java browser plugin using eselect.
• Support for configuring your VM using eselect.

While this may seem like a small list, it is a significant improvement over the old way of things. And this list is of user-facing changes... there are also vast improvements which help a lot of the developer side of things (ie making things much more maintainable).

[edit]
On a side note, if you have been using the new system for a while, there are a few things you may want to do:

• Make sure you're not using the old migration-overlay. This will cause some problems if you try to emerge VMs among other things.
• Remove the package.mask entries if you had used them
• Remove the package.keywords entries if you had used them

In other news... I've been always been a bit quiet on the blogging... but, I hope to change that, at least a little bit. I have some ideas for some writeups to show off Gentoo as a Java development platform... so stay tuned

Cross posted to gentoo-dev and gentoo-java mailing list.

Yesterday, the Java team held a meeting.
The agenda for the meeting is available at here.
This summary follows the format of the agenda.

1. Personel updates

   First task was to aquire information about active developers who work with Java
   related ebuilds, it produced following list:

   • betelgeuse (Petteri R

As a recommendation to people who use /etc/portage/package.unmask regularly: You really ought to keep tabs on the thing that you're unmasking... and once it has been unmasked, you should remove the entries from package.unmask.

Here's a scenario: You heard about the new Java system being in package.mask, so you decided to try it. Cool. It has since come out of package.mask... but you still have it unmasked via /etc/portage/package.unmask. Now, we release a new revision of java-config that we put in package.mask for testing... and now you get the version that we are heavily tested, and it doesn't quite work 100%...

So, please, be mindful of your package.unmasks.

So, one of the issues that has come up on occaision is that JAVA_HOME ends up pointing at, for instance, /opt/blackdown-jdk-1.4.2.03, instead of the shiny, recently unmasked Java 1.5 you installed and set as your VM of choice.

The reason for this has is legacy support. java-config-1 isn't so smart. It determines what the current VM is based on JAVA_HOME in the environment. It expects it to be living under /opt/${P}, where ${P} is the name and version of the VM.

The workaround we found is described in the upgrade guide. However, the problem is, that java-config-1 would then no longer be able to know what VM is currently being used, which is a bit problematic.

Thanks to the hax0ring skills, we now have a patched java-config-1 that uses VMHANDLE instead of JAVA_HOME. VMHANDLE is the token by which a VM is identified with the new Java system, and happens to be in the environment.

We have added a new entry for /etc/profile.d, which uses the prescribed way of setting JAVA_HOME from the upgrade guide. This means that JAVA_HOME would be set correctly most of the time. The only time it wouldn't be accurate would be if you did not have a user vm set (JAVA_HOME points at /etc/java-config-2/current-system-vm), and then you set a user vm, JAVA_HOME would point at current-system-vm, instead of ~/.gentoo/java-config-2/current-user-vm. Running 'source /etc/profile' though, remedies the problem.

Perhaps java-config-2 can be updated to give notice that you need to source /etc/profile ? Or perhaps it can directly update JAVA_HOME... The only problem with the the latter point ist hat it would probably only fix JAVA_HOME in the current terminal, and not in all the other open terminals.

I've added revision bumps of java-config to the tree that work as described here. Because of the changes though, I've put them in package.mask while we finish testing the new way of handling JAVA_HOME. The package.mask entry is below, for those interested in testing and providing feedback:

# Joshua Nichols <nichoj@gentoo.org> (02 Aug 2006)
# Testing new versions of java-config, which will let us remove
# JAVA_HOME from env, which points to generation-1 system vm
=dev-java/java-config-1.3.0-r3
=dev-java/java-config-2.0.26-r6

Assuming there aren't any issues while testing, I expect to unmask it in a day or two. At that point, I'll also update all the env.d files for the VMs, so they no longer export JAVA_HOME (note: this is different from the profile.d, which is actually overwriting the JAVA_HOME originally being set by the env.d file).

The answer, as of this moment, is most definitely. There are two reasons for this at the moment.

1. there are still packages which don't compile when built with Java 1.5. In these cases, the new Java build system switches to a 1.4 JDK for building.
2. it is needed for packages that haven't been migrated to use the new Java system. This is necessary, otherwise we encounter the same exact problems that prompted the initial package.mask of Java 1.5.

Just to recap why Java 1.5 was package was package.mask'd.... It really comes down to backwards compatibility, and that Java 1.5 isn't 100% backwards compatible with Java 1.4. Things that ran with Java 1.4 should still run with Java 1.5... but some things that once built with Java 1.4 no longer compile with Java 1.5. Specifically:

1. There's a new reserved keyword with Java 1.5, enum. So where you used to be able to use enum as a variable name, you no longer can in 1.5.
2. A number of new methods have been introduced to some abstract classes and interfaces. If a particular implementation doesn't implement the new methods, then it won't compile against Java 1.5

Now, say you're using Java 1.5 to build all your packages, and then you come up to a package that can't compile for one of these reasons? It'd fail for one. But then you may try with Java 1.4... and all is well until you see a compile error: UnsupportedClassVersionError. What does this mean though?

Well, each major release of Java has it's own version of bytecode. Bytecode is forward compatible, ie run 1.4 bytecode in 1.5, but not backwards compatible. If you try to use 1.5 bytecode in 1.4, you will see the infernal UnsupportedClassVersionError. This happens because, since you were using Java 1.5, the dependencies of the package you were just trying to compile with 1.4 were built with 1.5, and the default behavior is to build the highest possible bytecode.

So, these are the reasons Java 1.5 was package.mask'd, and why we need to use Java 1.4 for building unmigrated packages.

But how does the new Java system help?

• We get around the problem of enum by specifically telling the compiler to use source="1.4", where enum is a valid variable name.
• We get around the changes in API by switching to a version where it can be compiled, until such time as the package can be properly patched.
• Additionally, we make javac compile the lowest possible bytecode, so it can be used by as many other packages as possible.

I'm pleased to announce that www-servers/tomcat-5.5 and dev-util/eclipse-sdk-3.2_rc7 have been added to portage over the long weekend.

We strongly encourage users to update to tomcat 5.5, and refrain from using earlier versions, as recommended by upstream. 5.0 and earlier will likely be removed in the future, and have put it in package.mask. Don't worry though, it won't go away right away, so users should have time to migrate.

As for eclipse, there are few few changes between 3.2_rc7 and the official 3.2 release. Once we verify our patchset works against 3.2, you can expect to see the official release added to portage. It is in package.mask for testing, and until we get the final release out.

The Gentoo/Java Team is proud to announce the release of the updated Java system. This means that Java 1.5 is finally unmasked.

It is currently in ~arch. To begin using it, follow the upgrade guide:

http://www.gentoo.org/proj/en/java/java-upgrade.xml

Here are some highlights of the new system

* Ability to switch the current VM on the fly
* Changes to the user and system VM take effect immediately, and no longer are tied to the shell environment, which means you no longer have to run env-update followed by source /etc/profile when you switch the system VM
* Now has the concept of a "build VM", which is used to emerge packages, and is configured independently of the system VM
* For each version of Java, ie 1.3, 1.4, 1.5, etc, the build VM can be configured as to which vendor and version of a VM to use
* The VM at emerge time will be switched on the fly according to its configuration, as well as the dependency of the package. For example, some packages won't compile with 1.5. In these cases, a 1.4 VM will be used at build time
* Java packages which build with ant will have their build.xml rewritten at build time in order to ensure that the correct version of Java bytecode is compiled
* Java 1.5 has been unmasked, and we will be ready for Java 1.6 when it is released this fall.

Just to keep people updated about how the new Java stuff is going... it's going pretty good :-D

A lot of smaller kinks have been worked out, better documentation, more useful error / warnings, and such forth. All in all, there has been a lot of good input and feedback.Most of the issues users have been running into is not having everything unmasked and keyworded properly. With unmasking,the former will no longer be an issue.

So, I hope to go forward with unmasking over the long (read: 4 1/2 days) weekend. At that point, we'll begin switching packages over to using the new eclasses, doing version bumps, bug squashing, and all that jive.

I'm pleased to announce that the new Java hotness has finally hit the tree It's currently in package.mask, but I expect to unmask it in the next few days.

To begin using it, you will need to add the appropriate entries to /etc/portage/package.unmask, and then follow the upgrade guide.

For those not familar with that this means, here are some highlights:

• Ability to switch the current VM on the fly
• Changes to the user and system VM take effect immediately, and no
  longer are tied to the shell environment (ie no more running env-update &&
  source /etc/profile after switching the sytem VM)

• Now has the concept of a

The road to unmasking Java 1.5 has been long and arduous. There have been enough issues to warrant it's own FAQ and an entire redesign of the way we handle Java packages.

I won't go into detail about the specific problems incurred, as the FAQ should sufficiently cover them.

Nearly a year ago, work was begun on a new build system (ie new eclasses and a new version of java-config). About six months later, we had a new fully featured, flexible build system. Highlights include build-time VM switching, build-time build.xml rewriting, and a more flexible means of storing/setting the system and user VM.

Unfortunately, there were enough incompatibilities between this new system and the old one that we couldn't just drop it in the tree as is. A few months were needed to determine how to best migrate to the new system, in such a way that it could be done incrementally, and it could be properly tested (ie be in ~arch). Notes about the method we choose can be found on our wiki.

Since then, a lot of work has been done to implement the migration system, as well as code and documentation cleanup.

So now, we (kartlk and I), have deemed the new system ready for prime time. This coming week, we will be finishing any last minute cleanups, and bringing in any packages that require 1.5. Once that is complete, we will be announcing the changes on the developer mailing for public scrutiny/input. Assuming that there are no issues that crop up, the new system would be brought into the main tree a week or so later.

You may begin rejoicing now.

As has been previously announced, we are officially part of Google's Summer of Code. I've decided to step up to be a mentor, and in particular, to mentor projects related to Java on Linux.

A few ideas follow. The 1a and 1b are listed already on our SoC page to an extent, but the idea is elaborated further here. If you plan on proposing one of these ideas, I really would expect you to even further elaborate.

1a)
Summary:

Build most of our Java packages with free (libre) virtual machines and free implementations of public APIs.

Background:

Currently, we really only support using a proprietary virtual machine (ie sun, blackdown, ibm, etc), because packages are likely to fail for various reason with the open ones.

For many open apis, such as javamail, java activation framework, etc, we have binary packages of Sun's proprietary implementations. In a number of cases, there are open implementations. However, our packages compile against and run using the proprietary implementations.

For reasons why one would want to be using Free Java, see the article on the Java trap.

As for a practical reason, use of proprietary packages from Sun and IBM can annoying for the end user, because in both cases, it requires placing a fetch restriction on the distfiles. To the end user, this means that an emerge gets halted until they agree to a license, and download the files.

Goals:

• Build/run all/most packages using free virtual machines
• Build/run all/most packages against free implementations of public APIs
• Might want to target specific big name packages, like eclipse, azureus, tomcat.
• Be able to select between different implementations of the same apis

Tasks:

• Work with upstream of packages that use propertary classes from the virtual machine (ie com.sun.*, sun.*)
• Work with upstream of virtual machines and packages when packages don't compile or run with using free java
• Find and package open implementations of public APIs

Hurdles:

• Lots of Java packages (300+). It is unknown how many will need to be patched.
• Upstream might not care about free java
• Might not be open implementations of all APIs

1b)

Summary:
Native compiling with gcj

Background:

GNU Compiler for Java (gcj) allows for compiling Java code to native machine code, as opposed to Java bytecode. Fedora/Redhat has done this to an extent for some time. It'd be great to be able to do this under Gentoo as well.

Tasks:

• Create a 'JDK' which uses gcj as a backend. In this case, JDK really means providing a javac, javadoc, jar, etc
• Have a way of keeping track of native bytecode
• Integrate methods for native compiling into the current build system for building Java packages on Gentoo (ie eclasses)
• Target native compilation of high profile applications, ie azreus, eclipse, freemind

2a)

Summary:

Build maven entirely from source.

Background:

We currently only provide binary packages of maven, due to the fact that it is a bootstrapping nightmare because of the monolithic nature of the build process. The build system, at its basic level, does the following:

• Build the 'core' maven functionailty using ant
• Build the 'core' maven functionality using maven
• Build all the plugins using maven

The problem with building all the plugins at once is that there are a ton of plugins, with many, many dependencies. Because of these dependencies, it would make it impractical to have a monolithic package, which would be used to build other packages.

Goals:

• Have modular packages for maven
• Have one package per plugin
• Have a 'core' maven package
• Have a 'minimal' maven package, which is core + minimal packages for compiling, javadocs, and jarring
• Have a 'full' maven package which is all the plugins
• Would need to work out a way to make the build much more modular

2b)

Summary
Build packages using maven

Background
Many packages, particular Apache projects, have been switching over

The main issue is getting jars from a maven repository. The normal behavior of maven is to download dependencies from a maven mirror. First
of all, things at build time should not be using the network. Secondly, dependencies should be provided by jars from packages that have previously been emerged.

Another issue is that maven 2 repositories contain metadata (specifically, pom.xml files) about the packages contained within. This is normally fetched from the repository, but since we don't want to be pulling from there, the question remains open as to where the metadata is gotten from and how its stored on the system.

Goals:

• Have a system to have maven use jars that we have built through portage
• Update packages to use maven when possible. These should have fine grain control to the plugins that are available at build time. Packages should depend on the minimal install, and whatever extra plugins they might need, and only those should be available at build time.

Possible solutions for dealing with maven repositories:
A) Create a maven-repository like structure, and have it populated with jars from the system
B) maven (2.0 at least) has a mechanism for providing alternative ways of fetching dependencies. We could then create an alternative way that's backed by portage.
C) Find a way to tell maven not to fetch dependencies, and hope that there are the appropriate classes available on the classpath

So, I've recently joined the dev-tools team in order to help maintain dev-util/eclipse-sdk. The ebuilds themselves haven't been touched much lately, aside from the occasional version bumps, and so have been in need of a little love.

I've just added 3.1.2 to the tree recently. In terms of upstream changes since 3.1.1, there isn't too much to write home about. In terms of the ebuilds, I've manage clean up a number of things that would make mere mortals tremble. This isn't to say the ebuilds are quite ideal yet, but it is certainly a step in the right direction.

In the coming weeks, I hope to continue sanitizing the Eclipse ebuilds, in addition to getting ready for the 3.2 release, which just entered release candidate last week.