On Jul 30, 2007, at 2:04 AM, Vamsavardhana Reddy wrote:
On 7/30/07, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote:
On 7/30/07, Kevan Miller < [EMAIL PROTECTED]> wrote:
On Jul 28, 2007, at 1:41 AM, Vamsavardhana Reddy wrote:
On 7/28/07, Kevan Miller <[EMAIL PROTECTED]> 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 https://issues.apache.org/
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
trunk...
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...
--kevan
