Thanks Cèsar,

your explanation has proved to be very useful! Thanks a lot!

I've done tests till now :
I could compile and run the FortuneCookie extension from my gvSig working copy and I've studied all the stuffs you've hinted me.

I guess I've understood more or less how it works and what's implementing what.

I've got back reading the libFMap_dalfiles project's code for trying to understand how it's implemented the DAL provider.
I still need to get deeper into it, anyway the first thing I will do tomorrow will be trying to implement something according to what I'm able to perceive from the reading of other DAL providers.

Thanks a lot again for your help,
I guess I'm close to understand something about this matter and that's thanks to your explanations.

Ciao,
Luca

Ok Luca, I'll take a look at it tomorrow morning.

To test your plugin, you only have to run a mvn install into the project. That will compile the plugin and copy all files into the gvSIG instalation.

How it knows where gvSIG actually is installed?

There is a maven configuration file called settings.xml, located into your $HOME/.m2 folder, which contains some general maven configuration options.

The plugin creation wizard, in one of its steps, asks you for the gvSIG location, so it adds or updates an entry into that file which is used by our maven configuration to know where to copy the gvSIG plugin files. If you want to change it by hand, just edit the $HOME/.m2/settings.xml file and look for an entry like:

  <profile>
        <id>gvsig-install</id>
        <activation>
            <activeByDefault>false</activeByDefault>
        </activation>
        <properties>
            <gvsig.install.dir>/home/user/gvSIG-2.0.0</gvsig.install.dir>
        </properties>
    </profile>

You can point it to a gvSIG 2.0.0 installation folder, if you want to use one of the builds we prepared two weeks ago, or to your gvSIG workspace. In the second case, rememember the gvSIG build is located in the "build" project, into the "product" folder. Ex:

   <profile>
        <id>gvsig-install</id>
        <activation>
            <activeByDefault>false</activeByDefault>
        </activation>
        <properties>
            <gvsig.install.dir>/home/user/workspaces/gvSIG2.0.0/build/product</gvsig.install.dir>
        </properties>
    </profile>

Hi Luca,

- When I create a plugin I get some java classes already ready within the src folders. What they are supposed to be for ?


The project created by the plugin wizard is an already working one. Its a simple implementation of a fortune cookies plugin for gvSIG.

The library provides the service to get a fortune cookie, and the plugin integrates that into gvSIG by adding a menu option.


- How can I use them ? For implementing what ?

In your case:

* In the library API and implementation projects you have an example of how to structure your code to be able to provide the separation between API and implementation.

In the sample code you have, in the API:

- A xxxManager: is the entry point to the API. Provides the main services of the library.
- A xxxLocator: the responsible to provide access to the single Manager instance.
- A xxxLibrary: initialization and configuration of the library.
- A xxxService: another interface for the API. You may use it or not depending on your library's functionality.
- Some exceptions throwed by the API.

In the implementation you have:

- Implementations of the API interfaces (the xxxManager and the xxxService in the example).
- Another Library implementation class, whose responsability is to register the implementation through the xxxLocator from the API.

You can find more information about how to use the Library[1] and Locator[2] in the gvSIG developers guide for the org.gvsig.tools project.

* In the gvSIG plugin project you have an example Extension which adds a menu option to show a fortune cookie. I think all that code won't be for much use in your case, as your plugin Extension class will be mostly empty and you are not going to add a user functionality to gvSIG. You can remove everything but the Extension class if you like.

[1] http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel/org.gvsig.tools/2.1.0/org-gvsig-tools-library
[2] http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel/org.gvsig.tools/2.1.0/org-gvsig-tools-locator

Hi all,

I've a question if somebody has time for me:

- When I create a plugin I get some java classes already ready within the src folders. What they are supposed to be for ?
- How can I use them ? For implementing what ?

The files I'm asking about are those in two separate folders:


1- org/gvsig/myextension/impl :
*DefaultMyExtensionManager.java
*DefaultMyExtensionService.java
*MyExtensionDefaultImplLibrary.java


2- org/gvsig/myextension/api :
*MyExtensionException.java
*MyExtensionLibrary.java ( described at [1] ? )
*MyExtensionLocator.java ( described at [2] ? )
*MyExtensionManager.java
*MyExtensionMessageException.java
*MyExtensionService.java


Cheers,
Luca

