avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mauro Talevi <mauro.tal...@aquilonia.org>
Subject Re: about cornerstone
Date Mon, 05 May 2003 10:39:29 GMT
Stephen McConnell wrote:
> Client applications (James for instance) have different concerns when an 
> API version changes as opposed to an implementation version incriment.  
> Updating and enhancing an implementation can move along completely 
> different timelines to the interface it is implementing.

well - if one envisages api and impl to move along of their own accord
and have several implementations then yes you need to create separate

> I think there are a number of things that need to solidify somewhat in 
> Maven.  On the top of my list the need for multiple source directories 
> (resolving to one source path).  Way to many plugins currently check 
> src/java to see if sources exist which negates the impact of src/idl _ 
> idl plugin (as an example).  Second thing is what you are talking about 
> - multiple artifacts - but I think this is more complex because of the 
> questions concerning version lifecycle and dependecies.

I'm still not sure what the thought about multiple artifacts is in 
I think they are oriented towards a more unified approach,
ie treating all artifacts coherently.
I understand where they come from, as the whole point of the maven 
approach is to enforce more "structure" as apposed to the ant approach, 
which allows more flexibility.  And in order for the dependencies to 
work you need to enforce some rules.
But there may be some cases in which a conceptually unified artifact,
needs also to be represented or offered separated.

> Similar problem to the IDL generated stubs and so on that I deal with.


> I've just committed two new subdirectories into avalon-corenerste - site 
> and threads.  In the threads subdirectory, if you do maven build, it 
> fires a reactor which builds the api and impl.  Post goals on the api 
> and impl sub-projects unpack the generated jar into the parent target 
> classes directory and a post goal in the target uses these classes to 
> build the consoidated jar.  It's a hack pending a plugin that does 
> conslidation taking into account the compostite set of dependencies.
> Do a checkout - and take a look at the threads and site directories - 
> I'm sure we can improve on some of the Maven stuff.  To generate the 
> site - do the following:
>  $ cd threads
>  $ maven build
>  $ cd ..\site
>  $ maven site
> I have only done the threads block for the moment - but I wanted to get 
> that in place as a kind of template.

a few comments:
1. there is a "bootstrap" problem:  if you do maven build it fails first
time around when it tries to execute the maven clean goal on the
impl project, since this depends on the api jar which has not been 
installed in the repo yet.
I should think that it suffices to not do a clean at the reactor level.
Simply have the single sub-project build goal depend on clean.
2. why are there 4 sub-dir in threads (api, impl, threads-api, 
threads-impl)?  Seems that there is a duplication here?  Redundancy in 
3. in the time-honoured cornerstone tradition, and to keep in line with 
the package names, could the sub-project names be "service" and "block"
instead of "api" and "impl"?

Cheers, Mauro

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

View raw message