You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2009/02/04 03:05:34 UTC
Re: Command-line launcher, was: Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
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
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.
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
Re: Command-line launcher, was: Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml
Posted by 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/
Re: Command-line launcher, was: Re: svn commit: r737681 -
/tuscany/java/sca/samples/build-common.xml
Posted by 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
Posted by ant elder <an...@gmail.com>.
On Wed, Feb 4, 2009 at 2:05 AM, 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
>
> 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.
>
>
This doesn't 'delegate' to the other launchers the idea is to replace them
so all the launching is configured in plain text files instead of hidden
away Java code. If you look a the JSE code [1] its very simple and just use
the Node API, so there is no extra 'layer' and its quite a lot simpler than
the old launcher code.
...ant
[1]
https://svn.apache.org/repos/asf/tuscany/java/sca/modules/node-api/src/main/java/org/apache/tuscany/sca/node/NodeMain2.java