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 12:24:51 GMT
actually, you probably can't use the task right now without a 
workaround.  Found a bug that didn't exist in my eclipse environment 
with the task.  The work around if you want to try it is to create the 
build directory and put a file in the build directory.  For some reason, 
the task is deleting javac's destdir if destdir is empty.
Dean

Dean Hiller wrote:

> 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
>>
>>
>>  
>>
>------------------------------------------------------------------------
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message