You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2009/01/26 14:44:41 UTC
Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
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, <sl...@apache.org> 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
>
>
>
Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
Posted by ant elder <an...@apache.org>.
On Thu, Jan 29, 2009 at 9:16 AM, ant elder <an...@apache.org> wrote:
>
>
> On Tue, Jan 27, 2009 at 11:29 AM, ant elder <an...@apache.org> wrote:
>
>>
>>
>> On Tue, Jan 27, 2009 at 9:42 AM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Tue, Jan 27, 2009 at 9:24 AM, ant elder <an...@apache.org> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jan 27, 2009 at 8:53 AM, Simon Laws <si...@googlemail.com>wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Jan 27, 2009 at 8:34 AM, ant elder <an...@apache.org>wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 26, 2009 at 7:29 PM, Simon Laws <
>>>>>> simonslaws@googlemail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jan 26, 2009 at 2:38 PM, ant elder <an...@apache.org>wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jan 26, 2009 at 2:07 PM, Simon Laws <
>>>>>>>> simonslaws@googlemail.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Jan 26, 2009 at 1:44 PM, ant elder <an...@gmail.com>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, <sl...@apache.org> 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
>
>
I've added an 'unmanaged' config file so this can now be used to run the
samples which use the Node APIs to start a runtime manually. For example to
run the calculator sample go to the sample\calculator folder of a distro
and type:
..\..\bat\tuscany.bat unmanaged target\sample-calculator.jar
or at the bin folder to your PATH and then its just "tuscany unmanaged
target\sample-calculator.jar"
...ant
Re: Command-line launcher, was: Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
Posted by Raymond Feng <en...@gmail.com>.
For c), you can look at the META-INF/MANIFEST.MF inside generated "features/equinox-manifest.jar". The classpath contains only the entries for the equinox launcher. To pass in the configuration (where are the bundles) to Equinox, use "-Dosgi.configuration.area=features/configuration".
From: ant elder
Sent: Friday, January 30, 2009 9:50 AM
To: dev@tuscany.apache.org
Subject: Re: Command-line launcher, was: Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
On Fri, Jan 30, 2009 at 5:38 PM, Raymond Feng <en...@gmail.com> wrote:
More comments inline.
Thanks,
Raymond
From: ant elder
Sent: Friday, January 30, 2009 9:23 AM
To: dev@tuscany.apache.org
Subject: Re: Command-line launcher, was: Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
On Fri, Jan 30, 2009 at 4:56 PM, Raymond Feng <en...@gmail.com> wrote:
A few comments:
1) Our distribution already contains the manifest.jar and equinox-manifest.jar:
* manifest.jar has the Main-Class set to the node launcher and Class-Path set to the required Tuscany modules and 3rd party jars
* equinox-manifest.jar has the Mani-Class set to the equinox node launcher and Class-Path set to the dependent jars for the launcher itself without pulling other Tuscany modules and 3rd party jars which are bundles under OSGi. We also have the configuration generated to list the bundles. It can be pointed using -Dosgi.configuration.area (system property).
I suggest that our tuscany.bat to leverage that instead of using the osgi.config and default.config which require manual maintenance and ** classpath drags unnecessary jars.
2) Let's use -<option> instead of positional arguments. For example,
tuscany -osgi contrib
3) We should allow the deployment composite to be used to launch the node, for example
tuscany -composite <compositeURI> contrib1 contrib2 ... contribN
The compositeURI can be a relative URI in one of the contribs or an absolute URI which points to an external composite file.
4) Do we prefer to have multiple commands for different purposes or one command with different options?
Some of those sounds really good, just to explain, there are two things that led to it being as it is right now. Firstly lots of ML discussion about runtimes, launching, and running samples where aspects of how this should work came up, without giving links to all the emails an OTTOMH summary is - to have a Tuscany persona, to remove the mystery about what happens, to make it simple, intuitive and consistent, and to enable simple sample builds. The second reason its like this is to get something going quickly with minimum work as it wasn't obvious if eveyone agreed we wanted something like this. One other thing was to make the .bat/.sh scripts as simple as possible as they're hard to maintain.
For (1) i'm nervous it makes it complicated and makes it hard to see whats going on. The current config file is simple and fairly intuitive so there is no mystery compared to digging around in a bat script to point to jars somewhere else which you then have to unzip and look in the manifest.
<rfeng>I have a different take here for the following reasons:
a) MANIFEST.MF is defined by the jar spec and "Main-Class" and "Class-Path" are standard headers
b) The manifest.jar and equinox-manifest.jar have the accurate set of classpath entries. And we also support the different configurations based on the distro, such as one for core, and one for web service. They are automatically generated by Tuscany and no manual steps are required.
c) The OSGi launcher should not pull in other Tuscany modules and 3rd party jars which are OSGi bundles. Having them on the launcher classpath is problematic.
d) Arguing about mystery, the launcher is already on the magical path anyway. I'm trying to avoid intuitive directory scanning in non-development mode.
Well it doesn't seem as magical or mysterious as the alternative to me, any newbie could look at the bat scripts and config files and likely understand what was going on. IMVHO we seem to over engineer and complicate so much in Tuscany, to a actual user running tuscany.bat would it really make any difference at all? What ever, how about we wait till all the distribution, feature, and sample running discussions have got a bit more finalized so we know for sure if we need something like this launcher at all and if so exactly what it needs to do?
For (c) could you give a bit more detail? We can probably fix it just by adding some more to the config file.
...ant
Re: Command-line launcher, was: Re: svn commit: r737681 -
/tuscany/java/sca/samples/build-common.xml
Posted by ant elder <an...@apache.org>.
On Fri, Jan 30, 2009 at 5:38 PM, Raymond Feng <en...@gmail.com> wrote:
> More comments inline.
>
> Thanks,
> Raymond
>
> *From:* ant elder <an...@gmail.com>
> *Sent:* Friday, January 30, 2009 9:23 AM
> *To:* dev@tuscany.apache.org
> *Subject:* Re: Command-line launcher, was: Re: svn commit: r737681 -
> /tuscany/java/sca/samples/build-common.xml
>
>
>
> On Fri, Jan 30, 2009 at 4:56 PM, Raymond Feng <en...@gmail.com> wrote:
>
>> A few comments:
>>
>> 1) Our distribution already contains the manifest.jar and
>> equinox-manifest.jar:
>> * manifest.jar has the Main-Class set to the node launcher and
>> Class-Path set to the required Tuscany modules and 3rd party jars
>> * equinox-manifest.jar has the Mani-Class set to the equinox node
>> launcher and Class-Path set to the dependent jars for the launcher itself
>> without pulling other Tuscany modules and 3rd party jars which are bundles
>> under OSGi. We also have the configuration generated to list the bundles. It
>> can be pointed using -Dosgi.configuration.area (system property).
>>
>> I suggest that our tuscany.bat to leverage that instead of using the
>> osgi.config and default.config which require manual maintenance and **
>> classpath drags unnecessary jars.
>>
>> 2) Let's use -<option> instead of positional arguments. For example,
>>
>> tuscany -osgi contrib
>>
>> 3) We should allow the deployment composite to be used to launch the node,
>> for example
>>
>> tuscany -composite <compositeURI> contrib1 contrib2 ... contribN
>>
>> The compositeURI can be a relative URI in one of the contribs or an
>> absolute URI which points to an external composite file.
>>
>> 4) Do we prefer to have multiple commands for different purposes or one
>> command with different options?
>>
>>
>
> Some of those sounds really good, just to explain, there are two things
> that led to it being as it is right now. Firstly lots of ML discussion about
> runtimes, launching, and running samples where aspects of how this should
> work came up, without giving links to all the emails an OTTOMH summary is -
> to have a Tuscany persona, to remove the mystery about what happens, to
> make it simple, intuitive and consistent, and to enable simple sample
> builds. The second reason its like this is to get something going quickly
> with minimum work as it wasn't obvious if eveyone agreed we wanted something
> like this. One other thing was to make the .bat/.sh scripts as simple as
> possible as they're hard to maintain.
>
> For (1) i'm nervous it makes it complicated and makes it hard to see whats
> going on. The current config file is simple and fairly intuitive so there is
> no mystery compared to digging around in a bat script to point to jars
> somewhere else which you then have to unzip and look in the manifest.
>
> <rfeng>I have a different take here for the following reasons:
>
> a) MANIFEST.MF is defined by the jar spec and "Main-Class" and "Class-Path"
> are standard headers
> b) The manifest.jar and equinox-manifest.jar have the accurate set of
> classpath entries. And we also support the different configurations based on
> the distro, such as one for core, and one for web service. They are
> automatically generated by Tuscany and no manual steps are required.
> c) The OSGi launcher should not pull in other Tuscany modules and 3rd party
> jars which are OSGi bundles. Having them on the launcher classpath is
> problematic.
> d) Arguing about mystery, the launcher is already on the magical path
> anyway. I'm trying to avoid intuitive directory scanning in non-development
> mode.
>
>
Well it doesn't seem as magical or mysterious as the alternative to me, any
newbie could look at the bat scripts and config files and likely understand
what was going on. IMVHO we seem to over engineer and complicate so much in
Tuscany, to a actual user running tuscany.bat would it really make any
difference at all? What ever, how about we wait till all the distribution,
feature, and sample running discussions have got a bit more finalized so we
know for sure if we need something like this launcher at all and if so
exactly what it needs to do?
For (c) could you give a bit more detail? We can probably fix it just by
adding some more to the config file.
...ant
Re: Command-line launcher, was: Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
Posted by Raymond Feng <en...@gmail.com>.
More comments inline.
Thanks,
Raymond
From: ant elder
Sent: Friday, January 30, 2009 9:23 AM
To: dev@tuscany.apache.org
Subject: Re: Command-line launcher, was: Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
On Fri, Jan 30, 2009 at 4:56 PM, Raymond Feng <en...@gmail.com> wrote:
A few comments:
1) Our distribution already contains the manifest.jar and equinox-manifest.jar:
* manifest.jar has the Main-Class set to the node launcher and Class-Path set to the required Tuscany modules and 3rd party jars
* equinox-manifest.jar has the Mani-Class set to the equinox node launcher and Class-Path set to the dependent jars for the launcher itself without pulling other Tuscany modules and 3rd party jars which are bundles under OSGi. We also have the configuration generated to list the bundles. It can be pointed using -Dosgi.configuration.area (system property).
I suggest that our tuscany.bat to leverage that instead of using the osgi.config and default.config which require manual maintenance and ** classpath drags unnecessary jars.
2) Let's use -<option> instead of positional arguments. For example,
tuscany -osgi contrib
3) We should allow the deployment composite to be used to launch the node, for example
tuscany -composite <compositeURI> contrib1 contrib2 ... contribN
The compositeURI can be a relative URI in one of the contribs or an absolute URI which points to an external composite file.
4) Do we prefer to have multiple commands for different purposes or one command with different options?
Some of those sounds really good, just to explain, there are two things that led to it being as it is right now. Firstly lots of ML discussion about runtimes, launching, and running samples where aspects of how this should work came up, without giving links to all the emails an OTTOMH summary is - to have a Tuscany persona, to remove the mystery about what happens, to make it simple, intuitive and consistent, and to enable simple sample builds. The second reason its like this is to get something going quickly with minimum work as it wasn't obvious if eveyone agreed we wanted something like this. One other thing was to make the .bat/.sh scripts as simple as possible as they're hard to maintain.
For (1) i'm nervous it makes it complicated and makes it hard to see whats going on. The current config file is simple and fairly intuitive so there is no mystery compared to digging around in a bat script to point to jars somewhere else which you then have to unzip and look in the manifest.
<rfeng>I have a different take here for the following reasons:
a) MANIFEST.MF is defined by the jar spec and "Main-Class" and "Class-Path" are standard headers
b) The manifest.jar and equinox-manifest.jar have the accurate set of classpath entries. And we also support the different configurations based on the distro, such as one for core, and one for web service. They are automatically generated by Tuscany and no manual steps are required.
c) The OSGi launcher should not pull in other Tuscany modules and 3rd party jars which are OSGi bundles. Having them on the launcher classpath is problematic.
d) Arguing about mystery, the launcher is already on the magical path anyway. I'm trying to avoid intuitive directory scanning in non-development mode.
</rfeng>
For (2) absolutley. Its only like it is now as that was easy to code, to use -<option> is a little more work but much nicer. Would also be good to have abrevations so there's minimum to type once you know what you're doing.
Same for (3), and maybe even multiple deployment composites.
For (4) i'm not sure, what do others think? I kind of like that the single command as it gives a persona, and the help option on the one command shows everything possible without needing to know about other commands. And its minimum scripts which i like as they're a not much fun to write and maintain.
...ant
Re: Command-line launcher, was: Re: svn commit: r737681 -
/tuscany/java/sca/samples/build-common.xml
Posted by ant elder <an...@gmail.com>.
On Fri, Jan 30, 2009 at 4:56 PM, Raymond Feng <en...@gmail.com> wrote:
> A few comments:
>
> 1) Our distribution already contains the manifest.jar and
> equinox-manifest.jar:
> * manifest.jar has the Main-Class set to the node launcher and
> Class-Path set to the required Tuscany modules and 3rd party jars
> * equinox-manifest.jar has the Mani-Class set to the equinox node
> launcher and Class-Path set to the dependent jars for the launcher itself
> without pulling other Tuscany modules and 3rd party jars which are bundles
> under OSGi. We also have the configuration generated to list the bundles. It
> can be pointed using -Dosgi.configuration.area (system property).
>
> I suggest that our tuscany.bat to leverage that instead of using the
> osgi.config and default.config which require manual maintenance and **
> classpath drags unnecessary jars.
>
> 2) Let's use -<option> instead of positional arguments. For example,
>
> tuscany -osgi contrib
>
> 3) We should allow the deployment composite to be used to launch the node,
> for example
>
> tuscany -composite <compositeURI> contrib1 contrib2 ... contribN
>
> The compositeURI can be a relative URI in one of the contribs or an
> absolute URI which points to an external composite file.
>
> 4) Do we prefer to have multiple commands for different purposes or one
> command with different options?
>
>
Some of those sounds really good, just to explain, there are two things that
led to it being as it is right now. Firstly lots of ML discussion about
runtimes, launching, and running samples where aspects of how this should
work came up, without giving links to all the emails an OTTOMH summary is -
to have a Tuscany persona, to remove the mystery about what happens, to
make it simple, intuitive and consistent, and to enable simple sample
builds. The second reason its like this is to get something going quickly
with minimum work as it wasn't obvious if eveyone agreed we wanted something
like this. One other thing was to make the .bat/.sh scripts as simple as
possible as they're hard to maintain.
For (1) i'm nervous it makes it complicated and makes it hard to see whats
going on. The current config file is simple and fairly intuitive so there is
no mystery compared to digging around in a bat script to point to jars
somewhere else which you then have to unzip and look in the manifest.
For (2) absolutley. Its only like it is now as that was easy to code, to use
-<option> is a little more work but much nicer. Would also be good to have
abrevations so there's minimum to type once you know what you're doing.
Same for (3), and maybe even multiple deployment composites.
For (4) i'm not sure, what do others think? I kind of like that the single
command as it gives a persona, and the help option on the one command shows
everything possible without needing to know about other commands. And its
minimum scripts which i like as they're a not much fun to write and
maintain.
...ant
Command-line launcher, was: Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
Posted by Raymond Feng <en...@gmail.com>.
A few comments:
1) Our distribution already contains the manifest.jar and equinox-manifest.jar:
* manifest.jar has the Main-Class set to the node launcher and Class-Path set to the required Tuscany modules and 3rd party jars
* equinox-manifest.jar has the Mani-Class set to the equinox node launcher and Class-Path set to the dependent jars for the launcher itself without pulling other Tuscany modules and 3rd party jars which are bundles under OSGi. We also have the configuration generated to list the bundles. It can be pointed using -Dosgi.configuration.area (system property).
I suggest that our tuscany.bat to leverage that instead of using the osgi.config and default.config which require manual maintenance and ** classpath drags unnecessary jars.
2) Let's use -<option> instead of positional arguments. For example,
tuscany -osgi contrib
3) We should allow the deployment composite to be used to launch the node, for example
tuscany -composite <compositeURI> contrib1 contrib2 ... contribN
The compositeURI can be a relative URI in one of the contribs or an absolute URI which points to an external composite file.
4) Do we prefer to have multiple commands for different purposes or one command with different options?
Thanks,
Raymond
From: ant elder
Sent: Thursday, January 29, 2009 6:33 AM
To: dev@tuscany.apache.org
Subject: Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
[snip]
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
To make that easier to try without needing to do a build i've published the binary distro snapshot at:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/tuscany/sca/tuscany-distribution-all/2.0-SNAPSHOT/tuscany-distribution-all-2.0-20090129.140350-1-bin.zip
...ant
Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
Posted by ant elder <an...@apache.org>.
On Thu, Jan 29, 2009 at 9:16 AM, ant elder <an...@apache.org> wrote:
>
>
> On Tue, Jan 27, 2009 at 11:29 AM, ant elder <an...@apache.org> wrote:
>
>>
>>
>> On Tue, Jan 27, 2009 at 9:42 AM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Tue, Jan 27, 2009 at 9:24 AM, ant elder <an...@apache.org> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jan 27, 2009 at 8:53 AM, Simon Laws <si...@googlemail.com>wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Jan 27, 2009 at 8:34 AM, ant elder <an...@apache.org>wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 26, 2009 at 7:29 PM, Simon Laws <
>>>>>> simonslaws@googlemail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jan 26, 2009 at 2:38 PM, ant elder <an...@apache.org>wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jan 26, 2009 at 2:07 PM, Simon Laws <
>>>>>>>> simonslaws@googlemail.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Jan 26, 2009 at 1:44 PM, ant elder <an...@gmail.com>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, <sl...@apache.org> 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
>
>
To make that easier to try without needing to do a build i've published the
binary distro snapshot at:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/tuscany/sca/tuscany-distribution-all/2.0-SNAPSHOT/tuscany-distribution-all-2.0-20090129.140350-1-bin.zip
...ant
Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
Posted by ant elder <an...@apache.org>.
On Tue, Jan 27, 2009 at 11:29 AM, ant elder <an...@apache.org> wrote:
>
>
> On Tue, Jan 27, 2009 at 9:42 AM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Tue, Jan 27, 2009 at 9:24 AM, ant elder <an...@apache.org> wrote:
>>
>>>
>>>
>>> On Tue, Jan 27, 2009 at 8:53 AM, Simon Laws <si...@googlemail.com>wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jan 27, 2009 at 8:34 AM, ant elder <an...@apache.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 26, 2009 at 7:29 PM, Simon Laws <simonslaws@googlemail.com
>>>>> > wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 26, 2009 at 2:38 PM, ant elder <an...@apache.org>wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jan 26, 2009 at 2:07 PM, Simon Laws <
>>>>>>> simonslaws@googlemail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jan 26, 2009 at 1:44 PM, ant elder <an...@gmail.com>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, <sl...@apache.org> 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
Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
Posted by ant elder <an...@apache.org>.
On Tue, Jan 27, 2009 at 9:42 AM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Tue, Jan 27, 2009 at 9:24 AM, ant elder <an...@apache.org> wrote:
>
>>
>>
>> On Tue, Jan 27, 2009 at 8:53 AM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Tue, Jan 27, 2009 at 8:34 AM, ant elder <an...@apache.org> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jan 26, 2009 at 7:29 PM, Simon Laws <si...@googlemail.com>wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 26, 2009 at 2:38 PM, ant elder <an...@apache.org>wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 26, 2009 at 2:07 PM, Simon Laws <
>>>>>> simonslaws@googlemail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jan 26, 2009 at 1:44 PM, ant elder <an...@gmail.com>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, <sl...@apache.org> 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
Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jan 27, 2009 at 9:24 AM, ant elder <an...@apache.org> wrote:
>
>
> On Tue, Jan 27, 2009 at 8:53 AM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Tue, Jan 27, 2009 at 8:34 AM, ant elder <an...@apache.org> wrote:
>>
>>>
>>>
>>> On Mon, Jan 26, 2009 at 7:29 PM, Simon Laws <si...@googlemail.com>wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jan 26, 2009 at 2:38 PM, ant elder <an...@apache.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 26, 2009 at 2:07 PM, Simon Laws <simonslaws@googlemail.com
>>>>> > wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 26, 2009 at 1:44 PM, ant elder <an...@gmail.com>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, <sl...@apache.org> 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
Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
Posted by ant elder <an...@apache.org>.
On Tue, Jan 27, 2009 at 8:53 AM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Tue, Jan 27, 2009 at 8:34 AM, ant elder <an...@apache.org> wrote:
>
>>
>>
>> On Mon, Jan 26, 2009 at 7:29 PM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Mon, Jan 26, 2009 at 2:38 PM, ant elder <an...@apache.org> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jan 26, 2009 at 2:07 PM, Simon Laws <si...@googlemail.com>wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 26, 2009 at 1:44 PM, ant elder <an...@gmail.com>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, <sl...@apache.org> 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
Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jan 27, 2009 at 8:34 AM, ant elder <an...@apache.org> wrote:
>
>
> On Mon, Jan 26, 2009 at 7:29 PM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Mon, Jan 26, 2009 at 2:38 PM, ant elder <an...@apache.org> wrote:
>>
>>>
>>>
>>> On Mon, Jan 26, 2009 at 2:07 PM, Simon Laws <si...@googlemail.com>wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jan 26, 2009 at 1:44 PM, ant elder <an...@gmail.com> 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, <sl...@apache.org> 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
Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
Posted by ant elder <an...@apache.org>.
On Mon, Jan 26, 2009 at 7:29 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Mon, Jan 26, 2009 at 2:38 PM, ant elder <an...@apache.org> wrote:
>
>>
>>
>> On Mon, Jan 26, 2009 at 2:07 PM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Mon, Jan 26, 2009 at 1:44 PM, ant elder <an...@gmail.com> 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, <sl...@apache.org> 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>
Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Jan 26, 2009 at 2:38 PM, ant elder <an...@apache.org> wrote:
>
>
> On Mon, Jan 26, 2009 at 2:07 PM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Mon, Jan 26, 2009 at 1:44 PM, ant elder <an...@gmail.com> 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, <sl...@apache.org> 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
Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
Posted by ant elder <an...@apache.org>.
On Mon, Jan 26, 2009 at 2:07 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Mon, Jan 26, 2009 at 1:44 PM, ant elder <an...@gmail.com> 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, <sl...@apache.org> 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
Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Jan 26, 2009 at 1:44 PM, ant elder <an...@gmail.com> 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, <sl...@apache.org> 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