Well, after months of Tap4 programming eagerly waiting for Spindle for Tap4, and looking over my shoulder for TapIDEA that seemed closer and made me consider trying IntelliJ... all comes down!
Nothing I can say regarding how important IDE support is that has not been said before. Kranga really said IMO the most important fact. We all have bills to pay. Tapestry is not what it is, has not the legions behind it from home made, helloworld like, small or even bug non profitable projects. Of course those exist, hell I'm working on one right now... but as for real world projects, as for Companies to back down Tapestry as their base framework, in order for Tapestry to get the acceptance it deserves... these compatibility breakers are really not helping. So talking of IDE suport, apparently we have always had the Tapestry code and the IDE code. The IDE code has to go deep into Tapestry internals in order to get what is needs, in order to do it's work. So a little flick of Tapestry and the IDE breaks. Geoff started to create an IDE agnostic core to a Tapestry plugin if I understood it correctly. Good, several tools could build on top of this common layer... but, still Tapestry had sort of it's back turned to these needs and projects and a little change in Tapestry, this plugin common core had to be refactored (here we at least have one fix solving all Tools specific IDE plugins working again). So what's wrong with this picture (IMHO), it needs more cooperation and more Abstraction Layers. We have obviously some of the best Java minds in the business in our community. Some of the best software architects available. Can't we think of a better way of using the resources available? The time we can spend individually in cooperation and not in different paths? Why can't we have for instance something like this: (Bare in mind I know nothing of the Tapestry internals and have not ever looked into any of the IDE tools source, just trying to help in theory to see if there a better way...) 1st layer: Tapestry commiters develop Tapestry and create rocket science that we all bow to each time it is released! :-D (I do at least!) 2nd Layer: An abstraction API witch is maintained through joined efforts of Tapestry commiters and IDE Tooling developers with the goal of making the bridge from the Tapestry techy-up-to-date and more volatile and the more consistent objectives of the IDE tools. The release of a new Tapestry would have to include this API working as an integrated part of itself. (with this I know I will get some violent remarks back!) - Tapestry would not make into, say Beta stage without a first working draft of this API. 3rd Layer: Something the likes of what Geoff constructed, the Tools Core API for Tapestry. Something that all IDE tools use and rely on for compatibility, something that shields them from most Tapestry changes in the other layers. This would be maintained by IDE tooling developers to have a common core to fit their needs. The more hardcore technical details and the major changes in Tap would normally not have impact on this layer, having being "translated" by the previous one. 4th Layer: Several IDE Tooling developers build specific IDE plugins on top of this previous layer, confiding in it's solid compatibility and abstraction of evolution beneath it I'm thinking out loud here but somehow I feel that cooperation is the key. We have so many willing by what it seems, but the way it is now it's difficult to set your heart to it. It looks like an impossible task because all the work that one does will be thrown away by the next Tap. I would really like to get a post here from Howard. The post Francis quoted out of Howard's blog I try to interpret has tooling is not a solution to lack of productivity, that if a framework is nor productive by nature, than it is not tooling that will solve this. I can not and I think Howard did not wish to convey the idea that even for a productive by nature framework like Tapestry is, it does not benefit from Tooling support. That the learning curve, the ease to pull new resources in little time of different technically expertise to a problematic project, that even an experienced developer can not magnify it's productivity with the help of a good tooling. By the shear quantity of posts that we get every time this issue gets mentioned on the list we can get a very good image of the general community position on this. A very good percentage miss tool support. The majority of the posts are saying that their productivity and real world acceptance of Tapestry would benefit from this, so I think is not a matter of it is needed, but a mater of how can the Tapestry community respond to this necessity with the time given by some very revered members of our community... and some other that with the right conditions would probably jump in! So pardon my long post and my apparent lack of humility in proposing those layers for this problem. I am only trying help us all to slice the elephant in slim slices before trying to eat it up in one wide chunk! Maybe like this, by decomposing the problem, by reducing it in smaller problems that may possibly be divided by teams, some already in existence and other waiting to be formed we can make this happen. The layers... well, they're an idea, maybe completely of target, but the general idea of it, I think might be a possibility of an approach to the problem. Regards, On 8/30/06, Francis Amanfo <[EMAIL PROTECTED]> wrote:
Henrik, Stop dreaming. If what you're saying is valid then we should have got Spindle for Tap 4 now. The fact of the matter is Howard just didn't listen to Geoff. With Howard's current opinion on tools, I don't think he would make a tool drive his fanatic and radical design decisions. My .02 cent. F On 8/30/06, hv @ Fashion Content <[EMAIL PROTECTED]> wrote: > > I think the best thing is building on WST and Tap5, while Tap5 is > developed. > The amount of special tooling needed for Tap5 should be limited. > > Judging form Geoff's posts the main problem with Spindle for Tap4 is the > large number of possible ways to configure an application. One of the > goals > for Tap5 is to simplify. So if we can start over on a new Spindle while > Tap5 > is > still in its infancy, we can perhaps ensure that the simplicity is > achieved > from > the perspective of tooling. > > Henrik > > "Hugo Palma" <[EMAIL PROTECTED]> skrev i en meddelelse > news:[EMAIL PROTECTED] > > Since Geoff decided to leave the Spindle project i've been thinking > about > > the future of TapIDEA. As many of you know, TapIDEA is built on top of > > Spindle, which means "No Spindle" -> "No TapIDEA". > > > > There are several scenarios that can be put into account in the current > > situation, and after a long consideration here are my conclusions. > > > > Someone else picks up Spindle where Geoff left off: > > I honestly don't think this is going to happen. AFAIK Spindle was a one > > man project so no one else has the know how to quickly get into gear > with > > the project. Some might think that that person could be me, and indeed > > i've become familiar with Spindle internals during the development of > > TapIDEA. But, there's the free time factor. I just wouldn't be able to > > find the time to do it. > > Still, if this scenario were to be become true, TapIDEA would live on. > > > > Spindle for T4 dies, a new project is born: > > Ok, so no Spindle and no TapIDEA for T4. What about T5 ? As Geoff as > > pointed out, T5 support is going to require an almost complete rewrite > of > > Spindle. So, in this scenario someone would implement Spindle(or create > a > > whole new project) for IDE support for T5, and TapIDEA would follow. I > > find that this is the scenario with the most chances of becoming > reality. > > > > Spindle and TapIDEA die for good: > > Well, there's always the possibility that no one will volunteer to > > continue our efforts of bringing IDE support to Tapestry. In this > scenario > > both Spindle and TapIDEA end their lives now. > > > > > > The TapIDEA project will be "hibernating" until one of these(or any > other) > > scenarios become reality. > > I guess now it's up to the community to present their ideas about this. > I > > hope that, together, we can give our contribution to making Tapestry IDE > > support a reality. > > > > Cheers, > > > > Hugo > > > > > > --------------------------------------------------------------------- > > 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] > >
-- Pedro Viegas
