On Wed, Jul 2, 2008 at 4:00 PM, Hans Granqvist <[EMAIL PROTECTED]> wrote:
> 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. You're not supposed to modify the module, you're supposed to provide your own. The module itself is actually loaded from the web.xml. You can always replace SocialApiGuiceModule with any other module. > > 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 > > >
