avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [proposal] cornerstone roadmap
Date Tue, 17 Jun 2003 12:29:15 GMT
Leo Simons wrote:

> Stephen McConnell wrote: a lot. I reorganised some stuff to extract 
> bullet points:
> 
>     * reuse is bliss
>     * rtfm
>     * it doesn't matter if the standard sucks?
>     * restructure, then release
>     * leaky abstractions?
>     * who needs consensus anyway?
> 

> 
> It doesn't matter if the standard sucks?
> ----------------------------------------
> 
>>> seperation in directory structure (ie src/api/ and src/impl/). Yet
>>>  another thing I want to do is convert the build to maven.
>>
>>
>> The structure I've put in place (and recommend) is to place the impl
>> and apis into seperate subprojects of a common group.  I.e. threads
>> contains sup-project api and subproject impl (as per discussion on
>> list a while back).
> 
> 
> link / keyword? There's a 100 ways to do it. How important is it we 
> consistently pick the same way?

Very important.



> RTFM
> ----
> 
>> I would like to see a little stabalization of the new Avalon build.
>>  Based on an attempt to build using Maven early yesterday I had a
>> bunch of messages telling me I had to do a bunch of things (and the
>> message was way too long).  This should not be necessary.  Using
>> Maven the entire process should be automated.  I would prefer to see
>> a clean solution (i.e. get maven, cd to your project, type "maven"
>> and your done).
> 
> 
> MPSRTFM (More People Should Read The F$#@% Manual) :D
> 
>     cd avalon/framework
>     maven dist -Doverride.version=4.2
>     maven avalon:deploy -Doverride.version=4.2
> 
>     cd ../fortress/container
>     maven dist -Doverride.version=1.1
>     maven avalon:deploy -Doverride.version=1.1
> 
>     cd ../tools
>     maven dist -Doverride.version=1.1
>     maven avalon:deploy -Doverride.version=1.1
> 
> releases built and deployed. To keep docs from appearing, just change
> buildsystem/maven.xml to have "dist" as the default goal (or something
> like that) instead of "avalon:info". But that is a bad idea.

More common than "dist" would to build and run tests.  I would have
"test" as the default target, and distributions get built later.

> Restructure, then release
> -------------------------
> 
>>> 1) we should create a brand-new repository avalon-components, with
>>> a maven build structure and a directory structure similar to what I
>>> have put in place for the avalon repository
>>>
>>> 2) we should move the packages in list (1) there
>>
>>
>> we should discuss this after a release of the core suite
> 
> 
>> Restructuring is way down on the list of priorities as far as I can
>> see and can always be done once the cornerstone releases are
>> completed.
> 
> 
> hmm. This is exactly my point: we should do restructure now, get
> something stable in place, *then* release. Otherwise we'll end up with
> incompatible releases or big changes further down the road which will
> just annoy your users.
> 
> putting it another way: I'm not going to do any of this /after/ a
> release because at that point the incentive to do it is gone. I am
> willing to invest the time /once/ to refactor builds and automate
> everything.

How about this: we *rename* "Cornerstone" to "avalon-components".
After we are done with the restructuring, we can move/merge the
Excalibur components (DataSource, Monitor, SourceResolve, XMLUtil,
etc.) into that repo.

Whatever is left we can look at later.  It will provide a clean
separation of components and reusable container utility code.


> Leaky abstractions?
> -------------------
> 
>> I disagree with this distinction.  For me, Excalibur is about
>> low-level utilities.
> 
> 
> well, we disagree :D. I think many of the components in excalibur would 
> be sm.lookup()ped together with many of the components in cornerstone 
> and it would make sense. Oh well, we're not going to agree so lets drop 
> that for now...
> 
>> [a single repository (with single build structure, single website,
>> etc etc) for all our components] is only valid if you ignore the
>> different granularity of the object/components provided under
>> excalibur versus cornerstone.
> 
> 
> why?

I agree, the distinction is artificial.  Some of the Excalibur
components are actually higher level than the Cornerstone components.
All *components* should be in one repository--but we can do that
incrementally.

> Who needs consensus anyway?
> ---------------------------
>  > Can I presume that what you are thinking is 100% consitent with the
>  > stuff I've committed yesterday and earlier today?
> 
> well, nope :D. But that's okay.
> 
> you go ahead and whip cornerstone into shape, I'll keep out of the way. 
> Consider my proposal dropped in favor of Just Getting Things Done (By 
> You, Not Me).
> 
> cheers!


Ok.


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


Mime
View raw message