Please see my comments below. Thanks, Raymond ________________________________________________________________ Raymond Feng [email protected] Apache Tuscany PMC member and committer: tuscany.apache.org Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com Personal Web Site: www.enjoyjava.com ________________________________________________________________
On May 10, 2010, at 10:05 AM, Simon Laws wrote: > 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. +1. The tuscany maven bundle plugin can be configured to produce feature/profile specific packages for different environments: * For standalone, the plugin can produce manifest jars that point to required dependent jars. I'm open to improve it so that we can generate shaded jars out of the features even though it has less flexibility to choose and compose. * For OSGi, the plugin can produce the Equinox configurations and target platform definitions. It can also generate aggregated OSGi bundles per feature. So it provides the choices for the module or feature based granularity. I had a prototype that allows our advanced users to choose the extensions such as implementation, binding, policy, databinding types and we figure out what dependencies are required to support such extensions. We can potentially add the ability to produce a customized distribution from the user selections. This tool can be the Tuscany runtime composer. > > 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
