I heard from the grape vine that some people didn’t know about the QR Code game at EclipseCon! All you need to play is to download a QR code reader for your mobile phone and start scanning!
I highly recommend Red Laser if you don’t have an application already to scan codes. Other than that, please read the rules of the game and start the hunt for codes!
Next week at EclipseCon 2011, it will be a year after we first presented some rough Git tooling to the eclipse.org community via a tutorial. At the time, the deal was that the tooling was in early stages and needed some love from early adopters to help improve the situation. I’m happy that things have come quite a long way since last year based on Eclipse Marketplace stats and the community contributions the projects have received.
So what’s next? In terms of tooling, we’re getting closer to our 1.0 release (which is planned for the Indigo release). The git tooling at Eclipse is much better these days, if you need help or have questions, please start with the most excellent EGit User Guide. From our user guide, you should tell that we support the majority of the common work flows now. If something is missing, please let us know by filing bugs or contributing.
If you’re an eclipse.org project, please consider starting the process to move your project repository to Git. There are a lot of eclipse.org projects already on Git. You can find great documentation at Eclipsepedia on how to do the move. It’s not that bad, the LinuxTools project has recently migrated to Git and the CDT project has stated that they will start the process after the Indigo release. It would be nice to see the all of the eclipse.org projects have plans to move to Git by the Indigo release.
A portion of the EGit and JGit teams will be at EclipseCon 2011, so please swing by our tutorial and track us down if you have any issues moving to Git or using the tooling. We believe that the tooling is good enough now to meet the majority of eclipse.org committer needs. All of us want to see eclipse.org fully on Git by the end of the year, so let’s work together to make this happen. If people think holding a BOF about moving eclipse.org projects to Git is a good idea, let us know and we can do it.
I’ve helped setup quite a few Maven Tycho builds for people as of late, with more requests coming in. Personally, I’ve had quite a bit of experience working with Tycho-based builds as being one of the first early adopters with the EGit and JGit projects at Eclipse. At that time, Tycho was pretty rough around the edges but I’m pleased to report I believe now Tycho to be one of the best, if not the best option for building Eclipse/OSGi related artifacts. Sure, it’s not perfect but it’s pretty damn good now. Furthermore, there are even large projects like Mylyn at eclipse.org that have moved to Tycho to manage their whole build if you need further proof.
One of the common complaints from folks within the eclipse.org ecosystem is how difficult it is to setup build. In the past, we had the Athena Common Build project at eclipse.org with some success. Athena helped many projects get off the ground when it comes to building and publishing their artifacts. However, it still suffered the drawbacks of PDE Build based systems when it came to debugging, customizing and extending the build system. For example, if you wanted to integrate with Hudson, add FindBugs to your build or run SWTBot unit tests, you suffered quite a bit. Well, I’m happy to report that Maven Tycho helps quite a bit with these customization issues. To help alleviate some of the pain we’re experiencing with build at eclipse.org, I decided to put up sample Maven Tycho project for people to look at and refine. I’m calling the effort Minerva as I think it plays nicely with what was done in the Athena project (Minerva is the Roman equivalent of Athena and the word Maven is in Minerva!).
The goal of the Minerva project would be to get a well documented sample build for eclipse.org projects. I can even envision a future when a new eclipse.org project comes around and they get a build already generated for them and hooked up to hudson.eclipse.org! I think once you have something working and it’s well documented, it becomes pretty easy to expand as you add new features.
To get started, I’d take a look at what is on the wiki already. If you want to play with code, ensure that Maven 3 is installed and then do a quick clone.
git clone git://github.com/caniszczyk/minerva.git
mvn -Dskip-ui-tests=true clean install
Once you do that, you should notice a p2 repository (update site) generated in the update site project’s target/site folder. To sweeten the deal, if you have Hudson (Jenkins) installed anywhere, you can configure it quickly to build the code base.
Remember how long something like that took before? In reality, Tycho isn’t that complicated to setup.
In Maven, the parent pom.xml serves as the central point on adding things to the build. It’s also generally the most complicated piece of the build as it contains information that is shared by children pom.xml files. The first part of the parent pom.xml contains identifying information:
... <groupId>org.aniszczyk.minerva</groupId> <artifactId>minerva-parent</artifactId> <version>1.0.0-SNAPSHOT</version> <packaging>pom</packaging> <name>Minvera Parent</name> ...
The second part contains profile information and where to get dependencies.
<properties>
<tycho-version>0.10.0</tycho-version>
<platform-version-name>helios</platform-version-name>
<eclipse-site>http://download.eclipse.org/releases/${platform-version-name}</eclipse-site>
<wikitext-site>http://download.eclipse.org/tools/mylyn/update/weekly</wikitext-site>
<swtbot-site>http://download.eclipse.org/technology/swtbot/${platform-version-name}/dev-build/update-site</swtbot-site>
</properties>
<profiles>
<profile>
<id>platform-helios</id>
<activation>
<property>
<name>platform-version-name</name>
<value>helios</value>
</property>
</activation>
<properties>
<eclipse-site>http://download.eclipse.org/releases/helios</eclipse-site>
<platform-version>[3.6,3.7)</platform-version>
<swtbot-site>http://download.eclipse.org/technology/swtbot/helios/dev-build/update-site</swtbot-site>
</properties>
</profile>
<profile>
<id>platform-indigo</id>
<activation>
<property>
<name>platform-version-name</name>
<value>indigo</value>
</property>
</activation>
<properties>
<eclipse-site>http://download.eclipse.org/releases/indigo</eclipse-site>
<platform-version>[3.7,3.8)</platform-version>
<swtbot-site>http://download.eclipse.org/technology/swtbot/indigo/dev-build/update-site</swtbot-site>
</properties>
</profile>
</profiles>
...
<repositories>
<repository>
<id>helios</id>
<layout>p2</layout>
<url>${eclipse-site}</url>
</repository>
<repository>
<id>swtbot</id>
<layout>p2</layout>
<url>${swtbot-site}</url>
</repository>
<repository>
<id>wikitext</id>
<layout>p2</layout>
<url>${wikitext-site}</url>
</repository>
</repositories>
What’s cool about setting up these repositories and profiles is that we can easily switch the build to run against Helios or Indigo repositories. If you want to run Indigo, simply set -Dplatform-version-name=indigo and you’re good to go. You could even setup multiple hudson jobs that build against various Eclipse releases if you want to ensure everything works properly.
The third part lists the modules (e.g., features, plug-ins) that are part of the build:
<modules>
<module>org.aniszczyk.minerva.core</module>
<module>org.aniszczyk.minerva.ui</module>
<module>org.aniszczyk.minerva-feature</module>
<module>org.aniszczyk.minerva.source-feature</module>
<module>org.aniszczyk.minerva-updatesite</module>
<module>org.aniszczyk.minerva.tests.core</module>
<module>org.aniszczyk.minerva.tests.ui</module>
</modules>
Each of those modules has a simple pom.xml that tells Tycho what type of project it is (think feature or plug-in). You should be able to piece things together by looking at the documentation on the wiki. Let me know if you have any questions and please feel free to add anything. My plan is eventually to get things up to shape so the code could live at eclipse.org and get things up to a point where a Maven archetype could be built and used to generate new projects.
Thoughts? Also, if you’re an eclipse.org project and interested in moving to Tycho, feel free to contact me and look at the example.
It’s that time of year again, the Summer of Code program is gearing up (timeline)!
If you’re part of an eclipse.org project, you should consider being a mentor and spending some time and coming up with ideas. To add an idea, simply update the wiki with your idea. In the past, eclipse.org has benefited quite a bit from this program by getting some code and attracting new contributors. I find mentoring to be one of the most rewarding activities, it’s great to share your passion with others. If you’re a student and don’t see any ideas that you like, feel free to track down some eclipse.org projects and ask them if they are willing to mentor any ideas you come up with. If you have any questions about the program, feel free to contact me.
Hey guys, just wanted to let you know that we finalized the EclipseCon 2011 keynotes!
Todd Lipcon will introduce Apache Hadoop and share his experience of working with large scale software systems. Mark Reinhold and John Duimovich will discuss the future of Java and in particular, OpenJDK. Finally, we’ll have David Gondek from the IBM Watson Strategy Team talk a bit about IBM Watson.
I find it interesting that Watson was mostly written in Java (with a smattering of Prolog and C++). If you’re curious how the machine works, check out this interview by the IBM Watson team. Oh, and please remember to register for EclipseCon if you haven’t already! I look forward to seeing everyone at the conference.
Hey guys, it’s that time of year for the Eclipse.org board elections! You should be getting an email soon with instructions with how to vote. Please take the time to read people’s position statements and vote as who you elect on the board helps determine where the Eclipse Foundation is headed.
From my point of view, I feel fortunate to be nominated again as I believe it’s going to be an interesting year for Eclipse. The year 2011 marks the 10th anniversary of the Eclipse Foundation and it’s amazing to see how many things have changed over the past ten years in the technology industry. It’s great to see the web becoming very relevant again… ten years ago all I remember is the browser being used as a medium to display a dancing banana. In all seriousness, I think the web is becoming more important and Eclipse needs to be prepared to participate in that space.
As I reflect what has happened last year while I was on the board, I’m proud of the progress we made in some things like moving to Git. While not as fast as I’d like, the committer representatives did all the groundwork in convincing the right parties to move things forward. I personally spent time contributing to the EGit and JGit projects to help get the tooling to a state that the whole Eclipse ecosystem could take advantage of Git. If I get elected again, I’ll do my best to continue this trend and see that by the Indigo + 1 release, all eclipse.org projects have moved to Git.
There are many things I want to do at eclipse.org like:
If you want more information, please read my position statement. Or, if you have any questions, feel free to email me or find me on Skype. If you think I would continue to do a good job representing the committers, I’d appreciate a vote.
The EGit and JGit teams are happy to announce the 0.11 release, just in time for Helios SR2!
You can grab the release from the Eclipse Marketplace or from our repository:
I’m happy to say we accomplished a lot for the 0.11 release which was mainly meant for improving some usability and performance issues (and of course, catching the Helios SR2 date). In JGit (new and noteworthy), additions were made to the porcelain API along with git-notes support. In EGit (new and noteworthy), we focused a lot on improving the performance so people should see improvements from the decoration of resources to the synchronize view. In terms of features, EGit now supports Mylyn integration via the commit dialog and history view. We also now support comparison of trees so you can easily compare projects and folders with the Compare with… action.
If you’re interested in helping us get to 1.0, please try out the code, file bugs and contribute if you have time. If you like what we do, consider starring EGit on the Eclipse Marketplace. We plan to iterate quickly so the next EGit and JGit release is planned for late April with a 1.0 for the Eclipse Indigo release in June.
Hey guys, this year at EclipseCon 2011 we’re going to do something new, EclipseCon Idol. It’s a contest where nine EclipseCon attendees will present in Ignite Style a topic that is interesting to them. It can be about Eclipse technology, but it does not have to be. The only requirement is that humor and comedy need to be a key part of your presentation. To see a good ignite-style presentation, check out this one from The Oatmeal…
To participate in EclipseCon Idol, please contact idol11@eclipse.org for full details. There are only nine spots available. We are looking for humor, so talks like “Why Modeling is taking over the world” will not be accepted. Good examples may include “Why my cats would make great developers”, “Why authoring tech books is like working at McDonalds” and “You too can be arrogant by knowing a useless dated programming language.” I hope you enjoy it, it should definitely be entertaining after some frozen beverages!
As a reminder, it’s the last week for early registration for EclipseCon 2011 – prices go up February 14. After you register, be sure to book your hotel room right away as the hotel is filling up fast and you want to be as close to the Hyatt bar as possible.
The deadline to get your eclipse.org Contribution Questionnaires (CQ) in for the Eclipse Indigo release is Feburary 11th.
This means that any third party packages that you would like to include in the release train, you need a CQ. Indicate that you need it for Indigo on the CQ and the IP Team will make sure it’s appropriately prioritized. This year’s big Indigo release review will be run from June 1-8, 2011. The IP team will need the review documentation prior to June 1, 2011 and IP logs by May 18, 2011.
Other than that, I’m looking forward to this year’s release train! I’m also looking forward to help naming the next release train… there are so many good options that start with the letter ‘J’ 🙂
We’ll have mobile applications available for people during the EclipseCon 2011 conference this year thanks to the awesome folks at itemis mobile.
I’ve been doing some beta testing recently and things are going well.
My question to all y’all is what type of features would you like to see in the final application? I was thinking of adding some social media aspects to the application involving tweeting the talks you’re about to attend amongst other things. It would also be nice to vote-in-application for sessions you’ve attended, but in the end, we can only do so much to improve the application.
What do you think?
