> > >> >> 1) Adding a little structure will make the distribution incompatible with >> Equinox OSGi launcher and PDE target platform. >> > > I believe this is a statement about how it works just now rather than a > statement about blockers for change. > > I more view it as a block for introducing structural changes. The current > layout can be directly used as an Equinox installation of bundles or PDE > target location. >
But looking at the docs having sub dirs doesn't prevent the bundles there being used either in an Equinox install and as part of the PDE target. It would be very surprising if it did. Granted our code doesn't handle it but that's our code. > > >> 2) There will be overlapping jars between features, with a flat structure, >> each artifact will have a unique location in the distro folder. >> > > True. This point is move valid I think. Think about this a little more some > feature will have three types of dependencies in the context of the Tuscany > organization > > SomeFeature depends on > 1/ jars from other features (e.g. core) > 2/ jars for the explicit dependecies for the module > 3/ jars from transitive dependencies that don't appear in either 1 or 2 > > > in 3 there could be jars that are common with other features but you don't > know precisely which. I guess this may break this idea or we could just put > these in a common sub dir. > The bottom line is that most likely we won't be able to find a good > partition of the jars unless we start to introduce duplications. That's why > I prefer to keep the structure fairly flat. > I'm just suggesting that the partition is based on whatever features are defined so that when you unwrap the distribution you get the impression that it's made up of different selectable parts. I agree that the type 3 jars are the problematic ones to which I don't have a good solution other than to assume that transitive dependencies might overlap. How about I first take a look at generating a manifest jar based on a feature and see if that moves me any nearer to satisfaction. This at least holds the list of jars for the feature. The JSE user can include manifest jars as appropriate. You still can't tell by looking at the manifest which jars are specific to the feature and which overlap with other features. However in doing this inspiration might strike. > > >> 3) Since the distro is just a local repo, only the configuration of the >> grouping matters for users. Having extra jars in the distro shouldn't bother >> if we overlay multiple functional distros into the same directory. >> > > I'm not sure I get this point but are you getting at a point about how we > configure the launchers/provide manifest jars? > > Yes, I see the manifest jars as the index to the set of jars for a > functional feature. > Ok, I'm going to go ahead and add manifest jars for one of the features and see how that goes. > > modules >>> +--- tuscany-assembly-2.0.0.jar >>> +--- tuscany-assembly-xml-2.0.0.jar >>> +--- stax-api-1.0-2 >>> +--- META-INF/MANIFEST.MF >>> +--- stat-api-1.0-2.jar >>> >>> I'm against adding extra structures for the libs folder to achieve the >>> grouping. >>> >>> 2) Grouping of modules into functional features >>> >>> This should be a very light layer on top of 1). It should be just a set >>> of configurations to organize the modules by function. When another >>> distribution is downloaded, it should be possible to just unzip it into the >>> existing distribution without any conflicts. >>> >>> For the 1st milestone of 2.x, we could try to get "api", "core" and >>> potentially "webservice" distributions out. >>> >> >> These all sounds like fine collections of function to me but can we go >> with the "all" distro for M1 where >> >> all = api + core + webserivce. >> >> It seems we can agree on "all". It seems we can agree that we need to be >> able to point samples etc at more coarsly grained modules, we don't seem to >> be able to agree whether these coarser grained modules should be >> distributed. Once we know how this works and have tried to create the >> distribution we may take a different view. >> >> >>> >>> 3) Configuration of the features for specific hosting environments >>> >>> * Maven: A pom project that list the set of modules for the functional >>> feature >>> * JSE/WebApp: generate a launcher jar whose META-INF/MANIFEST.MF that >>> uses the Class-Path header to define the classpath entries >>> >> Will the launcher be required to start the OSGi runtime? >> >> Not really, we just reuse the JAR MANIFEST.MF to define the classpath for >> JSE. In the WebApp scheme, if we point to a Tuscany distro and use the >> manifest jar to bootstrap the Tuscany runtime when the webapp is started, it >> works the same way as JSE. >> > > Sorry. I put the question in the wrong place. I was referring to the point > below. Are you suggesting that the only way that tuscany will run in OSGi is > if someone starts up an OSGi container with a config.ini specified? > > No. It's just one way to tell the Equinox runtime the collection of > bundles. I list them as examples to show that we can have simple > configurations on top of our distro to group them into functional > features for various hosting environments. > ok, I see. > > >> * OSGi: Generate a config.ini which lists the set of bundles to be >>> used by the OSGi runtime >>> >> * Eclipse: Generate a target platform definition or feature.xml >>> >>> Thanks, >>> Raymond >>> >> > Regards > > Simon > >
