You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2004/05/27 15:58:36 UTC
Gump builds
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.
> If the above is *too* fine-grain, then why not simply break out your
> james server build from the container build? The Avalon project has
> already gone though the process of separating out the different
> subsystem that james is dependent (tagged in cvs and published under
> specific versions).
Again, patches are welcomed.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Gump builds
Posted by Stephen McConnell <mc...@apache.org>.
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/excalibur-io#1.1
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
Re: Gump builds
Posted by Stephen McConnell <mc...@apache.org>.
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/excalibur-io#1.1
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org