Hi,

Jukka Zitting schrieb:
> Hi,
> 
> On Thu, Feb 12, 2009 at 8:26 AM, Carsten Ziegeler <[email protected]> 
> wrote:
>> Please keep in mind that Sling is a very modular system consisting
>> mainly of a variety of bundles. Sling has the intent to separately
>> release single modules (bundles). This is one of the number one
>> priorities for Sling - the big bang releases are just for convenience.
> 
> OK. I just want to make it easy for a Sling user to grasp what a given
> release (or a trunk checkout) is about.
> 
> For example, if I have all these individual component releases, how do
> I combine them to get a functional Sling installation? Perhaps we
> should better highlight the Sling Launchpad releases as the base that
> you need to get started, and other component releases as something
> that you can deploy to upgrade an already existing Sling installation.
> 
> Both the current and the proposed layouts make the Launchpad look like
> just another OSGi bundle, and you'll need to dig deep into the READMEs
> to figure out how to get started. How about structuring the top level
> of the source tree like below to make the Launchpad components more
> prominent?
> 
> trunk/
>     +--- parent/
>     +--- launchpad/
>     +--- bundles/
>     +--- contrib/
>     +--- examples/
>     +--- tests/
> 
> The bundles directory would contain all the bundles included by
> default in the Launchpad, and the contrib directory would contain
> other components that we don't think are ready yet for inclusion in
> the default installation. We could still group similar bundles
> together using subdirectories inside the bundles and contrib
> directories.

+1

This makes sense to me.

Just one question: You would in this case move the existing
launchpad/testing module to the new tests module ? And this new tests
module would be complete as today, in contrast to my proposal, which
said to split the launchpad/testing module. Correct ?


Regards
Felix

> 
> BR,
> 
> Jukka Zitting
> 

Reply via email to