Latest News

Syndicate content
GoFleet project
Updated: 37 weeks 2 days ago

Developing modules system

Mon, 06/20/2011 - 18:05

When GoFleet was released free, one of the main targets we really though it needed was a modularized system around a stable core. This way, developers who want to adapt GoFleet to their systems wouldn’t have big problems developing for GoFleet.

We started studying different module systems and popular frameworks to understand which one would be the best (as in easy, fast and developer-friendly). We had one advantage: it was a zero-start module system on a fully developed and used application. A whole refactorization. No legacy, no backwards compatibility. And we knew exactly what a developer would need (jobs, tabs and gui-style).

But Java is not module-friendly at all. You cannot simply do as in Drupal, drop a folder on your classpath and magically use it. Of course that Java developers know this and have had a hard time adding new features that can help modularizing apps. But sill, you cannot simply drop a jar on a library folder and double-click GoFleet script. Classpath hurts!

One of the projects we looked more closely was gvSIG. I didn’t quite like the way they solved the module problem, although I am closely waiting for the 2.0 version, where they add Maven to their development.

Yes, of course, Maven can be handy, but useless if you want to avoid packaging the whole project over and over again, every time you want to add or remove a module. And we all know that sometimes compilation isn’t as enviromental-free as we think want.

Finally we reached a solution. Still under heavy development and unstable, but a solution, made with interfaces and properties files. Yes, probably you will still have to recompile with maven, we still couldn’t avoid that without risking the stability of the core. But we have designed the module system so in the future, when Java advances on this field (or the GoFleet core allow it), we will be able to avoid this re-compilation without changing the system.

How will it work? Will continue on further posts But if you are really curious, you can take a look at my unstable branch. Exploded modules, I would say.

GoFleetLSServer

Sat, 06/11/2011 - 17:45

We have just started a new sub-project of GoFleet: the GoFleetLSServer. This server will be implementing the OpenLocationService standar so GoFleet can remotely ask for geographic computations like geocoding, routing, etc…. As it will be a standar web service, which can be used outside GoFleet main project, we thought that a separate project was needed.

Right now we have just a scratch of what GoFleetLSServer will be. Although we are looking for other libraries, as pgRouting have some unsolved bugs, this server will for now run over a PostGIS/PgRouting database. The first implementation (untested and buggy) is trying to work around some bugs on the Travelling Salesman Problem of the PgRouting library. Developers who want to implement further geo-functions are wellcome.

Right now the project will run on Java, because we want to reach as many environments as possible. Of course, heavy geo-calculations will be run on the database, we are not crazy yet!

Just moved to Github!

Tue, 06/07/2011 - 17:44

Just a short notice to tell you that we have moved from Gitorius to Github!

This decision was taken after considering that Github has more features and is more usable than Gitorius and the Issue tracker/forum we have been using until now. We hope that this will help watchers, users and developers be more in contact with GoFleet.

Also, you can now find us on twitter. If you don’t have a Github account to follow us, you can stay in close contact with the
development on twitter.

Version 0.0.1 Highly Unstable

Mon, 04/18/2011 - 11:55

We have released an unstable version (0.0.1) so you can test what is GoFleet (magic password:3emergya). The icons and images are  provisonal and so is the look and feel, but still, you can see a scratch of GoFleet’s functionalities.

This version is higly unstable on its APIs and its modules relationships, as we are still working on the modularization.

To create the database you have scripts you can run on a postgreSQL installation. This postgreSQL must have postGIS already installed. You can use any 8.x or 9.x postgreSQL installation. To run this scripts you will have to do something like:

psql -h db_server -U db_user -p db_port -f create_schema.sql

psql -h db_server -U db_user -p db_port -f initial_data.sql

To run the client, you have to go to the client folder and execute

java -jar client-0.0.1.jar

It will try to connect to a localhost postgreSQL. If your postgreSQL is somewhere else, you have to edit the jdbc.properties file to locate it.