This is all good info, thanks! However, I've looked into the source and have a few concerns. Here's what I'm struggling a bit with:
I really want to use Shindig as a basis for my social network, but Maven is a lil bit too complex for me (hey, I struggle with Ant! ;). I'd like to be able to write my code on my own and then slot it into Shindig, but the SocialApiGuiceModule.java needs to be changed at compile-time, which means I somehow *have* to build my social network in one build. I therefore *have* to understand Shindig's build process. Does this make sense? In an ideal world I'd like to: * Develop my code to interfaces, as needed by the guice module above * Download a Shindig release (or if not available, checkout and build Shindig) * Change a Shindig config file somewhere to use my code * Deploy Shindig + my code into my servlet container * Execute and be happy! I think this could help tremendously. I realize Shindig has just gotten started. Is my 'ideal world' setting above something we want Shindig to become or not? Am I missing the big picture, perhaps it is easier to 'slot' things into Shindig than I think? Thanks, Hans On Tue, Jul 1, 2008 at 1:49 PM, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: > "Hans Granqvist" <[EMAIL PROTECTED]> writes: > >>Hi all > > Hi, > >>I'm looking for advice how to best maintain code that my >>team develops (handlers and the UI and other components) >>and the rapidly changing Shindig code. > > for our internal development, I actually locked down on a Shindig code > base some time ago and cherry-pick some stuff that I really need in > our current implementation. Our Shindig looks a bit like a > Frankenstein's monster, however. We also reworked part of the > Javascript (mainly I am pretty concerned with the 0.7 -> 0.8 > interdependencies, we will probably use completely separated code > bases to support 0.7 and 0.8 (they will speak to the same shindig > core, though). > > We locked down the dependencies used by Shindig by modifying the POMs > and have an internal release process to add our patches to the Shindig > codebase. > > I toyed a bit with git and git-svn to maintain my local patches but > wasn't really successful. Getting my patches actually applied leads to > a whole slew of conflicts and M-x vc-resolve-conflicts doesn't work as > well with Git as it does with SVN... :-) > >>I am a bit unsure how to best handle the maven build since >>there is quite a lot of dependencies on external components. > > If you want to use anything maven based for a serious/production > environment, you need a local artifact repository. There is no way > around this IMHO. > >>While I can certainly use the Maven build as it is, it seems >>dangerous to depend on external components auto-updated >>by Maven. At the same time, taking a snapshot of the Shindig >>code probably adds a lot of headache in the future when it >>comes time to reconcile new Shindig code. > > Amen brother. :-) > > Ciao > Henning > > > > -- > Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, > 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person > Open Source Consulting, Development, Design | Velocity - Turbine guy > > INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 > Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen > > "Professor Peach in the library with the lead piping!" -- Donna >
