geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: Splitting up the server into a few more chunks
Date Thu, 30 Aug 2007 04:41:35 GMT
I think we don't really need svn, lets just mail around patches we  
make to the list and get rid of this scm crapo... too much work for  
too little benifit.... lol

:-P

--jason


On Aug 29, 2007, at 10:12 AM, Prasad Kashyap wrote:

> I'm trying to understand what we have discussed/decided so far. Please
> let me know if my summary is on track and help me correct course.
>
> We haven't discussed the actual maven groupIds/artifactIds/directory
> names yet. So all names used in this summary are just as examples.
>
> Summary:
> ---------------
> 1. Our basic objective is to deliver a framework and a large set of
> components with which our users can build their own Geronimo server.
> The primary goal of our build restructuring exercise should be to help
> us meet this objective.  The next goal should be to help us build
> smoothly and release efficiently.
>
> 2. We have to split the current build tree into support, framework,
> and plugins sub-trees. Other than support and framework, everything
> else should be plugins. This includes jee5, non-jee5, samples etc.
> which could go in their own subtrees or be together.
>
> Scenario 1:
>     server/support/trunk
>     server/framework/trunk
>     server/plugins/trunk/      <--- jee5, non-jee5, samples etc are
> all here together.
>
> Scenario 2:
>     server/support/trunk
>     server/framework/trunk
>     server/plugins/trunk/
>                                  jee5/
>                                  opt/
>                                  samples/
>
> Scenario 3:
>     server/support/trunk
>     server/framework/trunk
>     server/plugins/trunk    <-- jee5 plugins
>     server/opt/trunk          <-- opt plugins
>     server/samples/trunk  <-- samples plugins
>
>   Can we please pick a scenario here and move on ?
>
> 3. We have to restructure the build tree to make it feature-oriented
> rather than type-oriented like present. To take Jencks example, jetty
> runtime, jetty deployer and jetty admin should be kept together (as a
> plugin group) instead of keeping module jars and config cars separate.
>
>    server/plugins/trunk/
>                                 geronimo-jetty/
>                                            jetty-runtime    (1)
>                                            jetty-deployer   (2)
>                                            jetty-admin       (3)
>
>   "I think you should be able to install (1), (1 and 3) (1 and 2) or
> (1, 2 and 3)." - Jencks.
>
>
> Further discussion:
> ----------------------------
> Currently the plugins tree is structured as plugins/<component>/trunk.
> IMO, this is not feasible in the long run, esp. when we want to
> convert most of everything we have into plugins,  b'coz -
>
> 1. svn checkout of a complete Geronimo server (framework + all
> plugins) for a given version now becomes a nightmare.
> 2. building all plugins for a given version becomes difficult.
> 3. inheritance from a common parent becomes difficult. Many things
> will be duplicated across all the poms for all the plugins. Longer
> poms causes larger maintenance issues.
> 4. Even maven plugins whom we want to emulate for their independent
> release cycles are not structured this way. Trunk, branches, tags form
> the top tier.  http://svn.apache.org/viewvc/maven/plugins/
>
> Cheers
> Prasad
>
>
> On 8/8/07, Jason Dillon <jason@planet57.com> wrote:
>> On Aug 6, 2007, at 8:03 PM, David Blevins wrote:
>>> On Aug 6, 2007, at 8:12 AM, David Jencks wrote:
>>>
>>>> I certainly agree with your goal but am less sure about your
>>>> proposed naming and organization.  Also from looking at your list
>>>> it took me a couple minutes to figure out what is removed from
>>>> "server"
>>>>
>>>> I've been thinking that we could proceed by turning bits of the
>>>> server into plugins.  For instance I was planning to turn the
>>>> directory bits I commented out recently into a plugin this week.
>>>> I think we could fairly easiiy turn jetty, tomcat, and openejb
>>>> into plugins.  I wonder if, after turning the "easy stuff" into
>>>> plugins what we will think about reorganizing the remaining stuff.
>>>>
>>>> So then the question might be how to organize the plugins?
>>>
>>> Haven't read the rest of the thread yet, but I'd like to backup the
>>> idea of pulling things out one at a time, like we did with
>>> connector and transaction, making them plugins if possible.  It
>>> would be really great if people do things like upgrade OpenEJB when
>>> a new release came out -- which we're hoping is often.
>>
>> I'd still like to see the plugin mangement in the console work
>> something like the Confluence Plugin Repository Client ( http://
>> confluence.atlassian.com/display/CONFEXT/Confluence+Repository 
>> +Client )
>>
>> Which has a sex UI to show whats installed (version, urls, notes,
>> etc), whats not (with simple buttons to install) and when stuff is
>> out of date (with simple buttons to upgrade).  This would be *hugely*
>> powerful for administrators managing a Geronimo instance.
>>
>> :-)
>>
>>
>>


Mime
View raw message