I made some checks and still cannot figure out how provisioning
net.java.sip.communicator.UPDATE_LINK (used as the PROP_UPDATE_LINK
) would work for both windows and macosx.
In windows updater plugin, the link is first attempted to be obtained
from the provisioned properties first. If it is not defined there, it
is gathered from of the update-location.properties file. In
SparkleActivator, however, this link is only attempted to be fetched
from the ConfigurationService. It is then forwarded as a parameter of
the native call API to the Sparkle framework. This downloadLink is not
manipulated anywhere in the code before being passed to sparkle. For me
it only works if the link directly points to the full path of the
updates file, like so:
http://hostname.com/projectname/macosx/update.xml. Specifying only the
the root folder http://hostname.com/projectname/ breaks the updates for
both windows and macosx.
2012/11/21 Emil Ivov <firstname.lastname@example.org <mailto:email@example.com>>
On 21.11.12, 16:14, firstname.lastname@example.org > <mailto:email@example.com> wrote:
> Hi Emil,
> do you mean the following structure:
> In this case I do not get how would an update work, if download_link
> property from the versionupdate.properties file points to a specific
> file to be dowloaded, like so:
The Jitsi updater on an x64 platform would just get the above link and
replace the x86 with x64, then try to get the binary at the newly
> As far as I can determine from the source code, it is crucial to have
> update update_link property to point to different
> versionupdate.properties files, depending on the architecture version.
> This is not a problem, if every installation of Jitsi uses a
> pre-determined update-location.properties file, which is already
> configured depending on the installed version. We, however, want to be
> able to set that value dynamically, based on a specific partner
> configuration by the means of provisioning utilities
I am not sure I understand what your problem is. The update link just
points to the update root location. We append the OS to that location.
The link that's in versionupdate.properties then points to the actual 32
bit binary on windows and we simply expect to find the 64bit location
next to it.
> So if my line of thought is
> correct and our goals got a bit more clear I will rephrase the
> Is JVM architecture version seen from Jitsi (32bit/64 bit from
> System.getProperty("os.arch") ) always equal to the architecture
> of installed Jitsi or can there be some corner cases?
Jitsi will always update itself to the same arch that it is currently
In case you are running a 32 bit installation on a 64 bit OS, it may
notify you that a better option exists but that would only be during the
> Just as a side note: the same property is used in the Update
> Windows and in the Sparkle framework for MacOS, which renders it
> much useless if both OSes have to be supported (MacOS requires
> updates.xml file rather than versionupdate.properties). We have
> additional net.java.sip.communicator.MAC_UPDATE_LINK to circumvent
Not following. Why would it be useless? That's how we are currently
using it. The UPDATE_LINK just points to the root, you then simply need
to create "windows" and "macosx" directories where Jitsi will look for
more info depending on the system it is running on.
This way a provisioning server doesn't have to care about the OS and
arch of a client when feeding them the update URL.
> 2012/11/21 Emil Ivov <firstname.lastname@example.org <mailto:email@example.com>
> Hey Alexander,
> You don't need that. Just place the x86 link in the version update
> properties and make sure that both your x64 and x86 versions
are at the
> same location.
> Jitsi will do the necessary conversions automatically.
> On 20.11.12, 18:04, firstname.lastname@example.org > <mailto:email@example.com> > > <mailto:firstname.lastname@example.org > <mailto:email@example.com>> wrote:
> > Hi all,
> > we need to be able to provision the link to the
> > instead of having it hardcoded in the
> > The question is: how is it possible to find out which
version of Jitsi
> > is currently running (x64 or x32) in order to correctly
> > @archValue part of the link in Java in a similar way it is
done in ant
> > (using pre-set windows.arch.path). Would it be OK to completely
> rely on
> > the JVM that is being used and henceforth on
> > the System.getProperty("sun.arch.data.model") property?
> > Regards,
> > Alexander Fedulov