Today is the GSOC Firm ‘pencils down’ date, as opposed to last weeks ‘Soft’ pencils down date. More info on the hardness of pencils can be found here.

This week, being the last, there are new Live images available. I got a lot of help from Dan Allen this week, and we focused mainly on making the live distribution as great as it can be. We’ve decided to name these as a Remix rather than a Spin, since it’s still not an official Fedora Spin. I think it’s pretty great, but there’s always room for improvement, so if you think something would be better done differently, please let us know!

The ISO image files can be found at http://ryan.lt/fedora-java-remix/ (lost due to disk failure — 2013/03/25)

Here’s what you can expect:

- Standard Fedora GNOME desktop experience, with some minor customizations aimed at developers, including:

• GPaste extension for GNOME Shell.
• Caps Lock key is an additional control key.
• Custom Firefox homepage with relevant search feature, and additional useful bookmarks for Java developers.
• Custom .gitconfig with some useful shortcuts.

- Additional Java and related packages from the Fedora repositories, including:

• OpenJDK
• JBoss AS7
• Groovy
• Scala
• Maven
• Apache Ivy
• Thermostat
• Tomcat
• and more.

- Useful tools for developers (Java or otherwise):

• Git & Gitg,
• SVN & RapidSVN,
• Mercurial & TortoiseHg,
• Meld,
• vim,
• emacs,
• source-highlight,
• and more.

- Eclipse IDE with some useful plugins and customizations, including:

• Eclipse Webtools (those that are available in Fedora repositories).
• JBoss Tools (those that are available in Fedora repositories).
• EclEmma
• Eclipse plugin for FindBugs
• Eclipse Mercurial plugin
• Eclipse Git Integration
• Eclipse Subversion plugin
• JBoss AS user instance pre-configured to be managed by JBoss Tools in Eclipse.

So that’s it. GSOC is over. I’d like to give special thanks to my mentor Marek Goldmann; and also to Dan Allen who were both extremely helpful and supportive the whole way through. Huge thanks also to all of the people from the Fedora Java SIG who were always able to advise me as to what the best course of action would be in all of the stumbling blocks that we ran into; and to the JBoss Tools team for their helpfulness and expertise where and when it was needed. I look forward to continue working with everyone into the future, as we make Fedora the first choice for Java developers.

My current goals coming out of GSOC are to continue what I’ve started, including getting more JBoss Tools built (which again, still requires m2e-core, which I still haven’t figured out why it doesn’t work…grumble).

Once the Java Remix gets accepted as an official Fedora Spin, I hope to get more involved with the Spins SIG. I think spins tailored to specific audiences often makes more sense for people than one catch-all distribution. I’m surprised that there aren’t far more Spins, since the tools and documentation available are pretty great, and make the process a whole lot easier than it could be. I’d like to find out what the best way to include custom browser profiles in a Spin would be. A browser is an essential tool for any modern user, and I feel that since Spins are often targeted to a specific audience, their browser experience could be better customized also.

That’s all for now. Thanks again to everyone who has been involved or supported/motivated me along the way! I hope I pass the final evaluations…the tee shirts that are given to successful students are usually great and I really want one (oh, the financial stipend would also be nice)!

Holey moley, it’s the 13th of August! That means that it’s the ‘Suggested pencils down’ date for GSOC 2012, with August 20th being the ‘Firm pencils down’.The complete timeline can be seen here. On that note, I expect this is the penultimate entry in this blog series, after that I’ll go back to posting stuff of little importance! I’ll admit, writing the blog posts haven’t been my favourite part of the process, but they have been quite beneficial to keep me focused.

A nice surprise this week, with someone else packaging one of the dependencies on the list: Alexander Kurtakov (Eclipse Guy!) prepared eclipse-swtbot which is needed for JBoss Tools tests. Thanks Alexander! Unfortunately tests still aren’t working, but I think it’s a problem with tycho version in Rawhide rather than failing tests. The eclipse-swtbot isn’t in Fedora 17 yet, so I’m unable to test with a stable tycho release yet.

