Skip to end of metadata
Go to start of metadata

Agenda
0) what is up
1) verifier
2) poml.xml management for unsupported modules
3) GenericName vs Name

Action Items:

  • desruisseaux: will remove verifier from trunk and 2.5.x
  • jgarnett: will write up a proposal for handling unsupported modules

jgarnett* good morning
jgarnett This page still shows us meeting 3 hours from now
jgarnett - http://docs.codehaus.org/display/GEOT/3.1+Internet+Relay+Chat
jgarnett going to go over the past logs and figure out what to update the page to

desruisseaux (n=chatzill@mtd203.teledetection.fr) has joined #geotools

Eclesia (n=Administ@79.94.62.199) has joined #geotools

Eclesia (hi all)
desruisseaux Hi Eclesia
jgarnett good morning;
jgarnett it is meeting time.
jgarnett Shall we gather up some topics and get going ...
cbriancon hi
jgarnett 0) what is up 1) verifier 2) pom.xml management
jgarnett While we start I would like to thank Christian Muller for expanding his roll in the project; it is great to have

someone able to hunt down and squish ibm JRE related issues.
jgarnett does anyone else have topics for todays meeting?
desruisseaux not on my side
jgarnett okay it has been fine minuets so we should start.
jgarnett I am going to send a reminder email
jgarnett and I have updated the developers guide to reflect this meeting time:
jgarnett http://docs.codehaus.org/display/GEOT/3.1+Internet+Relay+Chat
jgarnett okay let's get our game on
jgarnett 0) what is up
acuster acuster---learning referencing for real this time, trying to understand what mathematical space(s) geometric

analysis needs to happen
jgarnett jgarnett - apparently breaking the 2.5.x build trying to sort our verifier and release artifact creation.

Reviewing 2.5.x proposals and user gide in anticipation of a 2.5.0 release. Looking into OGR bundling issues for udig and

generally being busy.
desruisseaux Martin: working in parrallel on ISO 19103 names and on mosaic work on 180,000 tiles.
jgarnett Sounds like you guys are having fun; thanks for the nice summary of naming issues on the geoapi mailing list

acuster.
jgarnett going to do a couple of pings and then carry on with the meeting
jgarnett jdolive ping
jgarnett groldan ping
emily_g emily: I made a few updates to the image mosaic code to allow additional styling parameters to be applied to the

images
jgarnett (I had really hoped to see simone as he is reviewing some of Emily's image-moasic work)
jgarnett 1) verifier
jgarnett We seem to be caught in a build loop on this one; it hits me every time we tag and try to make a release.
desruisseaux I suggest to just delete verifier.
jgarnett I was hoping we could use the build plugins to try out your ideas of "fixed version numbers" Martin.
acuster kill it
jgarnett okay that is a nice clear direction.
jgarnett thinking
acuster it doesn't catch our errors at the right time
jgarnett it did initially serve a value; it helped us find problems when we moved svn around right?
jgarnett (sorry for the review I am trying to make sure I have a good reason to vote to kill it; rather than just

annoyance you see)
desruisseaux When we move module directory? Yes it serves that purpose.
jgarnett can we make it an option? much like we did for code reformatting?

simboss (n=chatzill@host227-15-dynamic.27-79-r.retail.telecomitalia.it) has joined #geotools

jgarnett ie it would be nice to "verify" next time we move svn around ...
jgarnett this is a yes/no question .... I suspect we should probably kill it as well.
acuster too much work and no one cares enough to do it
jgarnett okay
jgarnett shall we move on ... wait this should give us an action item.
jgarnett I can remove it from trunk/
jgarnett not sure I have a 2.5.x checkout at work.
jgarnett do I have a volunteer with a 2.5.x checkout?
desruisseaux I can do the removal.
desruisseaux Will do it on both trunk and 2.5 branch.
jgarnett okay thanks martin
jgarnett and thanks for writing it up as well; it really did help during our svn group/name wrangling.
jgarnett 2) pom.xml management

awp_ has left freenode ("O.o")

jgarnett we ran into an issue with management unsupported/pom.xml last week.
jgarnett We have no clear guidelines on how to handle unsupported/pom.xml
jgarnett and we get in trouble over it every couple of months
jgarnett removing broken modules from the build; adding stuff to the build that takes too long to test
jgarnett and removing modules from the build that people are using.
jgarnett In general I expect PMC members to handle this as general "community support"
jgarnett (indeed the entire unsupported module experiment falls under "community support").
jgarnett So I got a question - are we doing okay on this topic as it stands? Or do we need to look into setting down some

