Twitter github
June 8, 2011
No Comments

Eclipse and The Indigo 500

By

Want to support the eclipse.org community? Join the Indigo 500!

The money goes towards to things like:

  • Providing more bandwidth for users and committers
  • Purchasing additional servers to host Eclipse projects
  • Sending students to EclipseCon
  • Sponsoring Eclipse community events

On top of that, recent disbursements from the Friends of Eclipse fund has gone to:

So hopefully you know that your donation is being used for good in my opinion. If you want to take advantage of some of the funds and are part of the Eclipse community, check out the wiki for more instructions on how to apply. It would be great to see some more usage of the funds for community related activities like meetups.

June 8, 2011
1 Comment

Research at Eclipse: CodingSpectator

By

I enjoy working with students and researchers, it’s refreshing sometimes. Also, it seems I get a couple emails every month from folks doing interesting research with Eclipse. It’s one area I feel we should support more at eclipse.org, but I’m not exactly sure how to facilitate research besides letting people know what you’re working on. Anyways, I feel like I should start sharing some of the research topics so here’s CodingSpectator…

CodingSpectator has been developed at Ralph Johnson’s research group. Ralph is a co-author of the seminal book on design patterns (GoF) and his research group has a history of important contributions to IDEs. CodingSpectator monitors programming interactions non-intrusively in the background and periodically uploads it to a secure server at UIUC. To get a representative perspective of how you interact with Eclipse, we would appreciate if you could install CodingSpectator for two months. Rest assured that we are taking the utmost measures to protect your privacy and confidentiality.

If you’re interested in helping the researchers out, please start with the consent form before installing the tooling. Let’s hope they come up with some interesting findings in the future 🙂

June 6, 2011
2 Comments

Eclipse Indigo Numbers

By

Here’s one of my favorite graphs to look at every year…

Eclipse Indigo is 62 projects and 46 million lines of code this year… that’s a lot of coordination!

June 3, 2011
No Comments

CFP: EclipseCon Europe 2011

By

As a reminder, the Call for Papers (CFP) went out for EclipseCon Europe 2011 recently so please remember to submit your proposals. All I know is that it will be a great conference and that it’s also the 10th year anniversary of Eclipse!

There will definitely be some frosty beverages to be had to celebrate all those years, hope to see everyone there!

June 3, 2011
7 Comments

Blaming in EGit 1.0

By

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!

June 1, 2011
2 Comments

Releasing in Open Source and at Eclipse.org

By

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…

  • Mylyn 3.6.2 (February 24, 2012 – Indigo SR2)
  • Mylyn 3.6.1 (September 23, 2011 – Indigo SR1)
  • Mylyn 3.6 (June 22, 2011 – Indigo)
  • Mylyn 3.5 (March 16, 2011)
  • Mylyn 3.4.3 (February 25, 2011 – Helios SR2)
  • Mylyn 3.4.2 (September 24, 2010)
  • Mylyn 3.4.1 (August 4, 2010 – Helios SR1)
  • Mylyn 3.4 (June 23, 2010 – Helios)
  • Mylyn 3.3 (Oct. 26th, 2009)
  • Mylyn 3.2 (June 24, 2009)
  • Mylyn 3.1 (March 4, 2009)
  • Mylyn 3.0 (June 25, 2008)
  • Mylyn 2.3 (Feb. 27, 2008)
  • Mylyn 2.2 (Dec. 19, 2007)
  • Mylyn 2.1 (Sep. 28, 2007)

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…

  • EGit/JGit 0.7.1 (Mar. 22, 2010)
  • EGit/JGit 0.8.1 (Jun. 2, 2010 – Helios)
  • EGit/JGit 0.9.1 (Sep. 15, 2010 – Helios SR1)
  • EGit/JGit 0.10.1 (Dec. 17, 2010)
  • EGit/JGit 0.11.1 (Feb. 11, 2011 – Helios SR2)
  • EGit/JGit 0.12.1 (May. 2, 2011)
  • EGit/JGit 1.0 (Jun. 1, 2011 – Indigo)

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?

May 19, 2011
2 Comments

Moving Eclipse.org Projects to Git

By

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!

May 18, 2011
No Comments

Commit Search and Viewer in EGit 1.0

By

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!

May 18, 2011
15 Comments

Eclipse.org Signing Support for Maven Tycho

By

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.

May 18, 2011
2 Comments

Travel Tip: Last Minute Hotels

By

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.

« Older Entries
Newer Entries »