While I see the value of a launcher - I don't think that this is the concern of Sling - we are the framework which should run in every OSGi installation; so let's focus on the framework and leverage other efforts like pax+runner, Karaf etc. instead of doing this stuff ourselves.
Just my 2c Carsten Felix Meschberger wrote: > Hi, > > Bertrand Delacretaz schrieb: >> I'm thinking of creating a generic launcher, using a text file >> definition to load and start jars, allowing a Sling launcher to take >> over and load and start bundles once a main class is started. > > This sounds a lot like Tanuki Java Service Wrapper ... > > >> Here's a rough idea - I haven't looked at Karaf closely yet, there's >> probably some overlap, but my idea is to create a generic Java >> launcher, having nothing to do with OSGi, that in turn launches an >> OSGi-aware main class. >> >> The launcher is a runnable jar, or a war file. >> >> It uses a text file named launch.txt to define what to launch, example below. >> >> # START launch.txt example >> properties: >> sling.home = ./sling >> org.apache.commons.launcher.protocols.maven.repository.1 = >> http://repo1.maven.org/maven2 >> org.apache.commons.launcher.protocols.maven.repository.2 = >> http://people.apache.org/repo/m2-incubating-repository >> >> protocols: >> # by default only the http and file protocol are provided to >> # load jar files, more can be added by loading protocol jars >> >> # The maven protocol, for example, grabs jar files from >> # repositories defined by the *.maven.repository properties >> # found above. >> jar http://some.repository/launcher-maven-protocol-1.4.2.jar >> md5=1231231239812cd21231987 >> >> bootstrap: >> # load a number of jars that are required to start the main class >> jar maven:org.apache.felix:org.osgi.compendium:jar:1.2.0 >> md5=1231231239812cd212315645 >> jar maven:org.apache.felix:org.osgi.core:jar:1.2.0 >> sha1=1231231239812cd21231123213 >> jar maven:org.apache.felix:org.osgi.foundation:jar:1.2.0 >> sha1=1231231239812cd2123112313 >> jar >> maven:org.apache.sling:org.apache.sling.launchpad.launcher:2.0.2-incubator >> md5=1231231239812cd2123112313 >> >> # now start the main class, from the org.apache.sling.launchpad.launcher jar >> main-class org.apache.sling.launchpad.launcher.Main -m launcher >> >> # The launcher stops processing here, and provides this file to the >> main class as its >> # standard input. The above launcher.Main processes the lines that follow the >> # above main-class statement >> >> # Load and start a few bundles, some with specific start levels >> bundle http://some.obr/some-bundle sha1=1231390890823121312 >> bundle maven:some.group:some.artifact:1.0 startlevel=2 md5=123213213984329843 >> >> # END launch.txt example >> >> Creating a launcher that will "never" change doesn't seem too hard, >> and then defining a Sling launchpad instance boils down to the >> launch.txt file. >> >> Using a text file to define bundles makes it easy for people to >> exchange configurations, as the text file fully defines the >> application assembly, based on the bundles URLs and digests. >> >> WDYT? > > At first I thought: What may this be used for. Maybe just because I > failed to understand the problem for which you present a solution. > > Is this about creating "custom Sling configurations" ? > > Now, this is certainly a valid request, to which we currently have two > answers: > > * The launchpad/bundles project defines a package of bundles to > be included in the app or webapp binary > > * A patch to extend the BootstrapInstaller to read more bundles > for installation from the filesystem > > Maybe we need an additional mechanism for setting up an initial set of > bundles. Now, there's pax runner [1] which sports so called profiles, > which may be exactly what you are envisioning ? > > While I like our current construct of having very small > environment-specific code (web app or standalone app) and the rest being > unified, we might also go for favouring the standalone app... > > Regards > Felix > > [1] http://paxrunner.ops4j.org/space/Pax+Runner > >> -Bertrand >> > -- Carsten Ziegeler [email protected]
