Thursday, March 29, 2012

Gemini Web feat. Gemini Naming or Injecting OSGi Services the Java EE Way

A presentation by Violeta Georgieva of SAP on the Gemini project on which she works.
  • Gemini is a web container
  • Develops with Libra installed that provides WTP and PDE working together. MANIFEST.MF in PDE manifest editor but right-click project > add servlet.
  • New dynamic web project, add osgi bundle in config
  • Run under Gemini web, can install other WARs or WABs (Web Archive Bundle)
  • Right-click > Run as > OSGi framework
  • A WAR/WAB can use OSGi services exposed in another WAB.
    • ServiceTracker in servlet to obtain an OSGi serviceJNDI
    • jndi with osgi-based url
      • e.g., new InitialContext.lookup("java.something")
      • Meta-inf/context.xml entry
  • Can use Dependency Injection (DI) using J2EE 6 annotations:
    • @Resource("name=LogService")
A pretty cool demo. How long do we have before we should deploy OSGi on the server? It's nice to know there's tooling available now and that OSGi service use is covered.

Eclipse 4.2: Tips on API best practices for a 3.x

A presentation by Eric Moffatt , Remy Suen [IBM], Paul Webster [IBM Canada] on common bugs they found in Eclipse code when run on pure 4.x. 
  • Aspects to investigate:
    • usage patterns
    • command patterns
    • part management
    • interaction with framework
  • Commands
    • Abstraction of some behaviour
    • Not visual
    • Not an implementation
    • Usage:
      • Declaratively via extension
      • Programatically by executing Handler service
      • Do not use Command.setHandler() - doesn't work
      • Do not use Command.executeWithChecks() - sometimes won't work
  • Handlers
    • Should not carry state
    • Get it using HandlerUtil, Command, or framework
  • Parts
    • Access a service locally if possible, i.e. getSite().getService(). It will scope and cleanup.
    • Parent composite assumptions
      • Never assume anything about a Composite that is given to you (e.g., the layout, styles, etc.)
      • Layout calls might not happen when you think
      • Shouldn't set layout on it either if you're not sure it doesn't have any children but you because siblings may not render if they use a different layout.
      • E4 is more flexible, so parts can show up anywhere
    • Keep parts isolated from one another.
    • Caching of values: Part's shell can change in 4.x when part is de/reattached, so don't cache it
    • setFocus() needs to be implemented, don't leave it blank. Set focus on a control in the part. Always called from UI thread.
    • Avoid downcasting to get implementation API, it won't be there in 4.x.
    • Preferences will continue to work through workbench or Equinox API.
    • Avoid Workbench.getProgressService().
    • SWT containment honored in 4.x, "Big Lie" in 3.x was that every view and toolbar was actually parented by shell. Do not cache Shell.

We should build a 4.x product and test installing our 3.x features in it. Compatibility layer should make them work but would point out such bugs.

Build Trust in Your Build to Deployment Flow!

A presentation by Yoav Landman of JFrog, the creator of Artifactory, on Continuous Integration (CI).
  • Benefits of CI:
    • Latest version
    • no maintenance release, just do frequent releases including bugfixes
    • less concern about backward compatibility
  • Challenges of CI:
    • Version tracking
    • root cause analysis
    • not everyone ready for this
  • Devs have agile tools. So do Testers. But DevOps?
  • All need access to versioning, tracabilty, access control, promotion, etc.
  • Binary repositories (leave the source at the build stage):
    • need Proxying
    • need smart storage, e.g. find source when needed
    • critical for CI & ALM
  • Artifactory Pro has P2 virtual repo!
  • Move binaries through phases, e.g. testing, staging, prod.
  • Need traceabilty from version control system and build server
  • Plugins for Hudson and Jenkins upload build info to Artifactory repository.
  • Releasing:
    • Your next build is RC
    • Once built and tested, push a button.
    • Version switch, move to another repo, tag
    • Process: snapshots, declare one RC, release
    • Release with Artifactory plugin - a little rigid but works on previously=built snapshot
    • Redundant release build can fail.
    • Should move snapshot, use binaries storage to promote, can script destination, etc.
    • Need to update pom and rename snapshot to be promoted
    • Done in Artifactory
We currently have problems using the maven-release-plugin with tycho. Artifactory removes that plugin's use, i.e. Maven does not release - Artifactory does. It renames and distributes snapshot and makes required POM changes in source. 

Artifactory seems to require artifacts.jar and contents.jar before exposing a virtual p2 repo... but isn't that a real p2 repo. It reportedly can't expose bundles in maven repos as bundles, which Nexus Pro says it can. I wonder though if we can generate an artifacts and metadata.jar for a maven repo in order to expose its bundle artifacts.

A Modular and Extensible OSGi Shell


