R: [Geotools-devel] Re: [Geoserver-devel] GeoServer and GeoTools versions

GeoServer GeoServer Developer
1

So we're sorry but, as things stands now, we have no choice but
to avoid doing any work in GeoTools (apart from the MIFDataStore which
is a very well defined and separated module).
We looked at last week's IRC meeting and saw the confusion about
the two GeoTools present versions, and we have no time to keep
it up with it.
So we're only going to do the minimum bug fixing we need to have
a working 2.1.x to use for GeoServer.

Then we'll work only inside GeoServer.
After the reception of the minimum bug fixing in 1.3.x,
we'll create a branch from trunk and start working inside it
but keeping with GT 2.1.x.
If we'll have any new functionality to add, we'll do that inside
GeoServer, even if that new functionality would be better suited
for inclusion in GeoTools.
There're some functionalities now present in GeoServer that we need
to factor out. The main one is the code inside
  org.vfny.geoserver.wfs.responses.TransactionResponse
that we intend to separate from the WFS and HTTP related code.
The result of this factoring-out would ideally go into GeoTools,
but we'll leave it inside GeoServer instead.
During this process we'll try to keep our branch updated from
trunk as much as possible.
A non comprehensive list of things that will go inside our branch are:
  .) Security by FeatureType
  .) Security by AttributeType
  .) Security by Polygon
  .) Notification by Polygon
  .) Locking by Polygon
  .) Versioning
  .) DataStore pluggability

In the end our branch will be our production server, so it'll hopefully
be actually working.
Also it would be a source of code to be ported to the GeoServer trunk,
but we cannot be sure about that. Maybe it will be too different, but
at least it may become a sort of prototype or source of inspiration for
functionalities to be implemented some other way.

Regarding all the pieces of code that should go inside GeoTools, it will
be someone else, more involved with GeoTools, that will decide if and how
to actually move them.

There will also be some code that will stay with our package names
and that we'll put in the GeoServer SVN only as JARs (both binary and
source).
This code would also be ported to GeoTools, we'd be happy about that,
but it will require someone else, more involved with GeoTools, to decide
if and how to actually move it.

Now, Dave, do we have your permission to proceed this way with GeoServer???
We may also need to put, at least temporarily, some classes in packages
not starting by org.vfny.geoserver both to speed things up and to keep
things separated. Would it this be acceptable???

Bye
Paolo Rizzi & Luca Percich

-----Messaggio originale-----
Da: dblasby@anonymised.com [mailto:dblasby@anonymised.com]
Inviato: giovedì 1 settembre 2005 21.43
A: geoserver-devel@lists.sourceforge.net
Cc: geotools-devel@lists.sourceforge.net
Oggetto: [Geotools-devel] Re: [Geoserver-devel] GeoServer and GeoTools
versions

(for the geotools folks, a few people were asking about doing Geotools
work and using it in Geoserver. That why I brought the topic
up at the
IRC meeting.)

I've been talking to some of the other Geotools folks about
whats going
on with 2.1.x and trunk (2.2). Some of it was in the last
IRC meeting:

http://docs.codehaus.org/pages/viewpage.action?pageId=31081

Geoserver trunk is currently based on the geotools 2.1.x branch.

Geotools trunk (2.2) is currently being actively developed on, and
there's probably quite a bit of instability and API changes. I dont
know if either of these issues are major or minor.

I've been told there's 5 people going to merge major changes onto
geotools trunk, so I'm hoping to avoid the problems until "someone
else" has tested it out for a bit.

Unfortunately, there's not supposed to be any work going on the 2.1.x
branch, so you're kinda in a catch 22! If you want to do anything of
consequence you have to move to Geotools trunk, which means
you'll have
to deal with keeping Geoserver up-and-running with all the (API)
changes they're making there, plus some instability.

Geoserver will switch over to the Geotools 2.2 branch, but
probably not
until gabriel finishes his FeatureType stuff. I'd like to see that
stuff in Geoserver & I'm sure he'll have it tested well.

I dont expect moving Geoserver to Geotools 2.2 trunk would take more
than a day or so (the CITE tests should pick up any potential
problems).

