More comments in line....
snip...
>>>
>>> As we have just a single manifest jar in the distribution the
>>> classpath becomes enormous and impenetrable so there is no way for a
>>> user to know what all the jars are for. We need something that is
>>> composable so users can easily add/remove extensions and understand
>>> the dependencies.
>>
>> I think the feature dependencies poms could be used to create
>> manifests with different contents. They could also be used to create
>> real jars too of course, like the base jar. Not particularly trying to
>> defend our use of manifest but want to get all the info on the table,
>> as it were.
>
> There could be multiple manifest jars and that would make more sense
> to me than the single all manifest if we were to keep them. But then
> you start loosing the benefit of easy use at the command line which
> was the point of having them, ie it starts getting a quite a lot to
> type:
>
> java -cp
> tuscany-api-manifest.jar;tuscany-core-manifest.jar;tuscany-osgi-manifest.jar;tuscany-webservices-manifest.jar
I think we should still maintain the features mechanism for collecting
mvn dependencies. From there we can build normal jars or manifest jars
for the time being. Ultimately I'm happier with 1 jar per feature as
it seems clearer rather than mapping that to mutliple jars through a
manifest. However there is an OSGi hurdle to jump here in that the
manifests have to be right.
>From a user point of view they probably don't care what we do as long
as it results in minimum work from their point of view. So we agree
that features map to a jar of some sort and we have to take it from
there and work out what that means given the OSGi angle.
> ...
>
>>
>>>
>>> There's not a lot of point of having both manifest jars and .bat/.sh
>>> scripts as they do exactly the same thing but the .bat/.sh scripts are
>>> more flexible, and the scripts are easier to use from a command prompt
>>> (there is also no point using the manifest jar with a Launcher class
>>> as they also do the same things).
>>
>> So let's assume that we don't use manifests what is our proposal for
>> the scenarios that are in the list that rely on them? We can use the
>> launchers directly and construct the classpaths either manually or
>> using the feature (shaded) jars although the latter means we need to
>> sort out the manifests in those jars to use them in OSGi. We could use
>> tuscany.bat/.sh but I don't know how the classpath is configured with
>> the script. Am looking now but if you could summarize that would be
>> good.
>>
>
> The current scrips have a .config file that defines the classpath
> used. Doesn't have to work the way the current scripts do but i do
> think its good to be able to easily see how they work, (i didn't like
> one of the old launcher approaches that used a java class that fiddled
> about with the class path adding and excluding directories and jars
> which made it really hard to work out what was going on). The current
> code is more complicated than it needs to be now as it tries to deal
> with all the different ways samples tried to package the runtime. All
> the scripts really need is to add all the jars in a directory tree and
> call some main class.
I agree that magic is not good. It tends to go wrong in uncontrolled
environments.
>
>> We should start to note which options we all agree on so we can focus
>> the discussion. (In temporarily collapsing the list again I noticed
>> that I had too many letter Ds first time round so I've moved the extra
>> D to the end of the list as I). Can you put a note against any that
>> you currently think are ok. We do of course need to improve the detail
>> of the description of all of them.
>>
>> A. running a contribution from the command line
>> I think we agree here but how is the classpath calculated in
>> tuscany.bat/.sh?
>> B. running a contribution from Maven
>> Ca. running a contribution from Ant (JSE)
>> Cb. running a contribution from Ant (OSGi)
>> Da. running a contribution from JSE program and from JUnit (JSE)
>> Db. running a contribution from JSE program and from JUnit (OSGi)
>> E. running a contribution from Junit under OSGi in Maven
>> F. running a contribution from OSGi
>> Ga. running a contribution from a webapp (.war as contribution)
>> Gb. running a contribution from a webapp (contributions inside war)
>> H. running a contribution from Tomcat
>> I. running a contribution from eclipse (or any other IDE)
>>
>
> The SCA samples would build contributions. With build it just creates
> the contribution and testing is limited to unit tests (ie no tuscany
> runtime started), my preference would be for the Maven build to also
> define the tuscany plugin so run them with mvn tuscany:run as its not
> complicated.
>
> Tuscany runtime can be started with:
> - distribution tuscany.bat/.sh scripts
> - mvn tuscany:run
> - programatically with NodeFactory for itests, JSE, *users needs to
> sort out the classpath
By including the appropriate feature based jars
> - webapp, *user needs to sort out the classpath
By including the appropriate feature based jars
>
> So that covers A, B, Ca, Da, Ga, Gb
>
> H, I'm not sure if we have it quite right yet so maybe treat this as
> alpha and ignore it for now in this discussion
Yep.
>
> I, would be good to bring up the 1.x plugin in 2.x as something small
> and simple would be useful to complement Eclipse STP, but lets also
> ignore this one for now too as no one has done this yet
Yep
>
> That leaves all OSGi ones and the two flagged with *user needs to sort
> out the classpath.
>
> For sorting out the classpath i like the shaded aggregate jars and
> being more careful with what dependencies are used, eg you can use the
> tuscany-base jar and its few dependencies at that stays the same no
> matter how we refactor, add or remove all the different modules jars
> so its easy to create an Ant build script as you know the few jars you
> need. Another help would be to use separate folders for things so
> something like implementation.bpel dependencies are all in a separate
> directory which could be used or not as necessary.
We currently have a modules directory where all jars are basically
flat. Features could be represented using manifest jars (we only seem
to have an all jar at present) and they rely on the distribution
structure. The issue with other structured approaches is duplicate
dependencies. It would be interesting to investigate just how much
duplication there is and how that can be managed. However all of this
needs to be driven from the user perspective. I do like the idea of a
user being able to see what jars are required for each feature. I
realize I'm not actually saying much in this comment. That's really
because I don't have a good answer and I know we've been down this
road before. What I think we need to do is try some things, i.e.
agree the preliminary list of launching scenarios
get a better grip on specifying the features
generate shade and manifest jars from the features
adapt the samples, where appropriate, for agreed scenarios
rinse and repeat so we understand the issues
as i said before I'd like to rename samples if people don't disagree
(and also fix up the README and diagrams)
I don't know how to make the OSGi stuff easier to use so maybe the
answer is to keep it as it is for the time being. I'm sure revisiting
the samples will help us here and take this on as a task for M6.
I think the priority this time round is to consolidate, remove as much
chaff as possible and fix the simple things to set us up to address
the bigger picture.
>
> Still thinking about OSGi but having all the jars for an OSGi runtime
> in a separate directory may help with that too.
>
> ...ant
>
So here's a go at the consolidated list....
A. running a contribution from the command line
Command: tuscany.bat/.sh
Classpath: core, extension and dependency jars
B. running a contribution from Maven
Command: Maven Tuscany plugin with mvn truscany:run
Classpath: Maven dependency on core + extension features
Ca. running a contribution from Ant (JSE)
Command: call tuscany.bat/.sh launcher directly
Classpath: core, extension and dependency jars
Cb. running a contribution from Ant (OSGi)
Command: tuscany-sca-equinox-manifest.jar
Classpath: sca-api, node-api, node-launcher-equinox - TBD
Da. running a contribution from JSE program and from JUnit (JSE)
Command:
org.apache.tuscany.sca.node.launcher.NodeLauncher.createNode(...).start()
Classpath: core, extension and dependency jars
Db. running a contribution from JSE program and from JUnit (OSGi)
Command:
org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher.createNode(...).start()
Classpath: sca-api, node-api, node-launcher-equinox - TBD
E. running a contribution from Junit under OSGi in Maven
Command: Maven Tuscany OSGi JUnit plugin
Classpath: maven dependency on features
F. running a contribution from OSGi
Command: Package contribution as a bundle that has an activator
that uses pattern D
Classpath: Load the OSGi runtime (Equinox) with
features/configuration/config.ini
Ga. running a contribution from a webapp (.war as contribution)
Command: web.xml configured to specify filter
<filter>
<filter-name>tuscany</filter-name>
<filter-class>org.apache.tuscany.sca.host.webapp.TuscanyServletFilter</filter-class>
</filter>
Classpath: core, extension and dependency jars
Gb. running a contribution from a webapp (contributions inside war)
Command: web.xml configured to specify filter
<context-param>
<param-name>contributions</param-name>
<param-value>/WEB-INF/sca-contributions</param-value>
</context-param>
<filter>
<filter-name>tuscany</filter-name>
<filter-class>org.apache.tuscany.sca.host.webapp.TuscanyServletFilter</filter-class>
</filter>
Classpath: core, extension and dependency jars
H. running a contribution from Tomcat
Command: install tomcat.war, from there install integration
I don't remember how contributions are installed.
Classpath: pakaged as part of deep integration
DEFER
I. running a contribution from eclipse (or any other IDE)
Command: No point and click tool in 2.x for eclipse yet
Use Da or Db
Classpath:
DEFER
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
