As recommended by Hernan, I have moved the proposal wiki page (mentioned at the beginning of mail chain) to another space. Please use this new link for accessing it:
Great. Thanks for your valuable comments Mark.
As you suggest a "tool/wizard for auto creating Geronimo Deployment Plan by scanning the corresponding Java-EE plan/annotation" would fit best within "Admin Console", may be as an extension to the Deploy New tool.
In addition, as you point out, it could also be useful to enable Developers to specify Geronimo specific deployment information through Annotations (may be as JSR-175 annotations instead of XDoclet based Annotations). One our Committers 'Sachin Patel' had started one such discussion http://firstname.lastname@example.org/msg39760.html. Your feedback here has helped clarify that discussion also.
Thanks again Mark. User feedbacks have always been Gold Mines. Please keep pouring your suggestions and feedback in future.
If I understand correctly David Jencks, Aaron Mulder, David Blevins, Tim McConnell and Others are the experts in Geronimo Deployment Plans and Annotations. It would be valuable if they too can post their view on this.
ShivaOn 5/21/07, Mark Aufdencamp < email@example.com> wrote:It's definitely needed! I'm the Architecture/Project Manager type with twenty years in the business. I've been engaged in re-learning the JEE stack over the last six months with Geronimo. I've been befuddled a half dozen times in the learning curve by the configuration files. This list has helped to resolve all of them:)I've been using MyEclipse learning materials which are all JBoss based. I've been able to use XDoclet to generate my ejb-jar.xml. This has been very helpful, but I have had to hand translate the open-ejb.jar components. This also applies to the geronimo-web.xml file. It would have been very helpful to have these generated by the XDoclet annotations like the available JBoss tags. I would also mention at this point that the lack of a global JNDI service created an additional learning knock about the container specific configuraion files:). Yes, they have to be defined n the container config in order to be accessed. That's the developer perspective in me.Now for the Architect/PM side. I very much believe in the seperation of duties, and auditability of application/server/network administration. I don't believe that I can get my server administrators to create a hand crafted deployment plan that would have any chance at mashing up with generic code coming from my web developer or ejb/database developer! A template system that incorporated creation of the container specific configuration based on the web.xml and ejb-jar.xml would be a valuable tool within the server administration tool set. I would expect a tool like this to be available within the management console in direct proximity to the deploy application tool! Setting deployment specific environment values falls within this scope as well. In my early J2EE experiences with Websphere 3.5, this was I believe a component of the server jar deployment wizard.My two cents.Mark Aufdencamp-------- Original Message --------
Subject: How important is simplifying Creation/Updation of Geronimo
From: "Shiva Kumar H R" < firstname.lastname@example.org>
Date: Mon, May 21, 2007 8:38 am
Creating or updating of Geronimo Deployment Plans has always been a tedious and erroneous task. As evident from the user mailing list, first time users (and sometimes even advanced users) have always had some issue or the other when it comes to correctly creating Geronimo deployment plans.I have always wished that Geronimo Development Tools (like Geronimo Eclipse Plug-in) provide some facility for auto creating or updating the Geronimo deployment plans. I have created a wiki page summarizing my proposal:
http://cwiki.apache.org/GMOxPMGT/geronimo-deployment-plans-how-to-simplify-creation-or-updation.htmlIf this is something of use for you as a user/developer, it would be valuable if you can take a moment and provide your feedback/comment as a reply to this mail. Your feedback/comment would help determine the needs of User community and would better convince the dev-community into taking this up.