Hi Martin, hi others
> I noticed that Geowidgets has been commited to SVN (nice!). But the
> directory structure is a little bit strange compared to other projects.
I am aware of that and I had my reasons to do so. However if we find solutions
that are more "usual" and work as good as this one, I'm perfectly fine with
changing the layout.
First let me give you an explaination why I did the structure as I did it:
http://svn.geotools.org/geotools/trunk/spike/geowidgets/trunk/stable/> - There is a geowidget 'trunk' inside the geotools trunk.
I chose to have a separate trunk directory because GeoWidgets will follow
another release schedule than GeoTools. So when GeoTools branches to some
stable branch this will not necessary mean that GeoWidgets can/will have a
stable branch at the same time. Furthermore I can create branches such as
http://svn.geotools.org/geotools/trunk/spike/geowidgets/1.0.M2/...
http://svn.geotools.org/geotools/trunk/spike/geowidgets/1.0.M3/...
without a need for GeoTools to branch.
So in short: This was my solution to the fact that GeoWidgets is WITHIN the SVN
of GeoTools, but has another release schedule.
> - There is a 'stable' and 'instable' subdirectory
Yes, I have "Stable" and "Instable" within trunk.
Let me first emphasize that Stable is NOT a replacement for stable branches or
tags. (although there are no branches currently on this SVN.) In the past I had
only one "GeoWidgets" project in trunk that included everything: Finished
widgets and packages, packages under development and some that just contained
classes I was playing with. But when I created the M0 and M1 releases, which
were supposed to contain only the more or less finished code (not "stable in
the sense of a a stable 1.0 release) I found that it would be easier to split
Geowidgets into two projects that depend on each other:
The "stable" project
- is fully documented with JavaDoc,
- contains working (but not necessary mature) widgets,
- has test cases and some JUnit tests and
- is released in milestone releases
whereas the Instable project (which is not yet up on SVN)
- does not require any of this,
- is likely subject to fundamental package renamings, interface changes a.s.o.
(under active development, so to speak) and
- is not released in milestone releases.
So there is (as far as I see) actually not the need to have specific branches
for active RnD work, which again means less maintnance effort.
The "Instable" project depends on the "Stable" project.
Now obviously the names "Stable" and "Instable" are confusing as I can see from
your feedback. Alternatively we could call them
- "finished" and "unfinished" or
- "finished" and "devel"
if you like that better. Maybe you even have a better idea.
> There is various 'src' directories (src-crs, src-main, etc.).
In GeoTools you have separate projects for different things like "main",
"epsg-access", "shapefile", ... Since the codebase in GeoWidgets is not so
large as to justify the additional work of maintaining several projects I
thought how to best organize the different sets of widgets within one (and now
two) Eclipse projects. I found that I could simply keep sources for each set of
widgets in one source directory each plus have one "src-main" directory that
contains shared code such as utility classes.
Now lets suppose I have finished a set of "foo" widgets. All I have
(theoretically!) to do is to copy the "src-foo" directory from "Instable" to
"Stable", document it, create tests if not yet there, check/remove warnings and
create a new milestone release. Fairly easy, I should think.
To cut long stories short: I thought this a good alternative to the approach of
various single projects that is used in GeoTools and as a way to keep the
source code together and have less maintenance work.
Does this make sense?
> 'test' are subdirectories of 'src'.
Is there any problem with that? In the beginning I had all test in one directory
but found it much better if they stay together with the sources they are
supposed to test.
It would be possible to create "test-main", "test-crs", "test-sld" a.s.o.
directories, but this would mean a large increase in project root directories
without any advantage.
Again, if you have suggestions how to make this SVN structure more "usual"
without losing the above advantages, just let me know and I will consider them.
P.S. Jody and I myself had/have problems building fresh checkouts. The libraries
get downloaded during a "Clean", but Eclipse doesn't realize they are there and
still shows the "missing dependency" errors. Only after doing some editing on
build.xml (insert a space character and save, f.e.) does Eclipse rebuild
completely and realize that it already has the dependencies in place.
I would be VERY grateful if someone with Ant and Builder experience could look
at my project configuration and build.xml and tell me what I've done wrong or
if this isn't my fault but an Eclipse bug or what else is going on. I have no
idea.
Matthias Basler
[hidden email]
----------------------------------------------------------------
This mail was sent through
http://webmail.uni-jena.de-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Locked
