ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emerson Cargnin - SICREDI Servi├žos <emers...@sicredi.com.br>
Subject Re: "Elements of Ant Style": ant files separation
Date Mon, 04 Nov 2002 16:47:13 GMT
I'd like to make question about the architecture of ant files:

I have a big financial system, with a lot of modules, so we planned to 
separate the big build file into smaller build files, what should be the 
preffered way
- creating one build file for each module
- creating one build file for each layer, say, web, ejb, eyc...

I prefer the first approache, but the people here seems to preffer the last.

And if i use the first, how to keep what not  change in a single build 
file and let each module keep just what changes? I know i can have 
build.properties file to separate properties that change, but it doesn't 
  extend to different targets....

I saw the fisrt approache at jboss project.


One problem with the first approache is when you use CMP entities that 
have CMR's, becouse it need to be deployed in a single ejb-jar.xml

Steve Loughran wrote:
> ----- Original Message -----
> From: "Ken Gentle" <j.kenneth.gentle@acm.org>
> To: "Ant Users List" <ant-user@jakarta.apache.org>
> Sent: Monday, November 04, 2002 6:18 AM
> Subject: Re: "Elements of Ant Style": the ./lib directory
> 
> 
> 
>>At 11:01 PM 11/3/2002 -0800, you wrote:
>>
>>
>>>----- Original Message -----
>>>From: "Ken Gentle" <j.kenneth.gentle@acm.org>
>>>To: <ant-user@jakarta.apache.org>
>>>Sent: Saturday, November 02, 2002 10:07
>>>Subject: "Elements of Ant Style": the ./lib directory
>>>
>>>
>>>
>>>>I've finally received my copy of "Java Development with Ant", and want
>>>
> to
> 
>>>>thank Steve and Erik for a great reference!
>>>
>>>we love positive feedback
>>>
>>>
>>>>I'm generally in agreement with these suggestions, but one stands out
>>>
> as
> 
>>>>diametrically opposed to my common practice.  in section D.4.5,
>>>
> Directory
> 
>>>>Structure, the recommendation is to keep library files "with the
>>>>project".  As most projects are managed from some type of SCM tool,
>>>
> that
> 
>>>>kind of implies keeping those lib/jars in the SCM system.
>>>
>>>not so sure about this kind of feedback tho :)
>>
>>That's not negative feedback - or it wasn't intended to be.  I was not
>>trying to say the practice is bad, or wrong, but that I've used other
>>methods to achieve similar results without incorporating jars/olb/.a files
>>in the repository.
> 
> 
> I know, I was just teasing. And its nice to see people going into the
> details of the book and seeing how well it aligns with their own thoughts
> and experience, because having been through different projects, you will
> know different things which work/dont work.
> 
> 
>>Understood.  I'm not advocating "taking what you got", but instead of
>>including the libs in the repository, why not include only the information
>>about the dependency and pull things together for inclusion at
>>deployment/distribution time (or not - one might also include the list of
>>dependencies as part of the distribution as installation pre-requisites).
> 
> 
> that makes sense. Provided there is enough info in there to get (maybe
> build) the versions of dependent libs used in with any build, you dont need
> your own copies.
> 
> 
>>>>I'm in the process of setting up the build environment for a new
>>>>employer/project (why do *I* always seem to end up doing this?),
>>>
>>>Because (a) you secretly enjoy it or (b) you dont trust anyone else.
>>
>>Ouch -- that was a rhetorical question.  I don't particularly care for it,
>>so it must be that "trust" thing... ;^)
> 
> 
> yup
> 
> 
>>I need SCM to record the changes in my source and its dependencies.  That
>>doesn't necessarily mean I have to keep the libs themselves under SCM.
> 
> 
> If you have another way of storing dependency info in SCM, *and* propagating
> changes out to all the team, then go for it -and tell us what you did.
> 
> -steve
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>
> 
> 


-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
| Emerson Cargnin          |
| Analista de Sistemas Sr. |
| Tel : (051) 3358-4959    |
| SICREDI Servi├žos         |
| Porto Alegre - Brasil    |
|xxxxxxxxxxxxxxxxxxxxxxxxxx|


--
To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>


Mime
View raw message