gvSIG blog

Hi everyone,
Here it comes a new small article about development with gvSIG Desktop.

In the last months, I´ve been asked many times about where are the gvSIG´s sources.
The quick answer would be::

http://devel.gvsig.org/svn/gvsig-desktop/

But in general, this is not enough.

The general advise which I give always is that do not recompile gvSIG Desktop. There is not need for creating your own plugins.

You should work against some binaries of gvSIG and develop your plugins without compiling all gvSIG, a really hard task. For your information, compile all gvSIG and create a distribution takes 10 hours more or less, without any problem. The process involves compile the gvSIG core along 60 more projects delivered over 40 different repositories, to finish creating a distribution with the core plus all the plugins of the distribution.

This makes that in addition to know about your problem, you must have the enough knowledge to compile and solve all the problems which can appear when setting up all the plugins of the distribution.

And not only that… if you modify the sources, compile them and share over your users, and not reversing these changes to the project, you will “anchor” those users to that gvSIG version. If they try to update it to access to fixings or improvements in previous versions, they will lose your changes. You will force them to choose between your customization or the improvements of the new gvSIG versions. And to each version, you will have to carry your changes. Every time that a new version had created, you will have to take your changes and put them again in your fork.

There are may of them that think ok,….why not?

In my personal opinion, in the medium-term this is not usually good for the ones who makes this practice or for the users. Sooner or later, the users will be disappointed with this software, requiring efforts to keep it updated. Efforts which are going over the customization, due to you will be loading your development with the maintenance of the one gvSIG distribution and not the concrete solution needed for your users.

To avoid this, in gvSIG we have being made some effort for modulating it, and introducing the “extension points” needed for not having to modify “core” and you will be able to do whatever you need from your plugins. The idea would be to have a standard distribution of gvSIG Desktop installed, and over it deploy your plugins with the intention of creating your own distribution from the standard one and your plugins (there are already some tools for creating customised distributions of gvSIG, you can read about it in Create your new plugin.

And if there is something that you don´t know to do from your plugin and believe that you need to do it changing the source code of gvSIG, you should ask to the development mailing lists. Sometimes, it is only a focus problem or we can add a new extension point suitable for doing what you need from your plugins. Or sometimes what you want to do can be helpful for other users and we can integrate it in the gvSIG code.

Sometimes I´ve been told that only want to see the gvSIG code. Well, even for that, there is no need to download the sources. Usually the SDI that you use can download the sources automatically for viewing, because each jar created of gvSIG creates another one with its sources, being available in the maven repository of the project.

In spite of this, I understand that at any point you want to know where are the sources…because it gives some security.The gvSIG sources are always available for everyone.. You can look for them in the link of the beginning and there is all “core” of gvSIG. You can download the trunk sources, but it is not an advisable option. These have the changes which we are we working with and sometimes are not stables.
So, then….

Which sources should be working with?

With each distribution generated by gvSIG, being a final version, RC, tested or of development. a tag is created in the SVN with the version number where the sources can be found. However, these numbers don´t follow the same criteria that the distribution. The version and the build number are orientated to the product. They can be changed arbitrarily to fit non technical criteria. From the development point of view, we use automatic version numbers, always incrementally and unique, and they can not be the same than in the distribution.

So… How do we know the “development” version of one gvSIG distribution

Starting for the easy one… How do I know the development version of the gvSIG core for a concrete distribution?

Well, if we have one gvSIG distribution, we can look in the “lib” folder at the root installation. There, we look the file:

  org.gvsig.andami-*.jar

We find, for instance:

• gvSIG 2.2.0-2313 ===> org.gvsig.andami-2.0.100.jar
• gvSIG 2.1.0-2269 ===> org.gvsig.andami-2.0.84.jar

This means that the project version org.gvsig.desktop, which is the gvSIG core, for the 2.2.0-2313 is the 2.0.100.

Once we know exactly which is the gvSIG core version, we can go to the SVN of the project (the URL of the beginning) and in the tags folder, we will find:

http://devel.gvsig.org/svn/gvsig-desktop/tags/org.gvsig.desktop-2.0.100

…which will have the sources of that version of the gvSIG core.

But, those are only the core sources. And if I want to download the sources of one plugin which is not in the core?

Well, that has a dark part, by one side and another one easier. Where the SVN of that plugin is and which version is the one used for the distribution.

Let´s start for the easy one with an example. Which is the development version of the data provider for the PostgreSQL?

We go as for the core of the gvSIG installation. In this case to the lib folder inside of the plugin:

  gvSIG/extensiones/org.gvsig.postgresql.app.mainplugin/lib

There we look the jar:

  org.gvsig.postgresql.app.mainplugin-*.jar

In general, the jar will have the same name that the one in the plugin folder followed by the version number. So, this version number will be the one that we will have to look for in the tag folder of the SVN od the project. In the case of postgreSQL would be something like:

http://devel.gvsig.org/svn/gvsig-postgresql/tags/org.gvsig.postgresql-2.0.30/

For gvSIG Desktop 2.2.0-2313 .

The most complicated will be to guess in which “lives” that plugin. There is not list with that information. The only thing that I can advise you is that you go to the project list of the gvSIG redmine, and try to locate the project of the redmine correspondent with the plugin, from which you want the sources. For example, for PostgreSQL would be:

https://redmine.gvsig.net/redmine/projects/gvsig-postgresql

And it should be there the URL to the SVN of the project.

If you are not able to find it, as always, you can ask development mailing lists

I hope that this post had been useful.
Regards,
Joaquín