<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:14pt"><div>As I think about this a little bit, it seems that drawing a little analogy between the linux kernel and modules used with the kernel might be an interesting way to think of our OpenSim evolution.<br><br>There is a core set of logic, somewhat analogous to a kernel. Then there are various modules of which some are in the kernel SVN and others are in forge.opensimulator.org and now other places.<br><br>The trick may be to come up with a build/release procedure that we run once a month or so and start evolving ourselves into a bit more consistent schema.<br><br>This sort of evolution brings more rigidity in development, so some folks will be advantaged and some dis-advantaged, as is always the case. But, I think it is worth considering and discussing.<br><br>Charles Krinke<br></div><div style="font-family:
arial,helvetica,sans-serif; font-size: 14pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Michael Cortez <mcortez@gmail.com><br><b><span style="font-weight: bold;">To:</span></b> opensim-dev@lists.berlios.de<br><b><span style="font-weight: bold;">Sent:</span></b> Monday, June 29, 2009 7:51:46 PM<br><b><span style="font-weight: bold;">Subject:</span></b> [Opensim-dev] Suggestion for project organization.<br></font><br>
I'd like to make a suggestion about how the OpenSim project is setup<br>in trunk for building and get some feedback from ya'll.<br><br>Currently if a developer would like to work on a new module for<br>OpenSim, they have to first decide if they want to work inside trunk<br>(building their module along with OpenSim in the same build) or if<br>they want to create a completely separate project that just links to<br>the DLLs produced from OpenSim's trunk. I don't know about others,<br>but I personally tend to want to build and debug using the entire<br>trunk.<br><br>So my new module experience is usually something along the following lines:<br><br>* Checkout trunk<br>* Prebuild<br>* Load up the project in Visual Studio, add a new project, or simply<br>add a new file to one of the existing projects (Core or Optional<br>Modules)<br>* Add any additional references to the existing or new project that<br>are needed for my new code<br>* Work on my code for a
while.<br>* Copy out the relevant files to my own separate code repository<br><br>Then at some point I end up updating the checkout with latest trunk,<br>running prebuild, load up the solution file and cuss because the extra<br>bits I added for my project are no longer present in the solution<br>(were overwritten by prebuild.) At this point I usually then go<br>modify the huge (and growing) prebuild.xml file to add my own project<br>in there, so it'll be generated along with the trunk projects each<br>time I prebuild.<br><br>I've also noticed a lot of feature creep of things into trunk of<br>things that are really optional and not required for either building<br>or running of OpenSim by a lot of people utilizing trunk -=- but they<br>are things being worked on by the core developers and are definitely<br>"nice to have" things.<br><br>Here is my suggestion:<br><br>1) Create a new top level directory in at /trunk/OpenSimModules to<br>contain
individual module projects that are not required/core modules<br><br>2) Create an empty Modules directory at /trunk/OpenSim/Modules/ where<br>nested SVN projects can be checked out to<br><br>3) Each module that is optional, and not truly required for every<br>OpenSim instance can slowly be migrated into /trunk/OpenSimModules/<br>for example /trunk/OpenSimModules/FlotsamAssetCache -- each of these<br>modules would have their own mini, self contained, prebuild included<br>in their project directory<br><br>4) Patch prebuild so that it allows a wildcard to be specified in the<br>include path, so the following would be valid: <? include<br>file="modules/*/prebuild.xml" ?> [Note: I have a working hack/patch<br>that would allow this]<br><br>5) Modify the main prebuild.xml file located at<br>/trunk/OpenSim/prebuild.xml to use this new expanded include<br>directive.<br><br><br>To use the repository in this new configuration, you would
first<br>checkout a copy of trunk/OpenSim -- or a stable build of your choice<br>-- you then look through the list of modules within<br>trunk/OpenSimModules for modules that you would like to use with your<br>OpenSim instance. You then do a nested checkout of those individual<br>modules into your local working directory at /OpenSim/Modules/* {svn<br>fully supports nested working copies like this.} You then run<br>prebuild as normal, which will now scan the OpenSimModules directory<br>and automatically add any found projects to the nant and Visual Studio<br>solution/build files. You then run nant or open the Visual Studio<br>solution file as normal.<br><br><br>What does this accomplish?<br><br>* It separates out optional modules so that we would be working in an<br>environment that is more like a "base kernel" with "modules" that you<br>add in to make distributions, aka the "Linux Distribution model."<br><br>* Separating out all
the non-required modules makes the core<br>trunk/OpenSim code easier to understand by new developers.<br><br>* This separation will also create a clear dividing line between what<br>is "core" and what isn't<br><br>* It will be easier to "drop-in" 3rd party modules that are not stored<br>in trunk, for compilation and debugging. GForge projects could simply<br>be directly checked out into the /OpenSim/Modules/ folder and would<br>automatically be included during prebuild with no further<br>configuration other then just running prebuild again.<br><br>* All default builds of OpenSim directly out of trunk/OpenSim will be<br>slim/light weight distributions because the optional stuff won't be<br>there.<br><br>* Individual modules could now be tagged and assigned version numbers.<br> They are also separately checked out and updated, thus making it a<br>lot easier to update individual modules from the main SVN repository<br>without also pulling down
updates to the core or other modules and<br>vice'versa {for example if you know the latest AssetCacheX is broken,<br>but you want to retrieve a core update, you can update core without<br>also updating that particular cache.}<br><br><br>The downsides?<br><br>I could only think of two, so this is where I need the most feedback.<br>The first being that it requires a little more effort on the part of<br>developers because you have to do multiple SVN checkouts to get a<br>"full featured" copy of OpenSim's source. The second being the<br>migration of the existing code, and the inevitable discovery of some<br>code that's too highly coupled to move and the re-factoring necessary<br>to do so.<br><br><br>Parting notes:<br><br>I'd also suggest doing the same for all the Grid & Stand-alone related<br>components, leaving only the bare essentials in trunk/OpenSim<br>necessary to make a grid attached instance along with the core<br>components needed by all
modules and grid services. Thus we would<br>have something like trunk/OpenSimServers or trunk/OpenSimServices<br>where the grid services (Asset Server, User Server, etc) would be<br>moved to, and they in-turn would be checked out into a<br>trunk/OpenSim/Server/ directory.<br><br><br>Thoughts, comments?<br>--<br>Michael Cortez<br>_______________________________________________<br>Opensim-dev mailing list<br><a ymailto="mailto:Opensim-dev@lists.berlios.de" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br></div></div></div></body></html>