On Mon, May 10, 2010 at 10:53 AM, Simon Laws <[email protected]> wrote: > 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. >
Yes unless someone has an alternative suggestion then i think the scripts seem like a useful way to run sample contributions at a command prompt. The current scrips have a .config file that defines the classpath used. >> >> 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 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 ... > >> >> 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. > 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 - webapp, *user needs to sort out the classpath 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 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 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. Still thinking about OSGi but having all the jars for an OSGi runtime in a separate directory may help with that too. ...ant
