Bertrand/all, As mentioned, to freeze a final usable state of DeviceMap before it would be safe to retire, can we have a version of DeviceMap Data (1.0.3 or 1.0.4 if it can be released, too in its current trunk state) under http://www.apache.org/dist/devicemap/ in a sub-folder (like "data"), too?
Your project Sling has a folder with XML files (I care very little about their exact purpose, just the existence) http://www.apache.org/dist/sling/eclipse/ And so does e.g. Karaf under http://www.apache.org/dist/karaf/documentation/ With files that are not inside TAR, ZIP or similar archives (in most cases they are not even signed with ASC, MD5 or similar, but that would not be a problem to do for DeviceMap Data) Most attic projects remain their http://www.apache.org/dist locations, so that would allow clients to rely on a place that does not go away. With the VM having gone offline several times, I would not even want to see that as the download URL even if it was possible. Keeping a static copy of the project page with the usual "retired" banner and the most recent download files seems OK. It would not change anything for people downloading it from Maven. As the Java client should also go to the Maven repo once more, so could do the data files, but ideally they should also go to a subfolder of dist/devicemap. Does that sound doable and reasonable to everyone? Werner On Fri, Aug 19, 2016 at 3:43 PM, Werner Keil <werner.k...@gmail.com> wrote: > Hi, > > Thanks for the clarification. > > I'm not sure, if that can be done in such a short time. Even Anatole at > Tamaya has not used certain Maven release plugins or processes before. I > can't remember if Reza ever did or also went a more manual, time-intensive > way when doing the occasional releases of DeviceMap data or classifier. > > The classifier similar to both .NET clients (there it's much easier > because .NET has a built-in configuration API and a properties like file > App.config even in the binary distro) has this default URL built in: > "http://devicemap-vm.apache.org/data/latest";; > > Even if you ignore the snapshot one (the latest clients will simply fail > because it doesn't exist any more) I assume the VM will be destroyed upon > archivation of the project. While e.g. > http://lenya.apache.org/ > > suggest, the main project page with a banner saying "it's archived" would > remain for every top level project even the archived ones. > > URL loader only works for "exploded" JARs, so it won't work for a remote > JAR on a Maven repository. > Adding that especially to the .NET clients IMHO is a too big task for an > "emergency release". > > Are there options to publish at least the latest "exploded" data folder > somewhere in a safe and compliant way? > That's what the URL in all these cases requires if you don't override it > (for .NET I think there is only the default, one has to tweak the config > file before running it, but that file is in the Console, not Client, so the > .NET ones are far better written than what Reza did with Java I'm afraid;-| > > Werner > > > On Fri, Aug 19, 2016 wrote: > > Hi, > > On Fri, Aug 19, 2016 at 12:16 PM, Werner Keil <werner.k...@gmail.com> wrote: > > ...Not sure, if you resigned effective as of today, or plan to do so in the > > very near future?... > > The latter, I was planning to send my effective resignation on Monday the > 22nd. > > > ...If a final release of Java and .NET clients taking device data also from > > a > > remote maven repository could be done,... > > If you want to prepare such a release in the next few days we still > have 3 PMC members to vote on it. > > -Bertrand > > >
