On Mon, May 10, 2010 at 8:46 AM, Simon Laws <[email protected]> wrote: > On Fri, May 7, 2010 at 1:39 PM, Simon Laws <[email protected]> wrote: >> On Fri, May 7, 2010 at 1:20 PM, Simon Laws <[email protected]> wrote: >>> On Fri, May 7, 2010 at 11:34 AM, ant elder <[email protected]> wrote: >>>> On Fri, May 7, 2010 at 10:39 AM, Simon Laws <[email protected]> >>>> wrote: >>>> >>>>> >>>>> Right, and I think we need to decide once and for all what we're going >>>>> to do about launchers. It seems complicated at the moment. >>>>> >>>> >>>> Ok, lets for a moment look at the various ways we currently have in the >>>> samples: >>>> >>>> 1- programatically with NodeFactory >>>> 2- programatically with NodeLauncherEquinox >>>> 3- Maven Tuscany plugin with mvn truscany:run >>>> 4- Maven Tuscany OSGi JUnit plugin >>>> 5- command line with binary distribution bin/tuscany.bat (or .sh) >>>> 6- Ant scripts invoking binary distribution bin/ launcher.jar >>>> 7- Ant scripts invoking NodeLauncher manual classpath >>>> 8- Ant scripts invoking NodeLauncher using generated manifest classpath jar >>>> 9- webapp embedded runtime with .war as contribution >>>> 10- webapp embedded runtime with contributions separately embeded in webapp >>>> 11- Tomcat deep integration with tuscany.war distribution >>>> >>>> and slightly different from those the Tuscany SCAClient can be used >>>> programatically eg samples/helloworld-scaclient with mvn exec:java or >>>> a manually created classpath with java -cp ... >>>> >>>> Is anything missing from that list? >>>> >>>> ...ant >>>> >>> >>> Touche, a good list and you've got a couple of things that I missed. >>> I'd like to approach this from what we expect the users to be asking >>> for then we can map our technical solutions to it. For example, from >>> the sample launching thread... >>> >>> A. running a contribution from the command line >>> B. running a contribution from Maven >>> C. running a contribution from JUnit >>> D. running a contribution from eclipse (or any other IDE) >>> E. running a contribution from Ant >>> F. running a contribution from OSGi >>> G. running a contribution from a webapp >>> H. running a contribution from Tomcat >>> I. running a contribution from JSE program >>> >>> I just added "I" >>> >>> Simon >>> >>> -- >>> Apache Tuscany committer: tuscany.apache.org >>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com >>> >> >> I found another couple of technology options. >> >> Both tuscany-sca-manifest.jar and tuscany-sca-equinox-manifest.jar >> have a main class specified in the manifest so could be used to start >> a contribution as well as defined the classpath for a launcher. >> >> Simon >> -- >> Apache Tuscany committer: tuscany.apache.org >> Co-author of a book about Tuscany and SCA: tuscanyinaction.com >> > > So here's a first stab a merging the two lists. This is not about > removing options that we might have but deciding which are our > preferred options in common scenarios and hence the options we are > going to use in the samples. > > Please edit and suggest alternatives as appropriate. Hopefully we can > add enough detail/examples and create a doc page so what to use > where/when is clear. > > > A. running a contribution from the command line > Command: tuscany.bat/.sh > Classpath: How does this calculate the classpath? > > B. running a contribution from Maven > Command: Maven Tuscany plugin with mvn truscany:run > Classpath: Maven dependency on features > > Ca. running a contribution from Ant (JSE) > Command: tuscany-sca-manifest.jar > Classpath: tuscany-sca-manifest.jar > > <java jar="${tuscany.home}/features/tuscany-sca-manifest.jar" > fork="true" failonerror="true"> > <jvmarg > value="-Djava.util.logging.config.file=../logging.properties"/> > <!-- optional to set the deployable composite --> > <arg value="-composite"/> > <arg value="Calculator.composite"/> > <!-- stop the node after the application runs --> > <arg value="-ttl"/> > <arg value="0"/> > <arg value="${sample.jar}"/> > </java> > > Cb. running a contribution from Ant (OSGi) > Command: tuscany-sca-equinox-manifest.jar > Classpath: tuscany-sca-equinox-manifest.jar > > <java > jar="${tuscany.home}/features/tuscany-sca-equinox-manifest.jar" > fork="true" failonerror="true"> > <jvmarg > value="-Djava.util.logging.config.file=../logging.properties"/> > <arg value="-composite"/> > <arg value="Calculator.composite"/> > <arg value="-config"/> > <arg value="${tuscany.home}/features/configuration"/> > <arg value="-ttl"/> > <arg value="0"/> > <arg value="${sample.jar}"/> > </java> > > Da. running a contribution from JSE program and from JUnit (JSE) > Command: > org.apache.tuscany.sca.node.launcher.NodeLauncher.createNode(...).start() > Classpath: base jar / manifest? > > Db. running a contribution from JSE program and from JUnit (OSGi) > Command: > org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher.createNode(...).start() > Classpath: base jar / manifest? > > D. 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: > > 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: Pacakge 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: Tuscany jars packaged inside jar > > 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: Tuscany jars packaged inside jar > > 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 > > Simon > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com >
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. 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. 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. 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). ...ant