procedures.
jgarnett For reference I had 3 developers go idle when we were messing around with unsupported/imageio-ext last week. So I

need to be able to tell management that we are handling this as a project
jgarnett and not wasting developer time.
jgarnett comments?
simboss honestly
simboss if we had followed the procedures
simboss nothing would have happened
simboss I think that was a matter of obstructionism vs procedures
jgarnett we have lots of procedures about modules (and letting each module maintainer work)
jgarnett but very little about the entire build system - other than to say it is the kind of thing PMC is responsible for.
simboss well
simboss as a baseline
simboss I would not expect people to take decisions without communication
simboss like it happened for the imageio-ext thing last week
jgarnett indeed; however it has been known to happen and known to be justified (usually in the case of me removing a

broken unsupported module from the build)
simboss that is specific compelling case
simboss which we could write down
simboss anybody can do that
jgarnett I am going over the developers guide and am seeing very little about a communication requirement; my assumption

here is that the PMC will to communicate.
simboss as a baseline I think
simboss that only cause for removing something from the build right away
simboss should be
simboss breaking the build
simboss everything else should need communication
simboss or better
simboss the module maintainer should have some degree of freedom
simboss the others a bit less
simboss but still
simboss I would not like to have someone
simboss remove a module
simboss even its own
simboss without notice
jgarnett I understand simboss; however we are in new territory here with both handling the pom.xml file and handling

unsupported modules.
jgarnett my default assumption is the module maintainer is responsible for their entry in the pom.xml.

cbriancon has left freenode ("Leaving.")

jgarnett I got in trouble for adding Ecleisa's work to the build when he was not ready for example.
jgarnett he was kind about it; but I was probably out of line. From my standpoint it was hard to collaborate with him if

his work was never in the build.
jgarnett I think we eventually used a profile to iron out that situtation.
jgarnett okay the fact that we have managed to talk for a few mins probably means the documentation / polices here can use

some work.
acuster Jody, I told you that I would trust your judgement, but if your solution implies that (1) anyone can propose a

unsupported module (2) that module can introduce any dependency and (3) that code gets deployed onto my hard drive, then I

am very vulnerable to the sloppiness of others
jgarnett acuster; it is true - we are taking on some up front risk and pain; in the hopes of pulling in new developers
jgarnett (and finding maintainers for code we would otherwise throw away)
jgarnett so far there are two downsides
jgarnett the risk you mention
jgarnett and for our existing developers to just make use of unsupported modules; because it is less work
simboss I am sorry acuster but I think you are shooting at a fly with cannonball
simboss we must be careful
simboss with the dependencies of the core libraries
simboss as we should have been with jaxb
simboss but as of plugins
jgarnett About the only strict restriction we have mentioned up front here is asking people not to commit data or jars

into the repository.
simboss it is quite simple
simboss dont want, don't use
simboss yeah
jgarnett it is not quite that simple simboss
simboss jgarnett++
jgarnett we are expecting people to checkout
simboss it is never simple
simboss but we need to move
jgarnett and include in their own build
jgarnett work they may not be interested in.
simboss somehow
acuster so why don't we throw all of unsupported into a profile
simboss I am fine with profiles
jgarnett we do that because we want as many eyes on the problem of api change and breaking stuff as we can get.
acuster that way I don't have to use any of it
simboss actually
acuster since I don't trust it
jgarnett acuster++
simboss that's how we handled the thing since the beginning
simboss we might have to ask aaime also
simboss to check if we are with the geoserver procedures
acuster yes, it was a strange decision to throw your work into the build with no warning
jgarnett simboss we have not been quite that strict; unsupported modules such as oracle have stayed in the build because

they are important to geoserver and udig as products.
simboss acuster: I agree
simboss but again
simboss building something routinely
simboss it does not mean
simboss we do not have to use profiles
CIA-35 desruisseaux * r31163 /branches/2.5.x/ (build/maven/verifier/ pom.xml): Removed build/maven/verifier plugin from

the 2.5 branch. Its look like that it was already removed from trunk, so both should be less troublesome now.

dany_r has left freenode ("ChatZilla 0.9.81 Firefox 2.0.0.16/2008070205")

