The IzPack project is proud to announce the release of:

• IzPack 4.0.1, a maintenance release of IzPack 4.0, and
• IzPack 4.1.0-beta1, a first preview of the upcoming IzPack 4.1 for testing purpose.

IzPack is a one-stop solution for packaging, distributing and deploying applications. IzPack is a project hosted by Codehaus.

IzPack is fully cross-platform and generates a single installer. As such, it is an alternative to native solutions such as platform-specific installers and package managers.

Both versions can be downloaded from the project download page at http://izpack.org/downloads. A list of IzPack main features is also available from http://izpack.org/features/.

Many thanks to the developers and contributors that have made this release possible!

Release notes:

• IzPack 4.0.1 release notes
• IzPack 4.1.0-beta1 release notes (work in progress)

The JRuby community is pleased to announce the release of JRuby 1.1.3!

Homepage: http://www.jruby.org/
Download: http://dist.codehaus.org/jruby/

JRuby 1.1.3 is the third point release of JRuby 1.1.  The fixes in this
release are primarily obvious compatibility problems and performance
enhancements.  Our goal is to put out point releases more frequently for
the next several months (about 3-4 weeks a release).  We want a more
rapid release cycle to better address issues brought up by users of JRuby.

Highlights:

- RubyGems 1.2
- Greatly improved interpreter performance
- jrubyc compiler usability improvements and bug fixes
- Reduced memory usage and object churn
- Dozens of IO-related and core class RubySpec fixes + reduced memory for IO
- ThreadGroup fixes to resolve Mongrel "dead thread" issues
- New options/properties for tweaking JIT, thread pooling, and more
- Block invocation performance improvements
- Much faster Time performance
- Much better support for --debug
- Mentioning that context classloader fix would be nice
  (since it quite user visible, and many users seen/asked for it).
  JRUBY-2495
- 82 issues resolved since JRuby 1.1.2

