Reza/all, See another complete rewrite of an existing Apache project and how they handled that in SVN: https://svn.apache.org/repos/asf/logging/log4j
The Log4J 2 project has its completely new separate folder. While on the "java" side in theory 2 independent Maven modules don't do harm to each other (same with the /examples module where both libraries/clients are used on top of the same data structure) there should be a plan and structure for data allowing e.g. patches to the 1.x data where necessary while evolving new 2.x data. I guess a separate structure either just for data, code or both is perfectly fine, but that doesn't mean deleting a working 1.x ready artifact, no other projects do that see Log4J. You keep picking on the mature and well demonstrated (with working examples) W3C DDR client, but what has been "dormant" since July are both the C# and VB client, which are unlikely to contain any of the updates or improvements to Java Client 1.1 or even 1.0.1. If any of these were to be considered "dormant", it's probalby the .NET projects. They released a 1.0 but at least the VB project contains weird folders like "My Project" and unless a Visual Studio Community Edition is sufficient, I admit it is not so easy to run them anyway unless you have a fully licenced Microsoft environment (I don't although I write PowerShell code at a current client) Werner On Fri, Jan 2, 2015 at 9:55 PM, Werner Keil <[email protected]> wrote: > Reza, > > You used the OpenDDR data pretty much as is. There is no "legacy", it is > the W3C compliant implementation that has always worked and produces more > precise results e.g. the real OS version. The approach is different. You'll > find especially some of the most prominent vendors like 52DegreesMobi and > others using a mix of some sort of "repository" and UA interpretation.. The > current classifier lacks the UA based correction all of these handle > whether they follow W3C DDR (like the biggest companies e.g. > DeviceAtlas,... do) or go a different path like WURFL. > > Some proposed "refactoring" or new structure would essentially move > towards "Apache WURFL" though I don't care about what they do now, but the > big difference with OpenDDR/DevicMap DDR is WURFL was never W3C compliant > either. Your client(s) including dClass or whatever the others are called > out there may use aspects of the W3C DDR structure but they neither abused > nor perverted them making it impossible to use proper W3C implementations > (both Open Source or commercial, see DeviceAtlas) with this data. Some > "here it is, compile it and do with it what you want" solution is neither > constructive nor useful to anybody. > > 2 perfectly working examples depend on the W3C DDR client and they work > with Java 8 which as of now seems problematic with the Classifier. > > What you tried to do for an extra pattern would have to look kind of like > this in BuilderDataSource: > <device id="SGP311"> > <list> > <value>SGP31\d</value> > </list> > </device> > > This works perfectly fine detecting the UA from that JIRA task regardless > of whether you enter > "Mozilla/5.0 (Linux; Android 4.3; SGP311 Build/10.4.B.0.577) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.102 Safari/537.36" > or > Mozilla/5.0 (Linux; Android 4.3; SGP312 Build/10.4.B.0.577) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.102 Safari/537.36 > > While it seems, Classifier only assumes BuilderDataSource <value> entries > as simple deviceIds, they are patterns of the model in the UA. > Like Android or other OS version, fixing the model based on the UA is the > only thing the builder does not do, but it was always meant to recognize > "close enough" patterns based on a Regular expression not just one > particular device ID. > > Code in a class like DDRLoader makes hard-wired assumptions, and is rather > monolithic, while the idea behind the W3C DDR Simple implementation is, > that a project where you'd enable OSGi or similar dynamics could even add > new builders at runtime or at least at design time in a separate file, not > one big monolithic class with Hundreds of if clauses. > > So from a design perspective, the W3C DDR implementation is better > structured and more maintainable with less "spaghetti code";-) > It certainly uses "Depencency Injection" in a W3C specific way on top of > service interfaces like Builder, Service, Property,... so it doesn't > require Spring, CDI or Guice, also because neither of these (except Spring > Framework, a DI solution largely based on XML, so you'd find a few common > ideas behind both;-) except early versions of Spring Framework were > available between 2004 and 2008. > > All major Apache projects have multiple releases in parallel. Tomcat 3 to > 8, see http://tomcat.apache.org/whichversion.html. > There are 3 parallel Tomcat versions actively developed. Neither of them > considers the other a disruption or competition. Each of them implements > different Specs within the Java EE umbrella. It's exactly the same with > W3C, and where a future branch of a project was to implement something > else, that is fair, but nobody just deletes all Tomcat versions prior to 8 > just for fun. And even the ones http://tomcat.apache.org/whichversion.html > calls "archived" were officially released. That's what the W3C Simple DDR > was ready for ever since. Having Data 1.0.1 available also on MavenCentral > was key, that makes it easier to build each dependent client out of the > box. That (and the glitch in the 1.0 data breaking the W3C client) is why I > did not trigger the release earlier. > > There is as little competition or threat by each of the libraries. Due to > its dynamic "service-loader" / DI mechanism just like Spring XML files a > large number of the XML files are important to the W3C DDR client and > changing a class name or adding references in one XML that don't exist in > another may cause errors up to preventing the JVM to start. > Just like Spring with malformed context XML files;-) > > Which is why changes that would break this DI mechanism are not feasable > on the W3C compliant 1.x branch of device-data. If a new branch deviates > from that based on redesigning the XML files, that is fine, but it is > something for 2.x And the W3C implementation may not rely on this structute > any more. Users will know and understand that. > > HTH, > Werner > > > On Fri, Jan 2, 2015 at 9:10 PM, Reza Naghibi < > [email protected]> wrote: > >> Werner, I understand. You are against this. However, you did not raise >> any noteworthy points as to why we need to keep the legacy client in SVN. >> All projects release new versions and deprecate old versions, why cant we? >> The client still exists and can be downloaded and maintained at its >> donation source [0]. Otherwise, all im doing is cleaning up the codebase >> and removing dead code. Nothing we have released depends on the legacy >> client. For the sake of moving forward and focusing on the future, im >> asking that we clean up the code base. The legacy client is simply too much >> of a distraction and is already disrupting our data release. >> >> [0] https://github.com/OpenDDRdotORG/OpenDDR-Java >> >> From: Werner Keil <[email protected]> >> To: [email protected]; Reza Naghibi <[email protected]> >> Sent: Friday, January 2, 2015 2:55 PM >> Subject: Re: Deleting the legacy ODDR client and related artifacts from >> SVN >> >> -1 >> >> As Bertrand and others suggested this is an alternate client perfectly >> legitimate and used by clients (your cDate implementation also used >> OpenDDR >> data first and now the ) among them some of the largest banks. >> >> You behave as if the DeviceMap project was your "property" not any better >> than the guys who took WURFL out of the Open Source community. >> >> Under no circumstances you must delete it. >> >> I don't expect other PMC members to second so you don't do any stupid >> thing. >> >> The W3C DDR implemementation works perfectly well, just because you don't >> understand it doesn't mean it doesn't work. >> >> If you did anything stupid to the W3C DDR implementation without a >> qualified majority (I just gave my veto) this violated W3C compatibility, >> hence on behalf of OpenDDR I could only withdraw/delete the entire >> contribution made by OpenDDR. It'll be removed and you'd have to start >> from >> zero with a "clean slate". >> >> DDR data in the current structure is MADE for the W3C DDR client. Abusing >> structures in ways you neither understand nor do they work in the >> "Classifier Draft" (hence the broken test or code) is damaging an >> detremental to the project, hence withdrawing all OpenDDR code and data >> would be the only answer to such abuse. >> >> Do you prefer that? >> >> >> >> >> On Fri, Jan 2, 2015 at 6:58 PM, Reza Naghibi >> <[email protected] >> > wrote: >> >> > Any objections to deleting the legacy ODDR java client and its related >> > artifacts from SVN? This is purely a code cleanup. Here are my thoughts >> on >> > this matter: >> > >> > -The legacy client was rewritten a year ago and it offers a huge set of >> > improvements. Its simpler, several orders of magnitude faster, more >> > predictable, and it moves all of the device logic from code to data. >> > Basically, its modern. One of the biggest changes is that the legacy >> ODDR >> > client loops thru every pattern looking for a match, one by one, using a >> > complicated set of heuristics specific to each class of user-agents. >> This >> > does not scale. The new client is able to check all patterns in parallel >> > using pure pattern matching. This scales extremely well. >> > >> > -The DDR data can no longer evolve to support the legacy client. While >> the >> > 1.0.x releases may work, once 2.0 is released, the legacy client will >> in no >> > way shape or form still work. >> > >> > -The legacy client is distraction. Its taking focus away from moving our >> > current objectives forward. This project, like all projects, must >> evolve. >> > This means rewriting clients, reformatting data, and basically throwing >> old >> > things away. This is a natural process in any software development >> project. >> > The same considerations must be given to old artifacts in this project. >> > This project must evolve. >> > >> > If there are no objections, I will be removing the legacy artifacts from >> > SVN in 5 days (120 hours). >> > >> >> >> >> > >
