Re: Source Tree Structure
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 cziege...@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=enq1=coreq2=mainq3=frameworkq4=centralq5=heartbtn=Large+Set Just my 2 cents, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: Source Tree Structure
On Thu, Feb 12, 2009 at 11:04 AM, Alexander Klimetschek aklim...@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.klimetsc...@day.com
Re: Source Tree Structure
Hi, On Thu, Feb 12, 2009 at 8:26 AM, Carsten Ziegeler cziege...@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
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 cziege...@apache.org
