geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: [DISCUSS] Adding a "Tech Preview" portlet group in Admin Console in G 2.0
Date Mon, 30 Jul 2007 14:18:13 GMT

On Jul 30, 2007, at 2:04 AM, Vamsavardhana Reddy wrote:

> On 7/30/07, Vamsavardhana Reddy <> wrote:
> On 7/30/07, Kevan Miller <> wrote:
> On Jul 28, 2007, at 1:41 AM, Vamsavardhana Reddy wrote:
>> On 7/28/07, Kevan Miller <> wrote:
>> On Jul 26, 2007, at 1:21 AM, Vamsavardhana Reddy wrote:
>>> How about adding a "Tech Preview" portlet group in Admin Console  
>>> in G 2.0 where we can include the portlets (for e.g., the "Create  
>>> Plan" portlet Shiva is working on.  See 
>>> jira/browse/GERONIMO-3254 ) for which user feedback will play a  
>>> great role in improving those further.  Once we decide on whether  
>>> to retain those or not, we can either move them out to a  
>>> different group or remove them from Admin Console accordingly.
>> Some of the new pluggable console support would have helped, here.  
>> But that's not going into 2.0. Personally, sounds like this should  
>> go into trunk, if it's not ready... Can still get good feedback...
>> --kevan
>> The idea is that if these portlets go in as part of a release with  
>> binaries readily available for download, we have a better chance  
>> of getting more users to try the portlets and possibly provide  
>> some feedback too in the linked wiki pages.  If it goes only into  
>> trunk, the users will still have to build the binaries from trunk,  
>> which they may not want to/may not succeed due to some reason or  
>> the other.
> Yes, I understood the idea.
> If a committer thinks that this code is ready and wants to commit  
> it, then why isn't it in trunk? If it was in trunk, then we could  
> evaluate and discuss getting it into branches/2.0. I'm currently  
> doubtful that it should go into 2.0...
> I am not referring to code that may be delivering 100% of what it  
> is expected to deliver.
> I thought an example may help here.  The plan creator portlet that  
> Shiva is working on, currently handles WAR files.  The fully  
> functional one is expected to handle  WAR, EAR, EJB JAR,  etc.

A WAR plan creator sounds like useful capability in its own right. I  
don't see any reason why it couldn't be provided stand alone. If this  
capability was committed in trunk, provided useful capability, and  
had low risk for causing other problems, I would probably be in favor  
of putting it in the 2.0 release. I would not tag it with a "Tech  
Preview" label.

Is a WAR capability the function you'd like to put into 2.0? I'll  
repeat -- you're best starting point is to get the function into  

This discussion has gotten me wondering about plan generation  
wizards, the j2g migration tool, and IDE tooling. Perhaps we should  
be thinking more holistically about these functions, rather than as  
disparate capabilities...

View raw message