1. Some java.sql.DataSource details
2. feature collection
3. Java 5
4. GeoAPI update
5. geometry module to supported

gtbot: Added agenda item '1: Some java.sql.DataSource details' to the list.
jdeolive: gtbot add feature collection
gtbot: Added agenda item '2: feature collection' to the list.
***aaime hides under the nearest bush
jgarnett: hello
jgarnett: gtbot add Java 5
gtbot: Added agenda item '3: Java 5' to the list.
chorner: any other items?
acuster: gtbod add GeoAPI update
chorner: gtbot add GeoAPI update
gtbot: Added agenda item '4: GeoAPI update' to the list.
chorner has changed the topic to: 1) Some java.sql.DataSource details 2) feature collection 3) Java 5 4) GeoAPI update
acuster: 0. what is up
chorner: gtbot start
gtbot: Logging started.
jonathanv: you guys still haven't figured out what to do about feature collections?
aaime: last week of work for me, then one week vacation
jonathanv: what's the problem?
chorner: stay on topic
chorner: what's everyone working on?
gdavis: hi
aaime: Geoserver 1.5.2. release
jgarnett: jgarnett - hooking up HsqlDialectEpsgMediator as the default
gdavis: I'd like to get the unsupported geometry module to supported status for this geotools release
chorner: testing new hsql/oracle epsg for connection leakage
gdavis: can/should we add that as an agenda item?
jdeolive: new feature model
jgarnett: yep
chorner: gtbot add geometry module to unsupported?
gtbot: Added agenda item '5: geometry module to unsupported?' to the list.
acuster: acuster: doing nothing, planning virtual udig work
jdeolive: jonathanv, i added a topic to talk about feautrecollections
gdavis: thnx cory
CIA-9: jgarnett * r26256 geotools/gt/modules/library/main/src/main/java/org/geotools/ (2 files in 2 dirs): DefaultFeatureCollection copy constructor
jonathanv: oh really
***chorner curses jody
acuster: there goes the auto post
chorner: gtbot list
gtbot: Agenda Items:
gtbot: 1: Some java.sql.DataSource details
gtbot: 2: feature collection
gtbot: 3: Java 5
gtbot: 4: GeoAPI update
gtbot: 5: geometry module to unsupported?
jgarnett: fine I will post; although why we cannot get the bot to ignore CIA-9 I am not sure...
gtbot: End of agenda items.
chorner: we just need 10 minutes of richard's time
acuster has changed the topic to: 1) Some java.sql.DataSource details 2) feature collection 3) Java 5 4) GeoAPI update 5) geometry module to supported (sic)
chorner: 1) Some java.sql.DataSource details
aaime: That's mine
aaime: Two little things
aaime: First one is a clarification
aaime: I did upgrad the old factories to use DataSource, the DBCP one in particular
aaime: and added three parameters for basic control of it (min/max connection, connection vitality check)
aaime: but I did not add the "advanced" factories, that is, those taking a DataSource as a parameter
aaime: I guess we can add those at our leisue when the need arise
aaime: at the moment I can't use those in Geoserver unfortunately (the struts UI is killing me)
aaime: Second one is a change I need to add before the release
aaime: DataSource factories should take a dsType parameter, just like dbType parameter is provided to jdbc datastores
aaime: so that we have a discriminator when two datasources accept the same parameters
jgarnett: so question/clairification - without datasoruce as prameter - does DBCP even get used? Or is it used internally by the factory you did implement (going to look now).
aaime: I'll add those before rc1
aaime: Used internally
jgarnett: okay
aaime: all factories are using DBCP by default
aaime: or else, they do use DataSourceUtil
aaime: which in turns builds a DBCP based one
jgarnett: thanks andrea that answers my question
aaime: if we ever wanted to switch to C3P0 by default
aaime: this give us a single point of change
aaime: If there are no further comments/questions, I'm done
jgarnett: questions
jgarnett: docs / docs / docs
jgarnett: I asked questions on this last week - any progress?
aaime: you're the one that volounteered for the docs?
jgarnett: indeed
jgarnett: I have some emails flagged from you
jgarnett: when the docs are done then this proposal is finished?
aaime: yes
jgarnett: cool.
aaime: sorry, can you resend those mails
aaime: in the mail maelstrom I receive every day I loose some
jgarnett: nope they were ones from you; let me turn them into docs. Mostly they are notes from you talking with acuster.
chorner: no other questions?
acuster: jgarnett, you going to document the above while you are at it? ...what DBCP vs. C3PO are
aaime: c3p0... ah, you missed some star wars episode, don't you? :-p
jonathanv is now known as jonafan
acuster: anyhow, let's not stall on that but leave it to the eventual docs. next?
chorner: 2) Feature Collection
jdeolive: this one is me
jdeolive: our feature colleciton is stressing me out... and here is why
jdeolive: 1. fc implements both collection + feature... but none of our implementations do it properly
jdeolive: 2. we have three different base classes for fc's,... which again makes implementation confiusing
jdeolive: 3. having to implmenet both collection and feature is hard ... which is why we dont have a good base class
jdeolive: it has been the messiest part of extending the new feature model thus far
iant left the room (quit: ).
snicoll left the room (quit: ).
jdeolive: 4. it duplicates query / feature reader functionality
iant [n=ijturton@c-71-58-71-181.hsd1.pa.comcast.net] entered the room.
jdeolive: which makes the api hard for users
jdeolive: having two options is bad enough... havign two options when one of them (fc) only half works is really bad
iant left the room (quit: Client Quit).
jdeolive: end rant
chorner: what are you proposing?
aaime: Not much to add from my part... my point of view is that Collection and phisical resource access are a bad mix
aaime: (aka, doing I/O in something that the world knows for being memory only)
jgarnett: I don't mind too much what we do; only that we do it over the next couple of months before geoapi FeatureCollection is pressed into stone.
jdeolive: nothing... just that fc is a problem
jgarnett: But this is all old ground ...
jgarnett: okay jdeolive++ good rant
jgarnett: next?
aaime: Hmmm... so they idea is, fc sucks, but we're going to keep it that way anyways?
aaime: Any hope to make it work as adverstised at least?
chorner: 3) Java 5
jdeolive: doubtful in my opinion... in my opionion the best solution is to strip it down... not make it implement collection
jgarnett: 2.4.x is out of the way
snicoll [n=snicoll@70.165-66-87.adsl-dyn.isp.belgacom.be] entered the room.
jdeolive: and dont try to duplicate functionality from query (liek sorting)
jgarnett: can we update trunk to use Java 5 now please.
jgarnett: jdeolive do you want to set up a breakout IRC on feature collection?
jdeolive: sure that would be good
jgarnett: cool.
iant [n=ijturton@c-71-58-71-181.hsd1.pa.comcast.net] entered the room.
jgarnett: Justin I want to ask you about Java 5 - as I think your build box is stricktly Java 1.4 right now
jgarnett: (and this would break it)
jdeolive: yup... and i have hesitatoins to updating trunk yet
jdeolive: we dont have policies for java 5 usage in place yet
jdeolive: until we do i would rather we stick with the profile
jdeolive: using generics and templates and enums can easily make code way harder to understand tehn the java 4 version
jgarnett: okay; what are you thinking of in terms of polices?
jgarnett: generics, templates and enums should only get in our way when we are defining new API yes?
jdeolive: like you can only use generics to strongly type collecitons, not to template a class... that sort of thing
jgarnett: So we would get a chance to review these introductions when the proposal is submitted.
aaime: I think there are examples of deadly combinations of generics and autboxing on the net
jgarnett: Do you want to write up your ideas on the "coding conventions" page justin.
aaime: we should search the blogs of 1-2 years ago
aaime: the topic was quite popular
jgarnett: I think what we are all wanting is "minimal" use of Java 5
aaime: indeed
jgarnett: mostly using it to keep our collections straight
jdeolive: agreed
jdeolive: type narrowing is good too imho
jgarnett: I don't mind enum
jgarnett: but would like to keep to the GeoAPI interface guidelines here
jdeolive: but yeah... lets start the proposal and start a coding guidelines page
jgarnett: enum used for a fixed set; codelist used for an open ended set
jgarnett: etc...
jgarnett: jdeolive you are okay with the task? Send email when the page is ready - and dont stress too much and realy damage is restricted to the public API change process so you will get a chance to review.
jgarnett: I would like to see us use Java 5 concurrrancy however..
jdeolive: i am pretty deep within the bowels of the feature model work at the moment
jdeolive: but will need java 5 in place to commmit
jdeolive: so yes... i can work on that
jgarnett: I will wait for the wiki page update (or do it myself) before we update trunk to Java 5.
jgarnett: next?
jdeolive: cool
chorner: java 5 concurrency
chorner: 4) GeoAPI update
acuster:
jgarnett: Is this a status update? or a jar update... i would like to know how the OGC meeting went.
acuster: GeoAPI went to the OGC conference in Paris
acuster: ...and successfully dodged the rain.
acuster:
acuster: Martin found out a week before that the working group had been disolved,
acuster: which we weren't sure what it meant.
acuster:
acuster: We went to try to push many changes since 2.0 through so as to
acuster: make two new releases, the compatible 2.1 and the client breaking 3.0.
acuster:
acuster: Martin and I gave a talk.
acuster: I waved my hands about what GeoAPI was to a fairly full room 20-30 people;
acuster: seemed well received.
acuster: Martin started asking the room for their opionions on change number 1;
acuster: total silence.
acuster:
acuster: No one had read the doc or felt qualifed to comment.
acuster: So he went through and summarized the proposals,
acuster: which was well received: they liked the rigour, they liked the idea.
acuster:
acuster: We passed a motion to ask the Technical Committee to let us form the
acuster:
acuster: GeoAPI Standards Working Group
acuster:
acuster: which, on thursday they accepted. The group will eventually propose GeoAPI as
acuster: its very own implementation standard. (When we return to GO-w territory we will
acuster: presumably deprecate the old spec and offer our own).
acuster:
acuster: So now:
acuster: 1) we will need volunteers to sit on the working group
acuster: 2) we will need to stay active and propose one set of changes at least a year.
acuster: If we do, in six months or so we could propose GeoAPI 3.0 as the base for the
acuster: standard and would work to amend and extend the spec thereafter.
acuster:
acuster: questions?
jgarnett: first
jgarnett: woot!
jgarnett: good work martin and acuster
jgarnett: 1) can you do what some of the other OGC groups do; and let open source people in on the process?
jgarnett: (if not I am stuck and cannot volunteer)
jgarnett: 2) should not be a problem
acuster: I'm not sure of what the membership rules will be
jgarnett: Also do you need a new charter?
acuster: nor if we can sneak in as members of OGC (which is a member)
jgarnett: (I assume this chater will be more straight forward ... we want Java interfaces for your crazy ISO specifications)
acuster: sorry of OSGeo
jgarnett: ah OSGeo++
acuster: yes, the charter will be small although perhaps not restricted to Java
jgarnett: understood
acuster: OGC is going to have individual memberships as well ($500ish/year)
acuster: and there's going to be a backdoor way for us to get the specs
jgarnett: FrankW ping? Can some of us that are OSGeo memembers attend OGC meetings / working groups as representatives?
acuster: because they are going to post the last draft
acuster: and all the comments
iant: when did OSGEo join OGC?
acuster: with some strict rule about comments being integrated to the final draft
acuster: but they need to iron things out
desruisseaux [n=chatzill@mtd203.teledetection.fr] entered the room.
acuster: iant, not sure when. The trusty Arnaulf was there as the OSGeo rep.
acuster: hey martin
desruisseaux: Hello all
acuster: we are just discussing your talk
FrankW: Arnulf is there as a rep for the where group, but also advocating on behalf of osgeo.
iant: He usually represents his company
FrankW: You can't go to meetings on behalf of osgeo currently.
acuster: yes, but this time he had a big tag
FrankW: I have gone once as a consultant to the where group.
acuster: ah, okay. He wasn't official.
acuster: but he was present
iant: I've been with GeoTools on my badge before (i.e. you can put what you like on the badge)
acuster: The meeting is kind of weird. A bunch of techno-geeks in their little world.
acuster: they do a lot of experiments, few land.
acuster: Anyhow, the sociology is for another day.
acuster: next?
chorner: 5) Geometry module to supported
jgarnett: still great work guys; thanks for all your hard work.
gdavis: that's me,... should be to "supported" though
gdavis: basically the module is ready to be brought to supported status. The bugs are fixed, the test coverage is at 50%, I've created a wiki page (http://docs.codehaus.org/display/GEOTDOC/Geometry+Module) and I'm about to go through the last bit of IP review.
jgarnett: (um it is )
gdavis: oh, it was unsupported a while back
gdavis: what I need is someone to review the wiki page listed above and provide any feedback, and let me know what, if anything, still needs to be done to get this to supported status.
aaime: does it build with java4?
gdavis: this module requires java5
aaime: so we need to move to java5 before moving it to supported no?
acuster: pre-approved!
acuster: a new status
aaime: ha ha
gdavis: right, which I thought was planned for the next geotools release?
aaime: 2.5
aaime: not 2.4
gdavis: ok, so in order to get this module to supported status for 2.5, what do I need to do?
snicoll left the room (quit: ).
acuster: and 2.4 is not even out yet so that puts your deadline out a ways.
aaime: get the feedback your requested above
aaime: get a positive vote
jgarnett: can we not move this to supported status on trunk?
acuster: jgarnett, is the king of the stars so he should know
aaime: and wait java5 to actually move it to supported
aaime: since otherwise you'll break all build boxes
jgarnett: geometry has one "star" left - the IP check.
acuster: so what's the decision on java5?
acuster: we wait for justin's review and then ...?
aaime: Mostly positive, we need some policy to avoid too
jgarnett: it looks to be happening on trunk (see agenda topic 3)
chorner: would it go in plugin, library, or extension?
acuster: s/review/policy doc
gdavis: I believe jgarnett said plugin
aaime: good question... library or extension I guess?
aaime: why plugin? is there an SPI behind this?
jgarnett: plugin; there are two implementations around; both just implement existing GeoAPI interfaces.
aaime: Ah, ok
acuster: gdavis, sorry for the clarification. your lib is geoapi + native code or geoapi+wrapper+jts?
jgarnett: We would have to define "FactoryFinder" in our API module
aaime: hmmm.... so it would be like epsg modules... library do not depend on it, but you need at least one to make gt work?
gdavis: this module does not use jts wrapper
jgarnett: aaime++
aaime: What about current JTS geometries?
jgarnett: jts-wrapper is a seperate implemenation (and only does a subset)
jgarnett: current JTS geometries are just the way they always are
aaime: (and all the code that depends on them directly?)
jgarnett: to be clear this module is an implementation
acuster: yeah, can you two explain where we will be in six months?
jgarnett: hooking up the new feature model is needed
acuster: how do we run your code without the JTS libs
jgarnett: before the rest of geotools cares
acuster: and conversely
aaime: and then making all the code independent of JTS geometries... ugh
acuster: how do we use JTS when your lib is around?
aaime: (or I'm missing something)
jgarnett: going to ask for a time out; this geometry module has nothing to do with jts - or the feature model.
jgarnett: it is pure implementation
gdavis: I'm not sure where the confusion is
jgarnett: and rests on its own merits
aaime: It's an implementation of an inteface
acuster: of geoapi only?
gdavis: correct
aaime: and to have renderer work with it
jgarnett: the confusions is people wondering how your module hooks up to geotols
gdavis: of iso 19107 specs
aaime: renderer has to work with geoapi geometries, no?
jgarnett: (ie rendering, feature model, expression and so on)
jgarnett: and the answer is - not your problem.
aaime: really, how?
aaime: because now I see plenty of code doing Geometry g = f.getDefaultGeometry()
aaime: and g is a JTS geometry
acuster: do we have other modules like this that arn't connected at all?
gdavis: perhaps jgarneet can answer that one, im not familiar with how all of geotools works
jgarnett: I will answer it - but can we treat this as a seperate topic?
acuster: aaime, you see that kind of code in geotools itself?
jgarnett: acuster the page with notes on this stuff is here: http://docs.codehaus.org/display/GEOTOOLS/ISO+Geometry+Research)
aaime: ti's everywhere, yes
acuster: ouch
jgarnett: so we need isolation; Expression interface
aaime: renderer, GML encoders, GML parsers
jgarnett: converters; so we can pull JTS Geometry (or ISO Geometry) into a Java 2D shape for rendering
acuster: thanks for the link
aaime: So we need to change all of our code and ask users to do the same
jgarnett: and deep intergration with datastore depends us getting our factory game on
jgarnett: See GeoAPI PositionFactory for an example API where a PointArray can be created from float[] or double[]
jgarnett: Some of this work gabriel all ready did
jgarnett: isolating the code that takes a JTS Geometry
aaime: This is another major api breakage, we should better have them both in one shot, otherwise we will make gt2 unusable for a few releases (at least, a royal pain to track)
jgarnett: into a "Converter" as used by Expression
jgarnett: so it can be pulled into a Shape for rendering
jgarnett: This balance; allowing both JTS Geometry and ISO Geometry to work is the major work justing is doing right now
jgarnett: as part of getting us a feature interface that does not suck
aaime: jdeolive, I did not know the feature model work switched us to geoapi geometries...
jgarnett: You can (without API breakage) renderer ISO Geometry right now; and query against them.
jgarnett: It does not
aaime: oh, is the new default geometry method return type an "object"?
jdeolive: aaime, it does not
jgarnett: correct
jgarnett: Well the super interface does; our JTS Feature will still be returning a JTS Geometry.
aaime: jgarnet, without some refactoring you can render stuff slowly
jdeolive: well the geotools Feature will still return a jts geometry as it does today
jgarnett: (here is the other intergration link: http://docs.codehaus.org/display/GEOTOOLS/Expression+Improvements#ExpressionImprovements-GeometryFilter)
aaime: Ha, so we'll need another API break to have GeoAPI geometries in the game?
jgarnett: Nope
jgarnett: if your code works against the GeoAPI SimpleFeature interface
jgarnett: you should be fine.
jdeolive: well i guess it will part of the upgrade to SimpleFeature...
jdeolive: i agree its a pain
jgarnett: jdeolive++
aaime: is that change part of the feature model work?
***acuster finally gets it
jdeolive: yes and no
aaime: What I want is an assessment of the effort that has resources backed
jdeolive: the first round of feature model work is to just get geotools Fetaure to etend geoapi feature
aaime: I don't like people telling me about a brave new world
aaime: and hinding (or forgetting) the work needed to get there
jdeolive: so its fine that geotools feature still works against JTS
jdeolive: but once client code switches to SimpleFeture completley... then the problem starts
aaime: and the resource (people/money) needed to get there
jgarnett: creating plugin/geometry is something we can do now; and will be valued. Intergration with the rest of geotools as an attribute can also happen now (or when anyone cares).
jgarnett: (so can we get back on track ... plugin/geometry )
jgarnett: nobody has a requirement right now to use ISO Geometry + ISO Feature do they? So we cannot answer questions on resoruce (people/money)
aaime: I wasn't complaining about the module itself, a dead, disconnected but mantained module creates no troubles
aaime: the troubles start if you try to connect it and leave the work incomplete
jgarnett: We have people using jts-wrapper in the wild; bryce was using it.
jgarnett: We are not starting to connect it.
acuster: well it does create a documentation issue
acuster: since newcommers will look at that module first
acuster: only to discover it's not connected
jdeolive: jgarnett, i have an idea
jdeolive: what if we moved SimpleFeature to geotools instead of in geoapi
acuster: what's the incentive for having it in supported?
jdeolive: that way we could still type narrow to JTS
jgarnett: The documentation issue is covered: http://docs.codehaus.org/display/GEOTDOC/Geometry
aaime: well, while we don't have an alternate implementation it's no trouble to put it in extensions no?
aaime: That would be make it clear it's not core
acuster: yeah, extensions would be okay
acuster: that should indicate something is wrong
jgarnett: um we have two implementations of this thing; this is just like referencing - other projects (besides the rest of geotools)
jgarnett: use this stuff.
jgarnett: so "plugins"
aaime: I don't agree, but have it your way
jgarnett: jts-wrapper may also want to go supported - I will talk to bryce? He should be able to get it done now that we have good test cases?
acuster: yeah, I don't care. It's good enough work that I'll let the newcommers suffer yet even more.
jgarnett: Please note that we do use some of these abstractions in geotools as it stands (DirectPosition) is used when we do transformations.
aaime: these are in referencing thought
acuster: DirectPosition is now using this new geometry!?
aaime: no
jgarnett: that is a good question
aaime: that is even more confusing
jgarnett: what do you think gdavis?
gdavis: about plugin vs ext?
jgarnett: (There are three implementation of DirectPosition right now)
acuster: ha!
jgarnett: about this; does referencing require your geometry module
aaime: oh the horror
acuster: the only one I care about is in martin's referencing code
gdavis: ..not that i know of
jgarnett: (in order to have an implementation of DirectPosition)
aaime: that would make the whole geotools depend on a module which is otherwise disconnected
acuster: since referencing and geometry (currently) depend on each other
jgarnett: right now we defined equals / hashcode so the three implementations will not trip on each other)
acuster: and there is no logical way to break that co-dependency
jgarnett: darn ISO abstractions
jgarnett: well referencing only needs an implementation of DirectPosition for testing...
acuster: no
jgarnett: in a similar fashion geometry only needs referencing for testing.
aaime: he? no, it users directposition everywhere
aaime: in the transfrom code
acuster: it's not just for testing
jgarnett: It should be using a PrimitiveFactory for that should it not?
aaime: ?
jgarnett: (this is an honest question )
acuster: desruisseaux, t'es la?
aaime: No, it uses DirectionPosition directly, as an implementation class
aaime: (afaik)
jgarnett: aaime you are correct
acuster: it has its own directPos iirc
desruisseaux: acuster, yes
jgarnett: my question is this: GeoAPI defines a factory for getting your DirectPosition instnaces created
aaime: it has DirectPosition1d and 2d
jgarnett: should referencing use it?
acuster: any implementation will do, but why switch if it buys us nothing?
aaime: Can I ask why we should try to coax the geometry module into a dependency when there are no resources to make it work seamlessly with the rest of gt2?
acuster: yes, what andrea asked
jgarnett: the answer to both your questions is the same: do we want to "respect" a factory provided by the user
acuster: no, not yet for this
aaime: the answer is no because we never needed to?
jgarnett: ie if they give us one that uses a float[] for ordinates; should we use it
aaime: it does not buy us anything?
acuster: just for the DirectPositions of the referencing module? no. If it ain't broke, don't fix it.
aaime: the day Geometry is ready to be seamelessly used adding that factory it's a snap
aaime: doing that today is confusing and needless?
acuster: in the misty future, when geotools is an OSGeo project and... maybe
jgarnett: heh - I would like that to be soon (the OSGeo part)
jgarnett: but yeah; lets jump off that bridge when we come to it.
acuster: so should you all vote on the topic question: moving the geometry module to supported?
jgarnett: I think the correct order would be to have referencing use a "DefaultPositionFactory" that only can create points...
jgarnett: right...
jgarnett: let me ask
acuster: gdavis, where do you want your module to live?
jgarnett: gdavis are you ready for a vote? Sounded like you needed your IP review and wiki pages first
desruisseaux: I would prefer to let DirectPosition alone for now. Maybe we can revisit this issue later if there is request for that. Right now I would not like to throw more potential instability in the referencing module.
jgarnett: Do you want to send out an email when you got them.
gdavis: i dont know enough about where it should live to answer that. I've just been living in implementation world for this spec
gdavis: okay, so what I need is someone to review the wiki page for me
gdavis: http://docs.codehaus.org/display/GEOTDOC/Geometry+Module
gdavis: in the meantime ill be finishing up the IP review
jgarnett: nice code examples
gdavis: as for how it should hook into geotools, i dont feel I know enough about the module to answer that.
gdavis: er, not the module, geotools rather
jgarnett: agreed; the quick answer is it does not hook up to geotools yet
acuster: pico container!?
gdavis: heh
acuster: yet another twist on the geotools factory system
chorner: we're running late guys
jgarnett: heh; you try sorting out how to use the five geomety factories without it
chorner: perhaps call it a meeting?
gdavis: many of the factories require other factories and figuring out the dependencies is confusing
jgarnett: yep
acuster: well gdavis thanks for all the hard work
gdavis: pico container is just one example of how to go about it
jgarnett: gdavis can you send email when you IP review is done? we can figure out how to vote then...
gdavis: sure
acuster: gdavis, I suspect we should discuss the various solutions to the problem and then stay consistent
gdavis: okay
acuster: jgarnett, what's the general solution for factories needing factories needing...?
gdavis: so... can someone commit to reviewing this wiki page?
jgarnett: acuster? Are you thinking factories? I cover picocontainer as an option (along with spring).
jgarnett: I glanced through - but honestly acuster is better at reviewing
jgarnett: (he is meaner then me)
acuster: okay, I'll review.
acuster: gdavis, ping me if I get distracted since I can't start on this right away
jgarnett: acuster the general solution is to "wire it up yourself"; but in the real world people either:
jgarnett: - use spring (and an XML recipie)
jgarnett: - use pico container (which uses reflection)
gdavis: acuster, thanks. Im going to head out to lunch now. you can email me your feedback whenever you have a chance to review it
acuster: what about the whole factory finder meme?
gdavis: sometime today or tomorrow would be nice though
jgarnett: (aside: http://docs.codehaus.org/display/GEOTDOC/How+to+Find+a+Factory)
jgarnett: covers factory finder and "container"
jgarnett: the factory finder meme tends to break down here; as you need five factories all configured with the same CRS and percision; or you break things
gdavis: so, I think I got what I needed for now. The discussion of how this will become supported can resume via email I guess, once my wiki page is done and the IP review is done
jgarnett: martin used something called a FactoryGroup in referencing
jgarnett: (it was a container that he made by hand so I renamed it ReferencingFactoryContainer)
jgarnett: but there is no reason to make up this stuff by hand; hense the use of Picocontainer)
***acuster thinks the PMC simply needs to mandate one system
jgarnett: See bottom of this page for ReferencingFactoryContainer: http://docs.codehaus.org/display/GEOTDOC/09+Referencing+Factories
jgarnett: it is hard
jgarnett: uDig uses pico
acuster: because it's exhausting learning every alternative
jgarnett: geoserver uses spring
gdavis: can I assume my topic and the meeting are now complete?
jgarnett: really geotools should not dictate
jgarnett: agreed
jgarnett: chorner do I need to post the logs (since I confused the bot?)
gdavis: chorner is afk
jgarnett: gtbot stop
gtbot: Logging stopped.
gtbot: Posting news to GeoTools confluence...
gtbot: Unable to post news to Confluence. Saving logs to a local location.
gtbot: Logs saved in /home/rgould/IRC Meeting - 16 July 2007.log
vheurteaux left the room (quit: ).
jgarnett: that answers that question - I will post logs
jgarnett: jdeolive ping?
jdeolive: hi
jgarnett: We don't update the stable/development thing until 2.4.0 goes out do we?
gdavis: im going to lunch, ill be back later acuster. otherwise just post your feedback via email (gdavis@refractions.net) cheers!
iant left the room (quit: ).
jdeolive: i dont think so
jgarnett: okay
jgarnett: desruisseaux ping?
jgarnett: When we go to Java 5
jgarnett: will we consider the JSR-275 units jar?
desruisseaux: Jody?
jgarnett: hi
jgarnett: (welcome back)
jgarnett: if it is late feel free to ignore me; I am just excited about Java 5
desruisseaux: Yes, we will need to move to JSR-275 soon or later. JSR-108 is dead.