Agenda:
0) what is up
1) mvn vs jar names
2) dynamic sld graphics
3) SoC
4) arcsde
5) mvn vs jar names (revisit)

jgarnett has changed the topic to: 0) what is up 1) mvn vs jar names 2) dynamic sld graphics 3) arcsde
jgarnett: okay we are 15 mins into the meeting timeslot; can we start ...
aaime: sure
jgarnett: 0) what is up
***aaime trying to cram up proposals to make gt2 move a little
aaime: (if nobody stops me next thing is modular rendering)
***groldan is doing geoserver bug fixing and ensuring WFS output formats do use CoordinateSequence
***jdeolive is doing geosearch stuff and starting to play with geoserver config again
jgarnett: jgarnett; uDig can now render polygonsymbolizers from an SLD file again - happiness. Starting in on gabriel's mad plan to switch ArcSDE over to using commands in a queue rather than locks around connections.
***Eclesia improving style editor widget for SE
desruisseaux: Martin: revisiting the +/-180° longitude and +/-90°latitude limit in MapProjection, recently modified from MapProjection to a simple warning. It has more implication, like making CRS.transform(Envelope, ...) more paranoiac (they need to check if we cross the 180° limit).
desruisseaux: (typo: from MapProjectionException to simple warning)
simboss_ is now known as simboss
jgarnett: (reminds me Ecleisa; a lot of the scary code I found for style / expression stuff was in your classes :-D Try and use the SLD utility class so we can share hacks)
jgarnett: 1) mvn vs jar names
jgarnett: I think this is actuall a formal proposal from martin now?
desruisseaux: I write a wiki page with current situation, and the proposal that Jody suggested me in an IRC last Friday.
desruisseaux: (looking for the URL...)
jgarnett: page is not under "proposals" ... go fish.
desruisseaux: http://docs.codehaus.org/display/GEOTOOLS/Module+renaming
jdeolive: i did not like the alternative of renaming all directories
desruisseaux: I do not like renaming directory neither...
jgarnett: jdeolive++ I agree, what did you think about just renaming the "leaf" directories?
jdeolive: i am also thinking we might want to consider the point where the ends do not justify the means on this one...
jdeolive: no, i dont like that either
desruisseaux: Continuing: I do not like renaming directory neither, but I wonder if it would be the less trouble-prone solution.
jdeolive: i dont like having to add all this complexity into our build and module structure
jgarnett: I am not sure that "Module renaming" is the goal here; the goal seems to be to make our project a bit more normal with respect to maven? So more maven plug-ins work ...
jdeolive: just to get a particular report or artifact to "work"
desruisseaux: "mvn site" is not the only Maven plugin which could benefit from a layout 100% conformant to Maven expectation. Last time tried some other plugins was working better with Maven conformant structure (I admit that I don't remember which one... was a long time ago)
desruisseaux: Renaming directory make directory names uglier, but the build simplier since it allows us to remove all custom settings
jdeolive: so what was the problem with just removing the gt2-prefix?
desruisseaux: (<finalName>, <scm>, <url> and the like)
jdeolive: naming conflicts?
aaime: yes, various of them
desruisseaux: They were this H2 name conflict that I didn't spotted before commit (because we don't use H2 on our side...)
aaime: between moduels in gt2 (wfs datastore and wfs model)
ggesquiere [n=gilles@arl13-3-88-169-136-131.fbx.proxad.net] entered the room.
aaime: and with other projects
jdeolive: ok, so lets just rename those modules and tell people that they cant have two modules with teh same name in geotools
aaime: plus look on maven... most of the time each jar brings the proejct name along
jdeolive: not sure i undrestand the h2 one?
jdeolive: aaime++
jdeolive: that seems to be java standard for major prijects like spring
aaime: h2-2.5-SNAPHOST : datastore
jdeolive: why dont they have tehse issues? or do they?
aaime: h2-1.0-snapshot: h2 itself
zzorn left the room (quit: Remote closed the connection).
aaime: major projects are not using maven afaik
jdeolive: ok, so lets rename h2 then
aaime: (not sure)
desruisseaux: I think that Glassfish use Maven (not sure...)
jdeolive: they must in some wat to get there artifacts into the maven repos\
jdeolive: wat = way
aaime: jdeolive, not sure they are doing that
aaime: there may be some non developer type that does it
jdeolive: ok... they must have fun with snapshot versions then
jdeolive: regardless
aaime: I asked various times to have jars pushed into the maven repos (not for major porjects thought)
jgarnett: jdeolive++ you are correct we could rename "h2" as "data-h2" or "h2-plugin"
desruisseaux: "h2-store"?
jgarnett: or "geotools-h2"; but then the temptation is to be consistent.
jdeolive: how abotu h2-spatial
jgarnett: jdeolive++
desruisseaux: Yes I like h2-spatial
jdeolive: cool
aaime: this is spring: http://springframework.cvs.sourceforge.net/springframework/spring/
aaime: still using cvs, and still using ant
desruisseaux: (h2-plugin would be inconsistent with other plugins; we don't put -plugin suffix everywhere)
SamHiatt: I'd vote on that name.
jgarnett: for the main library modules we run into the trouble that our module names are pretty generic; "main.jar" and so on ...
jdeolive: agreed
SamHiatt: I mean, I'd vote Yes to that name.
desruisseaux: But on the proposal issue: we have a choice:
jgarnett: http://springframework.cvs.sourceforge.net/springframework/spring/maven/ has the list of "spring-aop" etc...
desruisseaux: 1) rename directory - ugly but really lead to the simpliest and less troublesome Maven setting we could have.
jgarnett: back in a second.
***Eclesia must go ++
desruisseaux: 2) Keep current state (with h2 renaming) - better directory name but requires Maven hacking
Eclesia left the room.
aaime: here is wicket: http://svn.apache.org/repos/asf/wicket/trunk/
aaime: prefix in the dir names
aaime: (using maven as we do)
jdeolive: i definitley vote for 2
aaime: I prefer 1 I think
desruisseaux: Jody?
aaime: this is hibernate: http://anonsvn.jboss.org/repos/hibernate/core/trunk/
aaime: (flat names)
jdeolive: aaime: is your reason for vorting on 1 so we can have maven artifacts prefixed with gt?
aaime: so that it's easier to deal with maven
aaime: maven is very fragile
aaime: so I expect troubles if we try to work in a way different than it expects
jdeolive: ok, i have a question
jdeolive: for martin
jgarnett: back
desruisseaux: Yes Andrea, Maven is very fragile. This is the reason I'm tempted by 2 while I would normally prefer solution 1.
jdeolive: what was the original issue?
desruisseaux: Oups, opposite
jdeolive: that brought about the original renaming?
aaime: making mvn site work
desruisseaux: Tempted by 1 will I would prefer 2 if Maven was more solid
jgarnett: hibernate confused me a bit; do they actually have a core.jar ?
desruisseaux: "mvn site" among other, but not only.
acuster [n=acuster@rab34-2-82-230-29-3.fbx.proxad.net] entered the room.
aaime: jgarnett, no, in the repos, they have prefixed names
desruisseaux: I wonder how they get prefixed names in the repository...
aaime: so they are in the same situation as us... but with a twist... I don't see anything that makes the prefixes for the repo
aaime: my guess: manual process or automated with a script other than maven
jdeolive: question, what do we need site for?
aaime: all the reports maven generates end up in site
acuster has changed the topic to: 0) what is up 1) mvn vs jar names 2) dynamic sld graphics 3) arcsde 4) graduation status 5) project updates
aaime: javadoc, coverage, dependencies, ....
jdeolive: sure
jdeolive: but those reports work just fine
jdeolive: or maybe i am wrong
aaime: if you run them on a single module, yes
aaime: not if you try to make a full build
jdeolive: so you cant generate javadocs for a full build?
desruisseaux: javadoc and all site
aaime: javadocs do work, other do not
desruisseaux: and there is other mojo plugins that I tried a while ago that doesn't like non-standard layout
jdeolive: coverage erports work
jdeolive: i have done them before
desruisseaux: (don't remember which one - maybe it was the one listing the todo tasks, or last svn commits, etc.)
aaime: wow, never managed to?
aaime: cobertura crashed, the commercial one had issues as well
jdeolive: anyways... the point i am getting to is my original
jdeolive: is this really worth it
desruisseaux: I would claim that yes
desruisseaux: As Andrea point out, Maven is very fragile
jdeolive: ok... well all the reports i deem necessary work...so i would say no
desruisseaux: mvn site is not the only plugin having trouble with non-standard layout
aaime: we have lots of confused users that could enjoy a good mvn:site result
jgarnett: aaime for hibernate-core can we see how they did the prefixed names in the repos ?
desruisseaux: The links are broken, unless you put <url> declaration in every pom.xml
aaime: jgarnett, yes, it seems they did
desruisseaux: And experience show that we always endup with wrong URL declared in pom.xml
jdeolive: these issues seem more like maven bugs to me
desruisseaux: Yes definitively, we have trouble with Maven being fragile.
desruisseaux: Note that I'm fine with either solution 1 or 2. The solution that I would like to avoid is what we had before...
jgarnett: looking at how hibernate pulled it off.
jdeolive: not sure i woudl call it fragile... just because some obscure thing with site generation does not work...
desruisseaux: I looked at the pom.xml and didn't found a clue...
jdeolive: i mean... thats probably why a lot of projects do not use the site stuff
jgarnett: http://anonsvn.jboss.org/repos/hibernate/core/trunk/src/assembly/ has a couple hacks that look similar to what we need? they morph things into a different shape for deployment ?
aaime: I still dont' get how they manage to add the prefixes
desruisseaux: Well, in the case of hibernate the JAR are prefixed in the repo simply because their artifactID are prefix. So hibernate is doing what we did before.
desruisseaux: (typo: their artifactID are prefixed)
aaime: yeah. Whilst on the other side wicket is generating their site with mvn site
aaime: so they added the prefixes
desruisseaux: So they have a directory/artifactID mismatch, like we did.
jdeolive: my preference is we leave things the way we had them before
jdeolive: it seems silly to me to jump through all these hoops for a non-necessary maven feature
jdeolive: but ... that is why we have a PSC
jgarnett: martin they have a bunch of site.xml stuff; is that what they use to untangle mvn site:site
desruisseaux: I feel it necessary...
aaime: (wicket site is generated by maven, incredible as it it, it's true... or at least it was before they switched to apache... not sure now)
jdeolive: desruisseaux: i my definition of necessary is "the project wont run without it"
jgarnett: I am halfway between
desruisseaux: It is valuable then...
jgarnett: we cannot afford another two days downtime
jgarnett: but the project should not really be running without code coverage results either.
jdeolive: jgarnett: come on
desruisseaux: And again, "mvn site" is not the only plugin.
jgarnett: I spend a couple days a year getting coverage results. Not saying this a is a great reason jdeolive; just admitting it is the truth.
desruisseaux: In the way we had before, we need more declaration in every pom.xml. Most peoples do not keep those declarations up-to-date.
jdeolive: thats life with maven...
desruisseaux: More than one pom.xml had wrong <scm> or <url> declaration.
jdeolive: it seems we used to do what most projects do
jdeolive: so i am against all of this
jdeolive: so consider my vote a -1
desruisseaux: Yes thats life with Maven. My hope was to simplify our life by relying on maven defaults.
***jdeolive is bowing out of conversation
jgarnett: from my stand point we are bit stuck here are we not? This proposal is not clear cut ready to go; and we made a mistake by trying to remove prefixes last week without a proposal (and without understanding the consequences)
aaime: jgarnett++
jgarnett: so what are we left with ... we have 10 mins left and some more agenda items that are also important.
jgarnett: martin your proposal as written will work?
jgarnett: and does not involve renaming any directories
jgarnett: can we use it until such time as <finalName> is fixed in maven?
aaime: jgarnett, the fix maybe 6 monts or 2 years away
jdeolive: submit a patch it worked for me with the eclipse plugin
aaime: maven bug fixing is even worse than gt2 one
jgarnett: good points all
jgarnett: The alternative proposal (where you rename leaf projects)
aaime: jdeolive, heh, I tried to work on maven a bit but really, that project has a serious documentation problem
jgarnett: has two down sides; merges are hard - and makes working on geotools expensive for everyeone.
aaime: I could not even find the javadocs...
jgarnett: and it does not completely fix the problem does it?
desruisseaux: I should fix it completly I believe
desruisseaux: The alternative proposal would leads to a 100% Maven default compliant layout.
jdeolive: until the next problem comes up
aaime: jgarnett, do you merge from the root of the modules? I usually do it inside th module otherwise it's too slow
desruisseaux: Next problem are less likely with default layout than default one.
desruisseaux: (typo: than custom one)
jdeolive: thats a naive view, considering that there are 3 other major projects that depend on geotools
jgarnett: aaime I do not understand the question ... "merge from the root of the modules"
aaime: jgarnett, I usually do merges inside the module that has the modifications
jgarnett: next question; both proposal end up with the same artifact names do they not?
aaime: so changing the name is just a matter or movign to a different directory
aaime: if you merge from the root of the gt2 codebase on the contrary
desruisseaux: No, the alternative proposal would have only "gt-" prefix, not "gt-lib" or "gt-ext".
aaime: changing names will make merge fail
jgarnett: oh I see see; svn merge; I usually merge from root; except when merging from 2.2.x - in which case I cry.
acuster has changed the topic to: 0) what is up 1) mvn vs jar names 2) dynamic sld graphics 3) arcsde
aaime: jgarnett, that's way too slow for me
aaime: (from the root)
aaime: it takes minutes before the merge starts
jgarnett: interesting; I did not know that aaime.
aaime: that's why I did not care about renamed directgories
jdeolive: i would rather wait minutes then have to run the command for 80 different modules
jgarnett: guys I need to wrap up this topic; can we return to it at the end of the meeting?
desruisseaux: Jody has fast network connection since he is close to the svn server...
aaime: jdeolive, right, but when do you have such massive changes?
aaime: (do you backport them?)
jdeolive: when you move classes and things like imports change it can happen easily
jgarnett: jdeolive++
jgarnett: guys I am going to move us to the next agenda item...
aaime: correct... (never happened to me thought, since I'm more of a bug fix man than a refactor the world one)
jgarnett: martin I will be happy to talk about this a bit more after.
jdeolive: i agree 80 is unlikely, but 10 is not
desruisseaux: Jody, okay.
jdeolive: different strokes for different folks
jgarnett: 2) dynamic sld graphics
jgarnett: understood; but
jgarnett: http://docs.codehaus.org/display/GEOTOOLS/Dynamic+SLD+Graphic+objects
jgarnett: there we go...
jgarnett: this one is you aaime
aaime: well, the proposal says it all
jgarnett: (and also a nice user who has been sending us lots of email and trying out alternatives in code)
aaime: the problem is making Mark and ExternalGraphic easily extensible
jgarnett: I have seen three approaches; the one andrea has written up is good ... and mostly I want to see this problem solved.
aaime: and allow feature attributes to be used in the definition of the symbol name
aaime: or the url that points to it
aaime: without breaking the SLD standard
aaime: or our object
wolf [n=wolf@hoasb-ff0add00-126.dhcp.inet.fi] entered the room.
wolf: hi
aaime: it all boils down to a creative use of CQL expressions templates withing the names specified in
aaime: the sld
aaime: as proposed
aaime: it allows to support extensible symbols in both marks and external graphics
aaime: generate charts, both locally and using a remote server
aaime: use a fully programmatic driven symbol set like mil2525b
aaime: and generally speaking allowing everybody to create plugins for whatever format they fancy
jgarnett: Hi wolf will put you down next
aaime: thought I'm personally interested in waht's easily reached thrur internet
jgarnett has changed the topic to: 0) what is up 1) mvn vs jar names 2) dynamic sld graphics 3) SoC 4) arcsde
wolf: jgarnett: ack
aaime: that is, symbols and fonts
aaime: that internet is full of
aaime: and that we cannot use nowadays
aaime: The hard part imho is not writing the parsers, but writing the symbosl
aaime: so we want to leverage what's already out there
aaime: that's it
aaime: questions? observations?
jgarnett: aaime; I only had one bit of feedback (that I sent to email); I suspect when the OGC does solve this problem they will use <PropertyName> and not CQL ... does not matter too much to me either way.
jgarnett: other than that lets rock and roll.
aaime: when they do
aaime: we can just have the factories receive the resolved expressions
jgarnett: We have a user slated to give us some MIL2525B stuff, so that will help vet the system with a real world example.
jgarnett: aaime++
sbenthall [n=seb@cpe-66-108-80-238.nyc.res.rr.com] entered the room.
aaime: but... we have an alternative... preparse the url so that they become expressions themselves
aaime: (did not think about this one in fact, could be interesting)
cholmes [n=cholmes@cpe-66-108-80-238.nyc.res.rr.com] entered the room.
aaime: say we take the url with embedded cql expression and we turn it into an OGC Expression
aaime: that we pass to the factories along with the Feature
aaime: (we use the string concatenation functions and the parsed cql expressions to make it up)
jgarnett: The data structure right now already holds an Expression
jgarnett: (at least last I looked)
aaime: that would require changing the parser... sigh
jgarnett: parser already generates a literal expression
jgarnett: you can use a visitor to attack that and do you CQL subst
aaime: yeah, but the parsing needed to turn mil2525://$

