[CCC DEV] JNI - Native Calls to WinSparkle.dll

[cljacobsen at gmail.com]

Hi Dave,

Right, I've checked out your code poked at it a bit and here is what
you should do:

1) Probably change the package name from
org.transterpreter.jeditsparkleplugin.JEditSparklePlugin to something
like org.transterpreter.jeditwinsparkleplugin.JEditWinSparklePlugin
(note the addition of 'win'). When I originally wrote the mac updater
there was no WinSparkle (or it was new enough that it had not caught
my attention) so there seemed little point in specifying MacSparkle...
however since there are now two distinct Sparkle plugins, one for Mac
and one for Windows, it is probably good form not to use the same name
for the two different plugins.

2) I think you mentioned something about passing strings through the
JNI was hard... i can't remember exactly what you said and I'm too
lazy to find the email, but if it is hard, then I'd get rid of the
win_sparkle_set_appcast_url function and just hardcode the URL in the
native bit (for now).

3) If we are going to be passing arguments to the native methods, I'd
consider implementing the native stuff in C++ as this has a better way
of interfacing with JNI I believe (in terms of passing arguments).

4) In order to build the native header files from the Java class, you
will actually have to compile the Java file (using the ant script). To
do this you will have to make sure that build.properties is set
correctly so that jedit.jar can be found. Mine looks like this:
jedit.install.dir=C:\\kroc\\distribution\\windows\\build\\jedit\\jedit-program\\
which assumes that you have run ./build_occplug.sh from the
distribution/windows directory.
Once you have successfully built the Java code for the WinSparkle
plugin you will need to run javah. However, the build script puts the
object (.class) files in the build directory, so you have to set the
classpath appropriately:
javah -classpath build -jni -d native
org.transterpreter.jeditsparkleplugin.JEditSparklePlugin

Now you can start implementing the native bits. Have fun with that. :)

Matt and I are working on getting the perl and python bits of the
tools to work in Windows and once that is done we should be much
closer to being able to run a Windows package. Having the Windows
Spakle stuff is going to be invaluable at that point when we
repeatedly find that we've done stuff wrong and need to push updates
to users :)

Once we get closer to things working we'll also need to start talking
about the URL for the appcast. This will be in a similar location to
that of the Mac updater. The URL is in fact a small application which
collects statics on the ppl pining the appcast URL (it collects anon
usage info, processor, ram, and such). I'm not sure if we can do the
same for WinSparkle (yet).

Cheers,
  Christian

On 13 July 2010 06:49, Dave Gilmore <gilmorenator at gmail.com> wrote:
> On 9 July 2010 14:37, Matt Jadud <matt at jadud.com> wrote:
>> Aye. And, like Christian said, feel free to commit your stuffs
>> somewhere into the Windows build directory if you want us to look at
>> it. However, it might be simpler to... try and make it as simple as
>> possible. That would imply a very simple Ant script, very small Java
>> program, and to see if you can get the paths for JINI right.
>
> Hi Guys,
>
> So I've stripped everything right back to the bare bones and made it
> as simple as possible,
>
> I have followed the folder and package conventions as outlined earlier
> in this thread and as used by Christian,
>
> I now have something that builds using the very simple ant build
> script - so a step in the right direction,
>
> You can grab the source code from [1]
>
> I still have a (different) JNI issue though :-(
>
> When I run the javah -jni -classpath from the command prompt I get the
> message "No classes were specified on the command line. Try -help"
>
> I googled the problem and found i needed to use the fully qualified
> class name which I did
> i.e. org.transterpreter.jeditsparkleplugin.JEditSparklePlugin but that
> also returns the same message.
>
> If i attempt to run the command without the -classpath option I get a
> similar error:
> "javadoc: error - Class org.transterpreter. etc etc not found....No
> classes were specified on the command line"
>
> I've checked and they are there - I can see them and my eyes work perfectly,
>
> I'm not sure what's going on here - could be my inexperience or I've
> missed something mega obvious!
>
> Anyway I would like to get it resolved asap as once it is everything
> should work just nicely,
>
> Please let me know where I've went wrong or what I need to do to
> resolve the issue,
>
> Cheers,
>
> Dave
>
> [1]http://projects.cs.kent.ac.uk/projects/kroc/trac/browser/kroc/trunk/tools/winupdater
>