Here is the log!
Ciao,
Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
-------------------------------------------------------
On Wed, Nov 11, 2009 at 10:43 AM, Jody Garnett <[email protected]> wrote:
> How did the rest of your meeting go? I only dropped in for part of it ...
> Can you post the logs?
>
> On Tue, Nov 10, 2009 at 7:53 PM, Simone Giannecchini
> <[email protected]> wrote:
>> (Ops, just noticed I sent it to the wrong list)
>>
>>
>> Ciao folks,
>> we are facing some probs with the gs hib catalog integration: we have
>> created a few patches in the last months which have been sitting
>> around for a while, therefore we would like to hold a breakout IRC to
>> gain again some momentum in the development, improve and then commit
>> the patches in order to move to phase 2 with this work, which means
>> performance improvements.
>>
>> The main point-of-contacts for this chat should be Emanuele Tajariol
>> and Justin Deoliveira, anyway, I will be around myself and anyone
>> interested is more than willing to join the chat.
>> I am proposing to hold the chat tomorrow @ this [1] time on the IRC
>> GeoServer channel.
>>
>> Ciao,
>> Simone
>> [1]
>> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=11&day=10&hour=14&min=0&sec=0&p1=53&p2=240&p3=215&p4=179
>> -------------------------------------------------------
>> Ing. Simone Giannecchini
>> GeoSolutions S.A.S.
>> Founder - Software Engineer
>> Via Carignoni 51
>> 55041 Camaiore (LU)
>> Italy
>>
>> phone: +39 0584983027
>> fax: +39 0584983027
>> mob: +39 333 8128928
>>
>>
>> http://www.geo-solutions.it
>> http://geo-solutions.blogspot.com/
>> http://simboss.blogspot.com/
>> http://www.linkedin.com/in/simonegiannecchini
>>
>> -------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Geoserver-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
[15:07] <simboss> etj, jdeolive, afabiani: ping
[15:07] <afabiani> pong
[15:07] <etj> pong
[15:08] <jdeolive> howdy
[15:08] <jdeolive> shall we talk catalog?
[15:08] <etj> y
[15:10] <simboss> etj the floor is yours
[15:10] * etj was looking for the jira entries
[15:10] <etj> ok np
[15:11] <etj> atm the hib catalog isn't compiling
[15:11] <etj> as it is when checked out from svn repo
[15:11] <etj> since a change in the trunk is requires
[15:12] <etj> a jira was filed for it
[15:12] <etj> but justin pointed out some issues about it
[15:12] <etj> first of all, the fact that the hib catalog just dups
some of hte info beans
[15:13] <jdeolive> do you have a link to the jira?
[15:13] <etj> cant find it here, sry, atm I'm working very far from my
usual place
[15:13] <etj> I dont have my links at hand
[15:14] <jdeolive> np
[15:14] <jdeolive> i think i remember the issue
[15:14] <etj> k
[15:14] <jdeolive> but yeah, to me the duplication seems like the main problem
[15:14] <jdeolive> i think what would be ideal
[15:15] <etj> the other major problem was about the changes in XStreamPersister
[15:15] <jdeolive> is if we 1) isolate what the problems with using
the beans as is are
[15:15] <jdeolive> 2) change them in cases where we can
[15:15] <jdeolive> 3) subclass only when it is needed
[15:15] <jdeolive> there is also duplication
[15:15] <jdeolive> at the catalog level
[15:15] <etj> ok to all 3 pts for me
[15:15] <jdeolive> which i think will be problematic as well in terms
of maintainance
[15:16] <jdeolive> for instance, with the resource pub work many
changes are required to the catalog
[15:16] <jdeolive> they will be doubled
[15:16] == ingenieroariel [[email protected]] has joined #geoserver
[15:16] == epickle [[email protected]] has
joined #geoserver
[15:16] <simboss>
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&reporterSelect=specificuser&reporter=etj_
[15:16] <sigq> Title: Issue Navigator - jira.codehaus.org (at jira.codehaus.org)
[15:16] <simboss>
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&assigneeSelect=specificuser&assignee=etj_
[15:16] <jdeolive> etj: cool, so what will be the best way to figure
out what is wrong with the current beans?
[15:16] == bmmpxf [[email protected]] has joined
#geoserver
[15:16] <sigq> Title: Issue Navigator - jira.codehaus.org (at jira.codehaus.org)
[15:17] <etj> k, but I'd rather stick to have somthing compiling and runing atm
[15:17] <jdeolive> etj: sure
[15:17] <jdeolive> do you have a log of the compliation errors?
[15:17] == doktoreas [[email protected]] has quit [Read error:
145 (Connection timed out)]
[15:17] <jdeolive> or is that another jira?
[15:17] <etj> the other issue was about the XStreamPersister
[15:18] <etj> even if we merge the *Info beans
[15:18] <etj> we also need custom converters
[15:19] <etj> in order to have the hibernate Collections properly encoded
[15:19] <etj> i.e. PersistentList, PersistentMap and so on
[15:19] <jdeolive> ahh ok
[15:19] <jdeolive> so the issue is
[15:19] <etj> or xstream will just extract useless data from them
through introspection
[15:19] <jdeolive> yeah, but we should be able to configure that
[15:20] <jdeolive> and add support directly for the hibernate collections
[15:20] <jdeolive> but yeah... i guess some flag or something will need to exist
[15:20] <jdeolive> to switch what will be the default
[15:20] <etj> I implemented a way to inject into the XStreamPersister
[15:20] <etj> the needed converters
[15:20] <etj> only when the hibernate profiled is specified in mvn
[15:21] <etj> using straight spring injection
[15:21] <etj> it's in the proposed patch
[15:22] <jdeolive> yeah... i was not really crazy about the idea of
introducing a new interface... but i admit i may have to come around
[15:22] <etj> even if the current implementation will also change the
defaultimplementation for the beans
[15:22] <jdeolive> seemed like maybe some subclassing may be simpler
[15:22] <jdeolive> but i admit i don't have the same understanding of
the problem
[15:23] <etj> uhm, I'm afraid subclassing won't do
[15:23] <etj> beacuse XStreamPersister is not instatntiated and
injected by spring
[15:23] <jdeolive> we could change that
[15:23] <etj> but it is created by calling new
[15:23] <etj> could do
[15:24] <etj> my main aim was not to make too big changes to the
trunk, when I wrote the patch
[15:24] <jdeolive> yup, understood
[15:24] <jdeolive> but i think we can't get around doing that if we
want to do this properly
[15:24] <jdeolive> so my motivation
[15:25] <jdeolive> is to figure out what the cahnges to trunka re needed
[15:25] <jdeolive> so this work can be done as cleanly as possible
[15:25] <jdeolive> but i understand you guys have deadlines
[15:25] <etj> the issue was not about deadlines, but by changing less
things as possible, since gs was in RC then
[15:26] <jdeolive> right, that too
[15:26] <simboss> my goal is to have this done in the quickest and
cleanest way :-)
[15:26] <jdeolive> which technically on 2.0.x is still a restriction
[15:26] <simboss> so that we can move forward with the rest of the
things we got to do
[15:26] <jdeolive> question:
[15:26] <jdeolive> does this work have to be done on 2.0.x?
[15:27] <jdeolive> or can we start working on trunk where we have a
bit more freedom
[15:28] <simboss> we need 2.0.x as well
[15:28] <jdeolive> simboss: does the current implementation work well
enough on 2.0.x?
[15:28] <simboss> not bad
[15:28] <simboss> but we need to move on the next steps
[15:29] <simboss> as I briefly told you down under
[15:29] <simboss> enhancing a bit the catalog, improving the ui
[15:29] <simboss> I am aware that some of these changes
[15:30] <simboss> will be difficult to push into 2.0.x
[15:30] <jdeolive> yeah
[15:30] <simboss> due to the fact that they require changes to the
(internal) API
[15:30] <aaime> right
[15:30] <simboss> but I need to push as much as possible
[15:30] <simboss> I am tired of having to maintain patches and internal branches
[15:31] <aaime> the frustration is understandable, but at the same
time we cannot destabilize 2.0 just released with massive changes
[15:31] <aaime> it took months to get it into shape
[15:32] <simboss> that is why we are taking small steps in the
desirable direction
[15:32] <simboss> I know where I want to go
[15:32] <simboss> andwe more or less know how
[15:32] <simboss> we are trying to make out patch match where
geoserver is going :-)
[15:32] <aaime> so the idea would be to make compromises on 2.0.x to
have a pluggable catalog
[15:32] <aaime> and do the full thing on trunk? and maybe have
hiberante catalog become the default there?
[15:33] <aaime> (just trying to get an understanding)
[15:33] <jdeolive> we were trying to get to the understanding :)
[15:33] <simboss> jdeolive what is the timeline for your pub/res split work?
[15:33] <aaime> sorry, go ahead, I jumped in the middle of the discussion
[15:33] <jdeolive> simboss: well the resource pub work is (now)
targetted at 2.1.x
[15:33] <jdeolive> so still far off
[15:34] <simboss> mmmhhh
[15:34] <simboss> thinking
[15:34] <jdeolive> but i hoped to start working on trunk soon
[15:34] <aaime> far off == 6 months?
[15:34] <aaime> (for a stable 2.1 I mean)
[15:34] <simboss> let's me explain
[15:34] <jdeolive> at least... probably closer to a year if history
teaches me anything
[15:34] <simboss> as you might imagine
[15:34] <simboss> 1 year
[15:35] <simboss> does not look like a deadline I can make use of :-)
[15:35] <simboss> let me explain
[15:35] <simboss> we have many installations of geoserver
[15:35] <simboss> that we maintain
[15:36] <simboss> and they all more or less use cutting edge
customizations from us
[15:36] <simboss> therefore I can accept a certain degree of instability
[15:36] <jdeolive> fair enough
[15:36] <jdeolive> but its hard to work within the framework you guys need
[15:36] <simboss> (those usually test things that later one we try to
drop to trunk of gt and/or gs, like gdal, jpeg2lk etc..)
[15:36] <jdeolive> where you have to do major work, but it has to be
done asap on a stable branch
[15:36] <jdeolive> so finding the compromise is a challenge :)
[15:36] <simboss> but I cannot shoot at a moving target :-)
[15:37] <simboss> exact
[15:37] <simboss> my goal atm
[15:37] <simboss> is to have the hibernate catalog
[15:37] <simboss> compiling
[15:37] <simboss> on 2.0x
[15:37] <simboss> and trunk
[15:37] <simboss> (this is why I called this IRC breakout)
[15:37] <simboss> and then start playing with the next changes we
discussed a bit
[15:38] <simboss> (we are going to make gsip and everything)
[15:38] <simboss> which means
[15:38] <simboss> support for pagination in catalog methods
[15:38] == juliatorti [[email protected]]
has joined #geoserver
[15:38] <simboss> as well as refinements in the hibernate mappings as
well as in how the Ui interacts with the catalog itself
[15:39] <aaime> (pagination alone won't be enough, you need filtering
and sorting too)
[15:39] <simboss> yep, that's how I call that part of the work
[15:39] * etj and aaime already talked a bit about it
[15:39] <simboss> :-)
[15:39] <jgarnett> suggestion: simboss is the moving target (use trunk
and release a stable when done)
[15:40] <simboss> jgarnett: yeah, that is why I was asking jdeolive
about the next thing on the plate
[15:41] <jgarnett> I would find it kinder to everyone to release a 2.1
earlier then a year; then to try and backport new work into 2.0
[15:41] <jdeolive> jgarnett: a year was not based on the impact of the work
[15:41] <jdeolive> it was based on the previous major releases
[15:41] <jdeolive> we put at a major release about once a year no?
[15:41] <jgarnett> agreed; I understood your argument.
[15:42] <aaime> any time we do major changes it takes months to get it
back into shape
[15:42] <aaime> trunk will be hit by 3 major changes in a row afaik
[15:42] <jgarnett> it is not a hard and fast rule; I would rather not
see major changes smack a stable release around if we can avoid it.
[15:42] <aaime> hibernate catalog, resoure/publish split, wcs nd
[15:43] <simboss> thinking... I think that the best thing atm would be
[15:43] <simboss> to find a way to
[15:43] <jgarnett> can we make three releases; ie step up the pace to
match incoming?
[15:43] <aaime> so even if I hope for a shorter reelease cycle this time
[15:43] <aaime> jdeolive has all the reasons to think about a year instead
[15:43] <simboss> cope with ETj issues
[15:43] <simboss> and then come back here in 2-3 weeks
[15:43] <jgarnett> (I cannot stay and chat; will read logs when done :-( )
[15:44] == iwillig [[email protected]] has quit ["leaving"]
[15:44] <jdeolive> simboss: sounds good, i have some ideas about how
we may need to work as well
[15:44] <simboss> and set out a clear path for the future
[15:44] <jdeolive> and i draw this from how the catalog and config
work was done last tiem around
[15:44] <simboss> I am also willing to fund some of your guys time
[15:44] <simboss> to help out on this
[15:44] <simboss> what do you think?
[15:45] <jdeolive> (i also have some permission to put some in kind
time in as well from my employer)
[15:45] <jdeolive> my thought
[15:45] <jdeolive> is to mirror how i managed the catalog change over
[15:45] <jdeolive> basically on trunk i was free to use the new
catalog apis, do things cleanly
[15:45] <jdeolive> but on the stable branch we always had to work
around that in order to keep things stable
[15:46] <jdeolive> so its still branch development i guess
[15:46] <jdeolive> but in this case we could do the improvements we
need to for the hib catalog on trunk the clean way
[15:46] <jdeolive> and backport to 2.0.x
[15:46] <jdeolive> in a way that won't affect stability
[15:46] <simboss> that would work I guess
[15:46] <simboss> I can even make things easier
[15:46] <simboss> as long as we isolate the changes
[15:46] <simboss> I can even work with the geoserver trunk
[15:47] <simboss> since I would control over the instability
[15:47] <simboss> and I could still use that for the most prototypal deployments
[15:47] <simboss> does it make sense?
[15:47] <simboss> this is why
[15:47] <jdeolive> that is anotehr option as well, to agree to only
have one major development going on a time and queue them up
[15:47] <simboss> exact
[15:47] <simboss> I was saying, this is why I said, let's remove th
obstacle we have in front now
[15:48] <jdeolive> that would also probably achieve the shorter
release cycle we strive for
[15:48] <simboss> and plan carefully the wrk ahead in a few weeks
[15:48] <jdeolive> sounds good
[15:48] <simboss> exactly
[15:48] <simboss> as I said
[15:49] <arneke> (stupid question: is it completely impossible to
support both catalogs for a while, have it be a Spring change which
one you use?)
[15:49] <jdeolive> arneke: that is how it is set up currently
[15:49] <jdeolive> but we have sort of reached the limit on keeping
them separate and now some changes are required to the core to make
the switchign clean
[15:49] <arneke> oh. at least I prefixed it with "stupid" :)
[15:49] <jdeolive> not at all :)
[15:50] <jdeolive> ok so simboss and etj , let's get you up and
running with something compiling and revisit in a couple of weeks?
[15:52] <etj> ok, so
[15:54] <etj> we'll commit the changes in the 2.0.x branch so that the
whole thing will compile and run
[15:55] <etj> and will clean the hibernate beans as much as possible
in the trunk
[15:55] <etj> (it's only a matter "id" and "isDefault" fields)
[15:56] <jdeolive> cool, so etj to confirm
[15:56] <jdeolive> what commits are reqruired to make things compile?
[15:57] <etj> if I remeber right, it was a change in the XStreamPersister
[15:57] <etj> plus an Interface and a DefaultImplementation
[15:57] <jdeolive> sigh... so yeah, that is what i consider the thing
to be cleaned up on trunk
[15:58] <etj> for mapping the various gs *Info interfaces to the
proper implementations
[15:58] <etj> yep
[15:58] <etj> I was talking about making the whole thing stable
[15:58] <etj> but
[15:58] <etj> we may work on the XStreamPersister a bit
[15:59] <etj> in order to make generic List works
[15:59] <etj> avoiding dependencies to Hibernate classes
[16:00] <etj> (sorry for the latency, I'm using a web client)
[16:00] <jdeolive> np
[16:01] <etj> cleaning the hibenrate beans stuff, and writing generic
converters to avoid hibernate collections misinterpretation
[16:01] <jdeolive> ok
[16:02] <etj> the thing should be cleaned a bit
[16:03] <jdeolive> ok sounds good, well i will await your next steps
[16:03] <jdeolive> i have to run to another meeting now
[16:03] <jdeolive> thanks for the chat giuys
[16:03] <etj> oky jdeolive
[16:04] <etj> thank you all
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
