On Mon, May 10, 2010 at 6:42 PM, Raymond Feng <[email protected]> wrote: > 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. >
It sounds like we have flexibility to cover future eventualities. I think that means we can go ahead and rationalized the recommended basic patterns we have be discussing here for use in the samples without too much concern that we will be stuck for support for more complex future scenarios. The area that there has been most discussion is the precise form of jars used to populate the classpath in command line examples. Having had the opportunity to have this discussion this doesn't worry me so much now. We've got a few approaches out on the table and seem to be agreeing that feature based jars of some form are the way forward. If we bear this in mind and tidy the samples on this basis them we can adjust the precise construction of these jars going forward. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
