[EMAIL PROTECTED] wrote:
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.
Hi,
Wouldn't changing ${maven.build.dir} do it ?
I'm not sure what you want to do there ...
Though, jars and dists are not created by Maven if UnitTests
fail, so maybe that's the behaviour you want ...
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)
There is an Ant CVS task. It should be pretty easy to use that in a preGoal.
I would use a <preGoal> to the goal you need to run like this: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?
<preGoal name="your-build-goal">
<tstamp>
<format property="build.date" pattern="dd-MM-yyyy/hh-mm"/>
</tstamp>
<j:set var="maven.build.dir" value="${basedir}/target/${build.date}"/>
</preGoal>
This way, the build would be made in "./target/3-11-2002/23-56" for instance.
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?)
Use snapshot dependencies. Those are downloaded every time Maven runs. For instance: <dependency> <id>foo</id> <version>SNAPSHOT</version> </dependency>
Q5) How can we integrate the versioning into the Maven build (incrementing the version number etc) (pre and post goals perhaps?)
Again, I'm not sure about what you want to do there ... But, again, I suggest that you use the CVS task to commit the file, in a postGoal this time ! ;-) Changing the version number in the POM *could* be done with Jelly's XML tag library, but I wouldn't recommend that. (I don't believe the POM should be modified programmatically)
Thanks very much.
You're welcome !
-Nick
St�phane
Looking fwd to contributing on this project (see previous post re VC++/VB plugins). Whats the best way to do this?
I would say ... send patches and submits, maybe ? ;-)
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.
Please don't send us to jail if this mail is reproduced all over the Internet (Jakarta mailing lists are archived in MANY places!) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran�ais ! Yahoo! Mail : http://fr.mail.yahoo.com -- 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>
