I've just made a large series of large commits which implement a lot more of the rfc 190 support, including multiple pid support and use of the DTO admin model. This involved rewriting all the integration tests to use the DTOs. Now at least they are a lot less repetitious.
One of the biggest conceptual changes between the old and new admin models is the (new) distinction between component description (basically a representation of the xml descriptor, and more or less represented by the ConfigurableComponentHolder), and the CompnentConfiguration, which are the "instances" of the description you may get by (possibly) configuring it with pids, factory pids, and (for factory components) properties from newInstance (represented by SingleComponentManager). Now you can tell if there actually are any configurations. Left to do are the scope support for exposed services and references, and the configuration-through-annotations bit. I also expect the DTO model to change a bit which will require some updates. Currently all the needed DTO classes have their source copied into the scr project; as soon as the R6 core jar gets to maven central the DTOs from there can simply be included instead. Perhaps we can decide whether it would be appropriate to import rather than copy the rfc190 DTO classes once they are more stable and the spec is closer to final. Note that according to the current policy we can't release DS until either rfc 190 becomes part of an official released spec or we remove the DTO classes. As discussed earlier on the dev list, I removed the obsolete admin classes. There is still one class in the org.apache.felix.scr package and the version checking plugin tells me this is a breaking change so the package version and bundle version have to move to 2.0. IIUC completely removing the org.apache.felix.scr package also requires moving the bundle version to 2.0. I wonder if we should put the old admin interfaces back and deprecate them? (They definitely won't have any implementation backing them). I've gotten very used to dealing with the concise bnd.bnd file format and fed up with maven's verbosity, so I moved the bnd configuration into a bnd.bnd file. If people don't like this I can move it back. However, I am wondering about moving farther and making this a bndtools project and using the bnd maven plugin so everything is run off the bnd.bnd file. I note the DS tck tests run through bnd seem to run an order of magnitude faster than ours, and wonder if running ours through bnd would also speed things up. This was a really large commit, and I would preferred to have exposed my work more gradually, but until the last couple of days significant amounts of the integration test suite didn't compile or pass, so committing them seemed like a rather bad idea. In the future if anyone wants to see my work in progress I can make a branch on github. Of course comments are more than welcome. thanks david jencks
