Ryan, If you'd like, I can grant you commit access to the service-cache project at sourceforge so you can work with a net while building your console. I started that "project" so we could work together and prepare potential submissions for Geronimo and benefit from access to CVS. Matt K's working on a CLI management interface there (last I heard--I don't see a lot of activity). Otherwise, it might suit you better to host your own project CVS. I'm a big advocate of the DIY route--to take your future into your own hands and administer your own CVS tree is very liberating. I recommend everyone tries it.
In any case, the CVS tree at Geronimo is not a good place for experimental work or speculative R&D between non-committers and especially for those of us not working within the context of a standard. It's a good place for tested, functional code and directed efforts. This is why I started the service-cache to begin with, because the project committers shouldn't be expected to maintain my experimental code at a fine-grained level. They don't need the overhead and I don't need the friction. Geronimo is just too modular in design for us to limit ourselves with the notion that we need to do all of the work *here*. I'm glad to have all of the conversations here, as it *is* the list of record, but we can write our own pluggable modules (how else could you describe a web application?) and maintain them elsewhere. Eventually, we'll be able to register them with Ibiblio and the server should be able to download and install them automatically at runtime. If the PMC and the committers want to make our modules the default functionality for the Geronimo stack, so be it. I'm happy to structure the work so it is easily injected into Apache's CVS tree, happy to build the diffs, submit them to the JIRA, and happy to work closely with the committers in supporting the product--but I'm not dead in the water if they're all busy, or out of town, or at ApacheCon. That's the beauty of the DIY approach. I know this management application is going to need several rewrites at some point down the line, but I'm trying to take the agile route and to focus on implementing features the developers need *right now*, like object invocations (which I'm almost done with, screen shot attached). I've gotten trapped in the past by overengineering in the early phases of development. It stalls visible progress and can be quite discouraging and frustrating, plus you never really understand the needs of an application until you've already built it incorrectly a few times (ask Jeremy and Dain about this). And those needs change, so it's ridiculous to plan too far ahead. Finally, as far as I'm concerned, the two most important features of this web application are that it's easy to use and that it pushes the aesthetic limits of the medium. And yes, I'm writing this from a marketing and design perspective as well as from a technological perspective--it's my prerogative. I want our management tools to kick the hell out of the competition, both for the glory of it and (more importantly) for the fun of it. So, please don't mistake my intentions--I'm not telling you to "fork off and write your own". I'm holding the door open to see what you can do, and I promise if your infrastructure can support the two most important features I noted above (and, as a designer, I'll warn you there are well-known aesthetic limits to the JSTL) I will be happy to join efforts with you down the road. For now, I suggest you code like mad, keep your efforts in a CVS repository *somewhere* public, and keep us all informed on your progress. I'm looking forward to seeing what you come up with. Cheers, -- N. Alex Rupp ([EMAIL PROTECTED]) P.S. MN is stacked with Geronimo developers. Midwest Represent ;-) ----- Original Message ----- From: "Ryan Sonnek" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, October 31, 2003 11:44 PM Subject: Re: console-web ok, here are my ideas. please let me know if they go against any design you had in mind. 1. remove html from JSP custom tags. 2. use JSTL in jsp tags to output lists of JMX services 4. use xdoclet to generate web.xml and taglib.tld. 3. refactor majority of code into reusable JMX client for use with other "consoles". i think this might work best to add a new module, so that the console-web module has a dependency on the new module. this would allow for the taglib.tld to be picked up automatically without having to specify it in the web.xml i think that was pretty much it. i have not done any development for geronimo, but have gone through the wiki extensively. what would be the best way to go about this? do the development, create a patch, and submit it to JIRA? if i have questions, should i email you directly, or would the dev list or wiki be a better communication spot? Oh, and i wanted to let you know that it's great to see other minnesota based J2EE developers! i'm from mankato myself, and down here, J2EE is still in it's infancy. Ryan Sonnek ------------ "God is the Lord of angels, of men - and of elves." - J.R.R. Tolkien
<<attachment: geronimo_console_comp_02.gif>>
