Michael Bedward wrote:
> Hi Adrian,
>
> Please excuse this slight hijack of the topic, but there have been
> mentions of eventually back-porting the new and beautiful code to work
> against Java5. Do you have any feelings on how realistic that idea is
> ? My guess is that it's unlikely to happen for all of the usual, real
> world reasons.
>
> I ask as someone who will probably be working with Java5 for some time yet.
>
> cheers
> Michael
>
>
Hey,
Porting the Geotools foundation, gt-utility, gt-metadata, and
gt-referencing back to Java 5 will happen since that is the plan going
forward for Geotools referencing. Martin is the only one among us who
has wrapped his head fully around the referencing mathematics and the
ISO specification so it is much better and easier to maintain a backport
of his work than to try to follow his changes on Geotools 2.
It actually is probably not going to be that hard since the language
changes, while quite useful, are not major. We need to drop the JAXB
annotations if they still bother people and tweak some of the calls to
new methods like the new System.arrays calls. I know Martin is committed
to helping the initial backport which is currently planned as a clone
with patches to make it easy to maintain over time. How that backport is
integrated into the Java5 code line and how it will be maintained will
obviously be up to those working on that code.
The styling work is a harder question since it's much higher up the
stack and depends on feature. We'll find out what happens when we get
closer to it becoming possible.
We are going to end up with two lines of code, one for each generation
of the language, that much is clear. That may or may not happen within
the "GeoTools" framework, it kind of doesn't matter. It will obviously
have to happen partly outside the SVN repository. Both Java and the
cleanup effort are using mercurial so that means the most likely thing
is the continuation of the SVN augmented by a series of Hg repositories.
Architecturally the issue doesn't seem terrifically complex. We are
going to have a repo with the base code (util/metadata/referencing) for
each language version, and then have repositories working off of those.
Whether those repos are a single SVN into which code is imported or a
forest of mercurial clones is mostly personal working style preference.
Structurally, we have seprate layers:
base utilities (e.g. factory finding system)
metadata
referencing
grid coverage (feature less)
JTS (isogeometry someday)
feature (growing to support formal coverages)
data access
rendering (w/ styling)
and then a slew of packages in various states of support beyond that. So
if an architect were to design the two code lines for the two language
version, she would probably create, for each language version, a repo
for each layer with Maven integrating the whole. That would allow users
to depend on only the pieces they wanted.
However, what will actually happen is anyone's guess. We may decide to
work together to keep the parallelism or to work each on our end. To my
mind, it no longer matters since I am no longer shackled to the SVN.
I'll work with others as long as it is fun and seems worth it, and work
on mercurial or bazaar or git for my own code, pulling in changes as I
choose and offering it to all as they may choose. Ultimately, the
distributed versionning systems completely change the game. One has to
be structured about what work goes where but gains the freedom to run
ahead of others and integrate back as needed.
Merely as illustration, I can talk about *my* code stack which can be
quite independent of anyone else's. I'm trying to use mercurial for
everything and using Java 6 exclusively.
One of my projects, my work on ISO 19107 compliant geometry, uses a
fork of GeoAPI, Martin's geotidy, and then works in its own repo.
The fork of GeoAPI allows me to prototype new interfaces for the
geometry package without impacting anyone else. My own repo lets me
do whatever I please, and maven does the right thing by me.
Another of my projects, also on Java 6, extends further up the
stack. It starts with a fork of Geotools 2 feature and data store
packages which acts essentially as a feature freeze of those
classes, integrates our recent revival of Martin's old render and
the new styling work, pulls in code from our server, and then adds
libraries for the code on which I am working. This stack is not
suffciently clean and we are planning to clean up the stack for the
begining of next year as we transition it to use Martin's geotidy
and writing this mail has given me new ideas for cleaning it up.
It's also got an SVN in the middle which makes everything harder.
So, going forward, I expect that I will be building a formal set of
mercurial repositories for Geotools code on Java 6 with geotidy as the
base, my geometry work, Feature level code, data access code, rendering
code, server code, and web client code. Recent work on mercurial is
making it simple to maintain this kind of 'forest' and clone the lot or
work on each piece separately. I expect that will be my strategy going
forward. So generally, I will keep my own copies of each of these,
pulling from upstream when it suits me.
Hopefully that gives you a picture of how *I* understand things and am
planning to proceed. Others hopefully understand things differently or
't'would be a boring world indeed.
cheers,
--adrian
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
