avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Gump builds
Date Fri, 28 May 2004 01:25:25 GMT
Noel J. Bergman wrote:
> Stephen McConnell wrote (on jakarta commons):
>>Noel J. Bergman wrote:
>>>And I would love to have James (both branch_2_1_fcs and MAIN)
>>>building with GUMP.
>>One way to get a lot more value back from Gump for the James project
>>would be to separate build descriptions for the different components
>>that the James project is based on.
>>    * james core
>>    * dns
>>    * remote
>>    * pop3
>>    * smtp
>>    * mail-store
>>    * user-store
>>    * spool
>>    * nntp-repository
>>    * nntp-server
>>    * fetchpop
>>>From here you would be able to get consistent feedback without the
>>overhead of the relatively expensive dependency chain that exists
>>in the current james server gump definition (23 direct, 203 implied).
> Patches are welcomed, but the only change it would appear to make would be
> that instead of being told that James failed to build, we might be told that
> certain components failed to build.  Not sure what that buys us for the
> effort.

The benefit would be *much* higher.

First of all, your gump build would be based against a set of supported 
Avalon components.  If you look at the real James dependencies - you have:

                                                        (1.0 is best)
   Product                                                       FOG

   avalon-framework/avalon-framework-api#4.2.0                   0.92
   avalon-framework/avalon-framework-impl#4.2.0                  0.92
   cornerstone-threads/cornerstone-threads-api#2.0.0             0.88
   cornerstone-threads/cornerstone-threads-impl#2.0.0            0.82
   cornerstone-sockets/cornerstone-sockets-api#1.0.0             0.90
   cornerstone-connection/cornerstone-connection-api#2.0.0       0.84
   cornerstone-connection/cornerstone-connection-impl#2.0.0      0.84
   cornerstone-scheduler/cornerstone-scheduler-api#1.0.0         0.9
   cornerstone-scheduler/cornerstone-scheduler-impl#1.0.0        0.84
   cornerstone-datasources/cornerstone-datasources-api#1.0.0     0.9
   cornerstone-datasources/cornerstone-datasources-impl#1.0.0    0.71
   cornerstone-store/cornerstone-store-api#1.0.0                 0.9
   cornerstone-store/cornerstone-store-impl#1.0.0                0.9
   cornerstone-connection/cornerstone-connection-impl#2.0.0      0.84

and the underlying Excalibur products:

   excalibur-thread/excalibur-thread-api#2.0.0                   0.9
   excalibur-thread/excalibur-thread-impl#2.0.0                  0.83
   excalibur-pool/excalibur-pool-api#2.0.0                       0.9 

   excalibur-pool:excalibur-pool-impl#2.0.0                      0.84

Aside from excalibur-io, the above collection of products represent a 
generally high ranking in the gump world view.  In effect, relative to 
the above dependencies - your chances of building James are for all 
practical purposes rather high.

However - lets look at the picture when we add the Phoenix platform and 
the corresponding impact on build probability:

   avalon-phoenix/phoenix#4.2                                    0.02

Taking into consideration the magnitude difference between the 
Cornerstone and related Excalibur components FOG factor versus the 
Phoenix FOG factor - I think its immediately apparent that a James gump 
build that locks into Phoenix is somewhat equivalent to notion of 
oneself to a dead horse.  Remember - Phoenix is a dead product, it's 
community has moved. Avalon's solution in this space is the Merlin 
container.  Simply establishing a gump build to run against the Merlin 
container will not impact things significantly relative to the 
equivalent Avalon and Excalibur ranking:

   merlin/merlin-unit#3.3.0                                      0.84

My conclusion is that simply dropping the James gump dependency on 
Phoenix will bring the James project into the active community in terms 
of useful feedback and consistent builds.

Concerning the gump descriptors - I can go ahead and make the changes to 
the descriptors and bring James into an active concern - however - we 
should think some more about the implication of the suggestion to break 
out James into it respective components (james core, dns, remote, pop3, 
smtp, mail-store, user-store, spool, nntp-repository, nntp-server, 
fetchpop).  This would require some refactoring of the build system 
(breaking out individual components and establishing independent builds) 
- something beyond a simple patch.

Personally I think this would be a totally good move and I'm ready to 
help out if there is a green light.

Cheers, Stephen.


| Magic by Merlin                       |
| Production by Avalon                  |
|                                       |
| http://avalon.apache.org              |

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message