> > >> > 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. > 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. > 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? > 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? > > * 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
