You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@devicemap.apache.org by Werner Keil <we...@gmail.com> on 2016/09/05 13:32:56 UTC
Re: [PROPOSE] Release DeviceMap-data and other dependencies (with
connection URL etc. fixed)
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 <we...@gmail.com> 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
Re: [PROPOSE] Release DeviceMap-data and other dependencies (with
connection URL etc. fixed)
Posted by Werner Keil <we...@gmail.com>.
Radu,
Unfortunately you did not answer the question before, but the folder at
Sling (I know the Update site may consist of several other signed JARs)
brings us in the right direction.
Following a release of say devicemap-data-1.0.4 into a signed ZIP file
and/or Maven repository, could we also put the XML files into a proper form
(of a W3C Device Repository, somewhat similar to what you have in the P2
repo) so all clients that support remote URL loading may use that?
It should not be a problem to sign each XML file individually like it's
done with Maven POMs (also XML files) but again, the signed archive of a
new version as well as the Maven repository are worthless, especially for
the .NET clients, those don't know JAR files or Maven. And since the Maven
repo also contains signed JAR files, this repo is no good for .NET, only a
local or remote folder/URL.
Would that work after a release?
Only then such release would be "productive" and useful to a final release
of clients that can be releases (e.g. the Java client) otherwise we would
all waste our time because the clients cannot use the archives.
Is there a way to do that after a release?
Thanks,
Werner
On Wed, Sep 7, 2016 Radu wrote:
Werner,
Why is it so hard to understand that a release, even for data files, needs
to follow a process? Why do we always need to have a never-ending list of
messages (10 from you alone on this thread) for simple things? Why do we
always need to point fingers at other projects when the release process is
the same for every ASF project?
Instead of writing 10 messages you could have spent that time more
productively by just preparing the signed release archive...
Just a FYI: the Sling example you're pointing at with a not-working URL is
actually the expansion of a *signed release archive*
-http://apache.org/dist/sling/org.apache.sling.ide.p2update-1.1.0.zip
- and
is there for convenience.
Regards,
Radu
Re: [PROPOSE] Release DeviceMap-data and other dependencies (with
connection URL etc. fixed)
Posted by Werner Keil <we...@gmail.com>.
Or take Apache Brooklyn's Blueprint catalog:
http://brooklyn.apache.org/learnmore/catalog/catalog-item.html#!entities/org.apache.brooklyn.entity.messaging.activemq.ActiveMQBroker
It's also clearly "code", but made available via the website.
On Wed, Sep 7, 2016 at 5:41 PM, Werner Keil <we...@gmail.com> wrote:
> Similar to e.g. Tamaya, Karaf has everything under a single codebase.
> https://github.com/apache/karaf/tree/master/manual is what gets deployed
> under http://karaf.apache.org/manual/
> http://karaf.apache.org/manual/latest/
> vs.
> http://karaf.apache.org/manual/latest-3.0.x/
> shows, there's also versioning of these artifacts.
>
> So since everything is "code" also in this case (sources like .asciidoc
> get interpreted into .html or other formats) then why can't similar sources
> also be made available to the DeviceMap site?
> It should not matter if we use SVN or Git either.
>
> Code in both SVN or Git repositories are useless to the URL loaders and
> even
> https://svn.apache.org/viewvc/devicemap/trunk/data/1.0/
> device-data/src/main/resources/devicedata/
> won't work, because the SVN browser turns it into a special form like
> https://svn.apache.org/viewvc/devicemap/trunk/data/1.0/
> device-data/src/main/resources/devicedata/BrowserDataSource.xml?
> revision=1717108&view=markup
> And the URL loader can't handle these dynamic URLs either.
>
> Eberhard way back tried to use the sources from SVN and it failed, only
> afer I pointed it to the plain URLs on the VM the .NET clients work since
> then.
>
> Instead of Karaf, let's look at http://apache.org/dist/sling/eclipse/
> It contains 1.1.0/ <http://apache.org/dist/sling/eclipse/1.1.0/> and
> other folders for releases of this artifact.
>
> Not signed ZIP archives like http://apache.org/dist/sling/
> apache-sling-eclipse-update-site-1.1.0.zip etc.
> Users would have to download first and use as local update sites.
>
> So if this alternate (more convenient for some) distribution of some parts
> of Sling works, why should it not work for DeviceMap?
>
> Are some projects "more equal"?;-|
>
> Werner
>
>
> On Wed, Sep 7, 2016 at 5:02 PM, Werner Keil <we...@gmail.com> wrote:
>
>> Then why can Karaf publish something DeviceMap can't ?
>>
>> Is their "tutorial/latest" simply part of the "site" which does not fall
>> under the release constraints?
>>
>> Again, as all the clients stand, especially the .NET ones (but without
>> significant improvement to add a "Remote JAR" option, also the Java Client)
>> a ZIP or JAR file on a remote server is worthless to all DeviceMap clients.
>>
>> If it's not possible to make the "data" folder and URL available in a
>> proper way (http://devicemap.apache.org/ will likely continue to exist,
>> only with the "retired" warning if it gets archived, so
>> http://devicemap.apache.org/data hypothetically also would, but nobody
>> is even able to start or maintain the VM after the PMC stops) then I don't
>> think any further release is worth the effort.
>>
>> Werner
>>
>> Hi,
>>
>> On Wed, Sep 7, 2016 at 1:42 PM, Werner Keil <we...@gmail.com> wrote:
>> > ...Can we turn
>> > http://devicemap-vm.apache.org/data/latest/
>> > into
>> > http://devicemap.apache.org/data/latest/ ...
>>
>> No, because that data must be published via the Apache release process
>> as per http://www.apache.org/dev/release-publishing and then
>> distributed at least viahttps://dist.apache.org/repos/dist/release/devicemap/ and possibly
>> other common channels.
>>
>> Once again, for this to happen you just need to create an archive of
>> what needs to be released, sign it and make it available so that this
>> PMC can vote on it - while it still exists.
>>
>> -Bertrand
>>
>>
>>
>
Re: [PROPOSE] Release DeviceMap-data and other dependencies (with
connection URL etc. fixed)
Posted by Radu Cotescu <ra...@apache.org>.
Werner,
Why is it so hard to understand that a release, even for data files, needs
to follow a process? Why do we always need to have a never-ending list of
messages (10 from you alone on this thread) for simple things? Why do we
always need to point fingers at other projects when the release process is
the same for every ASF project?
Instead of writing 10 messages you could have spent that time more
productively by just preparing the signed release archive...
Just a FYI: the Sling example you're pointing at with a not-working URL is
actually the expansion of a *signed release archive* -
http://apache.org/dist/sling/org.apache.sling.ide.p2update-1.1.0.zip - and
is there for convenience.
Regards,
Radu
Re: [PROPOSE] Release DeviceMap-data and other dependencies (with
connection URL etc. fixed)
Posted by Werner Keil <we...@gmail.com>.
Similar to e.g. Tamaya, Karaf has everything under a single codebase.
https://github.com/apache/karaf/tree/master/manual is what gets deployed
under http://karaf.apache.org/manual/
http://karaf.apache.org/manual/latest/
vs.
http://karaf.apache.org/manual/latest-3.0.x/
shows, there's also versioning of these artifacts.
So since everything is "code" also in this case (sources like .asciidoc get
interpreted into .html or other formats) then why can't similar sources
also be made available to the DeviceMap site?
It should not matter if we use SVN or Git either.
Code in both SVN or Git repositories are useless to the URL loaders and even
https://svn.apache.org/viewvc/devicemap/trunk/data/1.0/device-data/src/main/resources/devicedata/
won't work, because the SVN browser turns it into a special form like
https://svn.apache.org/viewvc/devicemap/trunk/data/1.0/device-data/src/main/resources/devicedata/BrowserDataSource.xml?revision=1717108&view=markup
And the URL loader can't handle these dynamic URLs either.
Eberhard way back tried to use the sources from SVN and it failed, only
afer I pointed it to the plain URLs on the VM the .NET clients work since
then.
Instead of Karaf, let's look at http://apache.org/dist/sling/eclipse/
It contains 1.1.0/ <http://apache.org/dist/sling/eclipse/1.1.0/> and other
folders for releases of this artifact.
Not signed ZIP archives like
http://apache.org/dist/sling/apache-sling-eclipse-update-site-1.1.0.zip etc.
Users would have to download first and use as local update sites.
So if this alternate (more convenient for some) distribution of some parts
of Sling works, why should it not work for DeviceMap?
Are some projects "more equal"?;-|
Werner
On Wed, Sep 7, 2016 at 5:02 PM, Werner Keil <we...@gmail.com> wrote:
> Then why can Karaf publish something DeviceMap can't ?
>
> Is their "tutorial/latest" simply part of the "site" which does not fall
> under the release constraints?
>
> Again, as all the clients stand, especially the .NET ones (but without
> significant improvement to add a "Remote JAR" option, also the Java Client)
> a ZIP or JAR file on a remote server is worthless to all DeviceMap clients.
>
> If it's not possible to make the "data" folder and URL available in a
> proper way (http://devicemap.apache.org/ will likely continue to exist,
> only with the "retired" warning if it gets archived, so
> http://devicemap.apache.org/data hypothetically also would, but nobody is
> even able to start or maintain the VM after the PMC stops) then I don't
> think any further release is worth the effort.
>
> Werner
>
> Hi,
>
> On Wed, Sep 7, 2016 at 1:42 PM, Werner Keil <we...@gmail.com> wrote:
> > ...Can we turn
> > http://devicemap-vm.apache.org/data/latest/
> > into
> > http://devicemap.apache.org/data/latest/ ...
>
> No, because that data must be published via the Apache release process
> as per http://www.apache.org/dev/release-publishing and then
> distributed at least viahttps://dist.apache.org/repos/dist/release/devicemap/ and possibly
> other common channels.
>
> Once again, for this to happen you just need to create an archive of
> what needs to be released, sign it and make it available so that this
> PMC can vote on it - while it still exists.
>
> -Bertrand
>
>
>
Re: [PROPOSE] Release DeviceMap-data and other dependencies (with
connection URL etc. fixed)
Posted by Werner Keil <we...@gmail.com>.
Then why can Karaf publish something DeviceMap can't ?
Is their "tutorial/latest" simply part of the "site" which does not fall
under the release constraints?
Again, as all the clients stand, especially the .NET ones (but without
significant improvement to add a "Remote JAR" option, also the Java Client)
a ZIP or JAR file on a remote server is worthless to all DeviceMap clients.
If it's not possible to make the "data" folder and URL available in a
proper way (http://devicemap.apache.org/ will likely continue to exist,
only with the "retired" warning if it gets archived, so
http://devicemap.apache.org/data hypothetically also would, but nobody is
even able to start or maintain the VM after the PMC stops) then I don't
think any further release is worth the effort.
Werner
Hi,
On Wed, Sep 7, 2016 at 1:42 PM, Werner Keil <we...@gmail.com> wrote:
> ...Can we turn
> http://devicemap-vm.apache.org/data/latest/
> into
> http://devicemap.apache.org/data/latest/ ...
No, because that data must be published via the Apache release process
as per http://www.apache.org/dev/release-publishing and then
distributed at least
viahttps://dist.apache.org/repos/dist/release/devicemap/ and possibly
other common channels.
Once again, for this to happen you just need to create an archive of
what needs to be released, sign it and make it available so that this
PMC can vote on it - while it still exists.
-Bertrand
Re: [PROPOSE] Release DeviceMap-data and other dependencies (with
connection URL etc. fixed)
Posted by Werner Keil <we...@gmail.com>.
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 <we...@gmail.com> 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 <we...@gmail.com> 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 <we...@gmail.com> 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 <we...@gmail.com>
>> 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 <we...@gmail.com> 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
>>>
>>>
>>>
>>
>
Re: [PROPOSE] Release DeviceMap-data and other dependencies (with
connection URL etc. fixed)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Sep 6, 2016 at 11:53 AM, Werner Keil <we...@gmail.com> 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 under
https://dist.apache.org/repos/dist/release/devicemap/ as usual.
-Bertrand
Re: [PROPOSE] Release DeviceMap-data and other dependencies (with
connection URL etc. fixed)
Posted by Werner Keil <we...@gmail.com>.
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 <we...@gmail.com> 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 <we...@gmail.com> 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 <we...@gmail.com> 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
>>
>>
>>
>
Re: [PROPOSE] Release DeviceMap-data and other dependencies (with
connection URL etc. fixed)
Posted by Werner Keil <we...@gmail.com>.
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 <we...@gmail.com> 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 <we...@gmail.com> 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
>
>
>