>Or should I start my own GeoServer branch, port it to GT 2.2.x and go
on
>working on it until some point in the future when it may be
merged into
GeoServer 1.4.x or
>something like that???

The problem is that we're going to probably be making a bunch
of changes
to geoserver to do the actual 1.3.0 release, so we'll have to maintain
both geoserver-1.3-for-geotools-2.1.x and the
geoserver-1.3-for-geotools-2.2.

dave

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

-------------------------------------------------------
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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

2

P.Rizzi Ag.Mobilità Ambiente wrote:

So we're sorry but, as things stands now, we have no choice but to avoid doing any work in GeoTools (apart from the MIFDataStore which
is a very well defined and separated module).
We looked at last week's IRC meeting and saw the confusion about
the two GeoTools present versions, and we have no time to keep
it up with it.
So we're only going to do the minimum bug fixing we need to have
a working 2.1.x to use for GeoServer.

I am sorry we gave the impression of being confused:
- GeoTools 2.1.x series supports UDIG 1.0.x and GeoServer 1.3.x sharing as many bug fixes as possible
- GeoTools 2.2.x series hosts RnD work such as UDIG 1.1.x and GeoServer 1.4.x

Then we'll work only inside GeoServer.
After the reception of the minimum bug fixing in 1.3.x,
we'll create a branch from trunk and start working inside it
but keeping with GT 2.1.x.

I do understand you hesitation, we tried working in GeoTools last year and had our work backed out. We went off and developed in UDIG only and were supposed to backport as time premits. Problem is time does not permit ... ever.

If we'll have any new functionality to add, we'll do that inside
GeoServer, even if that new functionality would be better suited
for inclusion in GeoTools.

There're some functionalities now present in GeoServer that we need
to factor out. The main one is the code inside org.vfny.geoserver.wfs.responses.TransactionResponse

I wrote that method and would love to know what your plans are.

that we intend to separate from the WFS and HTTP related code.
The result of this factoring-out would ideally go into GeoTools,
but we'll leave it inside GeoServer instead.

In my understanding that has largely been done, the GeoTools DataStore interface was constructed with that method in mind.

During this process we'll try to keep our branch updated from
trunk as much as possible.
A non comprehensive list of things that will go inside our branch are:
  .) Security by FeatureType
  .) Security by AttributeType
  .) Security by Polygon
  .) Notification by Polygon
  .) Locking by Polygon
  .) Versioning
  .) DataStore pluggability

I would really like to know your intended approach, for the following reasons. I suspect running some metadata assoicated with the type system, and wrapping DataStores as required. There is already a GeoServerFeatureSource that wraps most access.

GeoServer runs a metadata class - FeatureTypeInfo that we had ported to GeoTools once, and was kicked out. We ported it against as CatalogInfo, and were kicked out. And finally we have a consistent implemntation over in UDIG with plans to back port here:
-<http://docs.codehaus.org/display/GEOTOOLS/CatalogAPI&gt;

Some of the problem here is that I was the only developer needing this functionality, toolkits always go better with two sets of requirements to keep them honest.

In the end our branch will be our production server, so it'll hopefully
be actually working.
Also it would be a source of code to be ported to the GeoServer trunk,
but we cannot be sure about that. Maybe it will be too different, but
at least it may become a sort of prototype or source of inspiration for functionalities to be implemented some other way.

I would like to know your approach, and you could use the above CatalogAPI as a starting point if it would prove helpful to you. It has a much more flexable "Info" class for example.

Separatly I am revising the Feature Model with Gabriel and would like to know your thoughts on versioning. Will the simple String getVersion() opaque String (that geotools used to have) be sufficient, are you trying for long transaction support with branching and merging? Do you have any UML diagrams?

Regarding all the pieces of code that should go inside GeoTools, it will
be someone else, more involved with GeoTools, that will decide if and how
to actually move them.

It is unfortant that GeoTools has let you down in this manner, is there something that can be fixed?

