• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Ant in build environment

 
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is as much a build environment question as an Ant question, but here goes.
I'm on a team that is building an enterprise application - it contains ejb's, web apps, and a couple of stand-alone client apps. They're all bundled into an ear file for deployment.
The trouble is in the build environment. We have the following directories:
src/ - all source files
lib/ - jars to use for compile and deployment
etc/ - config files
...
build.xml
We use one build.xml (for now) to build everything, with targets that can build each individual application, or the whole thing.
It's getting unmanageable, and I'm considering a different structure:
/ejb
/src/
/lib/
/etc/
/webapp1
/src/
/lib/
/etc/
/webapp2
/src/
/lib/
/etc/
/clientapp1
/src/
/lib/
/etc/
Each app will have its own build.xml, and then there will be one main build.xml at the project root that can call the other build files.
Any thoughts on this? I'd like to get feedback from people who are managing big projects.
Chris
 
Ranch Hand
Posts: 149
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is how companies I have been at in the past have done it. A root project with calls deeper into the source tree.
One other approach along this line is to actually put all of the xml into one location and then using entity includes,build the deeper xml files.
This can be nice becuase all of your build 'code' can be found quickly and easily in one place but .. the deeper build files are a bit less readable.
 
Author
Posts: 111
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm in the process of building a big J2EE app, consisting of session beans, Struts, and other layers such as a common tree of source that is common to all tiers. I've crafted it such that the src directory contains "common", "ejb", and "web" subdirectories, each with its own package hierarchy. There is one build file that builds all pieces of it and bundles it into a full EAR. Until we need the pieces broken out into pieces used by other apps it is simplest to keep it all together. The advice I have is to keep the trees easily separated, and don't use patternsets (includes/excludes) stuff to isolate out pieces of a source tree into components - let the directory structure mirror the components that need to be built.
 
Chris Reeves
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, I just finished putting a lot of includes/excludes stuff in our master script.
I know how I'll be spending my afternoon.
 
Erik Hatcher
Author
Posts: 111
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
An advantage to keeping your directory trees separated, for example in the app I'm building right now, is that it allows us to pull the "common" tree out and move it up another level so that new projects can use it when/if it comes to that.
I feel for you having to refactor your build file, but in the long run it will be well worth it for future maintenance and for new developers - they simply create new source code and don't have to worry about having to change the build file patterns to pick things up, for example.
 
Chris Reeves
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I completely agree; everything is obvious on the other side of it.
Now, if I can just get everyone to stop coding for a minute so I can move their files around...
 
Beauty is in the eye of the tiny ad.
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic