Re: "Elements of Ant Style": ant files separation

[Emerson Cargnin - SICREDI Servi�os]

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" <[EMAIL PROTECTED]>
To: "Ant Users List" <[EMAIL PROTECTED]>
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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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>