You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@gmail.com> on 2009/02/11 10:47:54 UTC
Source Tree Structure
Hi all,
Our source tree is currently structured mainly according to
functionality. This is fine for quickly locating some bundle or project
to inspect or work on. It is problematic in the sense, that it is not
readily visible, what is being maintained in terms of releases and what
is included in big releases.
Carsten and Felix discussed this situation and propose a separation
between modules, which are very actively maintained and are included in
the big releases, and modules, which may or may not be actively
maintained to a certain degree, but which are not part of big releases.
We propose the following structure in trunk:
trunk/
+-- maven (Maven Plugins)
+-- jcrocm
+-- jspc
+-- sling
+-- parent (Parent Project)
+-- api (The Sling API)
+-- engine (The Sling Core Engine)
+-- scripting (ScriptEngines)
+-- api
+-- core
+-- javascript
+-- jsp
+-- jsp-taglib
+-- commons (Helper libraries)
+-- log
+-- json
+-- osgi
+-- mime
+-- testing
+-- scheduler
+-- threads
+-- jcr (JCR related modules)
+-- api
+-- base
+-- classloader
+-- contentloader
+-- jackrabbit-api
+-- jackrabbit-server
+-- ocm
+-- resource
+-- webdav
+-- launchpad (Launchpad Application)
+-- app
+-- webapp
+-- base
+-- bundles
+-- content
+-- testing (non-contrib stuff)
+-- servlets (Servlet Support)
+-- get
+-- post
+-- resolver
+-- extensions (Extension bundles)
+-- adapter
+-- bundleresource
+-- httpauth
+-- event
+-- i18n
+-- openidauth
+-- threaddump
+-- contrib (Contributions etc.)
+-- commons
+-- scripting (ScriptEngines)
+-- freemarker
+-- java
+-- jst
+-- python
+-- ruby
+-- scala
+-- velocity
+-- jcr (JCR related modules)
+-- jackrabbit-client
+-- launchpad (Launchpad Application)
+-- jcrapp
+-- testing (contrib stuff)
+-- extensions (Extension bundles)
+-- apt
+-- dojo
+-- dojo-sling
+-- gwt
+-- jcrinstall
+-- obr (OBR Server, was osgi/obr)
+-- runmode
+-- samples
+-- ... existing samples ...
Note on integration testing: The main launchpad/testing module only
contains the integration tests for the non-contrib modules, while the
contrib/launchpad/testing module contains all the integration tests
related to the contrib modules.
In addition, the main reactor at the trunk root gets two new profiles:
"withSamples" which calls the reactor in the samples module and
"withContrib" which calls the reactor in the contrib module. The contrib
and samples folder each get their own reactor which just build the
samples or contrib modules, resp.
With this proposed structure, it is easily visible, what gets included
in the main (big) release -- as part of launchpad/bundles -- and what
not. This of course does not prevent us from releasing single modules
from the contrib tree. And of course this is also not static: we may
well decide to promote a module from the contrib tree to the main tree
for inclusion in big releases. Likewise we might demote modules from the
main tree to the contrib tree to signify its omission from future big
releases.
Oh, and maybe the name "contrib" is just wrong, we were just not able to
come up with some better word....
WDYT ?
Regards
Felix
Re: Source Tree Structure
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Feb 12, 2009 at 11:04 AM, Alexander Klimetschek
<ak...@day.com> wrote:
> I might look a bit ugly, but [...]
Well, this might be true (you decide), but what I really wanted to say
was: "It might look a bit ugly..."
;-)
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Source Tree Structure
Posted by Alexander Klimetschek <ak...@day.com>.
Hi all,
first of all +1 for a restructuring. Separating the contrib stuff from
the main code, but still having the possibility to check out
everything in one place, makes a lot of sense. If more and more new
bundles come in (ala CookingEggServiceBundle), which won't be actively
maintained most of the time, Sling needs some rules and a good
location for those.
On Thu, Feb 12, 2009 at 8:26 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> With this structure we give a clean sign what we really support and
> which parts we would like to support but may be are not able to. We can/
> will have release out of the contrib dir as well, but this are single
> module releases then and driven by community requests.
>
> We, Felix and I, also thought about doing something like:
> /sling/trunk - the maintained stuff
> /sling/contrib - the contrib stuff
>
> But this directory layout creates too much of a friction. People
> checking out Sling never see the Contrib stuff.
You are right, non-trunk stuff is quite hidden.
> We could also do
> something like
> /sling/trunk/"core" (I've no good name for this, so I just choose "core")
> /sling/trunk/contrib
>
> But this looks ugly from a directory layout perspective as well. So I
> think the current proposal is a best efforts.
I might look a bit ugly, but it gives a clearer separation, just as
felix put an empty line between the "core" stuff and contrib/examples
in his draft of the structure. The only way to do that in a folder
structure is to add a level. contrib would be in the middle of 11
other folders, and I personally favor a self-explaining directory
structure.
Instead of "core" (which is probably misleading a bit, as one expects
some kind of "core engine" there), here are some other ideas (pure
brainstorming, so please ignore the bad ones ;-)):
- main
- sling
- released
- framework
- heart
And some Google Set help for inspiration:
http://labs.google.com/sets?hl=en&q1=core&q2=main&q3=framework&q4=central&q5=heart&btn=Large+Set
Just my 2 cents,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Source Tree Structure
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Jukka Zitting schrieb:
> Hi,
>
> On Thu, Feb 12, 2009 at 8:26 AM, Carsten Ziegeler <cz...@apache.org> 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
>
Re: Source Tree Structure
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Feb 12, 2009 at 8:26 AM, Carsten Ziegeler <cz...@apache.org> 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.
BR,
Jukka Zitting
Re: Source Tree Structure
Posted by Carsten Ziegeler <cz...@apache.org>.
Jukka Zitting wrote:
>
> IMHO, the trunk should contain *exactly* what goes into a release.
> I.e. a release should pretty much be just a packaged export of a
> tagged version of the trunk.
>
> If we want to track things that aren't (yet) going to be included in
> the next release, then they should be kept outside the trunk.
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.
We might have two to four big bang releases while we will have single
bundle releases at any time.
We already have a huge number of bundles but it's most likely that this
number will increase over time; the more success we have, the more
bundles we get. And it is also often the case that a bundle has been
developed by a single developer and contributed.
To avoid maintenance problems other projects had with a growing number
of modules and usual fluctuation in the community, we should address
this issue now and come up with some guidelines which will help us to
better maintain the project but also give the users a better picture of
what Sling contains.
We had/have similar problems within the Cocoon project; we grew up to
have over 55 so called blocks (bundles) and only a few of them were
really maintained by an active community. So it was hard to tell if and
who is able to fix a bug in this module. We tried to compensate this
later on by adding a wiki page listening all blocks and their active
maintainers. But what of course happened is that this wiki page never
really has been maintained, so in the end it's pretty useless for the user.
With this structure we give a clean sign what we really support and
which parts we would like to support but may be are not able to. We can/
will have release out of the contrib dir as well, but this are single
module releases then and driven by community requests.
We, Felix and I, also thought about doing something like:
/sling/trunk - the maintained stuff
/sling/contrib - the contrib stuff
But this directory layout creates too much of a friction. People
checking out Sling never see the Contrib stuff. We could also do
something like
/sling/trunk/"core" (I've no good name for this, so I just choose "core")
/sling/trunk/contrib
But this looks ugly from a directory layout perspective as well. So I
think the current proposal is a best efforts.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Source Tree Structure
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Paul Noden schrieb:
> Makes things a little clearer! Where would the groovy scripting engine
> come, under java?
Best of all: The Groovy Scripting Engine is not maintained by us:
Starting with 1.6 RC1 (RC3 has been published on monday), the
groovy-all.jar is a real bundle containing the Scripting Engine. Just
install that and you're done ;-)
Regards
Felix
>
> 2009/2/11 Jukka Zitting <ju...@gmail.com>:
>> Hi,
>>
>> On Wed, Feb 11, 2009 at 10:47 AM, Felix Meschberger <fm...@gmail.com> wrote:
>>> With this proposed structure, it is easily visible, what gets included
>>> in the main (big) release -- as part of launchpad/bundles -- and what
>>> not.
>> IMHO, the trunk should contain *exactly* what goes into a release.
>> I.e. a release should pretty much be just a packaged export of a
>> tagged version of the trunk.
>>
>> If we want to track things that aren't (yet) going to be included in
>> the next release, then they should be kept outside the trunk.
>>
>> BR,
>>
>> Jukka Zitting
>>
>
> Kind Regards,
>
> Paul Noden
>
Re: Source Tree Structure
Posted by Paul Noden <no...@nodster.co.uk>.
Makes things a little clearer! Where would the groovy scripting engine
come, under java?
2009/2/11 Jukka Zitting <ju...@gmail.com>:
> Hi,
>
> On Wed, Feb 11, 2009 at 10:47 AM, Felix Meschberger <fm...@gmail.com> wrote:
>> With this proposed structure, it is easily visible, what gets included
>> in the main (big) release -- as part of launchpad/bundles -- and what
>> not.
>
> IMHO, the trunk should contain *exactly* what goes into a release.
> I.e. a release should pretty much be just a packaged export of a
> tagged version of the trunk.
>
> If we want to track things that aren't (yet) going to be included in
> the next release, then they should be kept outside the trunk.
>
> BR,
>
> Jukka Zitting
>
Kind Regards,
Paul Noden
Re: Source Tree Structure
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Feb 11, 2009 at 10:47 AM, Felix Meschberger <fm...@gmail.com> wrote:
> With this proposed structure, it is easily visible, what gets included
> in the main (big) release -- as part of launchpad/bundles -- and what
> not.
IMHO, the trunk should contain *exactly* what goes into a release.
I.e. a release should pretty much be just a packaged export of a
tagged version of the trunk.
If we want to track things that aren't (yet) going to be included in
the next release, then they should be kept outside the trunk.
BR,
Jukka Zitting