devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Keil <werner.k...@gmail.com>
Subject Re: 2.0 is now alpha
Date Tue, 04 Aug 2015 15:52:59 GMT
Guess from a license point Jackson is as good (also Apache 2) but at least
in Budapest where fellow JSR 374 EG Member Hendrik has a talk about Johnzon
https://apacheconcore2015.sched.org/event/e64ea46ccc41daaa2c0d58bb9b32e6d4#.Va6ouHh3rTo
I'd
be happy to talk to him about possibly using Apache Johnzon and what he
thinks about it.

To allow parallel approaches (not only at events like Hackathons) someone
even before the restructuring created this
https://svn.apache.org/repos/asf/devicemap/branches/2.0/classifiers/ but
it's empty, and the name "classifiers" does not seem to make as much sense
there any more. While "data" probably makes no more sense, now that 2.0
development is done on trunk rather than a "feature branch" could we
consider this a sort of "sandbox" for new ideas like alternate JSON parsers
or even new language ports?

On Tue, Aug 4, 2015 at 5:40 PM, Werner Keil <werner.keil@gmail.com> wrote:

> What's the reason to use proprietary Shell scripts rather than a platform
> neutral Maven, Gradle or at least Ant script?
>
>
> On Tue, Aug 4, 2015 at 5:37 PM, Reza Naghibi <rezan@apache.org> wrote:
>
>> I did some updates. Here is the README:
>>
>>
>> https://svn.apache.org/repos/asf/devicemap/trunk/clients/2.0/reference/README
>>
>> Also, I remove the jars from the source (compile.sh now downloads the
>> required jars):
>>
>> https://svn.apache.org/repos/asf/devicemap/trunk/clients/2.0/reference/
>>
>> Let me know what you think...
>>
>>
>> On Tue, Aug 4, 2015 at 9:09 AM, Reza Naghibi <rezan@apache.org> wrote:
>>
>> > > Do you think slightly enhancing that reference client so it can be
>> used
>> > as a barebones client is a bad idea?
>> >
>> > I think thats a good idea. But the client would have to be copied into
>> the
>> > clients/2.0/java folder first before being worked on. Like I said, with
>> > minimal work, this client can be turned into the official Java client. I
>> > personally would prefer someone else to take the lead on the Java
>> client,
>> > so maybe Volkan or someone else can spearhead this task (obviously I
>> will
>> > and can assist). Whoever does this is free to write, restructure, and
>> > evolve the client as they wish, as long as they adhere to the client
>> > guidelines, which are a no brainer....
>> >
>> > http://wiki.apache.org/devicemap/DataSpec2#Client
>> >
>> > > It might be good to explain that in the module's README for others
>> who might
>> > be as lost as I was
>> >
>> > Yes, I will definitely spend time soon beefing up the README.
>> >
>> >
>> > On Tue, Aug 4, 2015 at 8:43 AM, Bertrand Delacretaz <
>> > bdelacretaz@apache.org> wrote:
>> >
>> >> Hi Reza,
>> >>
>> >> On Tue, Aug 4, 2015 at 2:23 PM, Reza Naghibi <rezan@apache.org> wrote:
>> >> > ...The reference client basically exists to validate, debug, and
>> build
>> >> domains
>> >> > and provide a guide to how a real client should be written. This
>> client
>> >> > isnt really meant to be used directly by users. Its also meant to be
>> >> > written very cleanly (hopefully) and make minimal use of Java idioms
>> and
>> >> > patterns. This is why I avoided maven and most 3rd party libs...
>> >>
>> >> Ok, got it now, thanks!
>> >>
>> >> It might be good to explain that in the module's README for others who
>> >> might be as lost as I was ;-)
>> >>
>> >> Do you think slightly enhancing that reference client so it can be
>> >> used as a barebones client is a bad idea?
>> >>
>> >> A basic Maven build that produces a runnable jar that's also an OSGi
>> >> bundle is simple to setup, and the tests can run as JUnit tests - but
>> >> maybe you prefer having that in a separate "basic 2.0 java client"?
>> >>
>> >> As for a basic Java API, would a Map<Map> work?
>> >>
>> >> deviceMap.get(String userAgent) returns a Map<String, String> of
>> >> device properties or null if not found.
>> >>
>> >> -Bertrand
>> >>
>> >
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message