Re: Command-line launcher, was: Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml

[Luciano Resende <lu...@gmail.com>]

On Tue, Feb 3, 2009 at 6:05 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> I made some progress to use Apache commons-cli to parse the command line
> arguments for the Equinox Launcher. It can now process the following
> options:
>
> [-config <equinoxConfiguration>]: The configuration folder for Equinox
> [-c <compositeURI>]: The composite URI
> contribution1 ... contributionN: A list of contribution files or URLs
>
> To try it, you can build the distribution/all first using "mvn clean
> install", then run the following command:
>
> java -jar target\features\equinox-manifest.jar -config
> target\features\configuration
> ..\..\samples\calculator-equinox\target\sample-calculator-equinox.jar
>

Looks good...

> A related subject: I don't see a need to have a separate launcher which
> delegates to the JSE or Equinox Launcher. Can we just update the shell
> script to directly call the JSE or Equinox launcher main class? I'm working
> on the UNIX script based on the one from Tomcat.
>

+1

Do we even need a script ? Can't we just document the command line in
the sample README, and provide the necessary ant targets so users can
do : ant run or ant run-managed. This way we avoid exposing the user
that just want to run the sample, to multiple magical layers.

> Thanks,
> Raymond
>
> From: Raymond Feng
> Sent: Friday, January 30, 2009 10:02 AM
> To: dev@tuscany.apache.org ; antelder@apache.org
> Subject: Re: Command-line launcher, was: Re: svn commit: r737681 -
> /tuscany/java/sca/samples/build-common.xml
>
>
> 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
>
>
>
>
>



-- 
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: Command-line launcher, was: Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml

[Raymond Feng <en...@gmail.com>]

I also got the JSE launcher working the same way, for example:

java -jar target\features\manifest.jar 
..\..\samples\calculator\target\sample-calculator.jar

Thanks,
Raymond

--------------------------------------------------
From: "Luciano Resende" <lu...@gmail.com>
Sent: Tuesday, February 03, 2009 7:00 PM
To: <de...@tuscany.apache.org>
Subject: Re: Command-line launcher, was: Re: svn commit: r737681 - 
/tuscany/java/sca/samples/build-common.xml

> On Tue, Feb 3, 2009 at 6:05 PM, Raymond Feng <en...@gmail.com> wrote:
>> Hi,
>>
>> I made some progress to use Apache commons-cli to parse the command line
>> arguments for the Equinox Launcher. It can now process the following
>> options:
>>
>> [-config <equinoxConfiguration>]: The configuration folder for Equinox
>> [-c <compositeURI>]: The composite URI
>> contribution1 ... contributionN: A list of contribution files or URLs
>>
>> To try it, you can build the distribution/all first using "mvn clean
>> install", then run the following command:
>>
>> java -jar target\features\equinox-manifest.jar -config
>> target\features\configuration
>> ..\..\samples\calculator-equinox\target\sample-calculator-equinox.jar
>>
>
> Looks good...
>
>> A related subject: I don't see a need to have a separate launcher which
>> delegates to the JSE or Equinox Launcher. Can we just update the shell
>> script to directly call the JSE or Equinox launcher main class? I'm 
>> working
>> on the UNIX script based on the one from Tomcat.
>>
>
> +1
>
> Do we even need a script ? Can't we just document the command line in
> the sample README, and provide the necessary ant targets so users can
> do : ant run or ant run-managed. This way we avoid exposing the user
> that just want to run the sample, to multiple magical layers.
>
>> Thanks,
>> Raymond
>>
>> From: Raymond Feng
>> Sent: Friday, January 30, 2009 10:02 AM
>> To: dev@tuscany.apache.org ; antelder@apache.org
>> Subject: Re: Command-line launcher, was: Re: svn commit: r737681 -
>> /tuscany/java/sca/samples/build-common.xml
>>
>>
>> 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
>>
>>
>>
>>
>>
>
>
>
> -- 
> Luciano Resende
> Apache Tuscany, Apache PhotArk
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/