Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
To: dev@avalon.apache.org
From: Mauro Talevi <mauro.talevi@aquilonia.org>
Subject: Re: about cornerstone
Date: Sun, 04 May 2003 18:47:31 +0100
Lines: 61
Message-ID: <b93jnh$l7d$1@main.gmane.org>
References: <3EB2A86E.9010702@apache.org> <b904in$sup$1@main.gmane.org>
 <3EB3E89A.4070104@apache.org> <b92mfj$nks$1@main.gmane.org>
 <3EB4FF07.50603@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
In-Reply-To: <3EB4FF07.50603@apache.org>
Sender: news <news@main.gmane.org>

Stephen McConnell wrote:
> > 
> 
> I must confess that it is an annoying subject.  In the case of a project 
> like cornerstone threads we have basically one interface class and one 
> implementation class.  It certainly feels like overkill to have all of 
> these project structures around just to keep Maven happy.  On the 
> otherhand, all of Maven logic holds true - both impl and api projects 
> have different versions, dependencies, names, etc.

do they? if so then one should actually make them two different 
projects, but to me it does not feel like it is needed in the case of
cornerstone blocks.
I see the point of having a complete separation between api and impl
when you have a fatter api - say the servlet api or others.
and you have a lot of ways of implementing this api.
then you would have a project to define the api - usually via a
specification, and separate projects that implement it.
but here does it really hurt anybody to have the same version, names
and even dependency in the api and impl?
Also, if you have two implementations of the api you would have to 
create another project?  And would have to invent another name other 
than impl.  Just seems a bit overengineered.  Unless one sees from the
beginning the necessity to have multiple implementations which have
completely different dependencies, etc ...
Then you would have to have a cornerstone-x-default project for the
default implementation of block x and add implementation projects as 
required.

In any case I would push the case with the maven folks to allow multiple
artifacts, at least as far as jars are concerned.
The other scenario I had posted on the maven list was the separation of
rmi stubs in a separate jar.  Now that is a build-time artifact and you
cannot put in a separate codebase.

> I'm currently doing so sub-project post goals to copy classes from the 
> target builds up to the parent project under which a jar is created - 
> but this less than optimal becasue the dependency info is inconsistent.  
> I think the real solution is a plug-in that takes an api project and an 
> implementation project are generates a merged jar with a manfest derived 
> from the combined dependencies of the two.

That's a possibility - ie to relate different projects with different 
types (api and impl).  Surely something for the maven todo list.

But for the moment how would you propose to create a combined jar if you
create separate projects?  Some people would find it annoying to have to
include api and impl jars for all the cornerstone blocks.

> I see a couple of problems with this approach - firstly the impl version 
> and the api version need to be different.  Secondly, the api manifest 
> generation isn't going to correctly reflect the api jar dependencies.

I accept that they issues are there but I consider them the lesser of 
the two evils compared to the api/impl separation.
At least for small artifacts such as cornerstone blocks.

A matter of personal taste - I guess :-)

Cheers, Mauro


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