A "manual" integration is ready. Pls find a description in `org.eclipse.swordfish.tooling.target/copy.txt`.
----
Best regards,
Dzmitry Krakadzeyau
From: swordfish-dev-bounces@xxxxxxxxxxx
[mailto:swordfish-dev-bounces@xxxxxxxxxxx] On Behalf Of
Renat Zubairov
Sent: Tuesday, June 02, 2009 12:43
To: Swordfish Developer Discussions
Cc: Dzmitry Krakadzeyau
Subject: Re: [swordfish-dev] Swordfish runtime build integration: proposal
Hi,
So, do we have a decision how will we proceed with build integration or shall we discuss it further?
Renat
On 28.05.09 13:51, "Jürgen Kindler" <juergen.kindler@xxxxxxxxx> wrote:
Hi all,
I think we are mixing up two things here. The reason why decided to create the lastGoodSwordfishRuntime directory is simply that I
wanted a place with a fixed name that remains stable (opposed to what CC does: it created a new directory for each successful build)
so a script can easily be written. And I wanted to avoid that accidently pushing the button will give you some untested results (because
when we have the integration tests running again they will run in a separate build (which then will the one to "publish" what RT thinks
is a last good result. As on the build server the CC runs the builds in random order we need a way to "communicate" so a fixed directory
makes sense.
If a user works locally, the scenario is different:
- the user controls where s/he locates the projects
- the user controls when to run a build (and will be smart enough not to attempt a tooling build if the RT build failed.
- after the RT build has finished successfully, the artifacts have a defined place RELATIVE to the RT project already - there is no need to copy them again within the scope of the RT directory
I propose that you name build file & target I should use and allow the target to have a parameter (the source directory) I can set during the CC copy project. Then I can call your build script from the CC build to copy the bundles from the directory defined
in the CC project to the directory your script knows.
That will be simple and reusable for users too.
Something like
<!-- Install last good bundles for in a specific directory -->
<!-- up the currently used bundles. -->
<!-- Properties to be set: -->
<!-- - source.dir - the source directory for copy -->
<!-- - destination.dir - the destination directory for copy -->
<target name="svnInstallLastGoodBundles">
<echo>Installing last good Swordfish Runtime bundles ...</echo>
<echo>Remove current bundles from "${destination.dir}"</echo>
<delete>
<fileset dir="${destination.dir}" includes="*.jar"/>
</delete>
<echo>Copy new bundles from "${source.dir}" to "${destination.dir}"</echo>
<copy toDir="${destination.dir}">
<fileset dir="${source.dir}" includes="*.jar" />
</copy>
</target>
will do. You could even hard code the destination.dir relative to your project root ...
GreetinX
Jürgen
On 5/28/09 12:49, "Dzmitry Krakadzeyau" <dzmitry.krakadzeyau@xxxxxxxxx> wrote:
Hello all.
As you probably know we need some jars from the Swordfish Runtime (RT) to build Swordfish Tooling. Here is a user story and a TODO.
Scenario
- A user checks out the both of trunks.
- The user runs an RT build using an Ant build script from the RT trunk. If the build is OK (tests are passed) then the "lastGoodSwordfishRuntime" directory is created inside the directory with RT trunk and all the necessary jars are copied to it. The result:
we have a target platform.
- The user runs a special Ant script from the Tooling trunk. This script creates the "target_platform" directory inside the directory with Tooling trunk and copies all the files from the "lastGoodSwordfishRuntime" directory to it. The result: we have a target
platform inside Tooling and we do not need the RT trunk for now -- so if the RT directory will be destroyed (all can happen!) we can build Tooling anyway.
- The user runs a Tooling build using an Ant build script from the Tooling trunk. This script uses jars from the "target_platform" directory.
Tasks
- Minsk team writes the script for copying.
- Juergen creates a CC button which will run the script for copying on the server.
- Minsk team updates the Tooling build Ant script.
----
Best regards,
Dzmitry Krakadzeyau
__________ Information from ESET Smart Security, version of virus signature database 3832 (20090206) __________
The message was checked by ESET Smart Security.
http://www.eset.com
__________ Information from ESET Smart Security, version of virus signature database 3832 (20090206) __________
The message was checked by ESET Smart Security.
http://www.eset.com