A presentation by Lazar Kirchev of SAP on the new, upcoming Equinox shell (OSGi console).
  • Improvements in usability, added telnet and SSH support.
  • Currently cannot correct mistypes - no backspace, no history, no tab completion.
  • New version based on Apache Gogo
  • Can start with port, e.g. -console 2222, for remote access.
  • Command line editing and tab completion (telnet or remote only), history, telnet, SSH
  • JAAS or public key authentication
  • 4 bundles to autostart
  • Piping, grep, help [command]
  • config.ini entries: osgi.console and osgi.console.ssh , followed by port number
  • Virgo, the enterprise web application server using OSGi deploys, used to demonstrate remote access:
    • Two regions: user and kernel
    • Two shells too
    • One region or shell cannot access the other - security
    • Configuration through ConfigAdmin (2 instances also)
    • By default, its config.ini has telnet and ssh disabled - enable to use
    • Ports 2401 and 2501 - kernel and user
  • Programming for shell, i.e. writing OSGi console commands:
    • console commands are OSGi services with scope and function properties
    • osgi.command.scope : "eclipsecon"
    • osgi.command.function : new String[] { "printfile" }
    • Converters and formatters, e.g. pass bundle id argument, convert to bundle object to be received as actual argument.
    • Install new bundle and start
    • help | grep printfile <- tests that new service is available
  • Available with Juno.
  • "Mostly" backward compatible with 3.7, 3.8.
I spend a lot of time in the OSGi console debugging installations and OSGi services, both for our team and when requested by others. This will greatly improve the effectiveness of such debugging. For example, a developer can start with -console [port] and I can debug his runtime using his IP and putty. We can debug prod the same way if we want! Huge!

Making Mylyn the Agile Oil, and Glue, for your ALM stack

"The heterogeneous ALM stacks commonly found in enterprises challenge users with a lack of integration." "Mylyn's broad ecosystem of extensions bridges that gap with the popular IDE tooling that providing visibility into projects. These tools are based on the frameworks of the Mylyn sub-projects that cover key ALM concerns."
  • Lets bring everything in to the IDE
  • Integration is difficult
  • Mylyn creates an API for consistant integration between Eclipse and task tracking tools

  • Mylyn Framework
    •  Tasks (Bugs, issues, stories, requirements)
    • Context (Activity and artifact tracking, focus)
    • Versions (SCM, change sets, linking)
    • Builds (Releases, continuous integration)
    • Reviews (Task-based code review)
    • Docs (Wiki documentation, transformation)
  • http://eclipse.org/mylyn/

The Future of ALM

A keynote presentation describing recent trends in Application Lifecycle Management (ALM) using a car manufacturing example. With, for example, four dozen software suppliers, we see huge software ecosystem changes. His observations:
  • Taiwan now approaching Germany as top eclipse downloader
  • Software development increasing much faster than workforce
  • Henry Ford doubled employee salary, automation next
  • Toyota's just-in-time gave every worker autonomy - able to stop line
  • Empower the people
  • Autonomy, Transparency, Collaboration
  • Software delivery silos: testers, project managers, devs, business analysts, operations
  • Cultural gaps, devs see all devs as rocket scientists, etc.
  • Boeing had delays because of software traceability
  • Handing off to each production stage lost accountability and traceability
  • Long term cost
  • They stopped production to fix traceability
  • Requirements -> development -> testing -> operations
  • Just in time = reduce inventory
  • In development, it's requirements
  • No link between req and ops
  • Toyota proved it's faster not to batch up what's handed off
  • Optimize task batch size = collaboration
  • Task needs to maintain workflow, activity and context
  • Incorporate social stream
  • Mylyn's model: planning, product, user story, task, commit
  • Expose Mylyn workflow
  • Contribution, workflow, automation
  • Gerrit -> Hudson -> review task -> build -> Mylyn workflow -> review -> push = collaboration
  • All involved need to collaborate.

How I Learned to Stop Worrying and Love the Build

"With Hudson driving builds from the top; Git, Gerrit, Maven, and Tycho in the middle; and Mylyn controlling the pieces from the developer's desktop, The Eclipse Foundation provides an impressive stack of technologies for building software."

  • Why I was worrying
    • closed, private build jobs
    • cron jobs, shell scripts, ant scripts
    • unpredictable results

  • Continuous integration
    • ex. Hudson
  • Common build infrastructure (CBI)

  • Recipe for Success
  • Rules of Engagement
    • Transparency
      • Invite participation
    • Openness
      • Accept participation
    • Meritocracy
    • "With Hudson driving builds from the top; Git, Gerrit, Maven, and Tycho in the middle; and Mylyn controlling the pieces from the developer's desktop, The Eclipse Foundation provides an impressive stack of technologies for building software."

      • Earn participation
  • The Four Cs
    • Code (must show up at Eclipse with code)
    • Community
      • End users, Adopters, Developers
      • All are important
    • Cleanliness (from an intellectual property perspective)
      • Where does the code come from
      • Copyright
      • Ownership
      • Licensing
    • Cwality (Quality)
      • Transparent issue tracking, list discussion
      • Reviews (developing community, project is more than just code)
      • Inviting/Accepting participation
      • Diversity

  • ALM "Stack"
  • Build Maturity
    • Modular builds make CI possible
  • Tracking IP
    • Licenses
    • Third-party libraries
    • Developers
    • Contributors + Contributions
  • CI = continuous integration
  • IP = intellectual property