Issues fixed:
JRUBY-2495        Requiring and using a Java library that ends up using a Thread Context classloader doesn't work.
JRUBY-2582     Strip out gem cruft dring ant dist
JRUBY-2584     Comparable#== behavior differs from MRI
JRUBY-2585     Hash.[] should call to_hash if only one argument is provided
JRUBY-2590     [1.8.7] SecureRandom crashes, fails new rubyspecs
JRUBY-2592     Two JRuby crashes on Readline::HISTORY rubyspecs
JRUBY-2598     Rubygems installs non-functioning BAT files on Windows
JRUBY-2601     New default for jruby.jit.threshold property is not reflected in the --properties listing on jruby command line ref. JRUBY-2514
JRUBY-2605     Kernel.eval with yield behaves differently than MRI 1.8.6/1.8.7, causes some libraries failures with JRuby
JRUBY-2607     Gather all JRuby RubyGems changes out of RubyGems libs and into a single monkey-patching file
JRUBY-2614     StringIO#readlines("") hangs JRuby
JRUBY-2615     IO.popen doesn't allow shell commands to access STDIN
JRUBY-2617     gem install appears to be bulk updating every time.
JRUBY-2623     Rubyspec failures for StringIO's #close, #close_write, #close_read and #<<
JRUBY-2624     Object#initialize_copy should always be private
JRUBY-2625     IO#read_nonblock is broken
JRUBY-2628     StringIO's methods (new and truncate) should raise appropriate exceptions
JRUBY-2629     StringIO#<< and various read methods crash ruby if invoked on only-allocated object
JRUBY-2630     direct loading .class files fails with an IO Error
JRUBY-2631     jruby's select() doesn't properly handle objects that implement to_io
JRUBY-2632     IO#readpartial doesn't handle unget char
JRUBY-2633     Kernel#select with non-array argument crashes JRuby
JRUBY-2635     IO#readpartial crashes when negative argument is specified
JRUBY-2636     IO#readpartial doesn't honor maxlength parameter and always returns the whole buffer content
JRUBY-2637     Channelstram should null the buffer in close()
JRUBY-2638     StringIO#initialize_copy is not implemented
JRUBY-2644     TCPServer#close doesn't interrupt any pending #accept's
JRUBY-2646     NullPointerException when trying to invoke method whose arity is three and that is given a block.
JRUBY-2650     Block construction/instantiation is slower in compiled than interpreted
JRUBY-2652     NativeException does not have a direct accessor for the wrapped exception
JRUBY-2653     test_threaded_nonlocal_return test sometimes fail with an apparent threading issue
JRUBY-2659     Stringio#ungetc crashes JRuby in some cases
JRUBY-2660     More than 30 rubyspec failures for StringIO
JRUBY-2662     Tag or fix remaining OS X spec failures
JRUBY-2664     --debug option on Windows is broken
JRUBY-2667     Plenty of new StringScanner failures for JRuby
JRUBY-2669     StringScanner#peek crashes JRuby in some situations
JRUBY-2671     NullPointerException when converting an Array of Ruby that includes an instance of java primitive class.
JRUBY-2677     Problem in Process Command Line Arguments
JRUBY-2679     Selectively Disable JIT Compiler using command line options
JRUBY-2681     Multiple IO#readlines rubyspec failures
JRUBY-2683     Regexp#to_s behaves differently than MRI 1.8 or MRI 1.9
JRUBY-2684     gem management requires too much memory
JRUBY-2687     Socket.for_fd generates ArgumentError when running EventMachine gem (pure_ruby version)
JRUBY-2692     Bigdecimal#add never uses the precision arg, fails new rubyspec tests
JRUBY-2693     PROGRAM_NAME is not available in the modules included via -r command line option
JRUBY-2694     [1.8.7] Ability to specify suffix/extension for Tempfile
JRUBY-2695     Exception in the thread is not printed when Thread.abort_on_exception is set to true
JRUBY-2696     Kernel.raise should print the one-line exception info to $stderr in DEBUG mode
JRUBY-2698     Time.new inconsitencies
JRUBY-2699        If user's PATH contains '.' and 'jruby' resolves to './jruby', JRUBY_HOME is incorrectly set to '.', leading to 'NoClassDefFoundError'
JRUBY-2704     Upgrade rubygems to version 1.2
JRUBY-2707     JRuby does not load AOT compiler escaped name
JRUBY-2709     Interpreter crashes on a new rubyspecs for rescue
JRUBY-2710     CGI#out fails new rubypecs, prints results to original stdout rather than to the redefined one
JRUBY-2711     RubyArray keeps references to unreachable RubyObjects after clear, reject!, delete and delete_at
JRUBY-2713     AOT Compiler should default to no prefix
JRUBY-2714     Major performance slowdown when loading AOT compiled file
JRUBY-2717     Dir[..] does not accept more than two arguments
JRUBY-2719     Mongrel can't handle heavy load, fills up with threads and starts dropping connections
JRUBY-2721     ThreadGroup should not ever hold on to dead threads in its list
JRUBY-2722     Interpreter passes absolute path to the EventHook for 'require'ed files
JRUBY-2723     Interpreter passes wrong position on 'return' event
JRUBY-2728     Deadlock in Thread#exit when being joined from outside
JRUBY-2729     Kernel#caller should not cut off at eval like backtraces do
JRUBY-2730     Multiply-binding JRubyMethods with meta=true are not processed correctly by AnnotationBinder
JRUBY-2731     Significant speedup of Time methods (up to 300%-400% in some cases)
JRUBY-2733     StringIO#each_byte doesn't update pos, fails new Rubyspecs
JRUBY-2735     String#% should use to_ary to convert the argument to Array
JRUBY-2738     TCPServer#peeraddr on crashes JRuby
JRUBY-2742     Major code duplication in BAT files
JRUBY-2751     Array#fill should return self instead of raising an error when length is negative
JRUBY-2753     c-return passes different 'file' then c-call for load and require
JRUBY-2769     I/O Error (sysseek for buffered IO) when using reliable-message library
JRUBY-2770     IO#sysseek after IO#sysread raises IOError
JRUBY-2773     Crashes when using Enumerator#to_enum with Threadify#threadify
JRUBY-2779     Race condition in IO
JRUBY-2781     Can't compile Build 7142
JRUBY-2786     Lots of JRuby crashes on ARGF methods
JRUBY-2789     IO#read crashes JRuby when pos is bigger than the file length
JRUBY-2809     Not all at_exit blocks are being executed.
JRUBY-2814     release jna-posix and update jruby afterwards

