06 August 2012
This is the eleventh weekly installment of my GSOC blog series. More info on the progress of the Fedora JBoss Spin can be found on the Fedora wiki.
This week saw the inclusion of eclipse-jbosstools into the Fedora package collection. It’s currently available in the updates-testing repository if you would like to try it out and provide some feedback! Not all of the JBoss Tools are packaged yet, but if you use some of the available ones, I’d love to hear of any problems or successes that you have with the packages!
Next on my list was to submit the spin to the Spins SIG. As you can see from the title of this post, the name has changed from JBoss spin to Java spin: hopefully it will appeal to a broader spectrum of Java developers than just those who work with JBoss related stuff. Although I submitted it by the date that I originally thought was the deadline for getting a spin reviewed/accepted for F18, looking at info on the wiki today makes me less sure that my deadline was the correct one: the spins process page says that spins need to be submitted at least 3 weeks before feature freeze, rather than the 2 weeks that I originally thought. F18 release schedule also lists feature freeze as 2012-08-07, and not 2012-08-14 as I originally thought. When I realised this I contacted the spins SIG to see if it was too late to get into F18; but as that was only this evening, at the time of writing this, I don’t yet have confirmation either way. If it is too late, the name might be changing once more, from Java Spin, to Java Remix (unofficial spin).
After that, I went back to trying to build eclipse-m2e (Maven integration for Eclipse), a process I had started weeks ago. I ran into some strange problems that took a while here! I got some help from rgrunber in #fedora-java with an odd problem I was having where the jar for maven-model from maven2 was always being chosen over the more up-to-date maven-model from maven 3, and preventing build. Solution is to pass a depmap explicitly as an option to the maven invocation. An example of this can be seen in the spec file for tycho. Oddly enough the reason tycho uses an explicit depmap file is for the same problematic jar – maven-model. Perhaps something should be changed so that the up-to-date version is chosen by default?
The next problem had me stumped for about a day and a half: tycho was just giving up half way through, displaying an eclipse dialog that spanned my entire screen with a message that started with ‘JVM terminated.’ Absolutely no idea what was going on, had I. After trying close to everything, I eventually figured out what the problem was. Of course, solving problems is a lot easier when you know what the problem is! :) It turns out that it wasn’t something that I did (that’s always my first assumption), it was a problem with the jbosgi-repository package that had already been fixed in rawhide, but had not yet been pushed to F17. Fantastic.
With those hurdles out of the way, I eventually got to building m2e-core again. Today, I managed to get it to build successfully! I’m currently making a spec file for it, and hopefully I’ll have it ready for review very soon. I thought that it was going to involve patching OSGI information into every jar that it bundles, but after making a list of all of the jars that I expected to have to patch, I had a realization that most of them would not have to be touched at all. I’m actually only after making that realization right now, I hope I’m right!