sorry for not getting back at you sooner.
in subdir build, execute ant target get.dependencies to get all the dependent libs into your local repository.
if the eclipse classpath is not in sync, it is not considered a broken build. it is up to the eclipse developers to maintain that themselves. usually, it should be in sync, though.
for more info, you might also want to check the build/readme.html. that should explain the jbpm build process. But since we are finishing a rather large source code restructuring, this is still stabilizing. If something is not clear, please consider posting here again. we'll try to be more responsive.
Thanks for getting back to me Tom.
Actually I was thinking of something more along the lines of Apache Gump... http://gump.apache.org/ in that some system is constantly checking for updates to the cvs repository and periodically checks them out and tries to build them and then run a standard suite of tests against it.
In the development shop where I work, we've found that sort of thing tremendously valuable as we have people working all around the code base simultaneously. It lets us know if someone inadvertently broke the build w/out having to discover it yourself and then be stuck until either a fix is checked in or the change rolled back.
I usually start my day by checking the web site for our build and if it's "green" then I do a full update of the code base, and build while I'm reading forums, etc. Then, I know I'm good for the day to build and work with my changes w/out worrying about how far I may have drifted from other people's work (usually no more than a day's worth).
Thanks again for your response and AWESOME job building jbpm etc. It looks like a great code set and I'm really looking forward to working with it.
our it team has a continuous integration thing up and running. i just have to get a few things fixed before that runs again with the new restructured jbpm code base.
the biggest problem currently is the email tests. i'm using dumpster in the test suite for testing emails. but our continuous integration server doesn't allow for ports to be opened under 1024. so i need to find a way to tell dumpster to open up the fake mailserver on a different port. also i need to figure out how to tell the JavaMail API that mails should be sent using this different port...
All help with these two items are welcome.
I have created a jira issue for this: http://jira.jboss.com/jira/browse/JBPM-791
I started looking around (it's been years since I played with javamail) and it seems like it's just a property that can be set. So I'll poke at that a bit. if.... I can get a build working ;^)
Right now (after a cvs update today) I get a build failure because of...
/mnt/bayDrive/local/jboss/jbpm/jbpm.3/build/build.xml:56: The following error occurred while executing this line:
/mnt/bayDrive/local/jboss/jbpm/jbpm.3/designer/jpdl/org.jbpm.gd.jpdl.build/build.xml:58: The following error occurred while executing this line:
/mnt/bayDrive/local/jboss/jbpm/jbpm.3/designer/jpdl/org.jbpm.gd.jpdl.build/build.xml:165: The following error occurred while executing this line:
java.io.FileNotFoundException: /mnt/bayDrive/local/jboss/jbpm/jbpm.3/designer/jpdl/org.jbpm.gd.jpdl.build/target/projects/org.jbpm.gd.jpdl.docs/gpd.userguide/build.xml (No such file or directory)
i'll have a look at the build error. which target are you executing ?
try to see if you can launch the jbpm test suite in eclipse. the classpath should be ok if you have set the JBPM_REPO eclipse variable appropriately.
let us know how it goes
after 2 attempts, i managed to get the the build working (there is still a problem with a classpath that is being scanned before the libs are build)