[Linux Lobby] AFLobby Beta 3.9.7

AF · Post by AF » 19 Jul 2007, 01:23

Also when you post long barrages of text blocks, the more text, the less intelligible the text becomes. Especially when the text is wider than the post and wraps around to the next line, that pretty laid out stacktrace becomes garbled ancient greek.

Please move it to a pastebin.

YokoZar · Post by **YokoZar** » 19 Jul 2007, 01:30

AF wrote:Also when you post long barrages of text blocks, the more text, the less intelligible the text becomes. Especially when the text is wider than the post and wraps around to the next line, that pretty laid out stacktrace becomes garbled ancient greek.

Please move it to a pastebin.

http://pastebin.com/f3e894568

Right. Sorry about that. There are mechanisms for horizontal scroll bars for codeblocks in PHPBB too - that's sort of the point of the code tag, that it won't break lines for you.

YokoZar · Post by **YokoZar** » 19 Jul 2007, 01:32

At any rate, if this lobby is going to become a part of a package, it would be needed to have it compiling via the command line somehow, rather than opening it with netbeans. Is there any easy way to do this?

AF · Post by AF » 19 Jul 2007, 01:36

Not really, but why?

All you need is a nice pretty JAR archive, especially since that archive will be exactly the same regardless of where the package is created, and those places it would be different are places it wont work in, namely a JRE not made by SUN and not v1.6xxx.

And since everything in AFLobby is crossplatform or takes platform into consideration, theres no need for recompiling, ever.

Agon · Post by **Agon** » 19 Jul 2007, 13:57

What about ant or make?

imbaczek · Post by **imbaczek** » 19 Jul 2007, 15:33

ant should do the trick. if netbeans can't export a project to an ant file, it sucks even more than I thought.

AF · Post by AF » 19 Jul 2007, 16:47

I'm at a loss to explain why anyone would need to build the unmodified standard release source.

Its like writting a script to draw a 2x2 red square on a 32x32 bitmap, instead of drawing it on the bitmap then bundling the bitmap with the package.

If you put AFLobby releases inside packages as source to be built on the end users system then you're taking a very simple procedure and introducing a mountain of potential problems and issues even though the end result is always the same. There's just no point whatsoever. Its unnecesary work.

