Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm
Message-ID: <59B1C000C017D411A43200508BC7494E258840@GULF>
From: Jesse Tilly <JTilly@hoteltools.com>
To: "'ant-user@jakarta.apache.org'" <ant-user@jakarta.apache.org>
Subject: RE: Call for ideas: multiple EJB targets
Date: Mon, 16 Oct 2000 14:08:22 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

Can I throw another loop into this design?

My goal and current solution:

    My goal is to have a build that can VCS-update, compile, jar, ejbc, war,
deploy, test.  That's easy, in and of itself.  The build should also be able
to build and test subsets of the project upon request.  For example, I
should be able to build and test an individual EJB, and only build/test that
EJB.  In "makeland" this is accomplished by having makefiles in each
directory capable of building/using the system from that point in the
directory tree.  This is the current "accepted practice" of make.  Ant
provides me the ability to remove all the file system, scripting junk that
made porting these makefiles a nightmare and a half.  However, I don't want
to lose that functionality.  Right now, I have a kludge working for my EJBs.
At the command line, I can specify a property of the bean name I want to
work with.  A target set called <build | test | clean>-bean allows me to
work on just one bean at a time.  Unfortunately, the way to do them all
requires me to actually specify the names in the build.xml (with 1.1.  in
1.2 I could, theoretically, write a script that runs down the directories,
but that's still a kludge).  Ed's point about a modification to ejbjar is
good.  I would even write it if it weren't for the feature freeze and for
the fact that it's just ejbjar, which is WebLogic specific.  

Future solution:

I think, in general, Ant needs a mechanism to traverse directories
intelligently.  Then, you could just have an element do work in just that
directory.  Possibly a regular expression.  We're very close to it.  Imagine
having a target property that you could specify one of the current file
filters, creating a fileset across which all inner-elements would work on.
It's a bit complex for a quickie synopsis, but I hope my goal and ideas help
in everyone's understanding.

Thanks to everyone for their ideas.

Jesse

-----Original Message-----
From: Ed French [mailto:edf@MomentumSoftware.com]
Sent: Monday, October 16, 2000 1:32 PM
To: ant-user@jakarta.apache.org
Subject: RE: Call for ideas: multiple EJB targets


We also use a directory structure and naming conventions similar to Jesse's.
I think a really nice option would be having the ability to use the Remote
Interface
name as the base name to your Jar.  That way, you could keep the standard
file names for the xml files and you can use the jar suffix for any
customization
on file naming.  For example, if your remote interface is Account and your
jar
suffix is EJB.jar, the resulting EJB Jar would be AccountEJB.Jar.  Because
ejbjar
already parses the deployment descriptor, it would be fairly easy to
implement
this scheme.  In fact, I had a modified version of the ejbjar before the
most recent
changes (which I think are an improvement) that did exactly that.  We did
not want
to have to use any special naming conventions but still wanted a single
target
that could make all of the EJB Jars.

Ed French
Momentum Software, Inc.
Austin, TX  78703
edf@MomentumSoftware.com


-----Original Message-----
From: Jesse Tilly [mailto:JTilly@hoteltools.com]
Sent: Monday, October 16, 2000 11:03 AM
To: 'ant-user@jakarta.apache.org'
Subject: RE: Call for ideas: multiple EJB targets


Conor,

The key here is that you seem to have a similar, but very different
arrangement than ours.  It appears *all* of your descriptors are in one
directory, named with the naming convention.  Our directories follow the
naming convention with each directory having ejb-jar.xml,
weblogic-ejb-jar.xml and weblogic-cmp-rdbms-jar.xml files.  Ejbjar does not
appear ready to traverse directories to build beans.  I can possibly change
my build environment, but I am kind of fond of the bean-per-directory setup,
allowing for other things to be stored there, like documentation, test
classes and a convenient place to actually build the bean.  You are right
about the per-bean build.xml situation though.  It's not pretty and harks
back to Make days...which is why I'm using Ant in the first place.

Jesse

-----Original Message-----
From: Conor MacNeill [mailto:conor@m64.com]
Sent: Monday, October 16, 2000 9:25 AM
To: ant-user@jakarta.apache.org
Subject: RE: Call for ideas: multiple EJB targets


Jesse,

We regularly build multiple EJBs with a single build file using the ejbjar
task. We do use the ejbjar naming convention to name the deployment
descriptors. You probably don't need to have a naming convention for the
bean and PK classes as these are specified in the deployment descriptor. A
naming convention for these is not a bad idea, just not required for
building.

Our setup is similar to your. Code in one tree, descriptors in another. That
is mandatory for us as we deploy the same bean code with different
deployment descriptors.

I would recommend against going to separate build files for each bean.

Let me know if you need more info.

Conor


> -----Original Message-----
> From: Jesse Tilly [mailto:JTilly@hoteltools.com]
> Sent: Friday, 13 October 2000 13:37
> To: 'ant-user@jarkarta.apache.org'
> Subject: Call for ideas: multiple EJB targets
>
>
> Situation:
>    Project with multiple EJBs.  Each bean has its own subdirectory for
> storing its descriptor files.  The classes are packaged within the rest of
> the source.  Each EJB class follows the convention of <bean
> name>Bean.java,
> <bean name>PK.java.  This naming convention *should* allow me to have n
> beans but the global build environment be unaware of any particular one by
> name.  Due to uncertainty as to which 1.2 release is "most stable", I am
> running Release 1.1.
>
> My idea:
>   Along with the descriptor files, each bean's directory will have its own
> build.xml to provide for the ability to jar, ejbc, deliver and deploy
> itself.  The project build file should be able to simply traverse a
> directory tree of these descriptor directories.  Unfortunately, I cannot
> find a facility within the <ant> tag that allows me to "run all build.xml
> files below a certain directory".  Beyond that, I cannot think of
> any other
> way to solve my problem.
>
> Any ideas?
>
> > J E S S E  E  T I L L Y
> > Senior Programmer, Development
> > ____________________________________________
> > HotelTools, Inc.
> > 100 Galleria Parkway, Suite 1020
> > Atlanta, GA  30339
> > ph: 770.956.4080 x5361
> > fax: 770.956.4077
> > cell: 678.524.5764
> > http://www.hoteltools.com
> >
> >
>  <<Jesse Tilly.vcf>>
>
>