Inline on this particular aspect Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | Eclipse UOMo Lead, Babel Language Champion | Apache Committer | Advisory Board Member, DWX '15
Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | #EclipseUOMo | #DeviceMap | #DevOps Skype werner.keil | Google+ gplus.to/wernerkeil On Mon, Jan 5, 2015 at 9:40 AM, Bertrand Delacretaz <[email protected]> wrote: > Hi, > > It looks like there's disagreement about maintaining and releasing one > or two Java clients that use the DeviceMap data. > > I don't have a strong opinion myself - if we have volunteers to > maintain two clients, why not. > > The main problem IMO is whether both clients can use the same data set. > > I haven't been able to review all the recent discussions in detail, > but it seems like one recent commit broke one the clients while > improving the other - if that's the case, then something needs to be > fixed, or worst case two slightly different variants of the device > data set might need to be maintained. > > As of now (before a real major redesign and refactoring towards "2.x" takes place) they are compatible, also after those changes. There was a situation where the W3C implementation could not recognize any of the newly added devices. I pointed out, the W3C spec and implementation does offer a "proactive" way to detect multiple variations of a UA string (something like "Series 6*" which may be 60, 61, etc. just an example, regular expressions have always been used there for some devices) but Reza insisted we should currently just recognize 2 exact variations. The "parent" approach in DeviceData (instead of a regex in the Builder file) also got to work for W3C DDR. A strange side-effect seems to be, one of the 2 new entries creates an unexpected result in the "Classifier" Unit Test with the very latest trunk codebase. If anybody could verify that by running "mvn clean install" or similar against https://svn.apache.org/repos/asf/devicemap/trunk/devicemap/java/classifier/ that would be great. I still keep getting 1 unit test error. Reza's build seems to pass with the same codebase. Ideally both the existing Jenkins should be up and running again to help detect any problematic situation for each client, not just the Java ones. Beside 2 or 3 Java versions (6 if we still want, but of course 7 and 8 should be as they are the officially supported ones by Oracle) it would be best to have a "release" build of data and a combination of it and clients, e.g. "device-data-1.0.1" at the moment and a "nightly" build with the trunk equivalents. Bertrand, is this something you could help with? The VP/chair not necessarily has to do that as he/she officially is just a "channel" between the team and the board, nothing more, but with a sort of guiding function, these are things, I would expect a project chair could ideally do. You helped with the earlier Jenkins job, so by either asking infra yourself or helping the chair with that would be highly appreciated. Werner > What do people think, can we technically live with two java clients, > possibly maintained by different people, or are there technical > hurdles that prevent that? > > -Bertrand >
