1 and 2) There is a generic Loader (org.apache.devicemap.client.Loader) which takes in Readers (like an inputstream but it has an encoding: UTF8). FileLoader then wraps this and loads files and I was planning on creating a JarLoader which will detect and load resources from a jar. So it should probably be organized a bit better (interface and package), but I think if there is a new loading method, just wrap Loader, no?
3) sure 4) yes, we need a test framework. Right now im using org.apache.devicemap.client.Main for benchmarks and testing. ________________________________ From: Radu Cotescu <[email protected]> To: devicemap-dev <[email protected]> Sent: Monday, June 24, 2013 1:26 PM Subject: devicemap java client cleanup Hi devs, On Thursday I'm invited to talk at meeting no. 13 of the Bucharest Java User Group [1]. I've decided to tell people about our efforts of providing tools for client detection, both server-side and client-side. Since it's trivial to write a web app on top of Apache Sling for my demo I've decided to use the new client written by Reza because it's a hell lot easier to modify it for an OSGi environment compared to the current OpenDDR donated code. However, in order to make the jar file more friendly, I do need to change a few things: 1. the DeviceMapClient initialisation should be performed with the help of a configuration Map<String, Object> - I need to be able to pass InputStreams instead of having the code look for files on a file system; this way the driver code can do whatever it wants as long as it provides InputStreams 2. 1 implies that we don't need the FileLoader class any more 3. delete the Util.log (now called debugLog) method and pass all the logging stuff to SLF4J 4. maybe replace Main.java with a test (already covered in my changeset) ? Would anyone mind if I commit the previously mentioned changes? Thanks, Radu [1] - http://www.bjug.ro/editii/13.html