There will also be some code that will stay with our package names
and that we'll put in the GeoServer SVN only as JARs (both binary and
source).
This code would also be ported to GeoTools, we'd be happy about that,
but it will require someone else, more involved with GeoTools, to decide if and how to actually move it.

Open souce projects don't often function this way, usually they live or die by their ability to support new development. This is why I am very interested in what can be done to help.

Phrased another way, other people have the need to do RnD work on GeoTools how can we allow everyone to work together? Is it the sheer volume of active RnD, would laying down a roadmap help? What your time parameters?

I am not saying their is not a problem, I am just wondering how we can help.
Jody

3

Here is another silly idea,

Take a branch off the stable branch GeoTools 2.1.x
then at least we would be providing you with version control, and would be able to use "svn merge" and friends to isolate your changes for application to trunk (when the time comes).

Cheers,
Jody

4

Chris tells me that you guys are mostly done,

Given the fact that I am trying to move something similar to FeatureStoreInfo back into the geotools code base I would not mind a review, to see if it can cover your required functionality.

Please have a look at the diagram on this page:
-<http://docs.codehaus.org/display/GEOTOOLS/CatalogAPI&gt;

And let me know if IGeoResourceInfo is suitable for the kinds of issues you need to address?

Jody

5

P.Rizzi Ag.Mobilità Ambiente wrote:

Now, Dave, do we have your permission to proceed this way with GeoServer???
We may also need to put, at least temporarily, some classes in packages
not starting by org.vfny.geoserver both to speed things up and to keep
things separated. Would it this be acceptable???

Dave if GeoServer 1.3.0 is "code complete" why not make your stable GeoServer branch, and let GeoServer trunk follow GeoTools trunk? May be preferable to splintering GeoServer development up into branches.

Jody

6

I agree with Jody.
If geoserver starts 1.4.x branch, it will be far more easy to start
incorporating stuff to geoserver as work is done in gt trunk .
For those of us that are likely to be adding new functionality based on gt2.2,
we can use a branch of the stable 1.4.x and merge when done.

Gabriel

On Monday 05 September 2005 19:30, Jody Garnett wrote:

P.Rizzi Ag.Mobilità Ambiente wrote:
> Now, Dave, do we have your permission to proceed this way with
> GeoServer??? We may also need to put, at least temporarily, some classes
> in packages not starting by org.vfny.geoserver both to speed things up
> and to keep things separated. Would it this be acceptable???

Dave if GeoServer 1.3.0 is "code complete" why not make your stable
GeoServer branch, and let GeoServer trunk follow GeoTools trunk? May be
preferable to splintering GeoServer development up into branches.

Jody

-------------------------------------------------------
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
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

7

If at all possible I'd like to encourage you to not go this route.
Ultimately it's up to David though, and in the past I've always offered
people the option of doing gt2 work directly in geoserver. But I would
recommend against it.

I guess the main thing we could do for you is to quickly get geoserver
trunk working against 2.2.x. That's our plan, and we want to do it
soon, we've just been held up doing docs, making 1.3.0 super tight.
Perhaps we could consider branching into a 1.3.0 now, and we could have
geoserver trunk working against 2.2.x, so you guys wouldn't be the ones
doing all the bug fixing. Jody says udig is going to go to 2.2.x soon
as well.

Basically we're transitioning to a model where any RnD work should go on
a geotools branch, and you'd have the parallel GeoServer branch going.
It will start to be the case where bugs are fixed on trunk first, and
then maybe backported to the older branches. But if you are staying on
2.1.x you will start to miss out on more and more bug fixes as time
goes on, and upgrading to the latest will be more painful.

What is your time frame on this? And is your end product going to be
maintained, or just left after it's done? Like if you're just doing
this for a couple months, need some results, and don't necessarily need
a future-proof system, then what you're proposing makes sense. But if
the system is to go through upgrade cycles, I really don't think you
want to have it just live on 2.1.x. But I do understand deadlines, and
that you must evaluate the risks for yourself. And my bias is
obviously towards getting as much in geotools as possible - but its
benefits over the long term have also been proven time and again by
personal experience. But at the very least I'm glad you're doing it on
a geoserver branch, it does increase the chances of someone coming
along later and learning from what you will have done.

