work | Chris Aniszczyk's (zx) diatribe

Category “work”

Yesterday, the Symbian Foundation announced the release of the Symbian microkernel and development kit under the Eclipse Public License (EPL).

“The release of the microkernel demonstrates three vital, guiding principles of the foundation: first, the commitment of many community members to the development of the platform – in this case, Accenture, ARM, Nokia and Texas Instruments Incorporated (TI) all made contributions; second, progress in fulfilling our commitment to a complete open source release of Symbian; and third, a tangible example of providing the most advanced mobile platform in the world” said Lee Williams, Executive Director, Symbian Foundation.”

Good stuff. That’s going to be a lot of phones and devices with open source love in it.

Maybe Gartner’s prediction of open source dominance by 2012 will happen sooner?

Gartner believes that 80 percent of all commercial software applications will include open-source components by 2012. Gartner notes that the value and robustness of open-source software offers compelling opportunities for commercial software developers to reduce development costs.

I think open source and open development is in. Will people care though?

Ok, now back to watching those DroidDoes commercials…

October 21, 2009

8 Comments

Eclipse and Content Type Definitions

By Chris Aniszczyk

I came across a bug in PDE recently regarding content types.

For example, let’s pretend you had a xml file like this:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" 
    name="Command Provider for Dictionary Service">
   <implementation class="org.eclipse.example.ds.ServiceComponent"/>
   <service>
      <provide interface="org.eclipse.osgi.framework.console.CommandProvider"/>
   </service>
   <reference 
      bind="setDictionary" 
      cardinality="1..1" 
      interface="org.eclipse.example.ds.DictionaryService" 
      name="Dictionary" 
      policy="static" 
      unbind="unsetDictionary"/>
</scr:component>

And this content type extension definition:

<extension
         point="org.eclipse.core.contenttype.contentTypes">
      <content-type
            base-type="org.eclipse.core.runtime.xml"
            file-extensions="xml"
            id="org.eclipse.pde.ds.core.content-type"
            name="%content-type.name"
            priority="high">
         <describer
               class="org.eclipse.core.runtime.content.XMLRootElementContentDescriber2">
            <parameter
                  name="element"
                  value="component">
            </parameter>
         </describer>
      </content-type>
</extension>

Looks ok, right? The content type should be associated with files that start with the component tag. Cool! Well, the problem is since Eclipse is open for contribution, someone else can come along and define a “component” format and than you have the problem of your editor associations being messed up. Many bad things can happen.

<?xml version="1.0" encoding="UTF-8"?>
<component name="stuff">
    <...>
</component>

The fix is to have my content type definition scoped by namespace. This is trivial since XMLRootElementContentDescriber2 supports namespaces.

<describer
     class="org.eclipse.core.runtime.content.XMLRootElementContentDescriber2">
     <parameter
             name="element"
             value="{http://www.osgi.org/xmlns/scr/v1.1.0}component">
     </parameter>
 </describer>

You learn something new everyday.

October 19, 2009

No Comments

Eclipse Summit Europe 2009

By Chris Aniszczyk

I’m presenting at Eclipse Summit Europe 2009 which happens in about a week from today.

I’ll be speaking about OSGi Versioning and Testing with Jeff McAffer and Paul VanderLei. Please consider coming to the talk, it should be fun and will involve discussion of painting fences with neighbors.

Here’s the abstract:

The old saying goes, good fences make for good neighbors. Modular systems are all about the fences, otherwise known as contracts. OSGi-based systems are simply compositions of modules and contracts. To express contracts in OSGi, we use version numbers. From our experience in the Eclipse community, we have found that managing API and these contracts a difficult process.

In the first part of this talk, weâ€™ll discuss the problem of version numbering and managing change. Weâ€™ll bring forward real world examples that demonstrate the complexities in managing change, including examples from the Eclipse community where change has caused havoc. There will be a demonstration of some the tools we developed at Eclipse to help manage change in your OSGi-based applications.

In the second part of this talk we draw on experiences and examples from the OSGi and Equinox book to identify key elements of modularity and point out best practices for designing and building modular systems using OSGi. Along the way we highlight pitfalls and anti-patterns and talk about ease of testing as barometer for modularity.

On a side note, over 30 people have signed up for the Eclipse Summit Europe 5K run every morning!

Please don’t forget to sign up if you want to run and burn off some Kirsch.