A JAR package is not system specific. 1 package will run under ubuntu/windows/solaris/*insert arbitrary Operating system here*

An executable JAR package is all the source files compiled into .class files and then put into a zipa rchive with a manifest textfile giving details about which file is to be started first, and then renamed from .zip to .jar. There's no x86 code in there, there's no PPC code, no IL .Net/mono assemblies, no magical java assemblies in native code, its all crossplatform.

Summary

THERES NO POINT!!!!!! JUST INCLUDE THE JAR PACKAGE BECAUSE THATS WHAT YOU'RE GOING TO GET ANYWAY, INTRODUCING A BUILDING PROCESS WILL JUST ADD MORE UNNECESARY DEPENDENCIES, AND POTENTIAL BUGS

imbaczek · Post by **imbaczek** » 19 Jul 2007, 19:27

there's a point. imagine that your code could be built on a system where there's no netbeans (and no way to run it) - i.e., a buildbot machine that checks out aflobby's source upon any modification and packages it, conveniently saving you the boring work of uploading your own jars for every single nightly build.

AF · Post by AF » 19 Jul 2007, 21:28

Yes but thats not the same as building the jar then packaging it.

I use netbeans.

I only know howto do javac via command line, I've never created a full java JAR package via command line, or compiled 30/40 files at once. Knowing how good netbeans is, it does use Ant, but I dont know how, and its obvious it would have a way of doing it via command line because Sun made Netbeans.

But right now I dont see why you'd want it for a standard release. Packaging java source in a dev or rpm package to be compiled on the target machine is a pointless waste of effort.

YokoZar · Post by **YokoZar** » 20 Jul 2007, 00:25

AF wrote:Yes but thats not the same as building the jar then packaging it.

It should produce the same result, otherwise there would be a bug in the build process.

My goal here is to create an Ubuntu .deb package that can eventually be included in Ubuntu universe, and for that we'll need a source package that can be built automatically by a build machine using pbuilder.

I use netbeans.

I only know howto do javac via command line, I've never created a full java JAR package via command line, or compiled 30/40 files at once. Knowing how good netbeans is, it does use Ant, but I dont know how, and its obvious it would have a way of doing it via command line because Sun made Netbeans.

That's no problem, I don't mean to give you extra work if you don't see the value in it. I'll try and figure out netbeans myself, especially since I'm quite eager to get your lobby out to Linux users.

But right now I dont see why you'd want it for a standard release. Packaging java source in a dev or rpm package to be compiled on the target machine is a pointless waste of effort.

The end user isn't compiling it in any case - they're downloading the binary package. That binary package gets built from a source package, by a build machine like imbaczek mentioned.

You can't avoid having a source package - it contains all the control information for building the binary package, like dependencies and such.

It's actually easier in the long run to keep source code (and build instructions) in the source package than to build the source separately, put the binary into the source package, and then write a script from scratch to "build" the binary package from the binary data. That way, when a source code update is made, you just point the package to the new source rather than rewrite the build instructions to handle the new (and different) binary data.

Regardless, if the goal is to get the package out to Ubuntu users, and we want it in an Ubuntu repository, we're going to need to provide the complete source to the user anyway, and that means the source to the jar file. Putting it into the source package is simply the most elegant way of doing that, even if the only people ever downloading the source package are you, me, and the build machine.

edit: There's another advantage to building this way: the package building program can determine the shared library dependencies automagically from what it linked with while it built. This isn't so much of an issue for Java, but for other things included with a package it results in correct dependencies, every time.

fastfox · Post by **fastfox** » 20 Jul 2007, 00:36

I cannot check right now (my ubuntu is damaged

), but I remember netbeans using ant to build the jar file/package. You just need to find the right XML file and type ant thexmlfile.xml.
Netbeans makes these files by default.

AF · Post by AF » 20 Jul 2007, 05:43

There does appear to be a build.xml

However if you want to set up an automated buildbot style compilation procedure then you'll have to do it. I'm already overloaded with things as it is and I'd rather have other people do as many little things as possible to help spread the load.

Having said that the translation process will begin with RC2. I've already translated half of AFLobby into french, for example:

BrowserLauncher.Could_not_find_web_browser=N'a pas pu trouver le web browser
BrowserLauncher.Error_attempting_to_launch_web_browser=Erreur essayant de lancer le web browser
CAgree.Agreement=Accord
CAgree.I_Disagree/Disconnect=Je suis en d├â┬®saccord/d├â┬®branchement
CAgree.I_Agree=Je conviens
CBattleTableModel.Description=Description
CBattleTableModel.Status=Statut
CBattleTableModel.Map=Carte
CBattleTableModel.Mod=Mod
CBattleTableModel.Host=Centre serveur
CBattleTableModel.Players=joueurs

Taken from the french section of the languages_fr_FR.properties file.

A /ring command has been added, and support for being ringed added. I need a nice sound for ringing though (nicer than tasclient, good quality, possibly a single bell or gong with a lot of oomph, or a big explosion)

AF · Post by AF » 20 Jul 2007, 19:06

AFLobby is now in svn /trunk/AFLobby/

If you want starting boxes you can go get the source there and compile it.

fastfox · Post by **fastfox** » 22 Jul 2007, 22:38

Translated a big part into Portuguese!
How can I send you the file?

EDIT: get the file here http://rapidshare.com/files/44445291/la ... rties.html

Post by **Auswaschbar** » 22 Jul 2007, 23:01

I get the following error when compiling AFLobby:
http://pastebin.ca/630017

PS: I have dev-java/sun-jdk-1.6.0.02 installed

AF · Post by AF » 23 Jul 2007, 04:11

GroupLayout must be a Netbeans class.

And a diff would do just fin for extra translations, just remember not all of AFLobby has translation support atm, channels, pm windows, and the main view arent translatable yet.

However rapidshare is a terrible way to submit plaintext, for one it totally messes up the syntax by getting rid of all new lines making the file useless. Zip it up/rar it next time if you use a filesharing website.

edit:: nm, looking at the pages source fixed the newline issue, it seems to check out fine, Ill commit it to svn now, thx.

AF · Post by AF » 23 Jul 2007, 04:24

I've committed the portuguese translations and added a few changes that might improve your compile error issue auswaschbar

Post by **Auswaschbar** » 23 Jul 2007, 11:55

Your patch didnt resolve the errors. Now i did the following

1. emerged swing-layout
2. extracted the content of swing-layout-src.zip to AFLobby/src/aflobby (it contained some ./org/jdesktop/layout/*****.java files)

Now compiling works

edit:
it throws an exception:
http://pastebin.ca/630585

AF · Post by AF » 23 Jul 2007, 17:54

Please read devreadme.txt you have yet to fullfill all the required dependencies, namely the Substance looknfeel library.

In the meantiem I'd like it if you updated your svn copy and removed the desktop layout files from the swing library extensions package so i can contineu of switch class to use standard java 6 code.

Also, your use of the library sint quite right, they should be extracted into /src/ nto /src/aflobby because now

org.jdesktop.layout.GroupLayout

has become

AFLobby.org.jdesktop.layout.GroupLayout

The repercussions of which I do not wish to discover. So I'd correct thsi oversight. The swing layout extensions library may still be needed though for java 1.5 compatability, but I doubt that really matters.

I'd also suggest that instead you bundle a copy of the layout extension libraries that come with ym AFLobby releases and put them in a library subfolder like netbeans does in my packages and add that folder and those files to the classpath. The layout extension libraries are an external dependency and their source shouldnt be mixed with that of AFLobby. The same with substance.jar

Post by **Auswaschbar** » 23 Jul 2007, 19:54

In the meantiem I'd like it if you updated your svn copy and removed the desktop layout files from the swing library extensions package so i can contineu of switch class to use standard java 6 code.

I removed the files and made > ant clean && ant, here are the new errors http://pastebin.ca/631055

I'd also suggest that instead you bundle a copy of the layout extension libraries that come with ym AFLobby releases and put them in a library subfolder like netbeans does in my packages and add that folder and those files to the classpath. The layout extension libraries are an external dependency and their source shouldnt be mixed with that of AFLobby. The same with substance.jar

I have no clue what you want me to do

Spring RTS Engine

[Linux Lobby] AFLobby Beta 3.9.7