We're not allowed to do just "branch something into an Apache project" that is an official standard defined by W3C, OASIS or whatever. Neither Apache nor Eclipse or similar Open Source bodies define standards themselves.
I am not sure, where the JAR came from that is dated December (if that's the one our "lib" folder currently includes) because that has only class files. I just downloaded the official JAR ( http://www.w3.org/TR/DDR-Simple-API/#sec-java-representation) once more and that in addition to classes every single .java file comes in the same JAR, so we always had both. The JAR provided is simply a combination of a binary JAR and source JAR Maven might usually produce separately. The problem of no official delivery to MavenCentral is solved thanks to the Maven AddJARS Plugin: https://code.google.com/p/addjars-maven-plugin/ IMHO nobody outside the official W3C WG could deploy that to MavenCentral or similar repositories in a legitimate way. However, we might be able to do the same "hack" SpringSource once did to thousands of even legitimate Maven provided JARs produducing OSGi enabled clones like com.springsource.org.apache.maven.ant-2.0.8.jar You see, the Maven group and artifact names were changed to "com.springsource.*" while the actual class structure remained the same. This was done to almost every relevant Apache project, too. It seems the company now called Pivotal shifted this effort into an Eclipse incubator project, so especially for frozen or archived Apache projects where the PMC no longer works this seems the only to use them via OSGi. A Maven artifact like "org.apache.devicemap:devicemap-simpleddr-w3c.jar" is automatically created and has been for almost a year now. Until it stopped after graduation Jenkins also built these, our deliverables just weren't shared on a Maven repo until recently. And that seems to have been a manual process, too. Similar to the SpringSource effort of OSGi-enabling Thousands of JARs from the most popular open source projects, I suggest we could also deliver the Maveninzed but otherwise untouched original JAR by W3C under a name like "org.apache.devicemap...w3c.jar" Werner On Sun, Jan 18, 2015 at 9:17 AM, Reza Naghibi < [email protected]> wrote: > 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 < > [email protected]> </div><div>Date:01/18/2015 12:39 AM (GMT+01:00) > </div><div>To: [email protected] </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 <[email protected]> > 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 <[email protected]> > 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 < > >> [email protected]> wrote: > >> > >>> Hi, > >>> > >>> On Fri, Jan 9, 2015 at 2:13 PM, Werner Keil <[email protected]> > >>> 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 > >>> > >> > >> > > >
