On Thu, 2008-01-31 at 23:59 +0100, Martin Marinschek wrote:

>         Personally I'm keen to try to build something along the lines
>         I was
>         proposing - but first need to help get a new Orchestra release
>         out.
> 
> If you can solve the problem with restore-state and save-state and
> your solution does not decrease runtime performance, and you show me a
> compact way of including all meta-data in annotations, I'd be very
> grateful to see you hack away! However, we should discuss the options
> we have for getting the restore-state and save-state problem fixed
> first - I am pretty sure we will not find one if we want to extend
> from the JSF base classes.

Yep, it's just an idea at the moment; actually trying it will show
whether there are reasonable solutions to your points or not..

> 
> 
>         There isn't any hurry on getting this tomahawk build process
>         sorted is
>         there? I don't see any reason why tomahawk 1.1.7 cannot go out
>         with the
>         current build process..
> 
> I do not see a reason why it should - especially as even the
> trinidad-based approach will make it easier for you to work on your
> component-based approach, cause you can then generate your generator
> base-classes with the generator and don't have to go through all
> component-classes. Work that Leonardo has already done for you. We
> need to switch to using a generator - improving the way of generating
> things is then easy. I also need a generator cause I finally want to
> improve the performance in the components - and for checking out
> several ways of doing this, it is necessary to have a generator
> (except we find a solution along your lines with regards to
> restoreState/saveState).

I look at the vast list of bugs raised against tomahawk 1.1.6, and look
at the scary output of the maven reports (findbugs, pmd, etc) and think
that there are higher priorities than reinventing the build process
right now, when the current approach works. Yes it is ugly, but 1.1.7 is
mostly a bugfix release; we don't need to add many components or change
many APIs. We do want to promote a couple of sandbox components which is
a nuisance but can be managed.

And the thought of changing the build process for 1.1.7, then changing
it again for 1.1.8 is not too tempting. 

Of course this is open-source, so nobody can be told what to work on,
and what not. But I don't personally want to be testing a temporary new
build process while also testing a tomahawk rc. I think it would be
better to solve the build process issue just once, but it looks like
that would delay a tomahawk release - unless we get consensus to use the
trinidad approach (which doesn't seem to be the case ATM).

The last tomahawk release is over 6 months ago, which is the release
cycle for a whole Ubuntu distro, or a linux kernel...it would be nice to
get one out without further delays.

Regards,
Simon

Reply via email to