On 7/30/07, Kevan Miller <[EMAIL PROTECTED]> wrote: > > > 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... >
Thanks for raising this Kevan. The idea of "Plan Generation Wizard" basically started off as a new feature proposal to Geronimo Eclipse Plug-in. Later feedback from user mailing list suggested that such a tool would fit best within "Admin Console" in close proximity with "Deploy New" tool. Some of this discussion can be found here: http://www.mail-archive.com/dev@geronimo.apache.org/msg46831.html Hence the current focus is on getting this feature implemented as a new Portlet in Admin Console. This work will later be incorporated into Geronimo Eclipse Plug-in also to simplify developmental activities. Admin Console portlet is targeted to simplify the job of server administrators. Looks like there will be a overlap of the functionality of J2G migration tool and Plan Generation Wizards. Haven't looked into the details of J2G migration tool, but my initial understanding is that in addition to auto-transforming J-specific deployment plans into Geronimo deployment plans, it also auto-maps some J-specific security classes into the ones supported by Geronimo. So if a user already has a J-specific plan then "J2G migration tool" is the tool for him, else he can start looking into Plan Generation Wizards. And yes, sharing of code for the overlapping functionality between J2G migration tool and plan generation wizards is something to be looked into. Comments welcome. - Shiva --kevan >
