uportal 3.1.1 and build filtering
|
|
|
||||||||
|
Some javascript/style in this post has been disabled (why?)
You have to do it with Maven. We use build.properties to configure a
lot of different things. I've bolded the important bits that we added
to the pom.xml files.uportal-war/pom.xml <build> <filters> <filter>../build.properties</filter> </filters> <finalName>${uportal.docbase}</finalName> <plugins> <plugin> <groupId>net.sf.alchim</groupId> <artifactId>yuicompressor-maven-plugin</artifactId> <executions> <execution> <goals> <goal>compress</goal> </goals> </execution> </executions> <configuration> <excludes> <exclude>**/*.min.js</exclude> </excludes> <suffix>.min</suffix> </configuration> </plugin> <plugin> <groupId>net.sf.alchim</groupId> <artifactId>yuicompressor-maven-plugin</artifactId> <version>0.7.1</version> <executions> <execution> <goals><goal>compress</goal></goals> </execution> </executions> <configuration> <excludes> <exclude>**/*.min.js</exclude> </excludes> <linebreakpos>10000</linebreakpos> <suffix>.min</suffix> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> <version>2.0.2</version> <configuration> <webXml>${war-plugin-webxml-source}</webXml> <warSourceExcludes>WEB-INF/lib/uportal-impl-${project.version}.jar</warSourceExcludes> <webResources> <resource> <filtering>true</filtering> <directory>${basedir}/src/main/webapp</directory> <includes> <include>META-INF/context.xml</include> <include>WEB-INF/web.xml</include> <include>WEB-INF/log4j.xml</include> <include>help/feedback.html</include> </includes> </resource> <resource> <filtering>true</filtering> <directory>${basedir}/src/main/resources</directory> <targetPath>WEB-INF/classes</targetPath> <includes> <include>layout/theme/universality/universality.xsl</include> </includes> </resource> </webResources> </configuration> </plugin> [snip...] uportal-impl/pom.xml <build> <filters> <filter>../build.properties</filter> </filters> <resources> <!-- This configuration will make sure all .xml and .properties file are copied and filtered --> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> <includes> <include>**/*.properties</include> <include>**/*.xml</include> </includes> </resource> <!-- This configuration will make sure all resources are copied, except the .xml and .properties files --> <resource> <directory>src/main/resources</directory> <excludes> <exclude>**/*.properties</exclude> <exclude>**/*.xml</exclude> </excludes> </resource> <resource> <directory>src/main/java</directory> <includes> <include>**/*.properties</include> </includes> </resource> </resources> This will filter properties with ${PROPNAME}, for example: uportal-war/src/main/webapp/WEB-INF/web.xml <context-param> <param-name>edu.yale.its.tp.cas.proxyUrl</param-name> <param-value>${casProxyUrl}</param-value> </context-param> ${casProxyUrl} will be replaced with the value from build.properties Curtis Garman wrote: I'm setting up an environment with multiple instances of tomcat per server and was wondering if someone can give me a tip on setting up my build to take my server.home defined in my build.properties and use this as the base path for my tomcat log4j configuration files via swapping it in in place of a variable or something so that literally the only thing I have to do to deploy the same configuration to each jvm is change the server.home value. The way the current build.xml file is setup (using pieces of ant and maven) I'm not sure if this would be done via ant or maven. Not sure how others do it, but something like this seems like it would be a valuable default configuration for the uportal build script. [awhite.vcf] begin:vcard fn:Arlo White n:White;Arlo org:ITS;Application Integration adr;dom:Calpoly;;Chase Hall, Room 215;San Luis Obispo;CA email;internet:[hidden email] title:Analyst/Programmer tel;work:(805) 756-5211 x-mozilla-html:TRUE version:2.1 end:vcard |
||||||||
smime.p7s (4K) |
|
|
||||||||
|
In reply to this post
by Curtis Garman
Curtis Garman wrote:
> I'm setting up an environment with multiple instances of tomcat per > server and was wondering if someone can give me a tip on setting up my > build to take my server.home defined in my build.properties and use > this as the base path for my tomcat log4j configuration files via > swapping it in in place of a variable or something so that literally > the only thing I have to do to deploy the same configuration to each > jvm is change the server.home value. What exactly do you need to customize in log4j configs for each tomcat? We use multiple tomcats per server and use log4j's built-in ${catalina.base} property to automagically reference each individual tomcat's root. The same log4j config file is distributed to every tomcat, and they all use their own "logs" directories. - Aaron -- Aaron Brown ([hidden email] | 785-864-0462) University of Kansas Information Services System Design Enterprise System Integration Developer |
||||||||
|
|
|
||||||||
|
|
Curtis Garman wrote:
> Are your tomcat instances on the same server or different servers? > Mine are on the same server...so not sure that ${catalina.base} would > do it...each instance of tomcat would need it's own environment > variable wouldn't it?...I don't want my build dependent on a list of > environment variables that are dependent on one machine. If you can > explain your setup further, I would appreciate it. In our production environment, we have three servers with six tomcat instances each. They are each fully self-sufficient copies (no shared files between them), and they all use identical log4j.properties files, thanks to the ${catalina.base} property. Here is the relevant snippet from our log4j.properties file, with some placeholder names: log4j.appender.Whatever.File=${catalina.base}/logs/SomeLogFile.log Log4j is smart enough to detect the root of the tomcat which executed it, and uses that for its path. - Aaron -- Aaron Brown ([hidden email] | 785-864-0462) University of Kansas Information Services System Design Enterprise System Integration Developer |
||||||||
|
|
|
||||||||
|
|
|
||||||||
|
|
|
||||||||
|
|
Curtis Garman wrote:
> Aaron, one more question...you mentioned you have three servers...how > do you handle your project source code? Do you have a copy of the > project files on each server to be able to redeploy or do you have a > script or something that deploys across servers or what? We have a test system, used by our QA team for final testing before release, which is as close a copy to our production system as possible. We build our production code there (as .war files) and use a script to deploy to all the servers/tomcats. We have more production servers than the ones I mentioned, but the others are VMs with one tomcat each - their performance isn't as good as a real hardware server, so they're mostly useful during peak usage times. In all, it makes for quite a few tomcat instances, so we've been using deployment scripts for some time now and it works pretty well for us. - Aaron -- Aaron Brown ([hidden email] | 785-864-0462) University of Kansas Information Services System Design Enterprise System Integration Developer |
||||||||
|
In reply to this post
by Curtis Garman
|
||||||||
|
|
|
||||||||
|
|
|
||||||||
| Free Embeddable Forum Powered by Nabble | Help |
