Hi Jürgen,
One request from our side. Could you also
put additional jars into the lastGoodSwordfishRuntime directory?
List of the jars here:
http://wiki.eclipse.org/Swordfish_Documentation:_Running_Target_Platform
Thanks in advance,
Yuri
-----------------------------
Yuri Shamin
ITOS Ltd.
5/1, Melezha Str.,
Minsk, Belarus, 220000
office phone: +375 17 2620839
fax:
+375 17 2620247
mobile:
+375 29 6887577
icq: 104436734
skype: yuri.shamin
-----------------------------
From:
swordfish-dev-bounces@xxxxxxxxxxx [mailto:swordfish-dev-bounces@xxxxxxxxxxx] On Behalf Of Jurgen Kindler
Sent: Thursday, May 28, 2009 2:51
PM
To: Swordfish Developer
Discussions
Subject: Re: [swordfish-dev]
Swordfish runtime build integration: proposal
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
--
Jürgen Kindler
Senior Quality Engineer
Tel.: +49 228-182 190-55
Fax: +49 228-182 191 93
Juegen.kindler@xxxxxxxxxx
Wussten Sie
schon? SOPERA <http://www.sopera.de/services-support/trainingsangebote/> hat den Open Source
Business Award 2009 <http://www.osbf.de/en/node/1466> verliehen bekommen!
SOPERA GmbH - Open Source SOA
Subscription
Services, Support & Maintenance, Training,
Technical SOA Consulting & Customized Development
www.sopera.de <http://www.sopera.de/>
SOPERA GmbH ·
Geschäftsführer: Dr. Ricco Deutscher,
Harald Weimer, Peter Spiegel
Sträßchensweg 10 · 53113 Bonn · Handelsregister:
Bonn HRB 15336
Hohenlindnerstraße 11b · 85622 München
Vertraulichkeitshinweis:
Diese Nachricht und jeder übermittelte Anhang beinhaltet vertrauliche
Informationen und ist nur für die Personen oder das Unternehmen bestimmt, an
welche sie tatsächlich gerichtet ist. Sollten Sie nicht der
Bestimmungsempfänger sein, weisen wir Sie darauf hin, dass die Verbreitung, das
(auch teilweise) Kopieren sowie der Gebrauch der empfangenen E-Mail und der
darin enthaltenen Informationen gesetzlich verboten ist und gegebenenfalls
Schadensersatzpflichten auslösen kann. Sollten Sie diese Nachricht aufgrund
eines Übermittlungsfehlers erhalten haben, bitten wir Sie, den Sender
unverzüglich hiervon in Kenntnis zu setzen.
