I really don't see what all the fuss is about anymore. I've already stated that I'll be providing "some" form of T4 extension to upgrade to T5 when the time comes for it.
I've been wanting some of the features in T5 almost since the first day I started using Tapestry. I'm willing to go through the pain of developing a T4 upgrade extension to it if that's what it takes to get me there. I feel very comforatable with most of the code in T4 now . So..There we have it. :) On 7/30/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
this is a very simple minded thinking, liigo... what would an OS project be without the thousands that use it ? - that tell u what is needed/ not needed ? the businessfolks that use it ? contributing means more than just adding some line of code... im in a position where i choose the technology used for our company by myself, and the current discussion about migrationpath is the basic for all business decisions followed. to be clearly: if there is no migration path, i will see no use in using tapestry4 and 5 - no matter how good they are ! when telling about business applications, i have apps in mind that run 10, 20 years and more - so a basic upgrade path is necessary for at least some time, as we all have different problems than just the framework to be solved. choosing an technology usually implies using it a long time - and there u need a future vision regards, korbinian > -----Ursprüngliche Nachricht----- > Von: liigo [mailto:[EMAIL PROTECTED] > Gesendet: Sonntag, 30. Juli 2006 15:38 > An: Tapestry users > Betreff: Re: Tapestry 5 Discussions > > tapestry is a open source project. > before you requires others do or not do something, think what > you have done for it. > don't selfish > > 2006/7/30, Michael Echerer <[EMAIL PROTECTED]>: > > Norbert Sándor wrote: > > > - rethink the IOC container of t5 (use hivemind 2.0 or > maybe Spring > > > instead of a custom "unsupported" solution) > > I also agree that we shouldn't have another IoC container. > Spring is > > the de facto standard. Either take Spring and work around > missing features. > > E.g. use naming conventions instead of namespaces or whatever until > > Spring adds this, or stick to Hivemind and enhance this IoC > container > > to meet T5 needs. > > > - t5 should come with a compatibility layer for t4.X. > Jesse "promised" > > > this but Howard said nothing about it. > > +1... At least T4 users need a migration guide like the one we used > > +when > > migrating from T3 to T4. If it's a mechanical task it might be okay > > even if we need to trash a lot. Without a proper replacement guide > > however users either won't migrate to T5 or the will > migrate away from Tapestry. > > > - the development resources should be focused first on the 4.1 > > > branch, because the competing development of 4.1 and 5 delays the > > > release of 4.1. Users of t4 are currently waiting for 4.1, not 5. > > > - the most important one: pay more attention to the needs of the > > > current users - without them tapestry would be dead... > > Certainly true. Don't forget that Tapestry is a Apache top-level > > project. That means "stability" and "maturity", too. > > > > Tapestry should evolve to maintain its large user base. > It's not yet > > time for another revolution! > > > > There are lot's of Tapestry applications out there - even > dozends that > > made it from T3 release candidates to T4 final ;-) - that should be > > maintainable in future and we need a path to T5. No need for a > > revolution for T5, maybe for T6 again, but T5 should be an > improvement > > release first. > > A revolution now, might lead to a community split (T4 vs. > T5) or even > > cause Tapestry to die in the rise of JSF. The best > framework won't be > > choosen if you can't build on it because it remains a moving target. > > > > Developing for a moving target is something difficult to explain to > > business people. Explaining to develop using a best-of-breed GUI > > framework instead of JSF & Co., because it's a, b, c, d, e, > does f,g,h > > better is easy, if you can tell them that an even better Tx > is on the > > way we can upgrade to, instead of waiting for the > vendor-driven JSF process. > > > > > Cheers, > > Michael > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
