Hi, More comments inline.
Thanks, Raymond From: Simon Laws Sent: Tuesday, January 20, 2009 8:41 AM To: [email protected] Subject: Re: [2.0] Align samples with the distributions Agreed. It's just a local repo. Do you think adding a little structure add technical difficulty or is a flat structure a personal preference? I'm interested in situations like this where we have some people who want solution A and others want solution B (where both solutions are valid). How do we come to a conclusion? In the past this has tended to stall us a little so this is a good chance to see if we can do better;-) I'm seeing some technical issues: 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. 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. 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. 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. * 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
