Further to my previous email:
I have a couple of questions related to automated builds (nightly /
release)
We have currently been using ANT for day-to-day development and for
automated builds.
We employed a strategy for using the same script for day-to-day development
and for automated builds.
Some elements of this strategy are alerady built into maven - though I am
still trying to work out a couple of others.
I will briefly describe what we currently do with ANT - so my questions are
clearer
We had a standard set of targets for all of the basic tasks. Our strategy
with ant was to make sure none of these standard targets had any
dependancies between them (ie no depends="someOtherTask"). This mean that
each of the standard targets could be used in day-today development (ie, if
you just want unit-tests - thats all that runs). If we wanted to run a
sequence of targets, then this was encapsulated in a seperate target (e.g
buildTest, buildTestDeploy)
The buildTest target was the most important one. When we did a build, we
would collect all the new binaries in a ./dist/quarantine/ directory and
run the unit tests. If the unit tests passed, then we would copy the new
binaries to ./dist/latest
This meant that the developers' dist/latest would always hold a working
version. (NB: There was no upload to a central repository at this point)
It also meant that the unit tests effectively ran against the deployment -
there was never files missing from the distribution.
For automated builds, we then had a series of "batch" targets which called
the individual targets in a set sequence.
Briefly, the set sequence involved :
Step 1: create a new directory based on the the timestamp (e.g.
./.batch/20021030-1156/)
Step 2: fetch the source from source control (either CVS, SourseSafe or
Source Offsite)
Step 3: fetch the libs from source ctrl (we had external libs stored in
directories according to their version - and we always had a "latest"
directory - like maven's snapshot.
Step 4: increment the build number (for C++ this involved generating a
header file with the version embedded - for java its much easier)
Step 5: buildTest
Step 6: generate docs
Step 7: commit/check in the file containing the new build number
Step 8: label/tag source control with a tag using the new build number
Step 9: Update dist/latest in the central repository (CVS)
We had two other batch targets for updating the major and minor versions
(and storing them appropriately in ./dist/latest ad in ./dist/v_major_minor
and tagging source control with version number.
This clean src/lib fetch meant that we made sure that the src repository
contained all the require src and lib files and no other files hanging
around
This meant that we always had the source control regularly tagged with
working builds (build that would pass the unit tests at least)
So, after all that, my questions to do with maven are:
Q1) How can we employ the concept of a quarantine directory.
Q2) How can we run maven so that all the src is fetched (the libs are
kind-of taken care of by maven - but for C++ we have to do it ourselves)
Q3) How can we run maven so that the build is done in a different directory
each time (ie, there is no danger of pollution from a previous run). Call
form ant?
Q4) How can we make sure that local repository is in synch with the remote
repository (is there a way to "clean" the local repository?)
Q5) How can we integrate the versioning into the Maven build (incrementing
the version number etc) (pre and post goals perhaps?)
Thanks very much.
-Nick
Looking fwd to contributing on this project (see previous post re VC++/VB
plugins). Whats the best way to do this?
This message and any attachments (the "message") is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
---------------------------------------------
Ce message et toutes les pieces jointes (ci-apres le
"message") sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
--
To unsubscribe, e-mail: <mailto:turbine-maven-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:turbine-maven-user-help@;jakarta.apache.org>
