5 Replies Latest reply on Nov 22, 2006 1:12 PM by Norman Richards

    What's your prefered deployment strategy when developing?

    Ben Catherall Newbie

      Hi everyone,

      I'm really getting in to Seam now, great stuff, but what does everyone do in terms of deployment on JBoss when developing? At the moment I'm doing the usual build .ear and stick it in the /deploy directory. Whilst I don't mind redeploying when I've made changes to my EJBs etc, it would be nice if I could alter HTML bits and get to see them straight away.

      I remember reading this was possible, and have experimented with adding a file URL in the DeploymentScanner config, but it seems like once the remote directory is deployed it gets copied in to /deploy/tmp/ anyway so a modification to a file wouldn't be recognised anyway?

      Any thoughts most welcome

      Cheers -Ben

        • 1. Re: What's your prefered deployment strategy when developing
          Ben Catherall Newbie

          Spoke too soon!

          Works a charm with IntelliJ IDEA using an exploded EAR. I'm sure I tried this before (something was waiting for me to post obviously :D) !

          Then repackaging the html, rather than building the project, only copies the file in question over.

          • 2. Re: What's your prefered deployment strategy when developing
            Ning Zhao Apprentice

            I found the example on this page is very helpful:

            http://wiki.jboss.org/wiki/Wiki.jsp?page=EclipseSeamProject

            The first time it took me almost one hour to set up everything correctly but you can really grok the Seam's packaging structure once you completely walk it through by heart. It serves very well as a template. Now I've modified the booking example a great deal, adding jpdl pageflow and rules stuff, never had any packaging or "class/resource not found" problem following this example. Once you grokked the seam packaging structure and familiar with the several xml configuration files, you can apply it with any IDE.

            Currently the JBossIDE for Eclipse or any other Eclipse based IDE don't like to publish the project to a configured app server. However the workaround is extremely simple. You can "run packaging" with the eclipse seam projects set like the example, then copy&paste the ear file to the JBoss deploy folder. Either with a line of console command (cp ....) or with a GUI file management tool drag and drop.

            I've used all of Eclipse 3.2+, NetBeans 5.5 and IDEA 6. When it comes to deployment, I'm happiest with NetBeans' Ant-based approach. I used NetBeans to setup a new project and configured everything with its GUI tools. NetBeans generates the build.xml for me. You can happily work on projects with this build file (Assume the ant is installed on your system) without any big IDE and the deployment is a simple "ant deploy". Since most of the developers around me are still using Eclipse so I'm using Eclipse just to be social. Actually I like NetBeans better merely because it is so easy to get the working build.xml from it. :-)

            And yes, Seam is great stuff. I highly appreciate the idea behind and the Seam developer's hardwork. :-)

            • 3. Re: What's your prefered deployment strategy when developing
              Pete Muir Master

              If you are using Eclipse then seam-gen is a great way to go, it sets you up with a build.xml file and the correct eclipse project structure in 5 minutes. It sets up both an exploded ear and a 'normal' ear.

              Probably that Wiki page should be updated to tell people to use seam-gen now

              • 4. Re: What's your prefered deployment strategy when developing
                Norman Richards Master

                The new seam-gen stuff also has the ability to manage exploded deployment. You might want want to check that out for some ideas on how to do it.

                • 5. Re: What's your prefered deployment strategy when developing
                  Norman Richards Master

                  The new seam-gen stuff also has the ability to manage exploded deployment. You might want want to check that out for some ideas on how to do it.