[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] A need for branching uDig and Geotools, and how to merge again
|
Hi Harald.
This is a big message and I am quite busy but I am going to try to
find time to properly address this in the next week.
Just want you to know that I am taking the message seriously,
Jesse
On 3-Nov-08, at 9:07 PM, Wellmann, Harald wrote:
Sorry for cross-posting, but I think this issue has an impact on
both communities. This post is going to be long, so let me start
with a summary:
- For a couple of months, I've been experimenting with uDig to build
a viewer for a proprietary car navigation database format on top of
it. By now, I am positive that uDig (in itself and through its usage
of Geotools) provides an excellent basis for our work, and it would
be foolish not to use this basis.
- 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 a consequence, I had to build uDig from source and start
modifying the sources.
- I've now got a quick-and-dirty demo running, but for a more
permanent solution the Geotools libraries and all third-party
dependencies need to be converted to OSGi bundles, and all uDig
plugin manifests need to be revised accordingly. This requires
modifying Geotools as well (at least the POMs, not the sources.)
- The batch builds for uDig and Geotools both do not work without
modifications in our environment. (uDig does not build at all,
Geotools has a couple of test failures.)
At this point, I'm stuck and I do not see how to get any further
without creating branches both of uDig and Geotools or even cloning
the repositories. There are a couple of options:
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.
(No, I don't really mean that, or else I wouldn't be writing this
message.)
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.
(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.)
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.
(Actually, I've started working with Mercurial and hgimportsvn to
mirror the Geotools trunk and start hacking on a osgi branch. So
far, this setup seems to work well, and maybe even better than on
Subversion which does not support any incremental merges between
branches on server versions < 1.5.)
So much for the problem and the possible scenarios.
What I don't want to do is tread on anyone's toes, and I do not
expect anyone to solve my problems for me. Neither do I think I
could write a better uDig or Geotools on my own. I just have to
solve a problem which I believe to be of more than just private
interest, and which could be regarded simply as an alternative
distribution of (a subset of) udig and Geotools.
Some more detailed proposals for this task:
My feeling is that our plugins depend on not more than 25 % of uDig
and maybe 5% of Geotools. (We do not need any of the DataStore
formats supported by uDig and Geotools, and no editing features
either.)
So the first step is to identify the minimal subset of uDig and
Geotools required by our plugins. For Geotools, this will probably
be just modules/library/* and not much else.
All snapshot dependencies have to be replaced by milestone or real
releases. Currently, we are working on a trunk snapshot of uDig
using a snapshot version of Geotools using a snapshot version of
Geoapi, so we cannot control when Maven pulls in an updated snapshot
which might break our build.
All third-party dependencies of this subset have to be osgified.
Some of them can be taken from the SpringSource Enterprise Bundle
repository, others can be wrapped automatically using the maven-
bundle-plugin, and special cases need some manual treatment. All
these osgified artifacts need to be deployed to a public Maven
repository with different group or artifact IDs, and the Geotools
POMs have to use the osgified dependencies instead of the original
ones.
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.
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.
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.
Regards,
Harald
*******************************************
innovative systems GmbH Navigation-Multimedia
Geschaeftsfuehrung: Edwin Summers - Kevin Brown - Regis Baudot
Sitz der Gesellschaft: Hamburg - Registergericht: Hamburg HRB 59980
*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den
Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail
in error) please notify the sender immediately and delete this e-
mail. Any unauthorized copying, disclosure or distribution of the
contents in this e-mail is strictly forbidden.
*******************************************
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
