Thanks,
Raymond
From: Raymond Feng
Sent: Friday, January 30, 2009 10:02 AM
To: [email protected] ; [email protected]
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: [email protected]
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 <[email protected]>
wrote:
More comments inline.
Thanks,
Raymond
From: ant elder
Sent: Friday, January 30, 2009 9:23 AM
To: [email protected]
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 <[email protected]>
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