Next on the list was eclipse-m2e-core, which I’ve mentioned a few times previously. I spent quite a while talking about it in last weeks post so I’ll keep it brief this week. I thought I would have this ready for review very quickly this week, but it somehow dragged into Wednesday or Thursday. A review request is in, but there are issues. I don’t know if the issues exist in the spec that will be reviewed for Rawhide as I can’t currently test it. I got it to build in F17 with about twice as many patches; but after all that and getting it to build, guess what, it didn’t work! Eclipse just decided to ignore most of it for some reason. I’m hoping that it’s some small issue that I’m just overlooking, or maybe something in those extra patches that’s causing a problem. I spent hours looking at it to no avail. Akurtakov said he would take a look at it on Monday, so I’m hopeful of that. No better man for the job!

The reason I was packaging m2e (apart from it being a totally useful and cool thing to have anyway), was for JBoss Openshift Tools. Even though I’m not sure if m2e works, I’m sure that it builds; so I decided to try to build eclipse-jbosstools-openshift, now that I could use it as a dependency. Success! After a patch or two, it built. I’m really excited about this, because I use Openshift (this blog is hosted on it, for example), so I’ll be able to use these tools! I’ve never actually used any of the other JBoss Tools stuff (shh, don’t tell anyone), but I’m looking forward to learning to use them once I have time!

I also cleaned up the specfile for eclipse-jbosstools quite a bit. Now it’s a leaner, meaner, package building machine spec file. It used to take more than 12 minutes to do a build on my computer, now it takes a little over 5. I think that’s a pretty drastic improvement. I also cut the number of patches almost in half. Using the new POM macros makes it far more maintainable I think!

Oh crud, I meant to make a list of JBoss Tools modules that are in Fedora, ones that build but are waiting, and ones that don’t currently build. Oh well, tomorrow is another day!

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!

I mentioned last week that I had a few packages that needed reviewing before the JBoss Tools package could be reviewed: all of those got reviewed by some of the experts from the Fedora Java SIG. For most, there were a couple of things that needed to be changed, but this isn’t a bad thing, since it’s the part of the process that I learn the most from!

