ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Hiller <d...@xsoftware.biz>
Subject Re: ant task submission....compilewithwalls
Date Tue, 26 Aug 2003 11:59:16 GMT
yeah, that's weird.  I see the html file in my sent mail, but once I 
received it back from the list, it is not there.

So anyways, here is the summary.  In a project, there can be lots of 
modules and it is important to make sure the designs are not violated.  
certain packages depend on other certain packages.  Sometimes we 
accidentally put dependencies were we did not mean to put them.  At an 
architectural level we prevent this by putting stuff like server, 
client, and api in three totally separate source trees so that the 
client doesn't depend directly on the server but depends on the api 
only.  CompileWithWalls is designed to put up the walls at the design 
level.  Basically, lets say your server has a player, recorder and a 
mediasession that uses both.  player should not depend on recorder and 
recorder should not depend on player.

Here are the packages.....
biz.xsoftware.media.player
biz.xsoftware.media.recorder
biz.xsoftware.media

Currently if they are all in the same source tree, people may 
accidentally introduce dependencies between recorder and player making 
them unreusable and violating the design laid out.  compilewithwalls is 
defined like so to prevent this

<compilewithwalls>
     <walls>
        <package name="modA" package="biz.xsoftware.mod.modA"/>
        <package name="modB" package="biz.xsoftware.mod.modB"/>
        <package name="mod"  package="biz.xsoftware.mod" 
depends="modA,modB"/>    
     </walls>
     <javac>NORMAL Javac task with same params</javac>
</compilewithwalls>

Notice closely that all the dependencies of the packages are clearly 
stated in the walls element.  If many people start to like this, there 
may be a walls attribute later specifying the file with the walls 
element of dependencies.  The above guaranteed that modA will not be 
able to put code in that depends on modB and vice versa.  It also allows 
code to be put in mod that depends on modA and modB.

Another common use would be in a common module.  I just put these same 
walls up and was disgusted by some package dependencies I accidentally 
introduced.  This helps me prevent myself from doing it.

Currently at work we prevent this same thing by having separate source 
trees and people are complaining up a storm.  The thing is when we went 
to that structure we realized all these dependencies that we didn't want 
existed.  This helps with that problem of allowing one to keep one 
source tree and put up walls that prevent other packages to be used from 
certain packages that are supposed to be independent.

what do you think?  I already know my company wants to use it, a friend 
at another company wants to use it, and I want to use it on my open 
source project also.  I am curious what others think.  I hope you will 
try it on your common module and see what dependencies pop up.

I have attached the a zip this time with everything in it including the 
html file so it doesn't get stripped.
thanks,
dean




Conor MacNeill wrote:

>On Tue, 26 Aug 2003 01:22 pm, Dean Hiller wrote:
>  
>
>>Hello,
>>    What is the acceptance process of a new task?  I would like to put
>>this task in the ant repository for anybody else who needs it.  I have
>>attached the task, tests and doc for it.  I have put in the apache
>>licenses and stuff also.
>>thanks,
>>    
>>
>
>I don't see any docs (may have been removed by list manager) Could you give us 
>a quick summary of what this task is for?
>
>Conor
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org
>
>
>  
>

Mime
View raw message