IC, thanks. There was no tag for this, but then there's no reason not to tag the data.
If APIs are clarified as to what to tag and what not, we can still wait there. As mentioned in the threads, if Eberhard's contribution features stuff like IEvidence, IPropertyName,... and gets included in a 1.0.0 release, then the equivalent for Java also should be. If his changes are deferred to another release beyond 1.0, then the Simple DDR (though it is perfectly feature complete) could be left for a coordinated release. Werner On Wed, Jul 9, 2014 at 9:46 PM, Reza <[email protected]> wrote: > I already synced the data with the latest oddr release. Im closing your > ticket (DMAP-42). > > > ________________________________ > From: Werner Keil <[email protected]> > To: "[email protected]" < > [email protected]> > Cc: Reza <[email protected]> > Sent: Wednesday, July 9, 2014 3:35 PM > Subject: Re: Jenkins build is back to normal : devicemap-java6 #42 > > > > Bertrand/Reza/all, > > As mentioned, the Simple DDR builds like all the rest now. > I am checking device data for any updates in the most recent OpenDDR > resources (it was last done with v1.26, the latest available is 1.27) then > from my judgement the "data" part seems perfectly ready for 1.0.0 and as > key contributor to this artifact I'll tag it accordingly. > > I also created a new ticket https://issues.apache.org/jira/browse/DMAP-42 > for this. Unfortunately I am not able to change assignments in JIRA, even > for newly created tickets. If this can be fixed so that Eberhard (does it > work for you?) or myself can share the burden of adjusting these where > necessary, please try to address that. Otherwise fewer people would have to > do all that, or as it is now, tasks we're working on are wrongly assigned. > I don't know about the rest, but I use Eclipse Mylyn in a task context, so > commits are automatically commented properly. Reza noticed yesterday one > got mixed up, because the query ("assigned to me",...) doesn't work > properly if everything is assigned to either Bertrand or Reza despite > others (Eberhard, see .NET or Resources, W3C, etc. me) also working on it. > > Apache is a very wide ecosystem now. So the "greedy" fear of one API > overshadowing another seems a bit ridiculous and childish. Look at > * Shale > * Sling > * Struts > * Tapestry > * Wicket > * MyFaces > * ... > All of which active Apache Web Frameworks. You can do pretty much the same > thing with every one of them. Some may be quite old, but AFAIK none of > them (maybe Struts1, but even that is still used extensively around the > globe) are declared archived or discontinued so far. > > Speaking of Tapestry, this GitHub project is also approx. 2 years old, but > as other cases based on OpenDDR Simple API: > https://github.com/altocon/tapestry-devicedetection > The company stopped working and the contributor now seems to work at > Typesafe (in Germany) > As it is involved in the Java and JVM community at least on events like > JavaOne, etc. I may try to reach out to them, to see, if there was interest > to contribute it to DeviceMap. Given Tapestry is also an official project > (I met its founder once or twice, also did a large T5 project guess where, > at Telefonica O2) this could be a nice synergy. > Of course it could also be better placed in the Tapestry Community "Repo": > http://tapestry.apache.org/community.html#Community-Modules > > Cheers, > Werner > > > > On Wed, Jul 9, 2014 at 8:37 PM, Apache Jenkins Server < > [email protected]> wrote: > > See <https://builds.apache.org/job/devicemap-java6/42/changes> > > > > >
