I'm happy to use an alternative to manifests. A couple of comments
>
> Thanks Simon, i think this list approach is helpful. I have a comment
> that I'll see how people take before posting an updated list:
>
> I don't think the manifest jar should be used in the preferred
> options, here's why -
>
> The point of a manifest jar is to setup a classpath and define the
> main class to run. The primary reason we had one was to simplify
> command line use so you didn't have to type all that into a command
> prompt, but that is the same as what the .bat/.sh scripts now do.
So it sounds like we're agreeing on A, see below.
>
> Manifest jars are inflexible as they must retain the directory
> structure and that means the don't work in lots of environments such
> as Maven or webapps. As we need something that works in Maven and
> webapps we should try to find one approach that works everywhere as
> that will be simpler.
Fair enough
>
> 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'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.
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)
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
