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
