On Tue, Jan 27, 2009 at 11:29 AM, ant elder <[email protected]> wrote:

>
>
> On Tue, Jan 27, 2009 at 9:42 AM, Simon Laws <[email protected]>wrote:
>
>>
>>
>> On Tue, Jan 27, 2009 at 9:24 AM, ant elder <[email protected]> wrote:
>>
>>>
>>>
>>> On Tue, Jan 27, 2009 at 8:53 AM, Simon Laws 
>>> <[email protected]>wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jan 27, 2009 at 8:34 AM, ant elder <[email protected]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 26, 2009 at 7:29 PM, Simon Laws <[email protected]
>>>>> > wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 26, 2009 at 2:38 PM, ant elder <[email protected]>wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jan 26, 2009 at 2:07 PM, Simon Laws <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jan 26, 2009 at 1:44 PM, ant elder <[email protected]>wrote:
>>>>>>>>
>>>>>>>>> I know this is work in progress and we're not sure yet what the
>>>>>>>>> complete picture of how this will work yet, but one thing i think is 
>>>>>>>>> good
>>>>>>>>> with the current samples is that the build scripts are simple and self
>>>>>>>>> contained and can be copied by users. So i'd probably prefer the Ant 
>>>>>>>>> scripts
>>>>>>>>> don't use some shared common scripts unless its really needed. I 
>>>>>>>>> guess i'm
>>>>>>>>> wondering if we do need to separate common bits out then maybe we 
>>>>>>>>> haven't
>>>>>>>>> quite got this simple enough to use yet.
>>>>>>>>>
>>>>>>>>>    ...ant
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Jan 26, 2009 at 12:55 PM, <[email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> Author: slaws
>>>>>>>>>> Date: Mon Jan 26 12:55:41 2009
>>>>>>>>>> New Revision: 737681
>>>>>>>>>>
>>>>>>>>>> URL: http://svn.apache.org/viewvc?rev=737681&view=rev
>>>>>>>>>> Log:
>>>>>>>>>> Add an ant build file to hold some common targets used across the
>>>>>>>>>> samples
>>>>>>>>>>
>>>>>>>>>> Added:
>>>>>>>>>>    tuscany/java/sca/samples/build-common.xml   (with props)
>>>>>>>>>>
>>>>>>>>>> Added: tuscany/java/sca/samples/build-common.xml
>>>>>>>>>> URL:
>>>>>>>>>> http://svn.apache.org/viewvc/tuscany/java/sca/samples/build-common.xml?rev=737681&view=auto
>>>>>>>>>>
>>>>>>>>>> ==============================================================================
>>>>>>>>>> --- tuscany/java/sca/samples/build-common.xml (added)
>>>>>>>>>> +++ tuscany/java/sca/samples/build-common.xml Mon Jan 26 12:55:41
>>>>>>>>>> 2009
>>>>>>>>>> @@ -0,0 +1,34 @@
>>>>>>>>>> +<!--
>>>>>>>>>> + * Licensed to the Apache Software Foundation (ASF) under one
>>>>>>>>>> + * or more contributor license agreements.  See the NOTICE file
>>>>>>>>>> + * distributed with this work for additional information
>>>>>>>>>> + * regarding copyright ownership.  The ASF licenses this file
>>>>>>>>>> + * to you under the Apache License, Version 2.0 (the
>>>>>>>>>> + * "License"); you may not use this file except in compliance
>>>>>>>>>> + * with the License.  You may obtain a copy of the License at
>>>>>>>>>> + *
>>>>>>>>>> + *   http://www.apache.org/licenses/LICENSE-2.0
>>>>>>>>>> + *
>>>>>>>>>> + * Unless required by applicable law or agreed to in writing,
>>>>>>>>>> + * software distributed under the License is distributed on an
>>>>>>>>>> + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>>>>>>>>>> + * KIND, either express or implied.  See the License for the
>>>>>>>>>> + * specific language governing permissions and limitations
>>>>>>>>>> + * under the License.
>>>>>>>>>> +-->
>>>>>>>>>> +
>>>>>>>>>> +<project name="common">
>>>>>>>>>> +    <available file="../../distribution/pom.xml"
>>>>>>>>>> property="running.in.development"/>
>>>>>>>>>> +
>>>>>>>>>> +    <target name="common-set-development"
>>>>>>>>>> if="running.in.development">
>>>>>>>>>> +        <property name="distro.root"
>>>>>>>>>> value="../../distribution/all/target"/>
>>>>>>>>>> +    </target>
>>>>>>>>>> +
>>>>>>>>>> +    <target name="common-set-distribution"
>>>>>>>>>> unless="running.in.development">
>>>>>>>>>> +        <property name="distro.root" value="../.."/>
>>>>>>>>>> +    </target>
>>>>>>>>>> +
>>>>>>>>>> +    <target name="common-init" depends="common-set-development,
>>>>>>>>>> common-set-distribution" >
>>>>>>>>>> +        <mkdir dir="${sample.root}/target/classes"/>
>>>>>>>>>> +    </target>
>>>>>>>>>> +</project>
>>>>>>>>>>
>>>>>>>>>> Propchange: tuscany/java/sca/samples/build-common.xml
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>    svn:eol-style = native
>>>>>>>>>>
>>>>>>>>>> Propchange: tuscany/java/sca/samples/build-common.xml
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>    svn:keywords = Rev Date
>>>>>>>>>>
>>>>>>>>>> Propchange: tuscany/java/sca/samples/build-common.xml
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>    svn:mime-type = text/xml
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> That's a fair comment. We have to get the balance right between ease
>>>>>>>> ot use/copying and ease of maintenance. Let's see how it looks in a 
>>>>>>>> bit. I'm
>>>>>>>> using the common block atm so I don't have to keep going in and 
>>>>>>>> changing
>>>>>>>> three scripts as I have the following samples as test cases.
>>>>>>>>
>>>>>>>> implementation-java-calculator
>>>>>>>> host-webapp-calculator
>>>>>>>> binding-ws-calculator
>>>>>>>>
>>>>>>>> If it comes to it that we copy the majority of the specific code
>>>>>>>> back into each script that probably Ok with me (I reserving an element 
>>>>>>>> of
>>>>>>>> doubt to see how things work out) Before we do that though I'd like to 
>>>>>>>> see
>>>>>>>> if we can slim down that code to the absolute minimum and having it in 
>>>>>>>> one
>>>>>>>> place makes that easier (for me at least).
>>>>>>>>
>>>>>>>> Simon
>>>>>>>>
>>>>>>>
>>>>>>> Can't these type of samples have really really simple build scripts -
>>>>>>> all they need is a dependency on the sca-api jar and then compile the
>>>>>>> application classes to get an SCA contribution jar - thats it. We don't 
>>>>>>> even
>>>>>>> really need all those targets that we have in the 1.x sample builds to
>>>>>>> emulate maven functions, just the one simple compile step is all we 
>>>>>>> really
>>>>>>> need.
>>>>>>>
>>>>>>>    ...ant
>>>>>>>
>>>>>>
>>>>>> Ok, we lets play with them and see how far we can reasonably simplify.
>>>>>> All help much appreciated.
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>
>>>>> Well ok, going back to first principles the below Ant script for the
>>>>> implementation-java-calculator sample is about as simple as it could get. 
>>>>> It
>>>>> doesn't run the contribution to do that you'd use a launcher on the 
>>>>> command
>>>>> line. It doesn't test the contribution running in Tuscany to do that we'd
>>>>> have an itest as that type of test is an integration test of the Tuscany
>>>>> runtime not a unit test of the calculator class. It doesn't have any code 
>>>>> to
>>>>> work in the development environment because users are expected to be 
>>>>> using a
>>>>> distribution and Ant, developers use Maven and the sample pom.xml (which
>>>>> would be similarly simple). I expect you'll say something like "but we 
>>>>> need
>>>>> to be testing the Ant scripts in the developer build so they don't keep
>>>>> breaking", i don't think we do, they've kept breaking in the past because
>>>>> they've mixed several goals and become too complicated, keeping it simple
>>>>> like this will mean it wont break so easily and all the complexity will be
>>>>> in the launcher which would have its own unit tests.
>>>>>
>>>>>   ...ant
>>>>>
>>>>> <project name="calculator" default="compile">
>>>>>
>>>>>     <target name="compile" depends="init">
>>>>>         <javac srcdir="src/main/java"
>>>>>                destdir="target/classes"
>>>>>                debug="on"
>>>>>                source="1.5"
>>>>>                target="1.5">
>>>>>             <classpath>
>>>>>                 <pathelement
>>>>> location="../../modules/tuscany-sca-api-2.0-SNAPSHOT.jar"/>
>>>>>             </classpath>
>>>>>         </javac>
>>>>>         <copy todir="target/classes">
>>>>>             <fileset dir="src/main/resources"/>
>>>>>         </copy>
>>>>>         <jar destfile="target/calculator.jar" basedir="target/classes"
>>>>> />
>>>>>     </target>
>>>>>
>>>>>     <target name="init">
>>>>>         <delete quiet="true" includeemptydirs="true">
>>>>>             <fileset dir="target"/>
>>>>>         </delete>
>>>>>         <mkdir dir="target/classes"/>
>>>>>     </target>
>>>>>
>>>>> </project>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Why not include a run target. It seems much easier for the user to type
>>>>
>>>> ant
>>>>
>>>> rather than
>>>>
>>>> java -jar blah blah blah (which they can still do if they want to of
>>>> course)
>>>>
>>>> Simon
>>>>
>>>
>>> We could, and if we did that you also need a run target for osgi and what
>>> ever else we might support, and we need to duplicate those targets for every
>>> sample. So I'm exploring if we really need to that when we can have the
>>> launcher handle the runtime starting and keep the contribution samples
>>> clean.
>>>
>>> The consistent message with the samples could be about:
>>> - creating SCA contributions
>>> or
>>> - using SCA contributions in a Tuscany runtime
>>>
>>> The distribution would come with prebuilt sample jars so don't need to
>>> use the Ant build scripts unless you want to rebuild the SCA contribution.
>>>
>>> The launcher could by default use the contribution in the target folder
>>> of the current directory, so you just need to do:
>>>
>>> java -jar ..\launcher.jar
>>>
>>> which isn't really that much harder than "ant run" and it would be
>>> consistent across all the samples so you'd quickly get the understanding
>>> that to start a Tuscany runtime you run the Tuscany launcher. If that really
>>> is too hard to type we could ship simple .bat and .sh scripts that just do
>>> the "java -jar ..\launcher.jar" for you.
>>>
>>> That way also allows for other runtime environments without any change or
>>> extra code in the samples, for example, if you want to run in osgi you
>>> define a launcher config file for the equinox runtime once (the distribution
>>> would come with a predefined config file) and then just use "java -jar
>>> ..\launcher.jar osgi" and it would work for every sample that creates an SCA
>>> contribution.
>>>
>>>    ...ant
>>>
>>
>>
>> Alright, so lets try it and see how it works out. These are not big
>> changes from the build.xml file point of view so we have the opportunity
>> over the next day or so to try a few ways and see precisely which we like
>> best. Are you going to put this configuration together so we can look at it?
>>
>> Simon
>>
>
> Ok I shall start, feel free to help. We need:
> - some samples changed to have the very simple Ant build scripts
> - a launcher as in TUSCANY-2789
> - a launcher config file for the JSE runtime
> - a launcher config file for the equinox runtime
> - a Windows .bat file that calls java -jar launcher.jar
> - a shell script .sh file that calls java -jar launcher.jar
> - update the distribution to have a bin/ folder containing the launcher
> bits
>
>    ...ant
>

Ok the launcher part of this is working now. Build the all distribution and
that will have a new bin/ folder which has a launcher.jar, config files for
JSE and OSGi, and a tuscany.bat.

You can run that with java -jar or directly executing the .bat but easiest
is to add the bin/ folder to your PATH by doing something like "set
PATH=%PATH%;\Tuscany\distros\tuscany-sca-2.0-SNAPSHOT\bin" and then you just
need to type "tuscany" to runt the samples. For example in the
tuscany-sca-2.0-SNAPSHOT\samples\implementation-java-calculator folder type:

tuscany target\sample-implementation-java-calculator.jar

or to run it in the OSGi runtime use:

tuscany osgi target\sample-implementation-java-calculator.jar

Use "tuscany /?" for some brief help - If you use "debug" as the first
parameter it lets you use connect a remote Java debugger to the runtime. If
you use "fork" then it starts a new command prompt to run the sample which
can be useful for the samples which have separate service and reference
parts.

   ...ant

Reply via email to