circulatity introduced to build dependancies


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.




April 10, 2015, 3:19 PM

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 back in to core, and have data do the implementations of it.

April 10, 2015, 3:19 PM

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: Nice!

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: ok

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: boggle

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: right

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: indeed

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: filter->gml->data

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.

cholmesny: Ok.

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?








Fix versions

Affects versions