dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

2009/4/14 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>
>>
>> Yes, we have a list of pressing requirements, one is implementing
>> "easy-access-help" and the other is "datavalue-history". For implementing
>> first one I had small discussion with you, and we decided that I will look
>> shortly if migrating from webwork to struts2 is possible. I managed to
>> migrate one module to run on struts2, it is possible but takes some time and
>> efforts. As all of us know webwork is not updated since mid 2007
>
> Yes, but we should still have a review of struts 2 before launching into
> it... Anyway there are hundreds of action classes, interceptors etc and it
> will be a big job to change things.

My count is just over 400 actions.  And considerably fewer
interceptors.  Mind you the transition from webwork to struts2 doesn't
appear catastrophic
(http://struts.apache.org/2.0.14/docs/key-changes-from-webwork-2.html)
and probably a good bit could be automated.  But I know, the devil is
always in the detail :-)  But I agree with Murod - sitting on webwork
past its expiry date is a risk.  The trouble is that such a migration
can't be a gradual one like the hibernate case.  I guess it would be a
case of migrate one and all ...

Reminds me how it would be really useful to have some sort of selenium
test suite   I wonder what came of Satvik's efforts to put together a
list of test cases for the webapp.  Satvik, I saw the beginning of
this - can you share what you have?

What would the steps be in looking at such a proposal?  Something like
1.  review of struts2 and its differences from webwork leading to a
decision and prioritisation
2.  compilation of selenium style battery tests covering at least the
results of 400 actions!  Probably not all at once, but generally
something useful in itself.
3.  creation of a migration branch
4.  auto-convert as much as possible
5.  cycle of test and fix what's still broken

>>
>> "easy access help" was implemented, now I am working on second one.
>
> Nice.
>
>>
>> Hibernate has support for auditing persistent objects ("datavalue
>> history"), that is what we want. But it comes with annotations only, so I
>> decided to change hibernate libraries to host annotations, this is the
>> reason. I think using existing functionality is much better than hand
>> crafting history object for datavalue table.
>>
>> Why I said to Bob I am wotrking on this and that is because I have all in
>> my branch and cannot split easily what he wants (poms). I cannot distribute
>> pom with new hibernate dependencies, struts2, etc.

I think that it would be really useful to be able to fix the poms with
the existing dependencies rather than wait for the outcome of what
might be a long and uncertain process.  If you can just send the poms
I'd love to have a look.  I'm far from a maven expert, but I'm getting
better.

On unix like systems (including probably cygwin):

 find . -iname pom.xml |zip poms.zip -@

>>That's WHY I said lets
>> discuss these issues before we have made such a change. It is better to
>> discuss how to make these things happen, if they are useful. For hibernate I
>> can say transision is transparent, we can move one object to annotation,
>> while others are still in hbm.xml.
>
> OK. If you can use this side-by-side it sounds like a good idea. Sorry if I
> am sticking my nose in everything, just interested in hearing the rationale
> behind it...
>

This gradual transition sounds do-able.  Though I guess we are still
talking about a hibernate library upgrade even while still using a
mixture of modes.

Cheers
Bob