After I got the latest release of JBoss Tools downloaded, I tested building from that. Luckily, there was very little that needed changing! Once all of the newly reviewed packages made their way into rawhide, I tried doing a koji scratch build, which failed miserably. I eventually found what the source of that problem was: it seems that the eclipse-jbosstools package will be architecture dependent (i.e. there will be a slightly different set of rpms i386 and x86_64. The error message that was being displayed was something like ‘Unable to determine SWT fragment’ or something like that. I had completely forgotten that I had sne something in the parent POM file many weeks ago to get stuff to build with rpmbuild. Currently there are slightly different things being done, depending on the architecture.

By the time that I was ready to submit the updated/working srpm for review, I had moved to my parents house to take care of the house and dog (Sorry internet: dogs > cats) while they are away for a few days. Apart from the inconvenience of getting here and setting myself up again, there’s only really one big disadvantage of being here: a painfully slow net connection! For this reason, I had to cut down the size of the tarball inside the srpm to allow me to upload it. Reducing it from ~460MB to ~77MB made it a little easier – only taking around 45mins to upload, rather than several hours!

I hope to get this package reviewed tomorrow (Monday) so that I can finally submit the spin for review. I did a little more work on the kickstart file for the spin this week also, and I’m very close to getting the Application Server to be managed by JBoss Tools by default in the live spin. More work on that tomorrow, then submit it for review!

The name of the spin has also been brought up in discussion this week. It is to be decided whether it will be submitted as Fedora JBoss Spin or Fedora Java Spin. More on this in the next post I’m sure!

This week’s positive points:

We have what I would like to call a temporary fix for the jboss-reflect issue that I talked about last week. The problem was that the latest version forked another library and bundled it’s own subset of that. Our temporary fix is that we’ve now got an older version that doesn’t have any offensive stuff in it, and works fine for what we need it for. Thanks to Marek Goldmann andMikolaj Izdebski for their help with this! Huge thanks also to Rob Stryker who is working upstream to remove the dependency on this!

eclipse-wtp-jsf is packaged and awaiting review. This is great because it allows two more parts of JBoss Tools to be built: WS Tools and CDI Tools. I think eclipse-wtp-jsf may also be my first package that didn’t need any patching to be built for Fedora! This probably isn’t newsworthy, but I found it quite odd, considering some of the heavy patchwork that was needed for some of the other wtp packages.

Along with WS and CDI from JBoss Tools, the Freemarker IDE module is also building. This probably could have been included at an earlier stage, but it just clicked with me this week why it wasn’t able to import the necessary stuff that it needs from the freemarker jar that’s included in Fedora already.

I *think* the deltacloud module will also work, now that I have the deltacloud-client-java package created and waiting for review. I’ve only just created that package though, and I’m currently downloading the new 3.3.1.Final release of JBoss Tools so I don’t want to do any more local builds tonight until I can use that (since building JBoss Tools takes a while!). Also, have I complained before about the poor connection I get to anonsvn.jboss.org? It takes me hours to download a tag of JBoss Tools. :-/

This week’s not-so-positive points:

I was hoping to get the spin submitted for wrangling with the spins sig by now, but that hasn’t happened yet. There are a couple of packages that still need to be reviewed before I can even submit the amount of JBoss Tools that I included in the iso that I released for the last milestone two weeks ago (in other words, not including the modules that I’ve mentioned above). If you’re reading this, then you’ve got far too much time on your hands already: go review a package from the list!

I got a little bit closer to getting m2e-core to build, but I’m running into some problems that I don’t understand. I think they are related to tycho, but it’s probably something that I’m screwing up somewhere. I think I probably spent too long on this, and eventually gave up on it. I think focus needs to be on getting the spin kickstart file in for review now, as it needs to be submitted at least two weeks before F18 Alpha freeze if we want any chance of having it as an official spin for F18.

Hmm, that was a little shorter and to the point, compared to my last few posts on the subject!

Progress

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 http://www.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.

Two steps forward, one step back

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!

A little rant about github

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 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.

eval(GSOC)

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!

Eclipse Webtools updates

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!

Today is the ‘mid-term’ in the GSOC 2012 calendar, and as I mentioned last week, I’ve got the next iteration of the the spin ready. There are a few caveats to it, but I think it’s pretty cool so far! Not all of the packages are in the Fedora repositories yet, so I created a local yum repo that I could include the missing packages through. +Dan Allen added some ideas to the wiki for customizations that will make the spin awesome. Although these are only ‘proposed’ so far, I’ve included some of them into this release to see how well they work. A lot of them are not possible yet, and some of them I just can’t figure out yet; but the remaining ones should be in there! Here’s a vague list of stuff that the spin has over the vanilla fedora desktop image:

• JBoss AS7
• Eclipse, with all of the available webtools from Fedora, and lots of other features.
• A subset of JBoss Tools (this isn’t in Fedora yet)
• Some SCM tools, such as gitg, TortoisHg, and RapidSVN.
• Various other Eclipse customizations, including keybindings and JBoss perspective by default
• Gnome-Terminal opens maximized by default, and has some custom keybindings (see Dan’s recommendations)
• JAVA_HOME is set in ~/.bash_profile (I think, I forgot to check if this worked!)
• Caps Lock key functions as an additional Ctrl. No more cruise control.
• The proposed Gedit customizations, apart from the custom keybind
• Attached modal dialogs are disabled by default.

The current set of JBoss Tools includes the following components:common, usage, archives, jmx, as, and jst. There are a few more that are close to being ready to include, and hopefully it won’t be too long until all of them are included! My main disappointment is that we don’t yet have m2eclipse to provide maven integration in Fedora, so the quickstart examples from jboss.org/jdf can’t be added in the recommended way. I’ll look to package m2e soon, so hopefully this situation will change soon!

Here are some steps provided by Dan Allen, to connect to the Fedora packaged jboss-as, which works with the included JBoss Tools:

User instance, managed by JBoss Tools
————————————————-

1. Create a new user instance

jboss-as-cp -l $HOME/applications/jboss-as-user-instance

2. New > Server

3. Server name: JBoss AS 7.1 Runtime (managed instance)

4. Server runtime environment: Add… (if necessary)

5. Name: JBoss AS 7.1 Runtime (system), Home directory:
/usr/share/jboss-as, Configuration file: standalone-web.xml

6. Click Finish (three times)

7. Double click on “JBoss AS 7.1 Server (managed instance)” in Server tab

8. Click the Open launch configuration link

9. [ ] Always update arguments related to the runtime.

10. Modify VM arguments:

* Remove:
“-Dorg.jboss.boot.log.file=/usr/share/jboss-as/standalone/log/boot.log”
“-Dlogging.configuration=file:/usr/share/jboss-as/standalone/configuration/logging.properties”
“-Djboss.home.dir=/usr/share/jboss-as”
* Append:
“-Dorg.jboss.boot.log.file=${env_var:HOME}/applications/jboss-as-user-instance/log/boot.log”
“-Dlogging.configuration=file:${env_var:HOME}/applications/jboss-as-user-instance/configuration/logging.properties”
“-Djboss.home.dir=/usr/share/jboss-as”
“-Djboss.server.base.dir=${env_var:HOME}/applications/jboss-as-user-instance”

11. Click OK

12. Select the Deployment tab

13. (*) Use workspace metadata

14. Save

15. Drag application to “JBoss AS 7.1 Server (managed instance)” in Server
tab

16. Click the play button in the toolbar of the Server tab

Finally, the image files for this version of the custom spin are ready. That took quite a while to upload!

i686: http://ryan.lt/fedora-jboss-spin-i686/

x86_64: http://galileo.fedorapeople.org/fedora-livedvd-jboss/fedora-jboss-spin-x86_64/

kickstart file: http://galileo.fedorapeople.org/fedora-livedvd-jboss/fedora-livedvd-jboss.ks

The first thing that I did this week was to find out if the extra features that I had proposed to be added to the eclipse-wtp-sourceediting package would be okay, given that they created a cyclic dependency. As I had expected, it was a big no-no! We discussed for a while in #fedora-java on freenode, what the best way to package features from the Eclipse Webtools project for Fedora, given that the structure of the Webtools CVS repositories doesn’t make much sense sometimes. Currently the wtp packages in fedora are separated into what one would think are subprojects: the next layer of sub-directories. Some alternative ways that were suggested were to have one package per feature, (or per core/UI feature pair, where those exist); or have one super webtools package, with everything subpackaged. None (including the current method) seem perfect.

I separated the problematic feature out into its own package. The feature was org.eclipse.jst.web_core.feature, and I already knew that the org.eclipse.jst.web_ui.feature would be needed further down the line, so I included that in the package also, and called it eclipse-wtp-jst-web.

The next thing that needed to be addressed this week was the bundling of unpackaged jars in the JBoss Tools ‘archives’ module. I got to work building those, starting with jboss-common-logging-spi. I got that built, packaged, requested review; and then I learned that it was not to be packaged, because it was obseleted by jboss-logging. Great. I spent a while trying to figure out where it was needed, and trying to see if the jboss-logging package would work as a drop-in replacement. I eventually figured out that it wasn’t needed by that particular plugin at all, but rather another one of the bundled jars. There were a few like thise, and one that depended on those was jboss-xml-binding.jar. The bundled version of this was old, so I had a look at the most up-to-date version, and found that I could use that with jboss-logging. Problem solved. Well, one of them at least!

Marek, my magnificent mentor (adjectve chosen because of it’s alliteration with both Marek and mentor) was busy applying patches for me, and at long last, eclipse-wtp-webservices and eclipse-wtp-jeetools were buildable in F17, so I went through the motions to get them included.

Back to our fundly bundly jarry jars that are blocking JBoss Tools Archives. The remaining one was TrueZip. Upon investigation into this, I found that the bundled version (6.6) is obselete, and the current stable version (7.5.5) works quite differently. Hmm. I decided to go onto everyone’s favourite IRC channel, #fedora-java, and ask what the best course of action would be. I honestly didn’t want to package the old obselete version, but I also didn’t know if I could easily fit the new version in easily. My question was already being answered, or at least the concept was being discussed indirectly, when I hopped on to ask. I decided based on the conversation that was being held, that the only way forward would be with the up-to-date version of truezip, no matter how difficult it might be to get it to work with JBoss Tools. The last two F’s in the ‘Freedom, Friends, Features, First’ moniker, are very relevant in this situation!

I got to work with the packaging of that, and it turns out that it’s the largest spec I’ve written by far, currently standing at 432 lines. I ran into a few problems here and there, some of them were just me being stupid (this causes lots of problems always), the rest seemed quite soveable, just requiring a few patches here and there. TrueZip looks like a really useful idea, and it seems to be under heavy development for the last while, so that’s a plus! I found it a lot easier to package than the Eclipse stuff that I’d been working on for so long now, but it still took a while, because of the modular way in which it’s structured. Then again, maybe I found it easier because I’d learned so much by going through all that Eclipse stuff. I contacted Christian Schlichtherle, the lead developer for TrueZip, and he seemed quite enthusiastic about having it packaged in Fedora!

There’s a useful (although a little incomplete) page on the TrueZip site, on how to migrate from TrueZip 6 to TrueZip 7; so I’ve started following that and I’ve patched up the JBoss Tools stuff to work with version 7. The problem now is that I don’t know how to get Maven to find it, so I’m not sure if it works fully. I’m sure it’s an easy fix, and the wizards of the Fedora Java SIG will point me in the right direction. Unfotunately #fedora-java changes dramatically at the weekend: a hive of activity during the week, but a ghost town at the weekends!

This time next week, I hope to have the next iteration of the actual JBoss Spin available, hopefully it will finally have the JBoss Tools AS functionality (working with the packaged jboss-as). I realise that I’m way behind where I’d proposed that the Spin would be at this stage, but in hindsight I think my original expectations were a little unrealistic (for me at least)! It will be done, mo matter how long it will take!

As I mentioned last week, first on the agenda this week was getting eclipse-wtp-jeetools in for review. I got that done, and it’s currently being reviewed.

Next was eclipse-wtp-jpa (dali). I had started a spec for this last week, but then I realised that I would need more features from it, so I tried building those. I eventually got that done, and the package is now ready for review also (although it depends on eclipse-wtp-jeetools, so it will have to wait until that is approved.

After those two packages were ready for review, I had to think about what the next step was, since those were the main focus of my attention for a while now. I went back to jbosstools, to see how far I could get with that, with the new packages. I tried building a few times, and with each error, I added in the missing stuff (pre-built) to the local repository, just to see how much more would be needed. After a few tries, I had enough to build the parent,common,usage,archives,jmx, and as components. Then something silly happened: my focus shifted away from this task, to other things (while I was waiting for the 3.3.0.Final release of JBoss Tools to download). When I got back to it, I forgot that I had included some prebuilt plugins in the local repository, remembered that the AS component was building, and I thought “Oh great! Now I can go and make a spec for that”. When I finally got the spec made, it took me a while to realise why the package wouldn’t build, and needless to say, I was a little  annoyed when I figured it out!

Luckily, all the stuff that I was then missing was missing features from eclipse-wtp-sourceediting. That sounded fairly straightforward, just add the missing stuff, submit a patch, Bob’s you’re uncle, right? Wrong! The packages eclipse-wtp-webservices and eclipse-wtp-jeetools depend on the current feature that’s being built by eclipse-wtp-sourceediting, and the new features that would be added, depend on those packages! I was almost finished adding these features when I realised the potential problem. I asked in #fedora-devel to see if it was possible to have a situation where packages depend on each other, and I was told that it was ok, once it’s documented. To be honest, I’m not fully convinced though, it seems like a terrible idea!

Getting these features to build required quite a few patches to other existing packages, that didn’t have the right OSGI Manifest information. This seems to be a recurring theme. It might be just me, but it seems that the there is usually a huge gap between what OSGI information a package contains, and what eclipse/eclipse-pdebuild expects. This is quite frustrating, as it’s not always apparent why things aren’t building or working the way one expects them to. It’s not always apparent to me at least. All of these patches will delay things a bit, hopefully not too long.

After getting that all done, I went back to jbosstools again to see how much further I could get,with mixed results. It was working if I built it manually, but there were strange compilation errors from the spec, even though everything I was doing manually, was pasted from the spec file. It took me quite a while, but I eventually figured out that there are prebuilt jars in some of the components that I wasn’t removing when building manually. These of course were being removed in the spec file, so that’s what was causing the problem. Some of the prebuilt jars have equivalents provided in Fedora packages already, but of course, some of them don’t. That would be too easy! The new packages that need to be built have now been added to the list on the wiki page.

I was going to rant more here about the structure of eclipse webtools…the differing locations of plugins from the features that build/provide them; but it’s late, and I’ve already wasted enough energy today thinking about them!

This week I don’t have a detailed day-by-day breakdown of when I did everything, mainly because I can’t remember all of that!

As I mentioned last week, I finished by getting a subset of eclipse-wtp-jeetools working, but I was having trouble with one plugin of the org.eclipse.jst.enterprise_core.feature. At the time I wasn’t sure if I would need it immediately, but I didn’t want to submit for review until checking to see if it could be fixed. I sent a message to the java-devel mailing list to see if anyone could explain the problem. As I dug deeper back into jbosstools, I realised that I would need a lot more from both eclipse-wtp-webservices and eclipse-wtp-jeetools! Even though all of this webtools stuff may not be needed by Eclipse for the AS tools subset of jbosstools; to build the AS tools, other parts of jbosstools need to be built. It’s a similar process for almost all of the jbosstools: first build the target platform and the parent, the build the common component, then build any other components that your component depends upon (such as archives, tests, jmx, and usage; in the case of the AS component). This means that all of the heavier dependencies that are being packaged now, although they aren’t all necessarily going to be used by the AS component directly, they will hopefully pay of in the end, allowing us to package more of the other components more easily after.

Although I’d had a review request ready for eclipse-wtp-webservices for a while at this stage, it still relied on a few other bugs that I’ve mentioned before, being fixed. I had submitted patches for those, but then I forgot to follow up and make sure they were looked at. With the help of Stanislav Ochotnicky, Aleksandar Kurtakov and Mikolaj Izdebski, these got sorted out, and Mikolaj then helped me again by doing the review request. Thanks guys!

After I got eclipse-wtp-webservices into rawhide, I started looking back at that problematic eclipse-wtp-jeetools plugin that I mentioned above. It drove me to despair for quite a while, as there were no obvious tell-tale signs like before. It turns out that it was a problem with the OSGI manifest again! Even though eclipse-pdebuild seemed satisfied with the versions of the particular versions of the bundles that were being provided by the eclipse-wtp-webservices, they were failing silently, until the compiler couldn’t import them.

Once I figured that out, I tried to see if I could get more of the other features to build, starting with org.eclipse.jst.enterprise_ui.feature, since I would need it for the jbosstools common ui feature. This however would require the org.eclipse.wst.ws_ui.feature from webservices, so I got working on that first. At the moment, that’s now in the eclipse-wtp-webservices that’s in rawhide, and eclipse-wtp-jeetools will be ready for review tomorrow!

Next will be eclipse-wtp-dali, which I’ve also got a draft specfile for, but it needs some work yet!

Also, I wrote an additional blog post during the week, on how to create the Fedora JBoss Spin from the kickstart file that I created last week. I probably should have created the disk image and hosted it online somewhere, but unfortunately I don’t always have access to an internet connection where I can upload such a large file and still do other stuff at the same time! For the next milestone release, I’ll aim to get an image up!

]]> http://blog.grdryn.me/2012/06/18/fedora-jboss-spin-gsoc-2012-update-4/feed/ 0 http://blog.grdryn.me/2012/06/18/fedora-jboss-spin-gsoc-2012-update-4/