October 16, 2009

6 Comments

Browsers are hungry for memory too

By Chris Aniszczyk

I think over the past few years, my internet browsing experience has steadily decreased.

From Firefox leaking memory like a sieve to Safari officially eating more memory than Eclipse on a consistent basis.

Memory, it’s what’s for dinner.

October 15, 2009

14 Comments

Welcome to the Open Source Club IntelliJ

By Chris Aniszczyk

It looks like Jetbrains just announced that they are releasing a free and open sourced version of IntelliJ under the APL 2.0 license. Cool beans, however, open sourcing an IDE is just the first step…

The hard part is building a sustainable community. To channel Tim O’ Reilly,

…what really distinguishes open source is not just source, but an architecture of participation that includes low barriers to entry by newcomers, and some mechanism for isolating the cathedral from the bazaar. This architecture of participation allows for a real free market of ideas, in which anyone can put forward a proposed solution to a problem; it becomes adopted, if at all, by acclamation and the organic spread of its usefulness.

Let’s hope that IntelliJ isn’t just throwing the source over the fence and expecting magic to happen.

Good luck to IntelliJ creating that architecture of participation.

October 11, 2009

8 Comments

Aptana + PDT

By Chris Aniszczyk

There’s great news from Aptana and the Eclipse PDT project…

We are pleased to announce that Aptana is combining our efforts with those of the Eclipse PDT (PHP Development Tools) project, the official set of Eclipse development tools for PHP. We will be contributing various parts of the Aptana PHP plugin to that project. We believe that having a single plugin will be best for the PHP developers community, and look forward to a long and productive relationship with the PDT team.

Even though I had some choice words for Aptana in the past, I think this is a great move and should benefit PHP developers everywhere who rely on Eclipse for their development needs.

Let’s hope this is a sign that Aptana is going to work closer with the Eclipse community in the future.

October 8, 2009

18 Comments

Modularity is Fun?

By Chris Aniszczyk

A few days ago I had one of those moments that made me smile, let me describe it in pictures…

I recently was hacking on the JGit project as I’m working on getting a build ready for the project.

What did I notice? Well, there was some evil UI code in the JGit bundle.

You know what to do with evil UI code? Time to move it into another bundle!

Sweet! Now we have a nice separation between core and ui layers, right?

Oh no… compile errors… what the heck?

It looks like some of the code in the core bundle was referencing UI pieces. This is an obvious bad practice since there is the common use case that people may want to run your code in a headless fashion.Â However, as a developer, it’s common to start out and just group your code into one bundle. It’s sad but it’s just the reality of development. This reason should also highlight to you why modularity doesn’t come for free… you have to think about your dependencies and architecture. If you produce complex code first and try to modularize it later… you’ll end up in painful situation. Thankfully, when you have good tools that manage your classpath for you, errors like this become evident.

Ok, enough of my diatribes, back to getting a build for JGit in place at Eclipse.

On a side note, I’ll soon blog about using EGit and Gerrit to develop JGit, stay tuned.

September 30, 2009

4 Comments

Openfire switches to the Apache License 2.0

By Chris Aniszczyk

I was having my morning caffeine fix and saw a tweet go by…

I quickly went to the front page and noticed it hasn’t been updated yet:

However, this is interesting news to say the least. When established open source projects backed by some company switch licenses, there’s usually a business model change afoot. Or was there pressure from Google to switch the license since Google Wave uses Openfire under the covers>?

Thankfully, Matt Tucker’s explanation hints at some of the reasons:

I’m happy to announce that Openfire will be moving to a more liberal open source license — Apache 2.0. Apache 2.0 provides significantly more flexiblity than the GPL in virtually every way, so it should be a big win for the community all around. We expect to get all the source code headers updated for the next release. There were several motivations for making this change:

The GPL license was preventing some companies from using Openfire due to corporate policies

There was no reason to keep using GPL and end-users generally seem to prefer Apache

We’d like to encourage a broader range of commercial companies to contribute to the project and the Apache license is a good way to help make that happen

Would be happy to answer question or comments.

It was delightful to see the Openfire community be notified of the license change, with reasons why and a request for feedback. Scratch this one for the proper way of doing a license change in an open source community. In the open source world, we hold transparency sacred. Don’t be like switched from EPL to GPL and told no one until it was too late.

It’s important to be upfront and transparent.