simboss for selecting specific parts out of the whole library

  • Eclesia going ++
    acuster so what are the down sides of having a profile for unsupported?
    jgarnett I got lost in double negatives
    *--| Eclesia has left #geotools
    simboss the imageio-ext will stay unsupported as long as the gdal version we are waiting for won't be released
    acuster -Punsupported pulls them all in
    jgarnett the downside is we could break some code with out noticing.
    jgarnett the upsides are a reduced build time
    simboss yeah
    simboss a lot!
    simboss (smile)
    jgarnett and a reason for unsupported modules to want to upgrade their status.
    acuster but our response to breaking the code is to pull the module from the build anyhow, no?
    simboss but we could also have some specific profiles
    simboss to pull in only some of them
    simboss of course!
    jgarnett okay this is giving me some material to work with
    jgarnett I will write up a proposal for the handling of unsupported modules
    simboss if the geoserver guys wants to build with imageio.-ext enabled
    simboss they can do that
    simboss like we do
    simboss but as rule of thumb
    simboss we should build with most of them disabled
    simboss sorry
    jgarnett to really clarify it is an svn "work in progress space"; the contents are only enabled through profiles; and none

of it shows up in our prepackaged downloads.
simboss all of them
simboss yeah
simboss I agree
simboss so that everyone is happy
jgarnett martin / acuster feedback?
jgarnett I don't want to spend time writing up a proposal if this is going to be a stupid idea.
jgarnett desruisseaux ping?
desruisseaux Yes
jgarnett I am thinking of writing up a proposal about unsupported module handling; I was going to get a sanity check from

you before starting.
acuster personally, I like the idea of having them all out of the build
jgarnett the idea is to push the unsupported modules out of the build; only using profiles to add them in. And clarify the

fact that we don't ship them.
acuster and an easy way to include them all for those who want to see what they have broken
jgarnett acuster++ this does sound like a good way to handle this.
acuster it will make the transition to supported even more fun
jgarnett okay I will write this up and we can revise via email.
simboss i would also like to have the ability to turn my own module
simboss just in case
desruisseaux The above proposal (maven profile) can be a good mid-term compromise. A longer term approach may be to split

the SVN on two separated versionning system: "core geotools" and "experimental", with the experimental modules depending on

core milestones rather than snapshots.
acuster but the issue of what unsupported modules are allowed to pull in still seems relevant as long as the code uses a

centralized versioning system
simboss to do selective build
jgarnett simboss I was thinking of leaving that in the hands of the module maintainer? That makes sense does it not?
simboss it is perfect
jgarnett martin if possible I would like to use the same svn; remember my goal is as much getting new developers as

getting more code.
acuster martin, I like that. We should think about setting up a dummy maven and directory layout so users can (1) build a

module that depends on the "core"
acuster then (2) integrate that someday into the 'core'
jgarnett acuster; your point is valid - can we address that when a module tries to become supported? Or do we want to put

down some guidelines like we have for committing data and writing test cases?
desruisseaux The "split SVN" proposal is a long-term one. Not for anytime soon, so we can come back on it later. In short

term, maven profile would work.
jgarnett understood
acuster when a module wants to be supported, there should be an explanation of what it does, what it pulls in, and other

issues, yeah.
simboss I agree.
jgarnett and docs (smile) (I always need to mention docs)
jgarnett okay guys that sonuds like a wrap for the meeting.
jgarnett Martin we had some issues with Java 6 and IBM JRE build failures
jgarnett is that anything we need to talk about?
acuster but regardless, modules, supported or not, have a responsibility to follow the law, and be careful about what they

