Re: [udig-devel] A need for branching uDig and Geotools, and how to merg

["Jody Garnett" <jody.garnett@xxxxxxxxx>]

Thanks for the background info here ...

- uDig binary distributions or SDKs do not work for us due to version clashes in third-party dependencies of our own bundles and of the monolithic net.refractions.udig.libs bundle which includes all required Geotools libraries and external dependencies.

As mentioned this is something most RCP projects based on uDig have experienced and is something that *has* to be fixed up. We need your guidence on what to change where on this one; and we probably need to round up people to do the work. 

1) Nobody has similar problems and nobody sees the point of what I am trying to do. In that case, I could simply work on private clones, the communities would not see any of my modifications and I would be detached from any fixes and enhancements occurring on the trunks.

Not to worry - this is a known problem; and a solution has been requested since 2006 at least :-) We know what you are talking about.

 

2) Working branches will be created in the uDig and Geotools repositories for my team and myself to do the required modifications, merging changes from the trunk as often as possible. If and when our branches have stabilized and the communities have verified that the results are useful and correct, the working branches can be merged into the trunk and die.

We would like to meet the members of your team; do they have commit access at this time etc? 

 

(At first sight, this is the approach I would prefer, but I have second thoughts for technical reasons: Both repositories run on Subversion over HTTP, locking out anyone in a corporate IT environment with a web proxy blocking the non-standard HTTP requests used by svn. The only way we can use svn is over HTTPS. Moreover, the repository servers seem to have frequent downtimes. {udig,lists,gtsvn}.refractions.net have been off and on sporadically on Sunday and today, not for the first time.)

We may be able to set up HTTPS for this stuff (we would need to talk to admin@xxxxxxxxxxxxxxx for details).

 

3) As a variant of 2), I could clone both repositories, have them hosted by an open source provider offering services usable though our proxy, maintain a trunk mirror branch and an OSGi branch in my clones, so that anyone could track what we are doing and pull in any of our modifications into the official trunks at their own discretion.

 

If you are going to go to the trouble  we may just consider moving the repositories to osgeo hardware. Once again we are limited by volunteer time - it sounds like svn access has been poor lately so you may be able to round up volunteers.

Then the Geotools libraries will be osgified as outlined in
http://docs.codehaus.org/display/GEOTDOC/03+GeoTools+and+Eclipse+or+OSGi, without breaking the META-INF/services mechanism and without losing the capability of being used as plain old JARs on the classpath.

This is the part that is of interest to me; you may wish to show up for a geotools IRC meeting and talk to the community about it. 

Finally, net.refractions.udig.libs will be replaced by a collection of individual Geotools and third-party bundles. Other uDig plugins will drop the dependency on bundle n.r.u.libs and declare new dependencies on individual packages org.geotools.foo and any required third-party packages.

This is fine and an expected direction. 

Once we're done with this conversion for our subset, the scope can be extended to the rest of uDig and Geotools.

That's it... Please let me hear your opinions, or maybe there is even a simple solution I have failed to see so far.

 

You are on the right track,

Jody