[Opensim-dev] Suggestion for project organization.
James Stallings II
james.stallings at gmail.com
Tue Jun 30 13:34:59 UTC 2009
I have long supported the notion of moving all non-essential operations out
of core, and continue to do so, for the following reasons:
1. it simplifies the codebase
2. it makes the codebase more accessible to the casual developer
3. it reduces the responsibility of core devs to proactively police patches
Contrary to Mel's assertion that it is too early in the project to make
these sorts of changes, I submit that it is nearly too late.
As more and more layers are added or more tightly coupled to core
functionality, the maintainability of the overall project decreases, in
inverse proportion to the increase in complexity. In short, wait too long
and it will become impossible to apply these architectural design
sensibilities to the opensim codebase.
I really don't understand why this idea even comes into question - it is an
architectural move we have been working at slowly for some time, and MCortez
simply brings a comprehensive roadmap to the table.
I would also remind Mel that this is still an alpha project, and that is the
specific time when such overhauls should occur.
As a user and sometime programmer on opensim, I can tell you that I, for
one, would embrace such changes in the unstable branch of trunk; this is why
we have stable and unstable branches, to prevent the referenced user pain
while such surgeries are undertaken.
+1 here on continuing to move things into separate projects.
On Tue, Jun 30, 2009 at 3:16 AM, Melanie <melanie at t-data.com> wrote:
> In my opinion, it is too early in the project for such sweeping
> changes, as too much is in flux, or, as was said, too tightly
> coupled. Also, it's not just the devs, many users check out SVN and
> they can't jump through all the hoops.
>
> So, -1 or moving things into separate projects.
>
> However, I like the idea of wildcard includes for private and forge
> module support, +1 on getting that into our prebuild and submitted
> to upstream as well.
>
> Melanie
>
> Michael Cortez wrote:
> > I'd like to make a suggestion about how the OpenSim project is setup
> > in trunk for building and get some feedback from ya'll.
> >
> > Currently if a developer would like to work on a new module for
> > OpenSim, they have to first decide if they want to work inside trunk
> > (building their module along with OpenSim in the same build) or if
> > they want to create a completely separate project that just links to
> > the DLLs produced from OpenSim's trunk. I don't know about others,
> > but I personally tend to want to build and debug using the entire
> > trunk.
> >
> > So my new module experience is usually something along the following
> lines:
> >
> > * Checkout trunk
> > * Prebuild
> > * Load up the project in Visual Studio, add a new project, or simply
> > add a new file to one of the existing projects (Core or Optional
> > Modules)
> > * Add any additional references to the existing or new project that
> > are needed for my new code
> > * Work on my code for a while.
> > * Copy out the relevant files to my own separate code repository
> >
> > Then at some point I end up updating the checkout with latest trunk,
> > running prebuild, load up the solution file and cuss because the extra
> > bits I added for my project are no longer present in the solution
> > (were overwritten by prebuild.) At this point I usually then go
> > modify the huge (and growing) prebuild.xml file to add my own project
> > in there, so it'll be generated along with the trunk projects each
> > time I prebuild.
> >
> > I've also noticed a lot of feature creep of things into trunk of
> > things that are really optional and not required for either building
> > or running of OpenSim by a lot of people utilizing trunk -=- but they
> > are things being worked on by the core developers and are definitely
> > "nice to have" things.
> >
> > Here is my suggestion:
> >
> > 1) Create a new top level directory in at /trunk/OpenSimModules to
> > contain individual module projects that are not required/core modules
> >
> > 2) Create an empty Modules directory at /trunk/OpenSim/Modules/ where
> > nested SVN projects can be checked out to
> >
> > 3) Each module that is optional, and not truly required for every
> > OpenSim instance can slowly be migrated into /trunk/OpenSimModules/
> > for example /trunk/OpenSimModules/FlotsamAssetCache -- each of these
> > modules would have their own mini, self contained, prebuild included
> > in their project directory
> >
> > 4) Patch prebuild so that it allows a wildcard to be specified in the
> > include path, so the following would be valid: <? include
> > file="modules/*/prebuild.xml" ?> [Note: I have a working hack/patch
> > that would allow this]
> >
> > 5) Modify the main prebuild.xml file located at
> > /trunk/OpenSim/prebuild.xml to use this new expanded include
> > directive.
> >
> >
> > To use the repository in this new configuration, you would first
> > checkout a copy of trunk/OpenSim -- or a stable build of your choice
> > -- you then look through the list of modules within
> > trunk/OpenSimModules for modules that you would like to use with your
> > OpenSim instance. You then do a nested checkout of those individual
> > modules into your local working directory at /OpenSim/Modules/* {svn
> > fully supports nested working copies like this.} You then run
> > prebuild as normal, which will now scan the OpenSimModules directory
> > and automatically add any found projects to the nant and Visual Studio
> > solution/build files. You then run nant or open the Visual Studio
> > solution file as normal.
> >
> >
> > What does this accomplish?
> >
> > * It separates out optional modules so that we would be working in an
> > environment that is more like a "base kernel" with "modules" that you
> > add in to make distributions, aka the "Linux Distribution model."
> >
> > * Separating out all the non-required modules makes the core
> > trunk/OpenSim code easier to understand by new developers.
> >
> > * This separation will also create a clear dividing line between what
> > is "core" and what isn't
> >
> > * It will be easier to "drop-in" 3rd party modules that are not stored
> > in trunk, for compilation and debugging. GForge projects could simply
> > be directly checked out into the /OpenSim/Modules/ folder and would
> > automatically be included during prebuild with no further
> > configuration other then just running prebuild again.
> >
> > * All default builds of OpenSim directly out of trunk/OpenSim will be
> > slim/light weight distributions because the optional stuff won't be
> > there.
> >
> > * Individual modules could now be tagged and assigned version numbers.
> > They are also separately checked out and updated, thus making it a
> > lot easier to update individual modules from the main SVN repository
> > without also pulling down updates to the core or other modules and
> > vice'versa {for example if you know the latest AssetCacheX is broken,
> > but you want to retrieve a core update, you can update core without
> > also updating that particular cache.}
> >
> >
> > The downsides?
> >
> > I could only think of two, so this is where I need the most feedback.
> > The first being that it requires a little more effort on the part of
> > developers because you have to do multiple SVN checkouts to get a
> > "full featured" copy of OpenSim's source. The second being the
> > migration of the existing code, and the inevitable discovery of some
> > code that's too highly coupled to move and the re-factoring necessary
> > to do so.
> >
> >
> > Parting notes:
> >
> > I'd also suggest doing the same for all the Grid & Stand-alone related
> > components, leaving only the bare essentials in trunk/OpenSim
> > necessary to make a grid attached instance along with the core
> > components needed by all modules and grid services. Thus we would
> > have something like trunk/OpenSimServers or trunk/OpenSimServices
> > where the grid services (Asset Server, User Server, etc) would be
> > moved to, and they in-turn would be checked out into a
> > trunk/OpenSim/Server/ directory.
> >
> >
> > Thoughts, comments?
> > --
> > Michael Cortez
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
--
===================================
http://osgrid.org
http://del.icio.us/SPQR
http://twitter.com/jstallings2
http://www.linkedin.com/pub/5/770/a49
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090630/6e766a65/attachment-0001.html>
More information about the Opensim-dev
mailing list