geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <>
Subject Re: User Feedback Request -- this means you!
Date Thu, 06 Apr 2006 23:32:31 GMT
Sachin Patel wrote:
> Yes we should have both but I'm not sure if I agree with your second 
> statement. :) I think JIRA should be the first place users should go 
> to request a feature.  The wiki will never encapsulate all the work 
> that needs to be done for a project.  JIRA tells us this.  Thus the 
> wiki should be used to bundle the wish-list and associate them to the 
> themes and priorities for a release.  I think trying to keep jiras and 
> the wiki synchronized is invaluable and is unnecessary work.  The wiki 
> should be the place where to look for what is planned for that 
> release, and the discussions around and links to jiras/threads for 
> those items. So the first step I think should be to open jira's and 
> from there these can be sorted and prioritized and pushed up into the 
> wiki, I don't think it should be the other way around.  There is alot 
> of things that need to be cleaned up in current in JIRA and by using 
> it as the first place for work items this forces us to maintain and 
> constantly scub JIRA to provide an accurate indication of project status.
> thats by 2 cents :)
+1 - I always look in the JIRA records for a project (to get a picture 
of its stability and priorities) before adopting it.  JIRA is a great 
tool for prioritising and keeping track of work, lets not duplicate this 
in the Wiki.

> - sachin
> On Apr 5, 2006, at 6:12 PM, Matt Hogstrom wrote:
>> I think you need both.  The Wiki is a place to look at what there is 
>> to do...JIRA is the way to tell people your doing it.
>> Dave Colasurdo wrote:
>>> Wasn't suggesting the wiki as the final resting spot, just a 
>>> temporary holding spot while the user requirements were being 
>>> gathered, tallied, discussed and prioritized by the community.  It 
>>> works better than email threads passing in the night.  No objection 
>>> to moving the output to JIRAs..
>>> -Dave-
>>> Sachin Patel wrote:
>>>> I don't think they should go on the wiki.  Why can't we add them as 
>>>> Wish List Jira's with #votes and have the wish list query exported 
>>>> and posted?  This way further discussion and progress on each of 
>>>> the items could be tracked as well.
>>>> - sachin
>>>> On Apr 5, 2006, at 4:07 PM, Dave Colasurdo wrote:
>>>>> I tried to order them by priority (based on number of times 
>>>>> mentioned) within each category/sub-category..  The ones that were 
>>>>> mentioned the most are first on the list and so forth..  Items 
>>>>> that were mentioned only once are listed in random order..
>>>>> Anyway, I've updated the list below with the number of requests 
>>>>> for each item.   I've denoted with *(number)*.  Absence of a 
>>>>> number indicates one request for an item.
>>>>> Of course the community needs to digest the input and decide on  
>>>>> priorities.
>>>>> BTW, I have added Global JNDI ENC to the list..
>>>>> If folks agree with the format, I will post to the wiki..
>>>>> -Dave-
>>>>> Matt Hogstrom wrote:
>>>>>> This is great Dave...I think we need to prioritze them as well. 

>>>>>> Can you translate the priorty from the other e-mails to this?
>>>>>> Matt
>>>>>> Dave Colasurdo wrote:
>>>>>>> Excellent feedback from all..
>>>>>>> Here is an attempt to consolidate the feedback into one list.

>>>>>>> (Hope I'm not stepping on anyone's toes.)  I've grouped by a
>>>>>>> high level categories..
>>>>>>> Of course, one could argue that some of the items could fall

