Roadmap / Things-to-do

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Roadmap / Things-to-do

Geir Magnusson Jr.
It should come as no surprise that as we come to the end of  
certification, there are a lot of things we'll want to get done, such  
as usability, performance, new features, etc.

Can we start discussing what is on our personal wishlists/roadmaps  
and get a combined list we maintain here collectively?  I think we  
want to provide better visibility for those that want to contribute...

geir

--
Geir Magnusson Jr                                  +1-203-665-6437
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap / Things-to-do

Jeff Genender
I'll start...here are a few...

1) A nice usable, and polished management console.
2) A GUI configuration tool that allows you to add/remove components,
where the result is a set of plans with your custom configuration. (No
more XML hacking for the newbies out there).
3) True clustering (I don't know the status so this may already is being
dealt with) with rolling deployments similar to BEA (i.e. deploy but
don't activate until I say I am ready).
4) True hot deploy/undeploy (is this working? or does it need work?  I
have been somewhat unsuccessful without some form of restart)
5) Sniffable deploy directory.  It would be nice to drop EAR/WAR/etc in
a directory and have it auto deploy.

Jeff

Geir Magnusson Jr. wrote:

> It should come as no surprise that as we come to the end of  
> certification, there are a lot of things we'll want to get done, such  
> as usability, performance, new features, etc.
>
> Can we start discussing what is on our personal wishlists/roadmaps  and
> get a combined list we maintain here collectively?  I think we  want to
> provide better visibility for those that want to contribute...
>
> geir
>
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap / Things-to-do

Francis S Nazareth
In reply to this post by Geir Magnusson Jr.

Are there plans to have tooling  for Geronimo? I would preferrably see an eclipse-based IDE (for J2EE code generation), with a geronimo test environment embedded in eclipse.

Regards,

Francis
-----------------------------------------
ISL, IBM India
[hidden email]
Phone: +91 80 51927737



"Geir Magnusson Jr." <[hidden email]>

05/31/2005 10:18 PM
Please respond to dev

       
        To:        [hidden email]
        cc:        
        Subject:        Roadmap / Things-to-do

       


It should come as no surprise that as we come to the end of  
certification, there are a lot of things we'll want to get done, such  
as usability, performance, new features, etc.

Can we start discussing what is on our personal wishlists/roadmaps  
and get a combined list we maintain here collectively?  I think we  
want to provide better visibility for those that want to contribute...

geir

--
Geir Magnusson Jr                                  +1-203-665-6437
[hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Roadmap / Things-to-do

Jeremy Boynes
Francis S Nazareth wrote:
> Are there plans to have tooling  for Geronimo? I would preferrably see an
> eclipse-based IDE (for J2EE code generation), with a geronimo test
> environment embedded in eclipse.
>

One of the things being worked on elsewhere is Geronimo support in the
Eclipse Web Tools Project which I believe will provide some of this.

http://www.eclipse.org/webtools/
--
Jeremy
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap / Things-to-do

Alan Cabrera
In reply to this post by Francis S Nazareth
I was thinking the same thing but, for IntelliJ IDEA.  ;)


Regards,
Alan

Francis S Nazareth wrote, On 6/1/2005 12:35 AM:

Are there plans to have tooling  for Geronimo? I would preferrably see an eclipse-based IDE (for J2EE code generation), with a geronimo test environment embedded in eclipse.

Regards,

Francis
-----------------------------------------
ISL, IBM India
[hidden email]
Phone: +91 80 51927737




"Geir Magnusson Jr." [hidden email]

05/31/2005 10:18 PM
Please respond to dev

       
        To:        [hidden email]
        cc:        
        Subject:        Roadmap / Things-to-do

       


It should come as no surprise that as we come to the end of  
certification, there are a lot of things we'll want to get done, such  
as usability, performance, new features, etc.

Can we start discussing what is on our personal wishlists/roadmaps  
and get a combined list we maintain here collectively?  I think we  
want to provide better visibility for those that want to contribute...

geir

--
Geir Magnusson Jr                                  +1-203-665-6437
[hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Roadmap / Things-to-do

Jeremy Boynes
In reply to this post by Jeremy Boynes
Not sure what happened to this the first time ...

Jeremy Boynes wrote:

> Francis S Nazareth wrote:
>
>> Are there plans to have tooling  for Geronimo? I would preferrably see
>> an eclipse-based IDE (for J2EE code generation), with a geronimo test
>> environment embedded in eclipse.
>>
>
> One of the things being worked on elsewhere is Geronimo support in the
> Eclipse Web Tools Project which I believe will provide some of this.
>
> http://www.eclipse.org/webtools/
> --
> Jeremy
>

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap / Things-to-do

David Jencks
In reply to this post by Geir Magnusson Jr.
1. Complete Jeremy's packaging and assembly plugins and use them as
much as possible in the build.  I think this will make how geronimo is
intended to fit together a lot clearer and make the build make more
sense.

2. Examine and stabilize the interfaces between geronimo modules (also
between geronimo/openejb etc).  Ideally we could stabilize these to the
extent that no iterface changes would be necessary until geronimo 2.

3. Review the contents of each module to make sure it makes sense.  For
instance, I think that openejb core has at least 3 modules inside it.  
I'm also not quite sure about the distribution of code between the
connector and transaction modules.

4. Come up with a reasonable solution to the desire to set ports, pool
sizes, etc when starting the server.  To me this definitely does not
involve editing the contents of the original deployment plans or the
compiled configurations but some entirely separate solution such as a
configurable property database gbean.

5. Move to xmlbeans v2.

6. Make sure tx recovery works and build a UI for reviewing problems

7. Good pluto or other portlet integration.  Also a portlet based
management console.

thanks
david jencks

On May 31, 2005, at 9:48 AM, Geir Magnusson Jr. wrote:

> It should come as no surprise that as we come to the end of
> certification, there are a lot of things we'll want to get done, such
> as usability, performance, new features, etc.
>
> Can we start discussing what is on our personal wishlists/roadmaps and
> get a combined list we maintain here collectively?  I think we want to
> provide better visibility for those that want to contribute...
>
> geir
>
> --
> Geir Magnusson Jr                                  +1-203-665-6437
> [hidden email]
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap / Things-to-do

ammulder
On Sat, 4 Jun 2005, David Jencks wrote:
> 4. Come up with a reasonable solution to the desire to set ports, pool
> sizes, etc when starting the server.  To me this definitely does not
> involve editing the contents of the original deployment plans or the
> compiled configurations but some entirely separate solution such as a
> configurable property database gbean.

        Can we talk about this a bit more?  I'm concerned that a property
database won't work as well.  As in, we have a ton of configurable
properies set across a ton of GBeans.  We could provide a single database
to allow editing of like the 30% of those we expect to be most changed,
but then what happens when someone wants to change something else without
redeploying the server plans?  Eventually, I see this database getting big
enough that it becomes pretty irratating to manage having the "editable"
properties in two places, or balancing which goes where.

        In other words, I think we'd do better to have a more flexible way
to edit GBean properties in general, rather than keeping the current plan
strategy but also using a separate dynamic database.

        If we were going to go with this kind of dynamic database
approach, I'd like to really minimize what we put in there (ports and
perhaps security/SSL configuration) and then insist that you use a tool or
console to edit the rest (even if that means you have to start the
server).  Maybe this is what you had in mind.

Aaron