Well, you can add your own templates, etc to the STK module (for example) but if an STK update comes it will be a PITA to export all your stuff out of the module and then back in. Modules allow you to keep your code (not only java classes, but also templates) separate from the ones from Magnolia - it makes it easier to update to a newer STK/Magnolia core, not to mention that when I had all my templates kept with the STK ones sometimes it was hard to keep track which ones are mine (or modified), and which ones are from the STK. Note that this is just my opinion, if you'll find a different way, better suited for your needs, by all means use it (and share it with the rest of the community ;))
Best regards, Igor Klimer On Mon, Jul 13, 2009 at 12:36 PM, Brent McArthur<[email protected]> wrote: > Thanks for that Igor. We're using magnolia 4.1. Based on what you've > said it sounds like I've been thinking about this in the wrong way. > Are you saying that developing even the most basic websites that only > have a few templates / dialogs you should always package those sites > as jar modules and deploy them in the same way I did forthe STK? > > For some strange reason I had in my head that modules are only used > for deploying websites that need java components (to integrate with a > 3rd party web service for example) > > Cheers > > Brent > > On 13/07/2009, at 7:05 PM, "Igor Klimer" <[email protected]> wrote: > >> >> I'm not sure I understood you correctly but you can store all the >> things you mentioned in your filesystem - no need to keep it in JCR >> (imho, that doesn't have much advantages, that's why I "extracted" all >> the templates, dialog definitions, etc, to the filesystem and can put >> them under SCM). >> You do this by simply changing the addresses of all the relevant >> resources to point to files existing in for example your docroot. >> You didn't write which version of Magnolia you are working with but >> for example thhh 3.6.x branch has an Maven archetype for modules that >> would give you a ready-to-work-with module structure. For more recent >> versions, like 4.1.x I found that looking at existing modules on SVN >> is the best way to go. >> >> HTH & best regards, >> Igor Klimer >> >> >> On Mon, Jul 13, 2009 at 10:04 AM, Brent McArthur<[email protected] >> > wrote: >>> Hi Everyone, >>> >>> >>> >>> I’ve found this mailing list really helpful in learning Magnolia s >>> o I >>> thought I would try my luck again. >>> >>> >>> >>> Myself and my team have now done a successful demonstration to a >>> client >>> using Magnolia and we are proceeding to a proper project based on >>> Magnolia >>> which I’m stoked about. >>> >>> >>> >>> However, as with all of our other Java based projects I want to >>> ensure all >>> of our code is properly version controlled. Does anyone have any >>> suggestions >>> as to how best setup a project where changes can be made using >>> eclipse and >>> checked in to SVN? To give you a more detailed list of what I want >>> managed >>> by SVN: >>> >>> >>> >>> 1. JSP templates >>> >>> 2. JSP paragraphs >>> >>> 3. Template definitions >>> >>> 4. Paragraph definitions >>> >>> 5. Dialogues >>> >>> 6. Other repository configuration >>> >>> 7. Any java classes we write >>> >>> >>> >>> Basically, I want to be able to checkin all “non-content” >>> related project >>> information into SVN so we can tag, branch, etc. What do you all >>> recommend >>> for doing this? For our demo we did manual import and export of >>> sections of >>> the appropriate repository but in larger projects with larger teams >>> this is >>> just not sustainable. The overheads are too much. Do we need to >>> write a >>> bunch of scripts to do it or do they already exist? >>> >>> >>> >>> Any help would be much appreciated! >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Brent >>> >>> ________________________________ >>> ---------------------------------------------------------------- >>> For list details see >>> http://www.magnolia-cms.com/home/community/mailing-lists.html >>> To unsubscribe, E-mail to: <[email protected]> >>> ---------------------------------------------------------------- >>> >> >> ---------------------------------------------------------------- >> For list details see >> http://www.magnolia-cms.com/home/community/mailing-lists.html >> To unsubscribe, E-mail to: <[email protected]> >> ---------------------------------------------------------------- >> > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- > > ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
