Re: Excalibur/Cornerstone/James clarification

[Stephen McConnell <mc...@apache.org>]

Serge Knystautas wrote:

> Stephen McConnell wrote:
>
>> There are two scenarios I think you should be considering:
>>
>>   1. a James releasse scenario - this is where you referencing 
>> relased jars
>>   2. a James build that is based on the current CVS of Avalon based 
>> on Gump
>
>
> I agree with 1, but not with 2.
>
> I don't think it does James any good to treat the Avalon jar 
> dependencies any different than we would other libraries.  I also 
> don't think it does Avalon any good in the long term. 


Some clarification:

  Scenario (1) is getting James into shape so that it is
  built and distributed based on released jar files from
  wherever.  This is not the case today.  James is currently
  using an unsupported build of cornerstone.  James will
  also needs to upgrade at some point to the new thread jar
  from excalibur (that includes the fixes concerning pool
  sizes).  This upgrade impacts Phoenix as well because
  James is currently bound to Phoneix at the level of the
  code.  All of the above is managable stuff that is reflected
  in the James repository via addition of released jars in
  lib directories, etc.  Key actions that both James and
  Avalon people need to be concerned about is:

    * migration to a release for the cornerstone 1.0 components
    * migration to the updated thread 1.1
    * migration to a Phoenix release backed with thrread 1.1

  Scenario (2) is about collaborating sufficiently so that
  release candidates (like the current cornerstone-xxx-1.0 jars
  and the excalibur-thread-1.1 jar) can be validated.  The best
  approach to this is to establish a Gump based build procedure
  that is a seperate process that builds James against all of
  the current Apache repositories.  This has been in place for
  ages and has been failing for ages.  Things I'm doing are in
  part address this disconnect.

Some misconceptions:

  Nobody is suggesting that James move from well defined releases
  to HEAD depedencies.  Gump is an early warning system that will
  help to keep the James community aware of changes that may
  impact them across the entire Apache community.  I am suggesting
  that James/Cornerstone dependency get sorted - because the setup
  in James today with respect to cornerstone is far from
  satisfactory.

Hope that clarifies things.

Something else to keep in mind is that I'm moving close to a point
where I will be introducing James depedencies into code I'm working
on.  Having James in Gump (working) provides me with a lot more
assurance about things - if something fails - then I've got info
about the source (where the source could be James or could be a
dependency that James has on some other Apache project).

>
> I know it's not ideal, but for me the big API change that happened in 
> the Avalon project (Component -> Service I think it was) is not that 
> big of a deal.  What made it a big deal is that there was not much of 
> a clear release beforehand, I don't think any release (yet) after the 
> fact, and I haven't heard of a changelog or HOWTO to help users make 
> this change.
>
> Codebases change all the time, and I have to believe the Avalon 
> committers did what they felt was a right by moving to a different 
> naming/design pattern.  But with software engineering, you need 
> software development practices to support it.
>
> As an example with another open source project, we use Netsaint for 
> monitoring.  This was basically disolved, and the authors went and 
> refactored the codebase into Nagios.  I don't mind that Netsaint isn't 
> supported or that my large conf file needs to be completely 
> rewritten... because there is explanation of what happened, clear 
> releases so I can stay with Netsaint until we have the time to 
> migrate, and I've heard rumor there is a conversion tool out there to 
> help you migrate your conf file.  These practices allow me to handle 
> the change, and this is better than having Nagios people who are very 
> willing to help because in the end, I know my code/system best and 
> need to understand how to apply it.
>
> These software development practices allow the software engineering to 
> happen with less restrictions.  For the Avalon community, having James 
> build against Avalon and have Avalon committers help James with that 
> is a misdirection of resources (IMHO).  You will get James working on 
> it, but at the expense of other activities that can slow adoption of 
> the codebase (which ultimately James needs to see happen as well). 


I disagree with the "slowing adoption" argument.  Getting James in sync 
with avalon releases will accellerate adoption.

>
>
> So, I think Avalon should be treated just like other dependencies... 
> people can propose updates, the community reviews it, and then if 
> approved, the update happens.
>

Sounds good and I agree in principal.

BUT.

 1. James needs to dump cornerstone.jar
 2. A set of candidate releases of corerstone components have been
    prepared that incorporate bug fixes raised here.
 3. To move from a unreleased and unmaintained corerstone jar to
    the candidate release means tranition from CM to SM (details
    on this already supplied).
 4. Both Pete and I have done the transition (not a big deal)
 5. My testcase is showing problems and I havn't been able to
    figure out if this is a James, Cornerstone, Excalibur issue.
 6. Apparently there are problems in James HEAD that could be
    contributing to this.
 7. I would like to validate Cornerstone and Excalibur candidate
    released against James BEFORE proposing these packages for
    Avalon release.

Cheers, Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>