Fedora Java Spin – GSOC update 11
2012/08/06 5 Comments
This is the eleventh weekly instalment 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!
The Java Spin is such a great idea.
I would love it if this Java Spin included Netbeans, but afaik the package is still orphaned with nothing available for F17,
Leif,
I’d like to see NetBeans in Fedora 17 (or 18) as well. All we need is some folks interested in packaging it, and it will be moving forward again. Are you interested or do you know anyone who is? As Gerard has demonstrated, the Fedora Java SIG is super helpful, so whoever packages it won’t have to go at it all alone.
-Dan
Thanks for the replies guys, I’m not being notified about them for some reason,so I didn’t see them until now!
Even though I’ve never personally used NetBeans, I like the sound of having all possible free and open source applications available in Fedora. Choice is very important. Saying that though, as Dan mentioned, interest is needed, and also time and effort.
Being a package maintainer is about more than just the initial packaging – there are always bugs to fix, and updates to deal with. The current active members of the Java SIG (and greater package maintaining collective in Fedora), have quite a lot on their plate at the best of times!
Given that there doesn’t seem to be much NetBeans stuff in Fedora leads me to believe that if there are any users of it, they don’t have the time to do it. If you think you do, come join #fedora-java on freenode!
Stan implemented explicit version usage some time back, see https://bugzilla.redhat.com/show_bug.cgi?id=757732
Maybe repackaging maven to have a softlink with an explicit version point to the correct artifacts will allow you to skip the depmap work-around?
Thanks for the reply Carlo – I didn’t see it until now (blog isn’t notifying me of comments for some reason).
Yeah, he worked some magic again this week and fixed the maven-model version issue for good it seems. I’m not at all sure what he actually did, it might be exactly what you suggested!