devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reza Naghibi <reza.nagh...@yahoo.com.INVALID>
Subject Re: How to get the DDRSimpleAPI source code? (was: Does the build work?)
Date Sun, 18 Jan 2015 08:17:00 GMT
To use any non standard library or API in Java, the code needs to be compiled, signed, and
released into some kind of maven repo. I don't think that url is any of that. I still think
the best option is to branch the spec into our project.

Also, according to the timestamps, that directory looks like the first version of the spec
[0]. There is a September and December version. So that may not be the latest.

[0] http://www.w3.org/TR/2008/WD-DDR-Simple-API-20080404/




<div>-------- Original message --------</div><div>From: Werner Keil <werner.keil@gmail.com>
</div><div>Date:01/18/2015  12:39 AM  (GMT+01:00) </div><div>To: dev@devicemap.apache.org
</div><div>Cc:  </div><div>Subject: Re: How to get the DDRSimpleAPI
source code? (was: Does the build work?) </div><div>
</div>Since the question about the official W3C DDR sources has been answered (
http://www.w3.org/2005/MWI/DDWG/drafts/api/simple/java/src/) I wanted to
follow up on this thread, too. I assume we can safely use the API in
relevant artifacts?

Werner

On Sun, Jan 11, 2015 at 1:14 PM, Werner Keil <werner.keil@gmail.com> wrote:

> This is another user of W3C:
> http://www.detectright.com/w3c-compatibility.html
> It also shows which aspects of the Basic Vocabulary they use and
> sell/lease to customers.
>
> While not pointed from the main page directly to it, the W3C DDR Simple WG
> made both binaries AND source available, I suppose we can point to it and
> use without problems then?;-)
> http://www.w3.org/2005/MWI/DDWG/drafts/api/simple/java/src/
>
> Werner
>
> On Fri, Jan 9, 2015 at 3:06 PM, Werner Keil <werner.keil@gmail.com> wrote:
>
>> Unfortunately it's not that simple at least for builders (a file which
>> even classifier can't do without at the moment)
>> Class references like
>> "org.apache.devicemap.simpleddr.builder.device.DesktopOSDeviceBuilder"
>> control builder "injection" very much like e.g. Spring does, so the file
>> referenced by the properties used by W3C ServiceFactory has to be a valid
>> class name, otherwise it makes no sense and the W3C implementation can't
>> instantiate any builders.
>>
>> However, that's the nice thing being highly modular, I don't think we had
>> to "factor out" builders and some other modules, since they contain
>> absolutely no reference to W3C DDR.
>> import org.apache.devicemap.simpleddr.builder.Builder;
>> import org.apache.devicemap.simpleddr.model.UserAgent;
>> import org.apache.devicemap.simpleddr.model.browser.Browser;
>> //NO org.w3c here;-)
>> public class DefaultBrowserBuilder implements Builder {
>> ...
>> This Builder pattern was introduced and applied by OpenDDR and donated to
>> DeviceMap. So a W3C implementation could use not only data but also these
>> builders from DeviceMap without breaking the current data file. Should
>> builders no longer be part of a 2.x data format, then either a wrapper like
>> Reza drafted (all of that refers to W3C, it's a minimalistic approach to
>> mainly the "model" package and a few other classes in the Simple DDR
>> module) could be compatible with a new data file or builders defined
>> outside Aapache in a separate XML definition. As mentioned, the DI
>> mechanism for Builders could in future be redesigned to use a DI framework
>> like CDI/DeltaSpike, Spring or Guice.
>>
>> Werner
>>
>>
>>
>> On Fri, Jan 9, 2015 at 2:41 PM, Bertrand Delacretaz <
>> bdelacretaz@apache.org> wrote:
>>
>>> Hi,
>>>
>>> On Fri, Jan 9, 2015 at 2:13 PM, Werner Keil <werner.keil@gmail.com>
>>> wrote:
>>> > ...Thus something like let's call it "OpenDDR.next" that does not fall
>>> under
>>> > Apache requirements could use "devicemap-data" and "w3c.jar" together
>>> > without problems?...
>>>
>>> Yes no problem, if you guys do this outside of DeviceMap you can do
>>> whatever, as long as the project and package names are different from
>>> this project to avoid confusion.
>>>
>>> That doesn't prevent collaborating on data collection, structure and
>>> tests here and you wouldn't have to comply with Apache requirements on
>>> that project, which probably makes things easier.
>>>
>>> -Bertrand
>>>
>>
>>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message