Thanks everyone. You all make good points. Typically, with our ant builds, we have a special task called "setup_jboss" that will deploy certain jboss specific files (after doing some substitutions - ie datsource setup for a dev db, etc.). It's obviously not run all the time, so I guess I could keep the seem thing within maven (just haven't used the ant tasks from within maven yet, but will look into that.
On Mon, Oct 6, 2008 at 10:13 PM, Edelson, Justin < [EMAIL PROTECTED]> wrote: > We treat these JBoss configuration files as artifacts outside of the main > deployable (read: EAR file). The vast majority of our JBoss sites use the > same base server configuration, which includes the jboss-service.xml and > other files. jboss-service.xml uses system property placeholders for > environmental-specific bits. The system properties are defined in a separate > file and loaded into JBoss with the -P option. Each instance has its own > log4j.xml file and datasource xml files, but AFAIK, these could use property > placeholders as well if necessary. We version control all of these files > (obviously), but outside of the main application. > > The goal of this architecture was, as Bob says below, to use the same build > between dev, QA, and prod (although in reality, dev is usually a SNAPSHOT > build from CI) and to simplify new site creation by reusing the same base > server configuration. > > For more application-specific (vs. container-specific) stage-based > configuration, we use a combination of system properties (-Dstage=qa) and a > customized version of Spring internals. > > Justin Edelson > VP, Platform Engineering > MTV Networks Digital > > ________________________________ > > From: Bob Aiello [mailto:[EMAIL PROTECTED] > Sent: Mon 10/6/2008 9:00 PM > To: Maven Users List > Subject: Re: Best practice? Where to put app-server specific files > (log4j.xml, datsource xml files, jboss-service.xml , etc.) > > > > I believe that most people use the Ant plugin Assembly to parse the dev, > qa, > prod > environment files. I would suggest that you create them all during the > build. I have > seen some people put in the environment during the build and parse the > files > just for > that environment. This meant that they had to rebuild for dev, QA and Prod > (very > bad practice!). From a compliance point of view you do want your QA build > to be the same as the build that you promote into production (obviously you > have a deployment script to change over the environment files). > > What does everyone else do? > > Bob Aiello > Editor in Chief > CM Crossroads > www.cmcrossroads.com > http://www.linkedin.com/in/BobAiello > > > ----- Original Message ----- > From: "Rick" <[EMAIL PROTECTED]> > To: "Maven Users List" <[email protected]> > Sent: Monday, October 06, 2008 6:25 PM > Subject: Best practice? Where to put app-server specific files (log4j.xml, > datsource xml files, jboss-service.xml , etc.) > > > > I'm working on a typical JEE application that will be deployed to JBoss. > > (JBoss5 if it matters.) Things are going. I have a pretty standard setup: > > > > Parent Module > > EJB-JAR Module > > JAR Module > > WEB Module > > EAR Module > > > > > > Currently, however, I'm manually having to deal with certain files that I > > need in JBoss: > > * datasource.xml files > > * jboss-service.xml > > * log4j.xml files > > There will probably be some others as well. > > > > What is the best way to deal with these files? Is the best practice to > > create a directory in the parent module or ear module and just create > some > > custom ant task to move them around where they need to go? I couldn't > find > > much about a jboss maven plugin to help with these tasks, so I'm assuming > > hooking in regular old ant is the way to go? > > > > I'll also want to have certain variables in those files replaced with > > variables from a profile (dev, test, prod) depending on what profile I'm > > running. I'll look into that as well, since I'm sure there are some docs > > on > > it, but are the any issues to be aware of since I'm guessing these aren't > > standard files that I'm dealing with so is using the replacement > > mechanism > > more difficult? > > > > Thanks > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- Rick
