Nick -- You want a roadmap, but the culture here doesn't quite work that way. If you want to see a particular thing happen, the best way to ensure that it does is contribute so that the project moves in that direction. So far, the core contributors are guys who feel that working code is much more important than strategic plans. They have evolved Nukes through a number of refactorings and rewrites, with the idea of keeping it working from step to step, while incrementally improving functionality.
So the Nukes team is not working off some grand vision, but off of what each person feels is most important to do next --- and, hey, you're looking at a result that at least works... which is a lot more than you can say about lots of projects with fancy roadmaps. IMHO, strategy and architecture and planning are also quite important, and I hope to see more of that perspective in Nukes in the future, but I have to tip my hat to the practical wisdom of "rough concensus and running code" ! Julien is now making a major shift in the Nukes front end architecture, because the need for JSR-168 support rose to top priority. As he works through that process, he will naturally generalize some of the existing code to accomodate portlets, JSPs, etc as mandated by JSR-168. ( You know how you'll rework and "stretch" your interfaces into more general form when you go from having to support 1 concrete class to having to support 2 or 3 or 4....? So after having to support the TPLs and the JSPs and having to meet JSR-168 requirements, the front end code ought to look more general and flexible and accommodating than it does today. ) So after Julien accomplishes JSR-168 compliance, I predict it will be much easier for the rest of us developers to generalize further, and create support for a wider range of front end approaches --- including the more java-oriented kinds of templating (such as Velocity) .... and especially the most powerful and widely adopted standard for templating (XSL). That said, Nukes is now maturing to a point where "Architectural contributions" may be (almost) as welcome as "Code contributions". So if you have specific ideas of what would be good, how about writing them up in some detail and putting them on a wiki page? (Adding some prototype code wouldnt hurt, either) ;-) You can make a home for your contributions in the wiki: http://jboss.org/wiki/Wiki.jsp?page=NukesForJBoss http://jboss.org/wiki/Wiki.jsp?page=RequestsForFeatureEnhancements My .02 -- Howard View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3831715#3831715 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3831715 ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
