>> >> What's wrong with multiple launchers each appropriate to certain use cases? >> > > Nothing, i didn't mean to imply there should just be one single one i > was commenting that having a launcher per sample didn't seem perfect. > So i agree with what you've just been suggesting. I do think once we > have some of these done how we like then we should look at what of the > code really should be in samples/ or if some of it could be moved to > be part of the Tuscany modules function. > > ...ant >
For some of the samples we've separated the launchers from the contributions. Because of this we are able to offer a variety of launchers for the contributions, for example, launcher-command-line launcher-shell launcher-maven launcher-embedded-jse launcher-embedded-osgi etc Each of these demonstrate to the user a different way of launching a contribution(s). Remember that these are samples so the objective is not necessarily to provide the most expedient way of implementing the code but is rather to provide the clearest of demonstrations to the user of how to lauch contributions using Tuscany. I wasn't very clear in my original comment. What I was referring to specifically was the current launcher-embedded-jse and launcher-embedded-osgi solution where I originally provided a parameterized launcher for starting different contributions. On reflection I don't think this passes the test of being as clear to the user as we could be. I would prefer to offer a selection of examples demonstrating the launching different contributions in an embedded environment. Hence I'm suggesting creating separate launchers inside these embedded directories instead of a single parameterized launcher. Now I hear the shouts of let's have a single launcher. We already have several examples of that. See launcher-command-line and laucher-shell for example. If we build a generic launcher to demonstrate use of the embedding APIs I fear that would demonstrate to the user how smart we are at building a generic launcher rather than demonstrating how to use the API. This is what motivated my original comment, i.e. I think I've included more code to handle the parameterization, which is of no interest to the user, rather than focusing on use the embedding API to load and start a contribution. Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