Chris

Quoting "P.Rizzi Ag.Mobilità Ambiente" <paolo.rizzi@anonymised.com>:

So we're sorry but, as things stands now, we have no choice but
to avoid doing any work in GeoTools (apart from the MIFDataStore
which
is a very well defined and separated module).
We looked at last week's IRC meeting and saw the confusion about
the two GeoTools present versions, and we have no time to keep
it up with it.
So we're only going to do the minimum bug fixing we need to have
a working 2.1.x to use for GeoServer.

Then we'll work only inside GeoServer.
After the reception of the minimum bug fixing in 1.3.x,
we'll create a branch from trunk and start working inside it
but keeping with GT 2.1.x.
If we'll have any new functionality to add, we'll do that inside
GeoServer, even if that new functionality would be better suited
for inclusion in GeoTools.
There're some functionalities now present in GeoServer that we need
to factor out. The main one is the code inside
  org.vfny.geoserver.wfs.responses.TransactionResponse
that we intend to separate from the WFS and HTTP related code.
The result of this factoring-out would ideally go into GeoTools,
but we'll leave it inside GeoServer instead.
During this process we'll try to keep our branch updated from
trunk as much as possible.
A non comprehensive list of things that will go inside our branch
are:
  .) Security by FeatureType
  .) Security by AttributeType
  .) Security by Polygon
  .) Notification by Polygon
  .) Locking by Polygon
  .) Versioning
  .) DataStore pluggability

In the end our branch will be our production server, so it'll
hopefully
be actually working.
Also it would be a source of code to be ported to the GeoServer
trunk,
but we cannot be sure about that. Maybe it will be too different, but
at least it may become a sort of prototype or source of inspiration
for
functionalities to be implemented some other way.

Regarding all the pieces of code that should go inside GeoTools, it
will
be someone else, more involved with GeoTools, that will decide if and
how
to actually move them.

There will also be some code that will stay with our package names
and that we'll put in the GeoServer SVN only as JARs (both binary and
source).
This code would also be ported to GeoTools, we'd be happy about that,
but it will require someone else, more involved with GeoTools, to
decide
if and how to actually move it.

Now, Dave, do we have your permission to proceed this way with
GeoServer???
We may also need to put, at least temporarily, some classes in
packages
not starting by org.vfny.geoserver both to speed things up and to
keep
things separated. Would it this be acceptable???

Bye
Paolo Rizzi & Luca Percich

> -----Messaggio originale-----
> Da: dblasby@anonymised.com [mailto:dblasby@anonymised.com]
> Inviato: giovedì 1 settembre 2005 21.43
> A: geoserver-devel@lists.sourceforge.net
> Cc: geotools-devel@lists.sourceforge.net
> Oggetto: [Geotools-devel] Re: [Geoserver-devel] GeoServer and
GeoTools
> versions
>
>
> (for the geotools folks, a few people were asking about doing
Geotools
> work and using it in Geoserver. That why I brought the topic
> up at the
> IRC meeting.)
>
> I've been talking to some of the other Geotools folks about
> whats going
> on with 2.1.x and trunk (2.2). Some of it was in the last
> IRC meeting:
>
> http://docs.codehaus.org/pages/viewpage.action?pageId=31081
>
> Geoserver trunk is currently based on the geotools 2.1.x branch.
>
> Geotools trunk (2.2) is currently being actively developed on, and
> there's probably quite a bit of instability and API changes. I
dont
> know if either of these issues are major or minor.
>
> I've been told there's 5 people going to merge major changes onto
> geotools trunk, so I'm hoping to avoid the problems until "someone
> else" has tested it out for a bit.
>
> Unfortunately, there's not supposed to be any work going on the
2.1.x
> branch, so you're kinda in a catch 22! If you want to do anything
of
> consequence you have to move to Geotools trunk, which means
> you'll have
> to deal with keeping Geoserver up-and-running with all the (API)
> changes they're making there, plus some instability.
>
> Geoserver will switch over to the Geotools 2.2 branch, but
> probably not
> until gabriel finishes his FeatureType stuff. I'd like to see that
> stuff in Geoserver & I'm sure he'll have it tested well.
>
> I dont expect moving Geoserver to Geotools 2.2 trunk would take
more
> than a day or so (the CITE tests should pick up any potential
> problems).
>
> >Or should I start my own GeoServer branch, port it to GT 2.2.x and
go
> on
> >working on it until some point in the future when it may be
> merged into
> GeoServer 1.4.x or
> >something like that???
>
> The problem is that we're going to probably be making a bunch
> of changes
> to geoserver to do the actual 1.3.0 release, so we'll have to
maintain
> both geoserver-1.3-for-geotools-2.1.x and the
> geoserver-1.3-for-geotools-2.2.
>
> dave
>
>
>
>
>
>
>
>
> ----------------------------------------------------------
> This mail sent through IMP: https://webmail.limegroup.com/
>
>
> -------------------------------------------------------
> 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
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>

