to build gmldatasource requires adding the data module to the dependancies, the master build then fails as data depends on filter which in turn depends on gmldatasource.
I guess data should avoid depending on filter but I don't want to start messing with bits I don't understand.
CodeHaus Comment From: cholmes - Time: Thu, 6 Nov 2003 11:26:39 -0600
Hrm. So the files from filter that data needs are all for jdbc, to do the sql encoding. So the quick fix would be to just put those files in the data module.
More long term we might consider splitting up the jdbc stuff into a different module, since only those classes need the filter module.
And/or we could put the interfaces in org.geotools.data back in to core, and have data do the implementations of it.
CodeHaus Comment From: jmacgill - Time: Thu, 6 Nov 2003 11:45:04 -0600
A quick three way session was set up to think this through, the end result was a desicion to move SQLEncoder from the filter module into the data module thus loosing the dep between data and filter.
IanS had to leave part way though, so he may have to re-open the dission if we got it all wrong!
jrmacgill: ok, looks like all three of us are thinking about the cyclic dep
cholmesny: I just posted a comment on jira
iwschneid: its the test cases fault
iwschneid: they should not rely on filter for filter storage
cholmesny: No jdbc in data needs the filter encoders.
cholmesny: We should either seperate out jdbc into its own module
iwschneid: my compile worked fine, just the test cases failed
cholmesny: Or put the interfaces back into core.
jrmacgill: hangon which test cases?
jrmacgill: in gml?
iwschneid: sorry going for coffee or I miss my ride
jrmacgill: Chris, what causes each of the deps.
jrmacgill: data needs filter to encode queries
jrmacgill: filter needs gml to encode geometries in queries?
cholmesny: My gml module wont compile...
cholmesny: yes and yes.
cholmesny: gml needs data to transform FeatureReader
jrmacgill: though, this is why we had a core of interfaces and a lot of factories
jrmacgill: that said...
cholmesny: Yeah, I'd say the best may be to move the interfaces to core.
cholmesny: Data is still useful, as it'll have all the default and abstract implementations.
jrmacgill: will that actualy break the cycle?
cholmesny: As far as I know it will. But I'm not quite sure what Ian was talking about with test cases.
jrmacgill: or will gml be unable to use data?
jrmacgill: me netiher - then again, he probably wasn't building with maven
jrmacgill: probably -> possibly
cholmesny: Oh yeah, it would be nice for gml to be able to use the Abstract and Default stuff that data provides.
jrmacgill: what about moving jdbc out?
cholmesny: Yeah, or the alternative is to move SQLEncoding in to jdbc.
cholmesny: Which could also make sense, as it's the only thing that uses it afaik
jrmacgill: I like that one best so far
cholmesny: Let's think, would that actually fix the issue?
cholmesny: Data would no longer depend on filter.
jrmacgill: but not data->filter so, everything works
cholmesny: So the question is should those files stay in the filter package, or should they go into the data.jdbc package?
jrmacgill: we don't have closed packages, so just moving should be ok, and it breaks less code
jrmacgill: go with keeping the same package for now.
jrmacgill: can you add a copy of this chat session as a comment to the jira task
cholmesny: How about you do that and I'll do the committing?