Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I've been trying to compile FullSync myself, so I might contribute some code to this project. Yet, so far I've stranded on running FullSync.
I've got quite some java experience, but have never used eclipes before, so I tried compiling the code manually first. This worked, but then running net.sourceforge.fullsync.Main gave absolutely no output whatsoever (After I created logs/stderr.txt to suppress an error).
Okay, I just tried again, it seems that adding a "-h" option improves the situation. I know get a nice help text. Apparently I found the cli version (which is weird, considering there is a second Main class in the cli package).
Anyway, I have been trying to compile the ui, which worked. Running net.sourceforge.fullsync.ui.SplashScreen then didn't work, giving an error:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt-win32-3063 in java.library.path
I'm not sure why this is trying to load win32 swt libraries, since I am on linux/amd64...
Thinking that this might be caused because there is specific eclipse code, I tried compiling through eclipse. After some non-intuitive battling with eclipse I managed to open the project. It succesfully built (but I had to remove the external builder from the project, since I don't have metrics installed. Is this an error?), but when running, I observed exactly the same behaviour as with the command line java tools.
Any hints on the swt error?
Okay, I've got it solved. The first problem was swt.jar in the CVS repos: It contains win32 swt. Moving it out of the way and adding debian's swt.jar into the classpath brought me a bit further.
The error changed from not being able to load swt-win32-something to swt-pi-gtk-something. A quick google showed that this is because the swt-jni .so files are not in the library path. I solved that by putting /usr/lib/jni in LD_LIBRARY_PATH (putting it in /etc/ld.so.conf didn't work for some reason...).
So, now I was able to run SplashScreen: I got a splashscreen! Nothing more. Running out of main methods to run, I looked at the helptext of fullsync.main and it implies it should start the GUI automatically, which it didn't.
Looking at fullsync.Main.main() shows that all the GUI code has been commented in the latest CVS version, so that is my last problem. I'll try an earlier version instead and probably write some stuff about this all on the wiki.
Okay, looking better at the main routine shows that the code that was commented isn't GUI code and it has been commented in the last couple of releases too. So, the problem seems to lie elsewhere. The main routine forwards the commandline to a class in the cli package, but there the GUI is apparently not loaded. I'll see why that is when I have some more time.