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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
------------------------------------------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
