Equally important is, how the .NET and Java clients are similar or not? if Eberhard's .NET client supports W3C DDR Specs then the Java API also should. And
As for 1) the answer is, I am also currently the only active OpenDDR contributor, so what I'm allowed and supposed to do with OpenDDR Data (contribute into this project as a contributor to both) I also can and will do in case of the Java API. Werner On Wed, Jul 9, 2014 at 4:56 PM, Reza <[email protected]> wrote: > ok, lets try this again, please answer these questions: > > 1) Do we plan on supporting the legacy openddr java client? If so, who > will support it? > > 2) Do we plan on re-releasing the legacy openddr java client? > > 3) If we support and release the legacy openddr java client (your answer > to #1 and #2 is yes), what is the transition plan to get these legacy users > off openddr and onto the devicemap client? Or no plan, we support both > openddr users and devicemap users? > > ------------------------------ > *From:* Werner Keil <[email protected]> > *To:* "[email protected]" < > [email protected]>; Reza <[email protected]> > *Sent:* Wednesday, July 9, 2014 10:45 AM > *Subject:* Re: Legacy ODDR java client and w3c jar in our repo > > As mentioned and discussed with Bertrand in the other thread, myriads of > Apache projects, see Tomcat, etc. use "lib" folders for dependencies, JSP, > CSS, etc. > The W3C license is among the ones supported by ASF, so using the lib in a > downstream implementation is perfectly fine. > > The relation between the "old" and "new" client are a bit like JSP vs. > JSF. Both are Java EE standards allowing you to accomplish the same thing, > but believe it or not, the current ThoughtWorks Radar still has JSF on > "Hold" (explained as "widely adopted but we still feel it's a bit immature" > ) > > The same applies to the "new" client I'm afraid, especially with regards > to W3C compatibility. Many big sites and projects of various sizes use > OpenDDR now. So unless you offer them a 100% compatible Drop-in-replacement > in the "new" client, that is not usable to them in existing code without > rewriting the whole application. > > If we want to abandon and ignore these users and leave them with the > existing OpenDDR project rather than offering a "bridge" (and chance to > eventually migrate to the new one) that could mean leaving Simple DDR, but > I don't know if we want to do that. > > Bertrand, WDYT? > > > > On Wed, Jul 9, 2014 at 4:36 PM, Reza <[email protected]> > wrote: > > Why is the legacy ODDR java client still in our repo? > > > http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/simpleddr/ > > Do we plan on supporting it? If so, who will support it? Did I not rewrite > the client last year because of all of the issues this legacy client has. > > Do you (we) plan on re-releasing the legacy ODDR client as well? That > would mean we now have 2 java clients... > > Also, you checked in the w3c jar here: > > > http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/simpleddr/lib/ > > Once again, what is the point of trying to bring this old client back from > the dead? I will investigate what is needed to get w3c compatibility into > the new client. Checking this old client into our repo with the w3c jar is > likely not needed... > > ------------------------------ > *From:* Werner Keil <[email protected]> > *To:* "[email protected]" < > [email protected]>; Reza <[email protected]> > *Sent:* Wednesday, July 9, 2014 10:25 AM > *Subject:* Re: DeviceMap data and java client 1.0.0 release review ready > > We don't rely on the W3C JAR to be on Maven repo. The only slight > inconvenience (though the "addjars-maven-plugin" explains well, how this > could be done on a POM level for multiple modules, have not tried that one > yet) could be having to keep the tiny W3C JAR both in "Client" and > "SimpleDDR", but the issue of using the JAR in its binary form (that's how > W3C provides it) is solved > > If you can explore how W3C or any of the old WG members could still put > that to MavenCentral, more than just the DeviceMap project would welcome > (otherwise the guy who put it to GitHub would never have bothered) but it > is not a showstopper for 1.0. > > Werner > > > > >
