16 July 2012
This is the eighth weekly installment of my GSOC blog series. More info on the progress of the Fedora JBoss Spin can be found on the Fedora wiki. The fact that there is a blog post this week is good news, because it means that I passed the midterm evaluation, so I get to keep doing this for the second half of the GSOC period! :D
I started off this week looking into packaging m2e-core, which is a necessary requirement for some parts of JBoss Tools, including the examples from jboss.org/jdf and openshift integration; both of which would be great additions to the spin I think. After spending a while working with this, it became apparent that lots of patches would be needed for existing packages, mainly to add OSGI information. I started making some of these patches, but I decided not to start submitting them until I got a working spec file for m2e-core. This did not happen this week, because other accidental stuff (below) became a higher priority. I did manage to get two dependencies for it packaged, reviewed, and included in rawhide and f17: port-allocator-maven-plugin and maven-wagon-ahc; and a third packaged, which is awaiting review: maven-indexer.
Going back to what I had done last week, Mikolaj Izdebski began to review some of the stuff that I had waiting for review. A significant issue was found with jboss-reflect (which is a dependency of jbossxb, which is a dependency of org.jboss.ide.eclipse.archives.core): it contains a forked objectweb-asm, something that I had completely overlooked. As this is not allowed in Fedora, it would have to be removed. I first tried just deleting the relevant files, but needless to say that didn’t work! I then spent a while looking to see if the stuff that isn’t in the upstream objectweb-asm could be added directly to where it’s needed in jboss-reflect, but I didn’t get very far with that, and I believe it would be a horrible solution anyway! Looking at jboss-reflect, it seems that it may no longer be actively maintained, as the only place I could find source code for it was as a subproject of JBoss AS6. If this is the case, I think the optimal solution would be to not package jboss-reflect, if at all possible. To this end, I have sent an email to the jbosstools-dev mailing list to see if there is any possible workaround for using jbossxb (as it would also be good not to have to package that!), or to try to elicit other possible solutions that those guys might be able to think of!
I also had my first real experience using github this week, when I sent pull requests to sonatype to include license files for both port-allocator-maven-plugin and maven-wagon-ahc. I don’t fully understand why it is so popular amongst so many free and open source developers, when it is a non-free platform compared to alternatives such as gitorious, which is 100% free software under the AGPL. Seriously, what is the must-have killer feature of github? I mean I get that it’s shiny and social and stuff, but it seems odd and a little disturbing that such a large part of the greater open source community is not defaulting to the more open alternatives. That’s the main reason that I decided to put the repository for the Fedora JBoss Spin kickstart onto gitorious instead.
As I mentioned at the very beginning of this post, I passed the midterm evaluation for Google Summer of Code 2012. The evaluation period ran for most of the past week, finishing on Friday, when all of the evaluations had to be submitted. As part of the evaluation process, I had to submit an evaluation of my experiences over the first half of the program. Marek also had to submit an evaluation on his experience as my mentor: he must have said at least some good things since we passed…thanks Marek! :D
I eventually got around to updating the Eclipse WTP packages that I maintain, to their stable 4.2.0 versions. Of course, not without running into a few little snags! This was the first time that I had updated a package to a new version, so I got to learn how that works. It took me a while to figure out why the newly created sources tarball that I had created wouldn’t upload with the fedpkg new-sources <tarball> command, until I realised that the user I was issuing the command with, didn’t own the file that I was trying to upload. I’m not sure why that doesn’t work, but it’s probably for very good reasons! I also had to create proper scripts to download the relevant stuff from the eclipse webtools map file. I may have mentioned before that I find it hard to follow the organizational structure of the webtools project. When I remember that they produce a map file for each stable or development milestone release, then I don’t feel so bad. Most of the plugins and features here are hosted in CVS repositories, but there are some on SVN and some on git also I think. OF COURSE this caused me problems! :) There is one bundle foe org.eclipse.jpa that needs to be grabbed from SVN, whereas all the rest come from CVS, so this one had to be handled differently. Originally I just checked out the development trunk, which made everything fail spectacularly. I didn’t realise why immediately, but I eventually realised that I needed to get the revision information from the map file manually for that one.
Thats all for this week folks, tune in next week for more Fedora JBoss Spin fun and frolicks…same bat time, same bat channel!