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
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
