p2, your savior or your achilles heel? Everything an Eclipse team needs to know about p2

Complementary to Discovering the p2 API's. More details on the rules of working with p2:

• do not touch the installed files on disk
• do not move or delete plugins
• do not extract into the plugins folder - a zip can be used as an install location to p2 for proper management
• do not use the dropins folder
• do not replace published content, i.e. publish a new jar under an already published version
• always use a qualifier
• use feature patches if new release not feasible
• do not remove released repositories - use retention policies instead (?)
• use categories - composite repositories can introduce a category layer
• use descriptive feature names and provide descriptions
• MetadataGenerator has been removed in Eclipse 3.7 - use Publisher instead

The Future of Hudson Continuous Integration

A brief talk to dispel rumors of Hudon's demise in lieu of Jenkins. Hudson development is still ongoing with plans of better Maven integration and a lot of refactoring. Also announced was the promise of a Tycho book due next week!

Declarative Services - Dependency Injection OSGi Style

An overview of Declarative Services, most of it already known to us but included some interesting tips. XML descriptors are loaded at application start and bundles are lazily loaded. MANIFEST.MF header Service-Component can use wildcards if XML uses version 1.1 schema but not if using 1.0. Some description of low-level API such as ComponentContext but its use is discouraged. Four types of components were identified:

• Non-service component - can interact with services but not retrieved
• Service - the usual case
• ServiceFactory - can instantiate multiple copies of a service
• ComponentFactory - used by infrastructure

An overview of component attributes was given but this is well documented.

During the Q&A section someone asked how to obtain a declared service in application code! The answer was surprisingly simple, that declared services are registered with the Eclipse ServiceRegistry so they can be retrieved the same way any Eclipse service is obtained, such as the ISelection or IHandler services. The details are a little fuzzy to me now but I believe this means, rather than using a BundleContext and/or ServiceTracker, a service should be requested by interface from one of several ServiceProviders available throughout Eclipse. I'm pretty sure the Site is the best entry point for this. I think we need to test this and replace our current efforts to get services with this more correct, less-dependency-involved method. Given the information provided in Singlesourcing for Eclipse 4.x and Eclipse 3.x though, we might want to consider creating special classes to do this workbench interaction that we can remove when we migrate to Eclipse 4.x. This solves the question left at the end of 10 signs you're doing OSGi wrong. We also should make sure we're always using the 1.1 schema.

Developer Onboarding: Getting Developers Productive in Minutes Instead of Days

A presentation of how Nexus Pro can provision an IDE. The tool can be used to email a web link to new developer that opens a JNLP that starts a p2 installation, effectively installing an IDE. The installer can go on to check out projects. A view is provided with Refresh and Update buttons that can keep developers synchronized in their tooling. Can also be used to revert an IDE to a previous state to work on a bug in an old codebase. Preferences however are not well supported. Only supported by the commercial Pro version.

10 signs you're doing OSGi wrong

Examples of bad ways of using OSGi, summed up as:

• Ignoring dynamism - assuming services are always available.
• Using OSGi as an "applications" level programming platform - using OSGi API in pojos rather than keeping them pure and separating out OSGi-dependant code.
• Ineffective modularization - OSGi has a granularity at the package level which should be adhered to; package rather than jar cohesion should be sought.
• Over/under use of services - not everything should be a service but properly used it can simplify code.
• The myth of "pure" OSGi - plan for and regularly perform refactoring. Package code such that inevitable refactoring can move the package without breaking API. Be agile.

Lots of examples of what not to do but correct usage was at the architectural level with few code examples. For instance we were told to not use BundleContext or ServiceTracker to get a service, leaving me a little dumbfounded. They did state we should use Declarative Services so we're half right. Now I'm on a mission to find out how to get a service.

Discovering the p2 API's

Some warnings about how to get into trouble with p2 and the correct way to use it. Primarily this means letting p2 handle all things related to an installation and not modifying the application by hand... ever. Described was how to tweak the Update Dialog GUI, e.g. removing the repositories selector and add button, and how the headless API has been greatly simplified. Good overview information if we needed to interact with the p2 API but no practical information on setting up or maintaining a p2 repository as I had hoped.

Next Generation Development Infrastructure: Maven, m2eclipse, Nexus and Hudson

More information from another one of the guys from Sonotype. The presentation was focused on their development issues though rather than practical information. Of interest though was that they are trying to make Tycho an Eclipse project along with Aether, the Maven dependency-resolution engine. They seem to be focusing their commercial work on Nexus Pro and Hudson Pro while Tycho and Maven/m2eclipse seem to be planned as open-source. They spoke briefly of their Maven Shell product that is open-source too. It's an enhanced command-line tool that reputedly greatly speeds up Maven commands. If we don't move to m2eclipse we definitely should check this out.

Keynote - What Is Watson?

A presentation on the search technology behind Watson, the Jeopardy winning computer. A detailed description was given of the challenges of natural language queries and some of the strategies the team implemented. Approximately one hundred person-years went into the endeavour. The team is now mainly focused on medical applications - providing comprehensive search capabilities to medical professionals. Other efforts include multilingual capabilities and the ability for Watson to respond with questions designed to increase confidence in final answers. Quite interesting but not really portable to our work.