"Glad to hear from you ;-)"

>> Thanks, i hope to be more active in the future (too much work until now
...:-( ).

"I agree, that this should be simplified. We have been thinking of a
packaging descriptor from which we may simply build any packagings. But we
didn't come to any good solution yet."

>> Agreed. My feeling is that it´s easy for beginners to start with sling
but not so much when you want to build an enterprise platform with 3rd party
software. In this sense, [1] could be an interesting try to have the best of
content-driven applications and SOA togueter.

"
* JcrInstall (or JcrBundlesInstall)
 * FileInstall from Apache Felix
 * Apache Felix WebConsole
 * Apache Felix Command Console
 * OSGi Bundle Repository (usable with both Web and Command Console)"

>> Interesting. BTW, How can I use Apache Felix Command Console with a
launched sling webapp instance?

BR,

Juanjo.

[1]
http://servicemix.apache.org/SMX4KNL/running-apache-sling-on-servicemix-kernel.html

On Wed, Jul 30, 2008 at 11:54 AM, Felix Meschberger <[EMAIL PROTECTED]>wrote:

> Hi Juanjo,
>
> Glad to hear from you ;-)
>
> Juan José Vázquez Delgado schrieb:
>
>> Thanks Bertrand,
>>
>> Yeap, agreed with you this is the easiest way. In fact, has been my first
>> try. Although, IMHO Sling should let users add bundles on startup without
>> any code or additonal maven projects.
>>
>> WDYT?
>>
>
> IMHO the launchpad jar files are convenience to fire up a running Sling
> instance either as a standalone or a web application. As such they are
> prepackaged with what we think is it.
>
> It should be fairly easy using the launchpad/base module (which is the
> actually launcher code) to create a maven project which packages the bundle
> you need together with the launcher code. See the launchpad app, jcrapp (app
> module just containing Jackrabbit server stuff to run a Jackrabbit
> Repository as a server) and webapp modules as examples
>
> I agree, that this should be simplified. We have been thinking of a
> packaging descriptor from which we may simply build any packagings. But we
> didn't come to any good solution yet.
>
> Any ideas or even code are of course welcome in this area as they simplify
> the building Sling applications.
>
> But keep in mind, launching is just the first step in the lifetime of an
> application. The next steps are -- besides running and using it -- updating
> it and for this task exist various options, which IMHO might even be used
> for installation:
>
>  * JcrInstall (or JcrBundlesInstall)
>  * FileInstall from Apache Felix
>  * Apache Felix WebConsole
>  * Apache Felix Command Console
>  * OSGi Bundle Repository (usable with both Web and Command Console)
>  * ....
>
> Further there the OSGi Deployment Admin specification, we are also
> considerung using in Sling: We might create Deployment Packages of the
> various modules of Sling to install (and update) them in any OSGi framework
> with a running Deployment Admin Service. This should also simplify the
> creation of Sling Launchers.
>
> Hope this helps.
>
> Regards
> Felix
>
>
>
>
>> BR,
>>
>> Juanjo.
>>
>> On Tue, Jul 29, 2008 at 12:27 PM, Bertrand Delacretaz <
>> [EMAIL PROTECTED]> wrote:
>>
>>  Hi,
>>>
>>> On Tue, Jul 29, 2008 at 12:22 PM, Juanjo Vázquez <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>> ...* Launch the platform running a launchpad webapp instance.
>>>> * Preserve the genuine Sling launchpad webapp without modifications
>>>>
>>> (except
>>>
>>>> improvements, of course).
>>>> * Include the additional bundles on startup.
>>>> * Not include specific sling bundles on startup (i.e. include
>>>> org.apache.sling.jcr.jackrabbit.client instead of
>>>> org.apache.sling.jcr.jackrabbit.server).
>>>> * Use the local maven repository as OBR....
>>>>
>>> The easiest by far seems to create your own pom.xml based on the
>>> launchpad/webapp pom, and add/remove bundle dependencies as needed to
>>> create a custom webapp with the bundles that you need.
>>>
>>> You won't lose anything, as the launchpad webapp has no specific code
>>> (apart from the integration tests, but we're planning to move those to
>>> their own test-only module), it's just an assembly of bundles. The
>>> actual launcher code is in launchpad/base.
>>>
>>> HTH,
>>> -Bertrand
>>>
>>>
>>
>

Reply via email to