> - I cannot understand the following Eclipse House Rule: "Program To API
> Contract Rule: Check and program to the Eclipse API contract". Han you
> explain it a bit more?
Sure; it amounts to a request by the eclipse team to read the javadocs.
An example of this is the View interface; it is not enough to implement all the
methods - we also have to consider the order they are going to be called in.
1- class constructor
2- init - to set up any configuration
3- createPartControl - to create the widgets that appear on the screen
4- dispose - to clean up afterwards
If you read the javadocs you can learn that if the init method fails; they will
call dispose() to clean up anything.
So a common mistake is to do something like
button.dispose();
but you you need to consider if button was never created
if( button != null ){
button.dispose();
}
A uDig example is the difference between IMap (read-only) and Map (which is
read-write).
A common mistake is to do something like:
((Map)tool.getContext().getMap()).setXXX( object );
If you read the javadocs; you can find that the set methods are only supposed
to be called from commands. So a good example is:
final Object object = ...
map.sendAsync( new AbstractMapCommand(){
public void run(){
getMap().setXXX( object );
}
});
In this way the map can schedule the set method during a pause in rendering (so
we don't get a deadlock).
> - Is it possible to have uDig Javadoc available in Eclipse somehow?
It should just show up (as a tooltip or in the javadocs view). There is a
chance I screwed up and did not include the information in the SDK. I will test
this evening.
Currently we do not publish the javadocs anywhere; we should include them in
the "dropins.zip" so they show up in the eclipse help menu along with our out
docs.
> - In setting up the target platform "SDK Quickstart.pdf" differs from online
> documentation
> (http://udig.refractions.net/confluence/display/ADMIN/07+Eclipse+Preferences#07EclipsePreferences-PluginDevelopment%3ETargetPlatform).
> The first suggests to use the "delta-pack" as a target platform (with his 80
> plug-ins) while the online uses ${eclipse_home} that contains some ~500
> plug-ins. Why?
For General uDig development we use a target platform of:
- eclipse modelling
- delta pack (this includes a copy of SWT for each platform - windows, linux,
mac etc…)_
- a few extra things in the dropins folder - mostly the translations of eclipse
for different languages
For uDig SDK development (i.e. making your own plugins) we build on a target
platform consisting of two things:
- eclipse modelling
- the uDig SDK - containing the udig plugins; and a few extra eclipse plugins
that we use that are not part of the minimal eclipse RCP build)
- the delta pack (for cross platform release)
- Note: This is faster when generating your own plugin; since it does not have
to compile uDig all the time.
> Problem with Admin Documentation
>
> The whole process of importing Libs and Log4j, descrie in:
> http://udig.refractions.net/confluence/display/ADMIN/08+Libs+Jars#08LibsJars-ImportLibsandLog4jPlugins
>
> cannot be performed on 1.3.2-SNAPSHOTS: plugins are not detected.
> Any fix / workaround?
>
>
We should check that you imported the required plugins; the only reason we did
not import everything to start out with - is because it is very slow watching
everything recompile every time we touch "libs".
Jody _______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