Starting from today, the official IzPack news will be delivered from the IzPack Confluence space at Codehaus!

The RSS/Atom feed remains unchanged: http://feeds.feedburner.com/IzPack

Agenda:

1. what is up
2. OSGeo Representative
3. GeoTools 3.3
4. SoC Status Reports

Action Items:

1. jgarnett nominated as OSGeo representative

jgarnett: okay time to go
jgarnett: aaime it is now time right? So we can get you for 15 mins ...
jgarnett: Good morning Martin; anything for the meeting?
aaime: yep
aaime: for 13 minutes actually
desruisseaux: Hello Jody and all
jgarnett: I assume we are going to miss a few people with the new meeting time and all ...
jgarnett: so let us start
jgarnett: 0) what is up
aaime is working on speeding up the KML superoverlay code in GeoServer
jgarnett - udig now renderers; trying to review what is needed for 2.5.0; and generally happy it is summer
Eclesia1: hi al
jgarnett: Morning all ... topic 0) has already started; you know the drill - single line saying what you are up to. If anyone is up to something interesting you can chat with them on email.
jgarnett: 1) OSGeo Representative
jgarnett: Okay FrankW asked me today about our current osgeo representative form the PSC
Eclesia1 ahs prepared the style upgrade for 2.6.x, but has 4 last test failure in some stremaing renderer tests, but the code has no comment and is ... strange, so i cant fix those
desruisseaux: Martin: various task (cleaning, a bit of coverage work, etc)
jgarnett:
jgarnett: moving on ...
jgarnett: I started out in this roll but burned out - I think acuster took over. Can you confirm Martin?
jgarnett: (I am searching the email archive)
desruisseaux: You means for the PSC representative?
FrankW: Note, the OSGeo reprsentative is normally the PSC chair.
FrankW: Do you guys have a chair?
jgarnett: looks like cholmes has volunteered.
FrankW: This will be the person named VP, GeoTools and expected to speak on behalf of the project, and answer on it's behalf.
jgarnett: We have a project management committee
aaime: we had one eons ago, but we don't really have a chair anymore in our PSC
jgarnett: we had James as our tie breaker.
jgarnett: Email record shows chomes as our representative after me; Dec 12 2006.
desruisseaux: There is Ian Turton as the historical creator of the project (together with James)
aaime: I hardly believe he has time
jgarnett: - http://www.mail-archive.com/geotools-devel@lists.sourceforge.net/msg05935.html
jgarnett: Indeed he later stepped down from the PMC did he not?
aaime: he did
desruisseaux: I don't know.
jgarnett: okay I will volunteer for this one
aaime: so we're chair-less
aaime: jgarnett++
desruisseaux: +1 for Jody
jgarnett: well this is more a representative to the OSgeo foundation; so not exactly a chair.
FrankW: I believe Chris was the incubation rep.
FrankW: This isn't the same thing - or at least it does not need to be.
FrankW: I would think the VP GeoTools should at least be on the PMC!
FrankW: The rep is traditionally the chair though it is not strictly necessary.
jgarnett: oh I see ...
FrankW: From what I've seen, I think jgarnett is the logical choice if he is willing.
jgarnett: Okay - so I will need to write this down on the inncubation page I guess Frank?
jgarnett: And will put it in our developer guide as well.
FrankW: It doesn't have to be on the incubation page.
FrankW: But I do think you could note it in your PMC docs.
jgarnett: http://docs.codehaus.org/display/GEOT/4+Project+Management+Committee
jgarnett: done
jgarnett: So my role for this will be communication monkey
jgarnett: rather than code monkey.
FrankW: It would be best if jgarnett was put in this role by a vote of the PMC.
aaime: here is my vote
aaime: and now I really have to run away
jgarnett: aaime can you make the motion.
aaime: vote for jgarnett to be osgeo representative
aaime: +1
aaime is now known as aaime|away
jgarnett: +0 (since I am being nominated)
desruisseaux: +1
jgarnett: simone and jdeolive are on holiday
lreed [n=lreed@mail.refractions.net] entered the room.
desruisseaux: I don't think they would object.
jgarnett: Ian T is MIA (the joys of academic life may be too much for him)
jgarnett: I will send an email out; Frank this can be offical as the votes come back in.
FrankW: OK, thanks folks!
FrankW: jgarnett: I'll assume it will be ok, unless I hear otherwise. Use whatever your process calls for.
desruisseaux: Are we done with topic 1?
Eclesia1: (+1 for jody ^^ )
jgarnett: well I should of probably voted +1 so you could of gotten an answer right now; but we can wait a few days.
jgarnett: :-P
(9:48:32 jgarnett: 2) GeoTools 3
desruisseaux: Thats mine
jgarnett: martin the floor is yours; personally I like the range of ideas expressed thus far - I think we have lots to work with.
desruisseaux: We would like a GeoTools with some cleaning in it. Adrian proposed the "geotidy" name.
desruisseaux: (as a code name; could be GeoTools 3 or something else as people wish)
desruisseaux: We can not really continue very long to work on GeoTools 2.
jgarnett: I would also like the same thing
jgarnett: but I think we need to negotiate a bit on what tidy means
desruisseaux: Moving on distributed versionning system make easier to express a wider range of opinions.
desruisseaux: It also reduce the pressure to commit unfinished stuff.
jgarnett: martin we need to get some documentation on the distributed version control thing
jgarnett: we have some contributors that really need this.
jgarnett: (I have tried asking for a couple of weeks; can you write down even some quick notes to help them get started)
jgarnett: (I can make that a seperate agenda topic if you like)
desruisseaux: There is on-line tutorial on Mercurial
desruisseaux: How they will applied exactly to GeoTools is to be determined
desruisseaux: since we are still setting up what may be GeoTools 3.
desruisseaux: Peoples can start with that: http://www.selenic.com/mercurial/wiki/index.cgi/UnderstandingMercurial
jgarnett: So martin one of the things I want to emphaise here is communication; we had a hard time communicating with Simone when he was on a branch for a year. I am hard pressed to see how distributed version control is going to help matters stay on track; it is very attractive for groups of developers to go off on branches in order to make some tight deadlines - and then expensive to merge back in; go through the community process of collaboration and all that.
jgarnett: So I think that setting up a few policies
jgarnett: around the use of mercurial
jgarnett: is a great place to start.
jgarnett: Does that make sense; we have some great ideas on what geotools 3 can be.
jgarnett: And some wonderful opperunities based on the new work your organization; and several other organizations are getting involved in.
jgarnett: I want to make sure we are prepaired
jgarnett: before we open up GeoTools 3 for hacking.
CIA-32: jezekjan * r31012 /trunk/spike/jan/gsoc-transformations/src/main/java/org/geotools/referencing/operation/builder/GridParameters.java: Spike/Jan - Bug with negative array fixed
jgarnett: I have said I was prepaired to scope this out after OSGeo graduation; and thanks to some heroic efforts on acusters part we are now there
jgarnett has changed the topic to: 0) what is up 1) OSGeo Representative 2) GeoTools 3 3) SoC Stauts Reports
jgarnett: So what would you like to do martin? When can we start this discussion
jgarnett: is it something to handle at the PMC level?
jgarnett: Or should we as a responsible PMC consult the various organizations that fund our work? Refractions, GeoMatys, Open Planning Project etc...
desruisseaux: We could start the work and put a repository on-line on a geomatys server, so peoples can take a look if they wish.
jgarnett: I am not sure that would help Martin
jgarnett: part of the thing here is that we have a credibility crises here for GeoMatys
jgarnett: in terms of communication and control
jgarnett: still open development here would be good;
jgarnett: anything we can do to communicate your priorities; and what is happening with GeoAPI and so on would be excellent.
jgarnett: But perhaps I am thinking from another angle from you?
jgarnett: For me there is no repository yet; there is no GeoToold 3 project yet.
jgarnett: I need to get a "mandate" (something we can all believe in)
jgarnett: and then search for the correct venue; timeline; etc...
jgarnett: I am starting to entertain svn on osgeo hardware; and distributed version control to allow teams to work together (rather than branches)
jgarnett: but I need us to tell a better story then we did for GeoTools 2; both in terms of allowing teams to work together
jgarnett: and in terms of common goals.
desruisseaux: I would like to express the reasons why we are heading in the direction of GeoTools 3
jgarnett: I think we did a lot of that on email; the good news was that we all have similar motivations and similar scope.
desruisseaux: When I joined the GeoTools project 5 years ago, I was dreaming of a library
desruisseaux: I was hopping to build the best open source geographic toolsbox around (at least in the java world)
desruisseaux: As the years goes one, GeoTools became more like a bazar
desruisseaux: Patches submitted under time constraints
desruisseaux: While I come from a world where we try to think in longer terms
desruisseaux: (sciences vs business)
desruisseaux: Adrian and myself had strong disagreement with other member in this community
desruisseaux: But I stands with Adrian on most points. He have a quality that I appreciate a lot, which is sadly very uncommon in this community: rigor
iant_ [n=ijturton@96.235.253.34] entered the room.
desruisseaux: The fact that Adrian and myself are the only ones with a scientific background my be part of an explication why we are having a hard time to be in agreement with the business view.
jgarnett: Understood
jgarnett: Martin I also have a long term plan in terms of API; usefulness and community.
desruisseaux: I was hopping a library released on a "when ready" policy; but in practice it is developped on a "when the client want it" or "when geoserver want a release" policy.
jgarnett: Now we each have different capabilities in terms of funding this dream; so far I am only able to get small chunks of time/money and as such have not been able to do all I have wanted on each day.
jgarnett: The stratagy for GeoTools 2
jgarnett: has been to build it because it is needed
jgarnett: once we have a working implementation
jgarnett: back it on to formal geoapi interfaces
jgarnett: as they are made available.
jgarnett: We are always caught in the conflct because GeoTools is a library used to develope
jgarnett: the standards as well as to implement them when they are published.
jgarnett: So I like this cycle.
jgarnett: However GeoAPI side lost some steam; so one of the things I would like to see for GeoTools 3 is a swift kick to get the GeoAPI project moving?
jgarnett: Does that make sense? I think it is compatible with both your goals; your companies goals; and the need to ship a useful library all the time.
desruisseaux: I was wondering if GeoAPI could be the glue between GeoTools 2 and GeoTools 3 (making easier to switch to geotools 3), with the side effect of increasing his credibility?
jgarnett: In short I find I need both sides (sciences and business) to have a library that is both correct (yeah siences) and timely (yeah business).
jgarnett:
jgarnett: that is a good idea; migration stratagy is to use GeoAPI interfaces.
jgarnett: that has a lot of upside.
desruisseaux: I agree that there is both world (sciences and busincess) to conciliate
jgarnett: Now for GeoTools 2 we had a mandate - implement GeoAPI interfaces as they became available.
jgarnett: We did not quite get buy in for that mandiate all around; as an example (just like for documentation) there was not always budget to formally define a GeoAPI interface
jgarnett: for each deadline.
jgarnett: I think that is actaully really good.
jgarnett: because frankly a correct GeoAPI
jgarnett: that does not have a couple of implementations (and thus represent a compromise)
jgarnett: is pretty silly or not credible to me.
jgarnett: I am not sure how you feel about that?
desruisseaux: I believe that there is 2 things we need to do in order to get more GeoAPI implementations:
Eclesia1 is now known as Eclesia
desruisseaux: 1) make it alive as an OGC working group (a way to do "marketing")
desruisseaux: 2) Creates a test suite for GeoAPI implementation, which would give a clearer benefit for implementors to use this project.
desruisseaux: #2 implies moving some Geotools tests to GeoAPI.
jgarnett: yes to both counts
desruisseaux: Adrian is already preparing that for geometries.
jgarnett: the test case code should be either LGPL or Public Domain
jgarnett: (for obvious reasons)
iant_: couldn't we define GeoTools as the reference implementation of GeoAPI?
jgarnett: I am not sure that would be smart Ian
jgarnett: we make compromises to GeoTools to "get it done"
iant_: I'm not sure how you'd define tests for interfaces
jgarnett: for GeoAPI we often want to "Get it right"
desruisseaux: I would like that, but not from our initiative. It would be nice to get that words from OGC.
jgarnett: even at the expense of usability.
desruisseaux: We could select onyl a subset of geotools
desruisseaux: to be proposed as reference implementation
jgarnett: ianT_ you can inject a factory into the test case; implementors would subclass the test case.
desruisseaux: But the decision would need to be OGC's one (I don't think they would object if our implementation is correct)
jgarnett: Martin let me bounce an idea off you
iant_: OK
jgarnett: (and then we should think about wrapping up this meeting in 10 mins)
jgarnett: One way to get more GeoAPI implementations is to make more GeoAPI implementations.
jgarnett: consider GeoTools as the nice friendly beast we know and love from GeoTools 2
jgarnett: And a GeoTools Kernal or something
jgarnett: that has all the strict implementations.
jgarnett: As an example our Filter implementation today contains a lot of backwards compatibility loving code and hacks.
jgarnett: A second implementation that avoided all that would a) be fun b) be clear c) be intergrated with GeoTools at a Factory / GeoAPI level.
jgarnett: ie; we need more than one implementation to be crediable.
desruisseaux: But could this second implementation be proposed as part of GeoTools 3?
jgarnett: there is nothing stopping us from providing several implementations.
jgarnett: I am talking about the structure of GeoTools 3
desruisseaux: Fine
jgarnett: ie how to set it up as an interesting project; with room for collaboration etc...
iant_: I'm not sure how much credability it gets us if both implementations come from GeoTools
jgarnett: in a sense this would be very much "Eating our own dog food" on the factory front.
jgarnett: Iant_ ++
jgarnett: Iant_ I agree on the credibility side of things
jgarnett: but there are two levels here;
jgarnett: in terms of the java community GeoAPI was set up to provide a venue for communication
jgarnett: recent Java Collab discussions
desruisseaux: For GeoAPI, I think that we really need to find the time and energy to support a OGC working group. We need a chair and members of at least 3 different organizations.
jgarnett: have left me a bit cold; I don't think other projects are interested in collaborating at this level.
jgarnett: but I know from experience that commercial and research organizations are
jgarnett: (indeed behind the scenes they funded most of my geoapi / geotools / standards work)
jgarnett: so there is a roll here - but it may not always be with other java open source projects.
desruisseaux: As long as GeoAPI provides only interfaces, other projects may see it as just constraints. But if we provides a test suite for this interfaces, they are starting to see benefit in implementing them. If in addition we migrate for example the OpenOffice plugins from GeoTools to GeoAPI, they would have yet more benefit.
jgarnett: IanT - to finish. Even with two implementations from geotools memebers I would feel more comfortable and trusting of a geoapi interface.
desruisseaux: (assuming some are interrested in a OpenOffice plugins)
jgarnett: (I never want to repeate the SYS_TECHNOLOGIES experience)
jgarnett: martin we may need to offer a bit more than test cases; but it is a start.
jgarnett: Let me give an example; if we can start offering geotools modules as reuseable components
jgarnett: the boundaries of which are defined
jgarnett: using formal geoapi interfaces.
jgarnett: we may have something.
jgarnett: (But we got to work on thouse interfaces / boundaries)
jgarnett: there is a blance between correct and simplicity that we don't hit
jgarnett: and we can measure the lack of success
jgarnett: Still there are good ideas all around here; and good examples.
jgarnett: I find it amazing that the old CoordinateSystem implementation
jgarnett: is winning out the deegree community
jgarnett: over the new CoordianteReferneceSystem?
jgarnett: I don't even undertand how that decision is worked out?
jgarnett: DO you have any insight martin?
desruisseaux: I have theory
jgarnett: Is the old CS implementation that much more simple?
desruisseaux: The old CS implementation is simplier and closer to WKT, but it was to simple.
jgarnett: Or is it just a lack of control issue? So much process behind GeoAPI that developers would feel at risk ?
desruisseaux: On the Degrees using the old CS, the main issue is that they are not seeing the difficulties of referencing.
desruisseaux: They are discovering it as they progress
desruisseaux: And they are redoing what is already done in current geotools implementation.
desruisseaux: For example the post last week about how to get the CRS that are valid over the USA.
desruisseaux: By not trusting ISO 19111, they do not admit that the referencing issue is more complex that they believe
desruisseaux: And they are discovering the complexity progressively
desruisseaux: For example in the old CS implementation, there is no way to known if a CRS use a cartesian, ellipsoidal or spherical coordiante system.
desruisseaux: Soon or later, when they will want to do serious mathematic, they will hit this wall.
jgarnett: hrm
jgarnett: so what we have here is a communication problem
desruisseaux: You can not do all yours mathematic as if the everything is cartesian.
jgarnett: (ie I am sure you communicated correctly; but sometimes communication problems can be with respect to listening)
jgarnett: We also need to publish how amazing geotools is more often
jgarnett: Unless we write articles and talk about how nice it is to have a good coordinate reference system implementation
jgarnett: nobody will notice when they google the topic.
jgarnett: (right now if they google most of what they find about geotools is bursa wolf transform parameter questions)
jgarnett: but that is more of a PMC / publicity issue
jgarnett: one we should be able to turn to now that OSGeo graduation is winding down.
desruisseaux: Justin pointed out that not having the referencing module downlable as a single JAR is a major reason.
jgarnett: yeah that is a big one.
jgarnett: you know what.
jgarnett: that - and just that
jgarnett: would make an excellent "first" geotools 3 component.
jgarnett: (the idea of bundling geotools components seperate is a good one; you saw my email on version numbers)
desruisseaux: I had this idea in mind, and this is also a reason why I'm pushing for geotools 3.
jgarnett: well starting out with a message everyone likes is a good move
desruisseaux: Yes I saw your email - I was not sure if it would be easy to do or not.
jgarnett: (you know the pressure of science vs buiness means this first component will have to be "referencing for JTS" :-D )
desruisseaux: What would look like referencing for JtS?
jgarnett: it may not be easy; but we should tell some story with the version numbers.
jgarnett: that is a good question - what referencing for JTS would look like.
jgarnett: I have some quick ideas;
jgarnett: CRS facade + JTS facade
jgarnett: store the CoordinateReferenceSystem object in the Geometry.getUserData()
jgarnett: and use that maven plugin to hunt down all other stuff.
jgarnett: ie fold this into a single download = geoapi interfaces, various geotools classes - and epsg-hsql
jgarnett: does that sound about right?
jgarnett: note the normal GeoTools 3 referencing module would be more general;
desruisseaux: Yes it was my plan to provide a single JAR with what peoples need
iant_: have you seen the fatjar project on sourceforge?
jgarnett: this JTS+referencing thing would be a seperate "product" -
desruisseaux: Yes I saw fatjar
jgarnett: no; but martin found a slick plug-in for maven.
desruisseaux: And I'm thinking about using it
desruisseaux: I think that the Maven plugin used fatjar
iant_: I've used it for some of my projects and i works well - plugs in to eclipse
jgarnett: (aside: iant_ if you can vote on a couple recent proposals - we miss you!)
jgarnett: Okay this was a good discussion
iant_: (already voted for you as osgeo rep)
jgarnett: Martin I need to stay cool for a couple more weeks; and have these discussions with you
jgarnett: and then we can get serious and start some formal planning.
jgarnett: does that meet with your timelines at all?
desruisseaux: As of referencing in JTS, getSRID doesn't have to be EPSG number right? So it could be numbers generated by GeoTools and uniquely assigned to a CRS in a running JVM (or does it have to be persistent between different JVM executions)?
jgarnett: oh good thought there...
jgarnett: I suspect that some implementations will store the SRID number
jgarnett: (I know for POSTGIS we make use of this number to reference the Spatail_Ref_SYS table)
jgarnett: but that is a good thought.
jgarnett: 3) SOC Status reports
jgarnett: wolf was collecting them
jgarnett: Simone was on holiday so I tried to answer a few questions
jgarnett: but in general SoC students have not been at IRC
jgarnett: and with out a wiki page or status emails
jgarnett: I feel a bit out of the loop?
jgarnett: Does anyone have a SoC student?
jgarnett: Or is anyone here a SOC student?
desruisseaux: Not on our side
jgarnett: fair enough
jgarnett: We should call the meeting over
Eclesia: the one you asked me to help didn't even send me a mail ...
jgarnett: there is a couple threads about release planning this week.
jgarnett: Eclesia he did respond to both of us; it was not very clear but it sounded like he managed to sort things out.
jgarnett: (and thank you for trying to help; I think most of what he needed was an encouraging word)
jgarnett: Martin for release planning
jgarnett: what does referencing need?
darkblue_B left the room.
jgarnett: And is there any help that can be provided?
desruisseaux: It is basically in the same state than 2.4. It contains a lot of duplicated code; EpsgThreadedFactories are modified copy of other classes, and those classes are quite big.
desruisseaux: So the amount of duplication is quite important
jgarnett: Rigth and we put off the clean up until 2.5 here
jgarnett: well can we try cutting cold turkey?
desruisseaux: I'm not sure which implementation is actually used, which make interpretation of stack trace more hasardeous
jgarnett: we should be able to do that just with changing the FactorySPI file
jgarnett: if we do it now; it sounds like we will get a couple weeks of solid testing out of GeoServer
jgarnett: and I can try and transition to epsg-hsql on uDig trunk
jgarnett: when you say you are not sure what implementation is actually used what do you mean?
desruisseaux: I do not know by memory what is declared in META-INF
jgarnett: okay;
jgarnett: I do
jgarnett: right now "my" implementation
jgarnett: is not hooked up
jgarnett: so cutting over; and talking about any bugs on email
jgarnett: is the first step
jgarnett: We can leave the "old" implementation there for a bit; perhaps someone wants to use it via a factory hint?
desruisseaux: I don't think we should add a factory hints for old implementations
jgarnett: I was thinking the hint where you say exactly what factory to use?
desruisseaux: So lets edit META-INF...
desruisseaux: Ah yes
desruisseaux: I forgot this one
jgarnett: um; I will wrap up the meeting IRC logs then
jgarnett: (thanks everyone; early meeting time is indeed better for starting on time)
desruisseaux: Bye all
desruisseaux: Thanks for running the meeting Jody