Re: Switching frameworks (was: what about adding spring ?)

ok, let me try to summarize:

- Only after a significant framework-independent refactoring has taken
  place, it makes sense to move the code base to a framework.

- It is best to fully refactor Scarab and introduce a clean API. But
  this is a long term project needing many developer resources.

- The current Scarab code base is a mess and putting new functionality
  on top of this mess will become a tedious task and does not add to
clearity.

- refactoring the GUI in itself is a tedious taks, because it is fully 
  intertwinned with the backend. Hence refactorings of frontend and
  backend are also intertwinned. (i learned this from my parallel thread 
  about refactoring the velocity templates)

ok. That sounds like we are not in a good position here...

Scarab development is driven by needs of the individual contributors.
So it looks like we are well beyond the point, where someone of us will 
take the time and do the huge work of refactoring and cleaning up Scarab
just for fun.

So what can we do ?

I myself will now get back to my Scarab wishlist, add the functionality as i 
need it and propose my doings as additions to the trunk. I will take care to
keep add on complexity low and i also will try to remove existing complexity
by refactoiring where it is appropriate and helps my current development.

I also will take a closer look to "Sesat Commons IoC", which maybe can 
help me/us as an additional guideline. And i will let any framework out of
my mind for the moment.

Waving to Mick: What about the licensing ? If your commons-ioc is added to
Scarab,
we would need it to have a compatible license model, right ? Can you make
this
possible ?

regards, Hussayn
-- 
View this message in context: http://www.nabble.com/what-about-adding-spring---tp21418409p21435028.html
Sent from the Scarab - Dev mailing list archive at Nabble.com.

------------------------------------------------------
http://scarab.tigris.org/ds/viewMessage.do?dsForumId=455&dsMessageId=1021807

To unsubscribe from this discussion, e-mail: [[email protected]].