First of all, let me say that I don't appreciate the name-calling. I am not personally attacking anyone here. I am a very active member of the open source community and I too do it because I enjoy it. I enjoy working with Tapestry and I believe that Tapestry is a very well-designed framework. That's why I feel so strongly about its future. The only real issue that I have is that there's no migration path. As many others on this thread have agreed, no migration path really makes the businessey folks very nervous and they might not let us techey folks use Tapestry because of it and that would be a shame.
I have read the documentation on the new IoC container and I've already started discussion with the HiveMind team about including some of Howard's concepts into HiveMind itself. That's not an argument that Tapestry should keep HiveMind, but an illustration that I actually do support the direction that Tapestry is heading with the new IoC container. James p.s. Sorry to dual post, but this thread got splintered onto both lists. -----Original Message----- From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] Sent: Saturday, July 29, 2006 10:07 AM To: Tapestry development Subject: Re: Tapestry 5 Discussions -- Nice to see people paying attention Wow, I have to say I'm pretty disappointed in such talk from someone who is supposed to be the "chairman" of Hivemind. I'd almost say it sounds kind of immature. I support Howard's work on T5 completely, and since he and I are currently the two most active developers I think it has to count for something. We do this because we enjoy it, please don't try and take that away. If you think you can do a better job the door is always open. It ~is~ open source after all :) On 7/29/06, James Carman <[EMAIL PROTECTED]> wrote: > > Again, Howard, don't get me wrong. I really like some of the cool new > stuff > you're doing with Tap5, except for maybe Tapioca (that's not the official > name, but my "pet" name) vs. HiveMind. Anyway, one might interpret what > you've basically said here: > > "future users vastly outnumber the current users" > > to mean that you don't mind leaving your current users out in the cold > when > it comes to the future of Tapestry. I'm not saying that's what you said, > necessarily, but I'm saying it could be interpreted that way. > > Here's an interesting question. When writing T4, did you know that T5 was > going to be such a drastic rewrite? Probably not, or you would have just > architected T4 the right way to avoid the rewrite. Correct? Well, then, > who is to say that two years down the road whenever you get down to > working > on T6 that won't you decide the T5 architecture just won't work? You > probably thought at the time of writing T4 that the architecture was the > right way to go for the future and now it's "untenable w.r.t. to adding > new > features without breaking backwards compatibility." > > I have (not that I necessarily think you were addressing me, but just in > case) started to help make Tapestry more popular (Hibernate, Acegi, and > AspectJ integration for starters) and I've contributed to Tapestry itself > (autowiring), but a lot of my work will have to be completely rewritten > for > T5! > > Also, as a consultant, I have to recommend to my clients what technologies > to use in their best interest. If Tapestry continues down the path that > it's going, I could not endorse Tapestry as a viable technology solution > for > a large, on-going project. In other words, I wouldn't stick my neck out > to > suggest Tapestry given its track record. > > -----Original Message----- > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > Sent: Friday, July 28, 2006 6:12 PM > To: Tapestry development > Subject: Re: Tapestry 5 Discussions -- Nice to see people paying attention > > The current state of the T4 code is untenable w.r.t. to adding new > features without breaking backwards compatibility. Each upgrade of > Tapestry (2 to 3 to 4) has had major upgrade problems because of a > number of factors, mostly the design of the APIs and the need to > extend from base classes (as the base classes provide much of the > component functionality). > > In the long view of Tapestry, the future users vastly outnumber the > current users. Tapestry 5 is targetting that group of users. > > Existing applications coded to Tapestry 4 ... well, leave them on > Tapestry 4! Many users prefer to stay on Tapestry 3. They don't want > to face the upgrade from 3 to 4 if their application is working. The > design of Tapestry 5 will facilitate easy upgrades from 5 on ... > mainly because the API is minimal and flexible, consisting almost > entirely of annotations, rather the classes to extend and interfaces > to extend. > > Having an easy upgrade path from Tapestry 4 to 5 is a near > insurmountable challenge. > > Is Tapestry 5 a new framework? Yes. Will it be an easy transition > for developers (not code)? Yes. Tapestry 4 developers will see > Tapestry 5 and understand it quickly and easily, and be happy about > the new features. > > I see a lot of feedback from people I'm training in Tapestry 4. I see > people stumbling because of inconsistencies of naming, because of the > odd model (abstract classes), because of the need to understand too > much of the internals of Tapestry. > > I do get upset when people act like I'm holding a gun to their heads. > > Now, in terms of the IoC container specifically ... > > I'm preaching about simplicity, simplicity, simplicity. HiveMind is > simple, but still has a lot of mapping between Java and XML. As happy > as I am with HiveMind and the HiveMind community, the core fact is > that it is not as simple as I need it to be: the pure Java model of > Tapestry 5 IoC is going to fit like a glove with the rest of Tapestry > 5 in a way HiveMind (and certainly not Spring) could ever do. > > I've repeatedly spoken about, and blogged about, why Spring is simply > not a good fit for Tapestry 4 or Tapestry 5. Spring exists to allow > an application, a known entity, to be assembled. It simply doesn't > inlcude the concepts necessary to configure a framework, allowing for > the precise ovrrides and extensions that HiveMind and Tapestry 5 IoC > do. I've seen some laughable postings about what it takes to even > start to approximate HiveMind configurations in Spring ... huge > amounts of ugly Java code and uglier XML. No thank you. > > My metaphor for all this is that I'm trying to raise the big pole that > the circus tent will hang from. I can't wait to get the pole up so we > can start having the circus! Under this metaphor, the circus will be > the components and extensions that the community will put together. > > Finally, I've been at this for six years now. I enjoy working on the > code, and I suffer through the things necessary to permit that ... > Tapestry training, and marketting. Writing books. Creating demos. All > that stuff. What I constantly hear is demands and suggestions about > Tapestry and all I ask in return for all this time and effort is for > people to give back a little something in kind. I don't ask for money > (not for the software, not even as a donation), or time, or any other > demand BUT that people HELP PUBLICIZE TAPESTRY. It is in the interest > of the entire community that the word on Tapestry get out there. There > are good books, better than average documentation, and healthy > community but Tapestry just isn't getting the notice it deserves and a > major reason for this is that people are failing to get the word out. > > How many of you have written a white paper on your Tapestry > experience? How many have posted a supportive comment about Tapestry > on a release posting at JavaLobby, TheServerSide or elsewhere? How > many have tried to write an article on their Tapestry experiences for > publication? Tapestry doesn't have a corporate sponsor like JSF or > even Rails. Tapestry has its technical chops and its community. So if > you are looking for reasons why Tapestry doesn't have the level of > adoption you think it should have, don't look at the compatibility > straw man. Look to yourself and what you have done to support > Tapestry. > > > > On 7/28/06, Matt Welch <[EMAIL PROTECTED]> wrote: > > Howard, if it really will be as difficult to move from Tap4 to Tap5 as > you > > suggest, and if this new code base is indeed mostly new, perhaps it > might > be > > prudent to release what you are now calling Tapestry 5 as a new project > > instead; one that is "inspired" by the Tapestry concepts and intentions. > > Then Tapestry 4 could continued to be mainatained and if other > contributers > > we re so inclined, it could be upgraded to a more "migration friendly" > > Tapestry 5. > > > > Personally, I don't have a problem with the migration difficulty as I > dont' > > have any Tapestry 3 or 4 projects that I would upgrade. I built what > I've > > built using the best options I had available at the time and while I > > continue to maintain some of those appliactions, I dont' feel a pressing > > need to upgrade them to the newest framework. I won't be upgrading them > from > > Spring 1.2 to Spring 2.0 either. What's the big deal? As far as I'm > > concerned, there should be a migration path through all point releases, > but > > any easy migration is just gravy. > > > > I for one am thrilled to see that Tap5 is dropping some of the > encumberances > > of it's original implementaton. When I start a new project. I want it to > be > > using the best tools out available. Here's to Tap5 and all it's > > incompatibilities! > > > > On 7/28/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > > > > > Right now its impossible because there's nothing to convert to :-) > > > > > > It will be *VERY* difficult. This isn't a slap of new paint. Basic > > > paradigms are shifting around in a major way. It would be comparable, > > > or perhaps even larger than, converting between JSF and Tapestry 4. > > > Possibly on the order of converting from Struts to Tapestry 4. > > > > > > On 7/27/06, Norbert Sándor <[EMAIL PROTECTED]> wrote: > > > > I know that it's far away, but how easy/difficult will it be to > convert > > > > an application from 4 to 5? > > > > > > > > Regards, > > > > Norbi > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > Howard M. Lewis Ship > > > TWD Consulting, Inc. > > > Independent J2EE / Open-Source Java Consultant > > > Creator and PMC Chair, Apache Tapestry > > > Creator, Apache HiveMind > > > > > > Professional Tapestry training, mentoring, support > > > and project work. http://howardlewisship.com > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > -- > Howard M. Lewis Ship > TWD Consulting, Inc. > Independent J2EE / Open-Source Java Consultant > Creator and PMC Chair, Apache Tapestry > Creator, Apache HiveMind > > Professional Tapestry training, mentoring, support > and project work. http://howardlewisship.com > > --------------------------------------------------------------------- > 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
