This week's book giveaway is in the Java in General forum.
We're giving away four copies of Event Streams in Action and have Alexander Dean & Valentin Crettaz on-line!
See this thread for details.
Win a copy of Event Streams in Action this week in the Java in General forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

conceptual question in a multiproject environment - ANT

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hello,

Im working on an environment with multiple portlet projects, who are using
the following structure:

---Portlet Project---
|
---Domain Specific Services Project (holding DAO's, Services, Beans, Utilities)---
|
---Common Framework---

Im working on the build scripts at the moment and did the following:

-I followed the best practices by having a build.xml per project, which means that each Portlet Project, Domain Services project has its own build.xml.

Now, i have lots of common tasks like "init.war", "compile.war" etc. Those task are in a common-build.xml at the moment. The question is where to put that common-build.xml ...should i copy that common-build.xml into each project and would be forced to check and guarantee the integrity of those copied common-build.xml (which seems to be a weak concept to me) or do i make a "AntBuild" project with the following structure:



That would just destroy the "one build file per project"-concept...

What do you guys think about? What experience did you do in similar cases?
 
author
Posts: 5856
7
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My co-author an I had a similar situation for the build scripts for our book, where we had a separate project per chapter. What we did was created a separate project that contained the common build task, along with common files we needed for many of the other projects. Then the build.xml for each project included the build-include.xml file in the extra project. This really streamlined the build scripts for the chapters.

Also, this question should have been posted in the Ant forum. Could someone move this post there (I don't have my superpowers yet)?
[ October 13, 2008: Message edited by: Peter Johnson ]
 
chuan ito
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
uuups sorry but i dont have those superpowers either ;-D

if i externalize the common build configuration xml into such a external project, why not to put all the build files into such a project and guarantee the integrity of those files in one single project.

This would also result in the dependency of such an ant project for all the other projects.

Dont get me wrong im really happy for any input that i can get...im just trying to get the points to together to decide
 
Peter Johnson
author
Posts: 5856
7
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How would having a build in one project be dependent on a build in another project be any different from having a Java app or library in one project be dependent on a Java library in another project? Either way you still have to be aware of how changes to the common entity (whether build or Java library) might affect the entities that depend on it.

Practically, the build-include.xml file will probably change only very rarely. Once my coauthor any I had that file set up, we had to only occasionally change it, usually to add new targets to build things that we did not build before. And if you have a continuous integration process, you can quickly detect when something goes wrong.

Another thought - if you place all the builds in one separate project, how would you ever test them? You would not be able to until you grabbed the source code for one of the projects and then ran the build used for that project. And then consider the directory structure within version control - the build project would have build files in many directories which would overlap with the source directories. Hmm, that is confusing, perhaps an example will help.

Here is how the directories would be arranged if each project had its own build:



Each project would be extracted (from version control) into its own directory, that is, proj02 gets extracted into a directory named proj02.

But if you placed all of the builds into a single project, you would have this:



Now you would extract each project into the same directory.

That would make keeping the projects separate in Eclipse or NetBeans a little difficult.

Alternately, you could place all of the builds in the same directory (naming each one differently) and then set the basedir for each. This would avoid having the directories in version control, but it would require that everyone use directory names that match the specified basedir.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!