are depending on, no?
jgarnett or can we put it off till later.
desruisseaux I saw the email. The Java 6 issues are actually existing for one year or so.
jgarnett acuster - see above - I was trying to ask you that. I think there are some limits (such as we run into with ESRI

jars)
jgarnett but we will need to carefully word the issues so it makes sense
jgarnett (I wrote a blog post http://how2map.blogspot.com/ on the topic but I am not sure anyone read it)
jgarnett but yeah I agree with you; there are limits on the dependencies allowed - we just need to figure out what they

are so we can communicate them well.
desruisseaux I will fix the Java 6 issues, since geotidy is targeting Java 6 - so there is no way I can work on

referencing without fixing those issues. It is just that I need to finish GeneralName and its friend before to move on

referencing, since referencing depends on it.
jgarnett I am interested in how you are planning to fix GeneralName
acuster (1) by not making it a repository system
acuster i.e. no pointers to object
jgarnett the relationship between GeneralName and Record is what pretty much stopped my agressive geoapi work.
acuster ah, I have been ignoring Record. (smile)
acuster Martin probably knows more
acuster and has javadoc links
desruisseaux http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/util/GenericName.html
jgarnett acuster++ (now if you can do this before 2.5.0 goes out we can kill org.opengis.feature.Name)
acuster aha, now that's incentive
desruisseaux Tried to clearify the meaning of "head", "tail", "path" and "tip" with a figure.
jgarnett the "name as repository / reflection" story is what stopped us cold (after three months emailing bryce)
acuster yeah, they want to do a catalog system in the identification system
acuster with basically no documentation
jgarnett acuster - yeah someone finally sees my conflict (smile)
acuster even if it could work, it's bad standards writing
jgarnett now that said they have a reason
jgarnett they actually want a catalog system
jgarnett (not an identification system)
jgarnett ie my take on it last time is we went into the standard looking for the wrong answer.
jgarnett I basically decided that the "Name" part of GenericName / LocalName was misleading us
jgarnett into thinking we were looking at an identification system.
acuster surely we can start with an id system and build a catalog system on it later?
jgarnett Thus I could justify the creation of org.opengis.feature.Name as an identification system.
acuster does record need a catalog system to work?
jgarnett yeah it basically demanded it
acuster if you have time to look at what martin has done
jgarnett the deegree people dodged the issue and made their Record extend Feature.
acuster you could tell us if it satisfies the feature system
jgarnett my best idea yet is to make our Name in geoapi an identificaiton system
acuster it's attempting to be merely an id system
jgarnett and advise people to use something like JNDI for their catalog / reflection system.
acuster yes, we can cross that river when we want to build a record bridge
jgarnett What is your timeline martin? I am not going to have time to review (seriously review) until next week
acuster who uses records anyhow?
jgarnett coverage
jgarnett and catalog should use it
jgarnett both problems have lead me against it (and to asking for help on the geoapi list) previously
jgarnett catalog is supposed to return records
acuster I don't think martin has dealt with the issue of separator yet
jgarnett records that are described me one or more metadata.
acuster yeah, so catalog is a bigger deal that we can tackle on its own
jgarnett I was meaning formal OGC Catalog spec.
jgarnett not the ISO GenericName / LocalName / Namespace split.
acuster it may be as simple as adding a sub-class to name-the-id-version
desruisseaux About my time frame: I'm working on name mid-time, since I have to work on a mosaic in same time. So it may

take me a week before I have an implementation to suggest.
acuster which has a .getObject() method
jgarnett acuster that may be a useful hack; it goes against a bit what the ISO spec is trying to do does it not?
jgarnett ie if I look at a record that has MemberName(s)
jgarnett the MemberName(s) actually are the child objects.
acuster perhaps you are right
jgarnett if we make a getObject() method
jgarnett it would demote them to being like Map.Entry
jgarnett (not that that would be a bad thing - the ISO spec seems really poorly thought out in terms of a split)
acuster again, I have happily ignored record
jgarnett or our thinking approach is wrong.
jgarnett okay please look into how people use Name; even what we have as FeatureType right now
acuster so maybe we split GenericName into two hiearachies, one for id and one for cataloguing
jgarnett is supposed to literally extend Name
jgarnett something
acuster ouch

awp_ (n=chatzill@mvx-200-142-99-114.mundivox.com) has joined #geotools

acuster okay, will take a look
jgarnett I wish I had a good approach to recommend acuster; we often talk about difficult problems together? This is a

problem that has kicked me down a few times.
jgarnett so I am really looking forward to a fresh pair of eyes.
acuster to prepare my seething for the next OGC meeting
jgarnett and sorting out Record / RecordType would immediately benefit the CoverageAPI which I find "unbelievable" in its

current form.
awp_ Hello all, how can I edit http://geotools.codehaus.org/The+axis+order+issue ? (Just to update the code example on

"What GeoTools Does", which is using FactoryFinder instead of CRS)
acuster yes we have all lost the battle with name several times over, you, Martin, Bryce, me, and probably justin and

gabriel
jgarnett hi awp; our meeting is just ending so can I ask you to hold your question for a few more moments?
awp_ sure thing, sorry about that
acuster awp_, on the front page there are instructions on how to signup for editing rights
acuster we are done?
jgarnett acuster I was going to try it again when I had beaten a formal set of Names (ie a vocabulary) out of someone like

RobA. And see if it all made sense if I started with the right problem for the API.
jgarnett right now we do a few horrible things to report back records out of coverages; and then I have watched our

mistakes get repeated.
acuster nice, we should do that (the beating RobA. part).
jgarnett but yeah I will stop ranting and write up the logs.
acuster thanks for running the meeting
jgarnett thanks for the productive chat.
jgarnett awp_ ping? the floor is yours.

  • No labels