into an expression is nothing like standard sld parsing...
aaime: thought... yeah, it's doable
jgarnett: nope I am wrong sorry man
jgarnett: it is a URL
aaime: ah, for ExternalGraphics, yes
jgarnett: (I was getting confused with WellKnownName which is already an expression
aaime: yeah, it's an attribute, so an Expression does not make sense
jgarnett: okay moving on ... can we call a vote on this so aaime can get to work
jgarnett: jgarnett +1
aaime: sure, if there are no objections...
CIA-31: groldan 2.4.x * r29926 geotools/modules/library/main/src/ (3 files in 2 dirs): GEOT-1769, Use CoordinateSequence to write down GML2 coordinate lists, instead of Coordinate[]
aaime: aaime +1
aaime: and... that's it?
jgarnett: aaime I am a bad person; I left the meeting run over time.
aaime: well, let's move the vote to the ml then
simboss: poor aaime
jgarnett: jdeolive voted on email
aaime: simboss... poor what... you have a vote you know?
simboss: yep
simboss: I like this thing
simboss: I actually worked on something similar for nato
aaime: and? or... but?
simboss: but of course they never released it
simboss: I have to read the proposal
aaime: ok, voting on mail is good then
simboss: I am sure your approach is much better than mine
simboss: one curiosity
aaime: ha, who knows
simboss: did you look at APP6?
grrrrr [n=groldan@217.130.79.209] entered the room.
simboss: beside milstd2525b I mean
aaime: no, what's that?
jgarnett: okay next ...
simboss: similar simbolozgy
jgarnett: 3) SoC
jgarnett: wolf you have the floor
groldan left the room (quit: Nick collision from services.).
simboss: just more complex
aaime: I did not look into mil2525b either, theunsgis did that
grrrrr is now known as groldan
jgarnett: We are trying to see if the April 18th deadline is all we need to know about.
wolf: Okay, you need to decide on what projects you want
SamHiatt: desruisseaux: you still here?
wolf: preferrably by tomorrow 12:00 UTC
desruisseaux: Hi Samuel
SamHiatt: I was trying to build pg last night...
SamHiatt: had problems with the new gt renaming stuff...
acuster: hey sam, we're in a meeting right now, if you can wait a second
desruisseaux: Oups, sorry.
SamHiatt: Do you think If I rolled back to before the changes that I will be able to build?
wolf: Google has set a dealine on 19th april 07:00 UTC for assigning mentors, but just to be safe we want to do it on the 17th
SamHiatt: acuster: sorry! I thought the meeting was done! :Z
wolf: any more questions concerning SoC?
jgarnett: So 17th = tomorrow at noon?
wolf: no
simboss: today is 14th
wolf: tomorrow is 15 th
jgarnett: "wolf: preferrably by tomorrow 12:00 UTC"
simboss:
CIA-31: saul.farber * r29927 geotools/gt/modules/plugin/wms/src/main/java/org/geotools/data/ (2 files in 2 dirs): two minor code cleanups
jgarnett: So simboss you seem to be the man with the plan this year; what do we need to do? Make sure the projects we like have mentors? And vote them up ...
wolf: that is a very strict preferrably Like I'll bite you if don't make it
acuster: SamHiatt, try on #geomatys ("/join #geomatys")
jgarnett: and here I thought his bark was all we had to fear.
simboss: well I have found 2 projects which are interesting
wolf: Once I get the list of proposals each project wants (in order of preference) I'll adjust the scores
simboss: one actually is more like acontribution
simboss: the pyramid jdbc plugin
simboss: the second one is from a guy here in italy
simboss: he want to try and integrate better jpeg and png support
simboss: through jmagick+imagemagick
jgarnett: so simboss can we take this to email; and actually talk about the proposals? or is this going to be a case of no time?
simboss: yeah I can do that
jgarnett: (we are 15 mins over meeting time; and two agenda topics to go ...)
jgarnett: 4) arcsde
CIA-31: groldan * r29928 geotools/gt/modules/library/main/src/ (3 files in 2 dirs): GEOT-1769
sfarber [n=sfarber@88-149-177-23.static.ngi.it] entered the room.
jgarnett: gabriel asked me to warn people I was hacking arcsde datastore
jgarnett: I am starting to implement the plan he talked about on IRC a couple of weeks back.
aaime: what's the mad plan about?
jgarnett: So I will ping groldan and sfarber as I go.
aaime: (30 word summary?)
groldan: here
jgarnett: the idea is that locking the connection is killing gabriels happiness; and he wants to switch to a queue.
jgarnett: I need to make arcsde datastore run with only one connection; so I need to let the "metadata queries" use the current transaction / connection
jgarnett: (ie asking about table info etc...)
aaime: hmmm... what is the transaction-connection relationship in SDE? in jdbc is 1-1
groldan: sde connections are not thread safe, we use sde native transactions held at a connection, we need to access a connection concurrently, locking a connection for the lifetime of a FeatureIterator is hard to maintain and a performance killer
jgarnett: so even with all of that we have two ways in which arcsde datastore works; transactions for work; and AUTO_COMMIT for getFeatureInfo( typeName )
jgarnett: I need to narrow the gap and have them share the same connection.
jgarnett: (there is a big IRC discussion about this design here http://docs.codehaus.org/display/GEOTOOLS/2008/03/24/IRC+Logs+March+24)
jgarnett: it is what I will be working from.
aaime: where do you set the current connection? pass as a parameter, use it as an "in the environamet" param like a thread local?
groldan: its at the transaction state
jgarnett: Think a runnable that takes a connection as a parameter
jgarnett: this is mostly a warning; I am sure I will have questions as I go; I well send all email to the devel-list as it happens.
jgarnett: 1) mvn vs jar names part ][
groldan: the idea is to divide execution units in as tiny bits as possible and enqueue them, that provides for a more granular use of the connection, as oppossed to blocking the connection until a FeatureIterator is fully traversed
aaime: groldan, I get that... this seems to be doable only in read only access thought?
groldan: why?
aaime: well, transaction need to be isolated
aaime: if you have a long transaction running you cannot share the same connection with other transactions no?
groldan: executions units are: "fetch a feature", "insert a feature", etc. All of them work with the active transaction
groldan: okay
aaime: right, so you cannot share the same connection between differetn transactions, no?
groldan: addFeatures() is an execution unit per se
jgarnett: aaime I am only planning to share a connection for the read-only activities; ie the ones used by ArcSDEDataStore to look at metadata.
groldan: but its ok because a getFeature called while an addFeature is in progress needs to wait till addFeatures returns
groldan: so the queue still works?
aaime: groldan, what if you're scrolling with a feature iterator?
aaime: using that damn thing you don't know if you're reading or writing
groldan: not quite getting the point
aaime: probably me neither
aaime: too used to jdbc way of doing things
aaime: never mind
groldan: in jdbc you have different transaction isolation levels
groldan: right?
jgarnett: yes
aaime: that's not my point
groldan: okay
aaime: in jdbc you cannot allow two transactions to access the same connection
groldan: so I don't get it
groldan: here neither
aaime: but if you're using a feature writer or a feature iterator
groldan: its all about how you define the bounds of your transaction (the runnable)
aaime: you need to keep the connection "locked"
jgarnett: what is hard here aaime; is that jdbc connections are pretty threadsafe?
jgarnett: arcsde connections are not
jgarnett: so we need to wrap them in a lock or face death
jgarnett: gabriel wants to use a queue rather than a lock.
aaime: no, the fact that once you open a connection for a transaction, you cannot share it anymore
groldan: so aaime what you describe maps to a certain "transaction isolation level"?
jgarnett: I though you can share the connection with another thread?
aaime: sorry, so the problem is multiple threads trying to acecss the same transaction concurrently?
jgarnett: yes; that is the problem
aaime: (only if the other thread is using the same transaction)
groldan: the point of using a queue rather than a lock is that the connection is gonna be used by a single thrad, even when serving multiple threads
jgarnett: multiple threads; one connection; how not to screw up
aaime: aah, sorry, I was thinking about geoserver where different threads = different users = different transactions
simboss_ [n=chatzill@host253-202-dynamic.37-79-r.retail.telecomitalia.it] entered the room.
jgarnett: okay moving on?
groldan: yeah, its a per transaction queue
aaime: I guess your case is udig, multiple threads, one writing, the other rendering, but all against the same connection
sfarber left the room (quit: Read error: 104 (Connection reset by peer)).
groldan: yes
aaime: yeah sorry for bothering
jgarnett: desruisseaux ping?
desruisseaux: Jody, yes?
jgarnett: 1) mvn vs jar names
desruisseaux: yes
groldan: np, trying to explain it really helps
aaime: (not really sure jdbc connections are suposed to be thead safe thought... never mind, go on)
jgarnett: stack.pop()
jgarnett: Is everyone sick of this topic? I am really tempted to rollback the changes until we have a clear direction that will work; is that a horrible idea desruisseaux?
***aaime jumps out of the window
jgarnett: (good thing aaime is on the ground floor)
desruisseaux: If we roll back, does it means that this issue will be forgetten?
aaime: jgarnett, do you remember the iron bars at the window? ouch!
groldan: aaime: mind moving to #geoserver?
jgarnett: and here I though aaime was skinny
jgarnett: martin I don't think this will be forgotten; if I was scheduling stuff I would tackle this right before we release 2.5.0 (or 3.0.0).
jgarnett: ie we have so many problems right now on trunk with functionality; interrupting anything for a few days to sort out some build problems just upsets everyone.
sfarber [n=sfarber@88-149-177-23.static.ngi.it] entered the room.
jgarnett: It would also help to arrive at this with a proposal we know works; in this meeting we ended up discussing a bunch of "What-ifs" and we had no way to vote +1
CIA-31: groldan 2.4.x * r29929 geotools/modules/library/main/src/main/java/org/geotools/gml/producer/GeometryTransformer.java: organize imports in GeometryTransformer
jgarnett: so a couple of questions:
jgarnett: - Even with this proposal we still have a bunch of work unaccounted for; updating the user guide examples etc... is this something we can get funding / time for?
desruisseaux: In this particular case, it may be difficult to know if a proposal work before we try it on trunk, since some problem appears when peoples user the dependency. For example we couldn't have spotted the h2 conflict on our side since we don't have any project using h2...
jgarnett: - Lining up with maven expectations is a good thing; we will run into less problems.
jgarnett: right; so now that we tried it once we have a second test to try... that maven-ant-tasks script.
jgarnett: um and I still cannot deploy? being able to deploy probably needs to be another test.
desruisseaux: I have been able to deploy last friday.
aaime: It would be nice if all jars had always the same name, no matter how they are genreated
jgarnett: I was unable to deploy today ... see email.
aaime: (nice == really required...)
desruisseaux: I means, I have run "mvn deploy" after the prefix removal and it worked for me.
aaime: jgarnett, looked at the mail, the error message means nothing to me...
desruisseaux: If we want the same JAR name both in the repository and in the target/binaries directory, then it would be a push for alternative proposal (renaming directory) or a rollback.
jgarnett: thanks... I was clueless as well so I asked for help. I could deploy last week.
jgarnett: martin I think that is what we want.
jgarnett: I would personally rollback;
jgarnett: and then schedule this proposal for the "release candidate"
jgarnett: and make sure we have enough hands on deck to do the documentation and so on.
jgarnett: But I also want to understand the hibernate build process; since they seem to have it working ...
aaime: jgarnett, they do not generage mvn site afaik
desruisseaux: Release candidate would be too late, because it let too few time to spot the problems. It also means that we have to live months without daily site and javadoc.
jgarnett: I don't know how much flexibility you hae in scheduling martin?
SamHiatt: nice one aaime
jgarnett: well noticed aaime
***aaime checks out hibernate and sees what the heck comes out of mnv:site
desruisseaux: We could do that later too, but I would really love to have site and javadoc generated every days as soon as we can...
jgarnett: agreed martin
jgarnett: (I am not sure if that gets through since this has been such a heated topic; having mvn site working is a very good goal - it costs me days a year not having access to the coverage reports)
aaime: +1 me too... site is good
jgarnett: so I want to see how to get that at not too high a cost
aaime: test coverage?
aaime: why?
jgarnett: I had thought renaming the folders was too high a cost; but apparently it is not the case for aaime.
wolf left the room ("Konversation terminated!").
jgarnett: because I often have to meet test coverage requirements for a deliverable.
aaime: I see
aaime: jgarnett, yes, it's a by product of how svn network protocol works
aaime: it does lots of tiny reqeusts for merges and updates
jgarnett: so as I understand it geoserver and udig are working right now
aaime: so if I know where the change occurred, I can cut down most of them
jgarnett: but with known problems.
aaime: down from one minutes to a few seconds
jgarnett: (that is interesting aaime; later I may ask you for an example)
jgarnett: aaime we are pretty sure we want the gt-main.jar style in the repository right?
jgarnett: You can use martin's jar collector to fetch things out in the right shape.
desruisseaux: I would be okay for a rollback if there is good chance that this topic do not fall in a black hole for months or years...
aaime: imho yes... that's what everybody is diong
aaime: and frankly
aaime: would you like a main.jar in your classpath?
aaime: main of what?
aaime: if you depend on 20 external libraries, think if every one did the same
aaime: nice, hibernate does not build out of the box... they must have a damn private repo
desruisseaux: Well, as Jody point out, we don't have this problem when using jar-collector. But this is a non-standard solution.
jgarnett: understood; and the maven "answer" is not that cool; it asks that you keep a directory structure around to keep stuff straight.
jgarnett: so martin; even though udig and geoserver can probably be made to work
jgarnett: I honestly think we need to put gt-main.jar into the repository for end users
jgarnett: we could negotiate
jgarnett: if we can make monthly releases for users that would help offset this.
jgarnett: but I would like some more users at some stage :-D
simboss left the room (quit: Connection timed out).
simboss_ is now known as simboss
desruisseaux: In this case, and if we want a directory layout matching the module name, there is no other choice than renaming directories...
jgarnett: I would like to agree on that; aaime what do you think?
aaime: jgarnett, found hibernate secret sauce: they are still not using maven
aaime: they only have it on trunk
aaime: but they are releasing from a stable branch using ant
jgarnett: The remaining questions for me come down to timing.
jgarnett: but how do they release to the maven repository?
jgarnett: using the maven-ant-tasks to deploy?
jgarnett: (or some other madness)
aaime: no idea
aaime: manually I believe, this pom is made up, it has no parent: http://repo1.maven.org/maven2/org/hibernate/hibernate/3.2.6.ga/hibernate-3.2.6.ga.pom
aaime: wicket does it with maven, but they renamed the dirs
aaime: http://svn.apache.org/repos/asf/wicket/trunk/
aaime: thing is, they have a very simple structure compared to gt2
jgarnett: question in the wicket pom.xml they have
jgarnett: <moduleSets> <moduleSet> <includes> <include>org.apache.wicket:wicket</include>
jgarnett: what is that syntax for include ?
aaime: dunno... the modules tag is standard
jgarnett: oh that was in wicket-assembly-all.xml
aaime: don't know... never tried to make a maven assembly
jgarnett: does assembly have anything to do with what is deployed?
aaime: I don't believe so... it's for releasing no?
desruisseaux: It put the JAR a single ZIP file.
desruisseaux: (including dependencies)
jgarnett: If I look here
jgarnett: http://mvnrepository.com/artifact/org.hibernate/hibernate/3.2.6.ga
jgarnett: it really looks like hiberante is deploying a single jar
aaime: yeah, they modularized it on trunk only
aaime: all of the other hibernate-something in maven repo are completely separated projects
jgarnett: yeah; okay - reminded that you said that already.
aaime: different version numbers and different svn
jgarnett: so martin it looks like we are boiling down to a single worhtwhile proposal
jgarnett: can we update that page; and include the steps for updating the user guide.
jgarnett: and aaime can you think of a good time to try this again for geoserver?
desruisseaux: Okay, will do tomorrow.
aaime: wondering... would be fixing mvn:site so hard? Or else, do we have reproted an issue there?
aaime: jgarnett, don't know, I haven't been working on gs trunk for ... a month maybe
jgarnett: I wondered as well andrea; but my guess is mvn site:site gathers up so many reports; that any of them could break us.
aaime: you break it, I won't even notice unless you break the build hard
jgarnett: I see; well uDig is using trunk hard; and I lose billable hours and have to have a meeting whenever trunk goes down for days
aaime: yet today I was working on it... trying to reduce build times (unacceptable long)
jgarnett: So I would like a couple days warning; and to try this out on a weekend next time.
desruisseaux: Fixing patially mvn:site is tedious but doable. One of my issue is that it requires explicit <scm> and <url> declarations that nobody maintains, and which always become wrong with time.
desruisseaux: But even if we get partial mvn:site, some reports will work and some other reports will not.
aaime: desriusseaux, yeah, but I was thinking for or a real bug fix in the maven site code, not a workaournd?
desruisseaux: Each reports is an independant plugin, so whatever or not is a plugin-by-plugin question.
aaime: yeah, ok, I get it, everybody just assumes users follow the maven standard practices
desruisseaux: Some assumes, other do not...
jgarnett: agreed; remember we had a lot more success when we renamed the src/main/Java folders .... it pays to not push the maven plug-ins beyond the defaults
jgarnett: (as sad a statement as that is)
aaime: jgarnett, really? I always wondered why
aaime: (why we changed, that is)
aaime: now that was really breaking merges, since you had to do two separate merges for each fix (one for the src, the other for tests)
jgarnett: I ended up having a lot less maven trouble after the change.
jgarnett: heh; I still mege from 2.2.x
desruisseaux: For having default (make pom.xml simplier and more reliable), but also for making some room for other language if we wish (I admit we are not yet there, but I was thinking about SQL, PhP or JavaScripts...)
jgarnett: wow the main stream press are on to us: http://arstechnica.com/news.ars/post/20080414-googles-kml-map-markup-language-now-an-official-standard.html
aaime: ok, I'm out of here.. bed time
jgarnett: aaime just a sec
jgarnett: I was trying to see about timing;
aaime: erk...k
jgarnett: you are telling me you don't care - and it is up to me?
desruisseaux: I will post an email tomorrow about the module name issue.
jgarnett: ie my request for a few days warning?
aaime: timing?
jgarnett: ie when should we do this...
aaime: I said I personally don't care
aaime: but other developer will care, and a lot
aaime: ask jdeolive
jgarnett: okay
desruisseaux: I will post an email tomorrow. Would it be okay Jody?
jgarnett: so martin; should we roll back the prefix change?
jgarnett: And then work through this proposal process ....
jgarnett: (that is what I am trying to figure out)
jgarnett: do we limp along right now; or do we rollback ...
desruisseaux: Could it be a question in my tomorrow email?
jgarnett: yes it can
jgarnett: okay thanks for the extra long meeting of doom
jgarnett: good luck with your symbol hacking aaime
jgarnett: (I am looking forward to it)
aaime: thanks
jgarnett: I can post the logs...
desruisseaux: Thanks all for your patience.
sfarber left the room.
aaime left the room.