[1] http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel/org.gvsig.tools/2.1.0/org-gvsig-tools-library
[2] http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel/org.gvsig.tools/2.1.0/org-gvsig-tools-locator

Ok Cèsar,

thanks a lot!

All these stuffs you've showed me make lot of sense to me.
I think I'm starting to understand something.

To understand more I'd need to implement a basic extension with a foo functionality (like an "Hello World" application) for testing how all those work better.

I've created the plugin org.gvsig.sqlite with the options you've told me and I've added the provider sub-project within the org.gvsig.sqlite project.

I send you the compressed project's files (within a private email, as far as I can't attached it here), if you have the time to check I've done things alright and I have all the basic files needed for my extension.

Actually, I guess the next information I'd need is how could I compile the extension and how could I add it to a gvSIG working copy(like the one I've in the bin recently downloaded) for testing purposes ?

Cheers,
Luca

Hi Luca,

First of all, I'm going to explain the two project types available in the plugin creation wizard, "basic" and "with providers", which affect the project library structure:

- basic: it is used when you have an API and an implementation, and you don't have pluggable providers or services. As of now, some example gvSIG libraries that apply to that case would be org.gvsig.metadata (libMetadata) or org.gvsig.compat (libCompat). For the last one, the project defines an API and an implementation for Java SE (sorry, it is an old project and does not contain the default maven structure). The gvSIG Mobile project uses the same API but provides its own implementation for Java ME CDC.

- with providers: it is used when you have an API and an implementation, and you have pluggable providers for some part of its functionality. An example would be org.gvsig.fmap.dal (libFMap_dal). It has an API, an implementation and a SPI. That last one (SPI) is the API to use and be implemented by the data providers.

In your case, the project library would be the library to access sqlite, so I think it is the first case, a basic project type.

Next, in the wizard you have some additional options to take into account:

- Create swing library projects: this is for projects which also provide some functionality available through swing components. There you would have swing components which depend only from your library's API, without any dependence on appgvSIG or _fwAndami.

In your case, I think you can uncheck this option.

- Create gvSIG plugin: this is for projects which also provide a gvSIG plugin. That would be a common case, as a plugin is the only way we have now to add any functionality or register anything into gvSIG.

In your case, you should check that option. Your plugin would be very simple, as it will only exist to contain the sqllite provider for DAL. I mean, no menu entries, no button, no tool-bar entries, etc. You will only have an empty Extension implementation class.

- Create test application: this option is used mainly as a way to test your library without having to launch gvSIG, most useful when you have checked the "Create swing library projects" option.

In your case, you can create unit tests to check your sqlite library and the sqllite dal provider, so I think you can uncheck that option too.

That will leave you with something like this:

* org.gvsig.sqlite
o tags
o branches
o trunk
+ org.gvsig.sqlite
# org.gvsig.sqlite.lib
* org.gvsig.sqlite.lib.api
* org.gvsig.sqlite.lib.impl
* org.gvsig.sqlite
o tags
o branches
o trunk
+ org.gvsig.sqlite.app
# org.gvsig.sqlite.app.extension

Only the leaf projects are real java projects, so there are only 3 real projects: library api, library implementation and the gvSIG extension. There is still something lacking there, as there is no project for the sqlite provider. We could add another subproject for it, something like this:

* org.gvsig.sqlite
o tags
o branches
o trunk
+ org.gvsig.sqlite
# org.gvsig.sqlite.lib
* org.gvsig.sqlite.lib.api
* org.gvsig.sqlite.lib.impl
# org.gvsig.sqlite.prov
* org.gvsig.sqlite.prov.dal
* org.gvsig.sqlite
o tags
o branches
o trunk
+ org.gvsig.sqlite.app
# org.gvsig.sqlite.app.extension

And the real projects being:

- org.gvsig.sqlite.lib.api: sqlite java library API.
May be used by any java application, not only gvSIG.

- org.gvsig.sqlite.lib.impl: sqlite java library implementation.
May be used by any java application, not only gvSIG.

- org.gvsig.sqlite.prov.dal: sqlite provider for gvSIG DAL.
May be used still used by any java application,
but only through the DAL API.

- org.gvsig.sqlite.app.extension: plugin for gvSIG.

That structure will allow a lot of flexibility and an easier version and API change management.

I hope to have put some light into the project structure. If you agree with it, from now on we may discuss into this thread about any doubts about the project structure or about what code to put into each project, etc.