I understand they "usually are" but still Karaf distributes its documentation in various ways like http://karaf.apache.org/manual/latest/
and http://www.apache.org/dyn/closer.lua/karaf/documentation/4_x.html Which also includes a mirror of folders like http://apache.org/dist/karaf/documentation/4_x.html I don't care how exactly we call it, but something like the "documentation" folder where KARAF offers HTML or PDF files directly (not inside a ZIP) is also a requirement for DeviceMap. Reza chose the VM http://devicemap-vm.apache.org/data/ because he did not know better or wanted to have sole control over making it available, but the fact alone that HTTP and FTP servers are mirrored all over the world while the VM often breaks down and there is no mirror of it speaks for a different solution. DeviceMap Client (Java, C# or VB) cannot load data from a remote archive or JAR. The "JAR" option is only for a JAR deployed to the classpath. So in order to use data available online we should be able to put at least the latest version of the last release of the Data files to a working URL. Whether that's HTTP, FTP or both makes no difference, both should work. HTTPS would be an overkill since it's publicly available information. I'll rephrase the essence into a new thread. Werner On Tue, Sep 6, 2016 at 11:53 AM, Werner Keil <[email protected]> wrote: > ...Is there a reason why the XML files could not be put under something like > http://www.apache.org/dist/devicemap/data/1.0.4?... Apache release are usually tar or zip archives, including license, notice etc. If you can prepare such an archive for release we can vote on it and it then goes underhttps://dist.apache.org/repos/dist/release/devicemap/ as usual. -Bertrand Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | Eclipse UOMo Lead, Babel Language Champion | Apache Committer Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap | #DevOps | #EclipseUOMo Skype werner.keil | Google+ gplus.to/wernerkeil On Tue, Sep 6, 2016 at 11:53 AM, Werner Keil <[email protected]> wrote: > What about DeviceMap Data? > > Is there a reason why the XML files could not be put under something like > > http://www.apache.org/dist/devicemap/data/1.0.4? > > Similar to several other projects (like Karaf) > Allowing to replace that VM (which is not so reliable in any case, even for > active projects) > > We can do a release of W3C DDR without it, but replacing the > Classifier/Client with the VM location baked into it makes almost no sense > without an alternative. > > Werner > > > > On Mon, Sep 5, 2016 at 3:39 PM, Werner Keil <[email protected]> wrote: > >> Can't exactly remember if it made it to https://svn.apache.org/viewvc/ >> devicemap/trunk/contrib/openddr/java/, but I remember OpenDDR had a >> readme on how to manually install the W3C JAR via Maven install-local >> before building it. >> >> Guess all it takes is to reactivate some of those guidelines and >> procedures, then the "lib" folder and its content could be removed and it >> was OK to release it. >> >> On a side note, a once much bigger project OpenOffice I heard is close to >> being retired, too. http://openoffice.apache.org/ shows, it had the last >> release about a year ago, so it's not that unusual, and though OpenOffice >> graduated 2 years before DeviceMap, it may not be active that much >> longer...?;-| >> >> Werner >> >> >> On Mon, Sep 5, 2016 at 3:32 PM, Werner Keil <[email protected]> >> wrote: >> >>> Hi, >>> >>> I think that might work. The JAR (or WAR using it) will fail at runtime >>> until that external JAR is placed in the web-inf/lib folder, but given that >>> small inconvenience, I don't see why we could not release it without the >>> W3C JAR. >>> >>> Werner >>> >>> Hi, >>> >>> On Mon, Aug 22, 2016 at 2:08 PM, Werner Keil <[email protected]> wrote: >>> > ...The W3C DDR client is here >>> > https://svn.apache.org/viewvc/devicemap/trunk/clients/w3c-ddr/ ... >>> >>> As previously discussed, this cannot be released due to the >>> lib/w3c.jar, Apache releases cannot contain such binaries. >>> >>> Replacing that jar with a README indicating where people can get that >>> library code would be ok. >>> >>> -Bertrand >>> >>> >>> >> >
