Developer Call Notes - Jan 27, 2011

Attendees: Scott Cantor, Steven Carmody, Jim Fox, Nate Klingenstein, Chad La Joie, Bob Morgan, Brent Putman, Phil Smart, Rod Widdowson, Ian Young, Tom Zeller

Status Updates

OpenSAML: Brent

• completed combing xmltooling, openws, and opensaml into a single repository
• began reorganizing combined repository into a maven multi-module project; xmltooling and opensaml currently roughed out
• added shell script, which the IdP may want to adopt, that can be used to create new modules
• Things left to do:
  • split up openws into separate modules
  • determine which dependencies are declared in a given module, in the parent POM's dependencies list, or the parent POM's managed dependencies list
  • import the project to new shibboleth.net SVN server

IdPv3: Chad

• completed the core attribute rework; APIs should be relatively stable going forward
• completed initial work on new attribute resolver; still need to add some additional unit tests but the resolver currently seems to do the right thing when its methods are called
• Left to do:
  • more unit tests
  • porting of existing resolve plugins to new attribute/resolver APIs; this work will be split up amongst other developers

Notes about Eclipse Setup

• When checking out projects from SVN, the referrals take a while to check out. Don't worry that something is wrong; it just takes some time complete.
• The .settings/* files for the IdP modules are centralized and pulled in via SVN referrals. Depending on your settings, Eclipse may modify one of more of these files when you import the project. Just ignore these changes and do not attempt to commit them.
• Each project is now targeting the Java 6 Execution Environment. Depending on your settings Eclipse might adjust the .classpath. Do not commit this. Instead make sure that Eclipse's Java 6 Execution Environment points to a Java6 JVM on your machine ("Java 6 Execution Environment" is just a name; annoyingly, it doesn't necessary point to a Java6 JVM). To check this go to Eclipse's preferences and Java -> Installed JREs -> Execution Environments and be sure that a Java 6 JVM is selected. If a Java 6 JVM is not listed then add one to the Installed JREs.

Jira time tracking

It was suggested that Jira time tracking feature be enabled. Developers would then estimate the work for each issue and track their time worked on it.

Chad explained that he was concerned that this information could be misused by "pointy-haired bosses". However it also provides developers a chance to improve time estimation skills and more importantly, if estimates were grossly low, it helps identifies portions of the code that were unexpectedly complicated and may need to be look at much closer and possibly redesigned.

Developers all agreed to go ahead with this feature.

Coding Practices:

Chad is going to post a coding conventions page in the developers section of the new wiki. This will include instructions to use the Eclipse code formatting and Checkstyle rules we've been using for years. Three new items were also proposed (and accepted):

• Javadoc all test classes so that it's clear what exactly is being tested in each test case
• Use the final keyword for all method parameters and method variables for which it is appropriate
• When using the @SuppressWarnings("unchecked") annotation, only apply it at the field level; never at the method of class level.

See Java Coding Conventions

Embedded Discovery Service

Rod brought up two topics related to the Embedded Discovery Service (EDS).

First, building and packaging the EDS. The EDS will get a real build system (not sure which) that will minify things, create packages, etc. We will also investigate creating an EDS RPM which the SP can depend on. That way the EDS can be versioned separately (which Chad felt was important until such time as the EDS matures more) but still be installed with the SP.

Second, there was a question of license. Currently we have our Javascript code as well as a JSON parser that is from the public domain. The question was about how attach our license and where such notices need to appear. The decision was to put our normal Apache2 license in the distribution and on our JS code. During the minification process the license header on the Javascript will be stripped out and we're okay with that.

Comments on IdPv3 Architecture

Tom Zeller noted that in IdPv2, the Spring bean definitions hard-code a dependency between most beans and the logback configuration bean. This causes hassles if you try to use the Spring configuration logic outside the IdP. Also related to logging Chad noted that IdPv2 actually has two logging configurations. This was necessary because the IdP had to manage the reloading of the main logging file and so the second was introduced to be loaded prior to all the Spring initialization (which in turn loads the main logging file). Going forward, Spring will no longer be used to load the logging configuration. Within the IdP a Servlet listener will be used and logback's recently added configuration reloading support will be used to reload configs.

Chad then noted some recent IdPv3 commits that split up the notion of a "service" as it was present in IdPv2 in to two things. The notion of a "component" that carried an unique ID and could be validated. Some examples would be the attribute resolver, all its plugins, the relying party configuration manager, and all the profile handlers. All existing services will implement this interface. This removes any hard dependency on Spring (or any other notion of how to configure the component). Extending component will be the notion of a service. The service will embody the idea of configuring a set of components. Each component that would be turned in to a service would be wrapped in a service proxy. This will be explained further in the design documentation Chad is preparing to write.