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]
