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.
John
>
>
> - 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
few
>>>>>>> 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-
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>>
>
>
|