[Geoserver-devel] Re: 1.4.x, modules and Spring document on confluence

GeoServer GeoServer Developer
1

Hi Andrea,

This is great, it hits all the high points of what needs to happen quite well. A couple of comments.

The first is about how to acheive the dependency management among modules, ike you have said before Spring wont really do this for you. From what I understand its not possible to declare dependencies among contexts?

I attempted (not sure how well it worked) to acheive this at build time with maven. With maven 2 and transitive dependencies this solution gets a bit nicer. What are your thoughts about how you see this working. Is declaring dependencies at build time going to be enough?

Second is more on the management side. In my recent experiences with GeoServer 1.4.x and Geotools FM I have learned that dont like change :), at least not change on this scale. Which is understandable. And its always hard to convince the people who pay salaries that this type of thing is actually worth it. What would be nice is if we came up with a gradual transition strategy in which we could tie individual portions of the work to projects that people actually do care about. For instance a lot of this has to happen in order for the SA project to fly, but I am not sure how much of it.

Thanks for the hard work, this is going ot be a lot easer to explain to people with this document around.

-Justin

Andrea Aime (SATA) wrote:

Hi,
I've just written a document that explains how we could use Spring
and what advantages we would get by using it, along with a modules proposal
on http://docs.codehaus.org/display/GEOSDEV/Spring+proposal.

It would be very nice if people could read, evaluate, discuss, fix, comment it,
even on here on the mailing list.

Cheers
Andrea Aime

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

2

Andrea Aime (SATA) wrote:

Justin Deoliveira ha scritto:

Hi Andrea,

This is great, it hits all the high points of what needs to happen quite well. A couple of comments.

The first is about how to acheive the dependency management among modules, ike you have said before Spring wont really do this for you. From what I understand its not possible to declare dependencies among contexts?

Well, you can have parent and child context (thus, a hierachy of contexts),
but that would mess up things for service lookup by interface (a child contexts
sees its parent, but not the other way around).

I attempted (not sure how well it worked) to acheive this at build time with maven. With maven 2 and transitive dependencies this solution gets a bit nicer. What are your thoughts about how you see this working. Is declaring dependencies at build time going to be enough?

I believe so. At run time, it's a web application, and modules will end up
playing in the same vm with the same classloaders. So, we can say the
build time is module oriente, the run time is really monolithic again once
the single Spring context I envisage is started.

Second is more on the management side. In my recent experiences with GeoServer 1.4.x and Geotools FM I have learned that dont like change :), at least not change on this scale. Which is understandable. And its always hard to convince the people who pay salaries that this type of thing is actually worth it. What would be nice is if we came up with a gradual transition strategy in which we could tie individual portions of the work to projects that people actually do care about. For instance a lot of this has to happen in order for the SA project to fly, but I am not sure how much of it.

Yes, my intention was to start working on basic things like startup
initialization, configuration, replacing FactorySPI and have a simple solution
for the dispatch servlet that reuse most of the current classes, and work
on true remoting integration, security and whatnot later.

What I really need, is some feedback on the web framework. Does anyone know
if Struts can play with modular systems (I believe not unfortunately?).

Two options, you can split your struts file up, one section for each module (usually breaks down as a team responsible) - this is a *very* common use of struts. The other option is to run more then one struts controller, in effect one struts system for each module - and low coupling is achived through simple web links... low tech but actually pretty good.

Jody

3

Justin Deoliveira ha scritto:

Hi Andrea,

This is great, it hits all the high points of what needs to happen quite well. A couple of comments.

The first is about how to acheive the dependency management among modules, ike you have said before Spring wont really do this for you. From what I understand its not possible to declare dependencies among contexts?

Well, you can have parent and child context (thus, a hierachy of contexts),
but that would mess up things for service lookup by interface (a child contexts
sees its parent, but not the other way around).

I attempted (not sure how well it worked) to acheive this at build time with maven. With maven 2 and transitive dependencies this solution gets a bit nicer. What are your thoughts about how you see this working. Is declaring dependencies at build time going to be enough?

I believe so. At run time, it's a web application, and modules will end up
playing in the same vm with the same classloaders. So, we can say the
build time is module oriente, the run time is really monolithic again once
the single Spring context I envisage is started.

Second is more on the management side. In my recent experiences with GeoServer 1.4.x and Geotools FM I have learned that dont like change :), at least not change on this scale. Which is understandable. And its always hard to convince the people who pay salaries that this type of thing is actually worth it. What would be nice is if we came up with a gradual transition strategy in which we could tie individual portions of the work to projects that people actually do care about. For instance a lot of this has to happen in order for the SA project to fly, but I am not sure how much of it.

Yes, my intention was to start working on basic things like startup
initialization, configuration, replacing FactorySPI and have a simple solution
for the dispatch servlet that reuse most of the current classes, and work
on true remoting integration, security and whatnot later.

What I really need, is some feedback on the web framework. Does anyone know
if Struts can play with modular systems (I believe not unfortunately?).

Cheers
Andrea