The capra code is currently out of master but a legacy branch with the capra-specific code is still in the main repository as a separate branch
http://github.com/GeoNode/geonode/tree/capra I think that soon after the 1.0 release we should have time to nail down best practices for extending GeoNode, and the AME/File storage app will likely be the pilot instance of that. On Tue, Aug 24, 2010 at 3:24 PM, <[email protected]> wrote: > As far as the management of the CAPRA code with contracts that is something > that can be figured out. However it is useful to keep the CAPRA code around > as we will be installing an instance of the GeoNode on the CAPRA website so > we will still need the AME storage ability. > > ---- > Galen B. Evans > Disaster Risk Management > Latin America & The Caribbean > Sustainable Development Network (SDN) > World Bank > 1818 H St. NW > Washington, DC 20433 > +1-202-458-5344 > > [image: Inactive hide details for Sebastian Benthall ---08/10/2010 08:34:27 > PM---One thing we need to do before the 1.0 release is remo]Sebastian > Benthall ---08/10/2010 08:34:27 PM---One thing we need to do before the 1.0 > release is remove the CAPRA specific stuff from the generic c > > > From: > Sebastian Benthall <[email protected]> > To: > [email protected] > Date: > 08/10/2010 08:34 PM > Subject: > [geonode] Splitting off the CAPRA code > Sent by: > [email protected] > > > > ------------------------------ > > > > One thing we need to do before the 1.0 release is remove the CAPRA specific > stuff from the generic codebase and deployment available at master. > > Conveniently,the CAPRA-specific stuff is in src/GeoNodePy/capra and > src/capra-client. The only non-CAPRA specific things I can find in those > directories are the templates and default settings for the the new user > registration. > > I propose that as an interim solution to this problem, we > * Move the user registration code to src/GeoNodePy/geonode > * Make a 'capra' branch on Github/geonode, leaving the capra-specific > directories in it > * Remove the capra directories from 'master' and 'synth' > > If there are no objections, I'll work on this this week. > > In the longer term, it would probably make sense for there to be a > github/capra (or something) repository with its own GeoNode fork. However, > I haven't spoken with anyone at the World Bank about how they want to manage > or brand their internal code, and I think there are a lot of open questions > about how we are going to technically manage contract work around GeoNode, > including work for CAPRA, and > > [See ticket > *http://projects.opengeo.org/CAPRA/ticket/688*<http://projects.opengeo.org/CAPRA/ticket/688> > ] > > -- > Sebastian Benthall > OpenGeo - *http://opengeo.org* <http://opengeo.org/> > > > -- Sebastian Benthall OpenGeo - http://opengeo.org
<<ecblank.gif>>
<<graycol.gif>>
