We are close to releasing EGit and JGit 1.0 for Indigo, so I figure I’d take the time to share a new feature. If you’re a fan of annotating source files with revision and author information, EGit now has support for blame annotations (via the Team->Show Blame Annotations menu):
From there, you can easily jump to the commit viewer from the popup…
Happy blaming!
Releasing software is a bit of an art form and everyone has different philosophies, especially in the realm of open source. For some people, releasing something every week is critical, some people want to release consistently on-time and others simply never ship. We also have to be mindful that releasing software means different things in different communities. In mature open source communities like Apache and Eclipse, you’ll find more formal processes to deal with when announcing a release, whether it’s incubating or mature. I have a personal philosophy that shipping is everything, probably a remnant of my heavy involvement on the Eclipse platform team, but that’s a topic for another day.
Inside the eclipse.org community, there’s been some discussion lately about scheduling releases. Historically, the Eclipse platform ships a major release every year (triggers a release review as part of the EDP) with six-week milestones in between. Also, the Eclipse platform project aligns itself with the annual simultaneous release (e.g., Indigo). I think this works fine for the platform project because it’s extremely mature and dependent on by a lot of consumers. However, I would love to see the platform release more than once a year, but I haven’t had enough time to think about how to do that without being very disruptive. It is something the project leadership should be thinking about as we move into the 4.X Eclipse stream.
Since the Eclipse platform project is very prominent, a lot of other eclipse.org projects tend to align their releases with the platform. I think this is wrong method to choose your release schedule, especially if you’re a young project. Actually, some people I have talked to think that they only have to release once a year, which is wrong as the EDP doesn’t impose any major time restrictions on you releasing. I think each project should release according to its maturity level and adopters needs. For example, let’s look at the Mylyn project’s release history…
If we notice a pattern, Mylyn tends to release about four times a year and tries to align itself with the annual release train. Another example is the EGit/JGit projects…
The EGit/JGit project tends to release every few months and tries to align itself with the annual release train.
What’s your ideal release schedule? If you’re an eclipse.org project, why don’t you release more often?
As of late, a lot of eclipse.org projects (e.g., BIRT) have approached me about moving to Git after the Indigo release. In preparation for projects moving after the simultaneous release, we’ve setup a Git Task Force.
The task force is simply a group of volunteers that have a lot of experience in migrating to Git and can help your project. To take advantage of this, please sign up on the git@eclipse.org mailing list and feel free to ask questions or join the task force to help other projects. And of course, please checkout the information on the Eclipse wiki on how to migrate.
Happy migrating!
I’m excited about the upcoming EGit and JGit 1.0 release. There’s a lot of cool things that will be in the release, like the ability to easily search for commits. One option you’ll have is a dialog that is similar to the Open Type dialog in JDT, but for commits…
There is also integration with the Eclipse Search framework…
You can also view your commits with the new nifty commit viewer…
Thank you to everyone who is testing our nightly builds out and may we never have to use SVN again, enjoy!
I’m happy to announce that we have a first release of eclipse-maven-signing-plugin. If your project needs to sign your bundles as part of the Eclipse Indigo release, please give the plug-in a try. To get started with the plug-in, please add the proper maven.eclipse.org repository to your pom.xml…
<pluginRepositories> <pluginRepository> <id>maven.eclipse.org</id> <url>http://maven.eclipse.org/nexus/content/repositories/milestone-indigo</url> </pluginRepository> </pluginRepositories> |
After that, in the module that you generate your p2 repository, add this profile…
<profiles> <profile> <id>build-server</id> <build> <plugins> <plugin> <groupId>org.eclipse.dash.maven</groupId> <artifactId>eclipse-maven-signing-plugin</artifactId> <version>1.0.0</version> <executions> <execution> <id>pack</id> <configuration> <inputFile>${project.build.directory}/github-updatesite.zip</inputFile> </configuration> <phase>package</phase> <goals> <goal>pack</goal> </goals> </execution> <execution> <id>sign</id> <configuration> <inputFile>${project.build.directory}/github-updatesite.zip</inputFile> <signerInputDirectory>/home/data/httpd/download-staging.priv/egit-github</signerInputDirectory> </configuration> <phase>package</phase> <goals> <goal>sign</goal> </goals> </execution> <execution> <id>repack</id> <configuration> <inputFile>${project.build.directory}/signed/site_assembly.zip</inputFile> </configuration> <phase>package</phase> <goals> <goal>pack</goal> </goals> </execution> <execution> <id>fixCheckSums</id> <phase>package</phase> <goals> <goal>fixCheckSums</goal> </goals> </execution> </executions> </plugin> <plugin> <artifactId>maven-antrun-plugin</artifactId> <executions> <execution> <id>deploy</id> <phase>install</phase> <goals> <goal>run</goal> </goals> <configuration> <tasks> <delete includeemptydirs="false"> <fileset dir="/home/data/httpd/download.eclipse.org/egit/github/updates-nightly"> <include name="**" /> </fileset> </delete> <copy includeemptydirs="false" todir="/home/data/httpd/download.eclipse.org/egit/github/updates-nightly"> <fileset dir="target/checksumFix"> <include name="**" /> </fileset> </copy> </tasks> </configuration> </execution> </executions> </plugin> </plugins> </build> </profile> </profiles> |
Then all you need to do is run your maven build with ‘-P build-server’ as an added goal.
There are a couple things you need to watch for in regards to paths. The first is to ensure that you have a directory on the build server where signing can happen, in the example above, it was /home/data/httpd/download-staging.priv/egit-github. If you don’t have the proper permissions to create a directory under /home/data/httpd/download-staging.priv, please open a bug against the webmaster. You also need to ensure that you point to the archived p2 repository that is generated as part of the maven build. In the case of our example above, it’s ${project.build.directory}/github-updatesite.zip. The second part of the profile publishes the results on download.eclipse.org so you need to ensure that the directory there (e.g., /home/data/httpd/download.eclipse.org/egit/github/updates-nightly) is writable by Hudson (e.g., chmod 777).
I hope that gets you started. I plan on updating the Minerva example by next week to include all of this information and have it migrated to the eclipse.org Dash project where everyone can use it. A special thanks goes to David Carver and Jesse McConnell in helping get this in place in time for the Eclipse Indigo release.
In the past, I have blogged about travel tips (e.g., airline meals) so I figure I would continue the tradition but focusing on last minute hotels (although you can do this on a non-last minute basis). It’s not that I’m very frugal, I’m just not a fan of the price gouging that happens in the hotel industry. You may find this useful if you’re under tight travel budgets or there are times when a conference is in town and hotels raise their prices significantly.
This tip exploits mainly Hotwire and Priceline and focuses on North America (although I’ve had success with Hotwire in Europe). I’ll show you an example of how it works. For example, I need a hotel in Houston next weekend for a graudation party. I do a quick search on Hotwire (this would also work on Expedia’s Unpublished Last Minute Deals) and it shows me a bunch of options…
The downside is you don’t see the actual hotel you’ll stay at, but you do get access to some reviews and the star level. Here’s where the magic happens. I cross reference these examples with the forums from BetterBidding…
If I match up the star level and amenities, I can see that the second hotel listed in the Houston Galleria is going to be the Omni. From my experience, I’m almost always able to figure out the hotel from the star level amenities. From the twenty or so times that I have done this, only once it hasn’t come up with the hotel that I expected (it was another four star hotel so it was fine). If you prefer to use a bidding service like Priceline, you can check the BetterBidding forums on recent successful bids to get a good idea on what you should bid for…
In summary, Hotwire and Priceline in combination with BetterBidding work great if you need a reasonably price last minute hotel. The only downside you face is that you won’t earn loyalty points for your stay with the hotel. Other than that, I hope people find this useful.
For the past month, I’ve been piloting Gnome 3 and Fedora 15.
I’m pretty happy with the state of things now. I have to admit that in the beginning, I was cursing loudly asking for my desktop and panel back, but I’m used to the dash area and window picker now. The search feature (which is similar to Spotlight in OSX) is really useful and I end up using that for the majority of my tasks. I also find the notification system very well done along with the ability of dealing with messages without changing windows. In the end, all I can say is I find myself using Fedora more over my pretty MacBook Air for the majority of my tasks. I’m almost as productive as I was with Gentoo and Rat Poision back in the day 🙂
On a side note, when will “desktop Linux” realize that no one wants to write applications in Gtk, Qt or Python. And by no one, I mean there’s just a small slice of developers capable of writing applications in those languages (I don’t care how many Python snippets you provide). The first one to allow applications be developed in a more popular and saner language, preferably a combination of HTML/JS/CSS will do wonders to their respective communities. I think the direction Gnome is going with Seed but they need to still make things easier for folks.
Anyways, if you want to learn more about the Gnome 3 changes, check out this wiki page. The final release of Fedora 15 should be out in a couple of weeks, but if you can’t wait, grab the pre-release which has been working great for me.
The Jenkins community had a meeting yesterday, here are the minutes. As part of the meeting, there was discussion to see if there could be any reconciliation with the Hudson proposal at eclipse.org, they started a wiki page with their requirements.
I was mostly at the meeting to dismiss any false knowledge with how we operate at the Eclipse Foundation. There seems to be a lot of confusion that Eclipse is controlled by IBM and whatever evil companies you want to name, but that’s so almost a decade ago when Eclipse wasn’t a Foundation but a Consortium. If you take a peak at this year’s commit information so far, you see that individuals make up the most commits at eclipse.org so far (with IBM as a close second). Eclipse.org is a very professionally run open source organization that understands the line between commercial and open source offerings well, you won’t find many freetards here. You’ll find people who care deeply about developing quality open source software for companies and individuals alike. Just take a look at the eclipse.org membership rolls and you’ll see the amount of diversity. There’s an established development process called the Eclipse Development Process which gets refined every year or so and helps guide projects in the right direction to releasing quality software. In the end, each eclipse.org project is individually run by the committers and project leadership.
I have a selfish reason to have a great CI system at eclipse.org… we already are fanatical users of an older Hudson version for a lot of our eclipse.org projects (http://hudson.eclipse.org/) and having a project within the eclipse.org walls would allow for some nice dogfooding. On top of that, we have a great set of Mylyn Builds tools (see Mik Kersten’s blog entry) that allow developers to interact with their Hudson/Jenkins instances from within the Eclipse IDE. On top of that, the Eclipse community also has a lot of advice to share when creating a plug-in based ecosystem, from technology (e.g., OSGi) decisions to infrastructure to licensing.
In the end, it’s pretty comical that the Java ecosystem is large enough to damage itself like this. A prolonging fork of Hudson/Jenkins is a not an ideal solution for the future and having the projects reunited would be better in my humble opinion. Regardless of the decision, I hope people from both sides can put the politics and hard feelings aside and do what is right for your adopters, because at the end, you need to keep them happy, whether they are individuals or companies.
As part of our upcoming 1.0 release, JGit will feature some Git Ant tasks. This is great news if you want Ant tasks that are portable and don’t rely shelling out to call the Git command line interface. If you want to take a peak at the, check out the org.eclipse.jgit.ant module.
A special thank you to Ketan Padegaonkar from ThoughtWorks for the initial contribution. If you want more Ant tasks available, please feel free to contribute by looking at our contributor guide.