>>>>>>> into multiple categories...  Any glaring omissions?
>>>>> Specifications/Functionality
>>>>> ****************************
>>>>> -JDK 5 for Geronimo *(11)*
>>>>> -JEE 5 *(3)*
>>>>>   Enterprise JavaBeans 3.0 *(5)*
>>>>>   Java Servlet 2.5
>>>>>   Java ServerPages 2.1
>>>>>   Java ServerPages Standard Tag Library
>>>>>   Java Persistence Architecture (is this part of Java EE?)
>>>>>   Java Transaction API (JTA)
>>>>>   J2EE Management
>>>>>   J2EE Connector Architecture
>>>>> -JAX-WS support *(4)*
>>>>> -GBean improvements (doc, lifecycle, dependencies, dep. injection, 
>>>>> ..) *(2)*
>>>>> -Dynamic Queries *(2)*
>>>>> -javax.persistence
>>>>> -annotated session beans.
>>>>> -Support for JSR-168 (Portlet API)
>>>>> -ServiceMix
>>>>> -Maven2 support
>>>>> -service/daemon wrapper
>>>>> -Remove the requirement of the openejb-jar.xml??
>>>>> -Better db tools in the admin console
>>>>> -Configuration management, possibility to make a production 
>>>>> version without some current modules (e.g. OpenEJB or ActiveMQ),
>>>>>   there are end users who don't have the resources (memory, disk) 
>>>>> to run Geronimo fully equipped and they don't need every
>>>>>   feature of the J2EE stack
>>>>> - Continued support of Jetty
>>>>> -First class HttpSession clustering.
>>>>> -More integration with Apache mod_JK/mod_ajp . It would be nice if 
>>>>> a request would continue through a pool until it landed
>>>>> on a server with that webapp.
>>>>> -Mass deployment tools that allow the server 'cloning' and rollout 
>>>>> mentioned during Geronimos initial days.
>>>>> -Global JNDI ENC
>>>>> Tools
>>>>> *****
>>>>> -NetBeans support *(3)*
>>>>> -JDK 5 for launching and running the Geronimo Eclipse plugin *(2)*
>>>>> -Eclipse plugin improvement (it is really good but think it could be
>>>>> better)
>>>>> -Eclipse mini-roadmap (from Sachin)
>>>>>   - run resources directly from the workspace, so the ear isn't 
>>>>> built and re-packaged on every publish
>>>>>   - More control over the runtime/server wizards, publish process, 
>>>>> and server management
>>>>>   - Continue to build up the UI so we have a complete set of "form 
>>>>> editors" for the G deployment plans
>>>>>   - ability to see changes reflected live in something like the 
>>>>> Common Navigator as you modify your plans
>>>>>   - full synchronization between the source view and views using 
>>>>> the model
>>>>>   - copy/paste, undo/redo support
>>>>>   -There's also plans in WTP to improve the Server Tools Framework 
>>>>> to make it easier to have more control over what defines your 
>>>>> runtime.
>>>>> Usability
>>>>> *********
>>>>> -Deployment *(5)*
>>>>>   Less deployment requirements (simpler plans, more defaults, etc.)
>>>>>   Simplifying deployment (some means to generate geronimo 
>>>>> deployment plans?
>>>>>   Easier  way to  deploy  EAR Files
>>>>>   More application validation at deployment
>>>>>   Better redeployment to prevent requests from failing if they hit 
>>>>> that server during the  redeploy.
>>>>> -More powerful text configuration
>>>>> -Migration path from Tomcat to Geronimo
>>>>> -Shortcuts for building web services
>>>>> Process
>>>>> *******
>>>>> -More frequent releases incorporating more user feedback (small 
>>>>> releases  more often vs. big releases only 4 times a year) *(7)*
>>>>> -Geronimo Certified Partner Program (including Jetspeed-2 as a 
>>>>> member). *(2)*
>>>>> Documentation *(10)*
>>>>> *************
>>>>> -Tutorials *(4)*
>>>>>   How to use Geronimo with: Apache Axis, WSS4J, ActiveMQ
>>>>> -Cookbooks
>>>>> -Better documentation on deployment descriptors
>>>>> -More detailed documentation about the architecture and Gbeans *(2)*
>>>>> -A browsable table describing where to find all plans, etc. for 
>>>>> each deployed component or service.
>>>>> -More documentaion on deploying EAR's, WAR's, EJB's, RAR's, 
>>>>> classloading and dependencies with that apps)
>>>>> Examples *(4)*
>>>>> ********
>>>>> -Examples for everything
>>>>> -More documentation/examples for me should be more explicative 
>>>>> models of the basic openejb-jar.xml and ejb-jar.xml,
>>>>>    explaining which tag points where or what
>>>>>   Session beans, entity beans(BMP and CMP)
>>>>>   Message-Driven-Bean.
>>>>>>> -Dave-

View raw message