-------------------------------------------------------
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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

8

I would like to propose the following guidlines (which wiki page is the most appropriate for writting them down, if accepted by the geotools community?)

* Every new public or protected classes, interfaces, methods or fields
   must be flagged with a @since 2.2 javadoc tag.

* Members with @since 2.2 javadoc tag may change without notice until
   the Geotools 2.2 release is out.

* Members with @since 2.1 or @since 2.0 tags (or without @since javadoc
   tag at all) must not change, except if deprecated in previous release.
   Members from previous releases may be deprecated however.

I would also like to determine which RnD branches to create. I feel that to many RnD branches would be hard to manage, so I would like to keep the number low (actually I would be happy with a single RnD branch for all, with occasional merge to trunk). If we create many RnD branches, I guess we would have:

    - GridCoverage
    - Feature?
    - Catalog?
    - Renderer

What else?

  Martin.

9

Martin,

I like the idea for the @since versions.

I’ll probably want a branch to commit my xdo stuff on when it’s done (was going to code tonight, but have been reading FT stuff instead).

David

On 9/5/05, Martin Desruisseaux <martin.desruisseaux@anonymised.com> wrote:

I would like to propose the following guidlines (which wiki page is the
most appropriate for writting them down, if accepted by the geotools
community?)

  • Every new public or protected classes, interfaces, methods or fields
    must be flagged with a @since 2.2 javadoc tag.

  • Members with @since 2.2 javadoc tag may change without notice until
    the Geotools 2.2 release is out.

  • Members with @since 2.1 or @since 2.0 tags (or without @since javadoc
    tag at all) must not change, except if deprecated in previous release.
    Members from previous releases may be deprecated however.

I would also like to determine which RnD branches to create. I feel that
to many RnD branches would be hard to manage, so I would like to keep
the number low (actually I would be happy with a single RnD branch for
all, with occasional merge to trunk). If we create many RnD branches, I
guess we would have:

  • GridCoverage
  • Feature?
  • Catalog?
  • Renderer

What else?

Martin.

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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

10

Martin Desruisseaux wrote:

I would like to propose the following guidlines (which wiki page is the most appropriate for writting them down, if accepted by the geotools community?)

@since is good, the rest seems to just be in line with our change policy?

I would also like to determine which RnD branches to create.

I think the process is already in place, the RnD Page is already broken down into "In Flight" which is work with an active branch, and propsals (which are all talk and no code).

Some things that are In Flight are fairly short term (FeatureVisitors and Random Access) and some are long term (GridCoverge and FeatureModel stuff).

Sound good? If it would help we could add an "svn" link to the In Flight table, so people can see the source code as it comes together. What is probably more of interest to people planning work is when the RnD projects intend to complete, I sent a news item to geotools recently on that very topic.

Cheers,
Jody

11

Jody Garnett a écrit :

@since is good, the rest seems to just be in line with our change policy?

Yes, except that without @since tag (or something equivalent), developpers using Geotools trunk currently have no way to know if an API is stable or in development, except checking in SVN history or in the javadoc of a previous release. This is why I'm suggesting to set the @since tag as a required part of all public and protected javadoc.

  Martin.