Apache Struts 2.3.35 Upgrade - backward incompatibility in s:if
We upgraded from 2.3.34 to 2.3.35 in one of our applications, but although the upgrade is described as backwards compatible, we found a problem in the UI. The simplified example is as follows. *Given* a JSP with: foo bar *And *scopesValues was previously set (, where scopes is a Listscopes in the action) *When* the List scopes has [Portuguese Things, XXX] *Then *the JSP will print: bar[Portuguese Things, XXX] If I revert to 2.3.34: *Then *the JSP will print: foo[Portuguese Things, XXX] What could be causing this? Since this breaks one of our pages we are now hesitant on what other places could break after the upgrade. Kind regards, Miguel
Re: Some questions about Webby
Hey Thorsten, Did you manage to figure out this? I've just asked the exact same thing in m2e's mailing list! Cheers, Miguel Almeida On Tue, May 8, 2012 at 2:47 PM, Thorsten Heit thorsten.h...@vkb.de wrote: Hi, today I decided to give Webby a try. Apart from Webby Core I also installed the embedded Jetty 8.x container. So far, so good. Some questions: a) How does Webby deal with dependencies having their scope set to provided? Our applications are mostly WARs / EARs that are deployed into WebSphere Application Server 7.x. Therefore a couple of dependencies such as javax.servlet:servlet-api or javax.mail:mail are specified in the pom.xml's with scope provided. Using such an application with the embedded Jetty container results in ClassNotFoundExceptions; using a local Tomcat 7.x installation (on which I have the necessary jars copied into the lib folder) works, although it seems to me to take a bit longer for startup. b) Can I use Webby to debug web applications via HTTPS? The locally installed Tomcat instance is already configured for accepting SSL connections. This works well as long as I'm debugging my application via Eclipse, WTP and m2eclipse-wtp, but obviously not when using Webby. Creating a run or debug configuration lets me only choose a normal HTTP port, but there's nothing about HTTPS... Regards Thorsten
Re: Multiple Snapshot duplicates in WAR file
On a correction to my previous emai: the dependency:analyze was run on Project Foo, not ProjectX. On Tue, Aug 7, 2012 at 12:33 AM, Miguel Almeida migueldealme...@gmail.comwrote: I have a multi-module project (one of the modules is a WAR). Some modules depend on projectX, and some of the dependencies depend on that projectX too. I've used maven properties and dependency management to ensure they all depend on the same version (0.0.7-SNAPSHOT). See the dependency-analyze in [1] I have performed a lot of changes in multiple projects today - a lot of snapshot deployments. On running my CI server's deployment job (runs deploy site:site and then site:deploy) I get a WAR file with *multiple timestamped versions of the projectX's SNAPSHOT (3, per module api,core,mail). * Running the goal package locally doesn't yield the same problem - only one snapshot is packaged in the war, as expected. I've tried to figure out why this could be happening, but I am lost. Does anyone have an idea of what could be wrong? Cheers, Miguel Almeida [1] [INFO] --- maven-dependency-plugin:2.1:analyze (default-cli) @ projectX-persist --- [WARNING] Used undeclared dependencies found: [WARNING] org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar:1.0.0.Final:compile [WARNING] org.company.clinicalmanagement:clinicaltrial-api:jar:1.0.2-SNAPSHOT:compile [WARNING]org.springframework:spring-tx:jar:3.1.0.RELEASE:compile [WARNING]org.company.security:security-api:jar:0.0.7-SNAPSHOT:compile [WARNING]commons-logging:commons-logging:jar:1.1.1:compile [WARNING]org.apache.struts.xwork:xwork-core:jar:2.3.4:compile [WARNING]org.company.audit:audit-core:jar:0.1.0-SNAPSHOT:compile [WARNING]org.company.security:security-core:jar:0.0.7-SNAPSHOT:compile [WARNING]org.company.security:security-mail:jar:0.0.7-SNAPSHOT:compile [WARNING]joda-time:joda-time:jar:2.0:compile [WARNING] Unused declared dependencies found: [WARNING]org.company:projectX-shared:pom:1.1.0-SNAPSHOT:compile [WARNING]org.company:projectX-model:jar:1.1.0-SNAPSHOT:compile [WARNING]org.company:projectX-configuration:jar:1.1.0-SNAPSHOT:test [WARNING]org.springframework:spring-core:jar:3.1.0.RELEASE:compile [WARNING]org.slf4j:jcl-over-slf4j:jar:1.5.8:runtime [WARNING]org.slf4j:slf4j-api:jar:1.5.8:runtime [WARNING]org.slf4j:slf4j-log4j12:jar:1.5.8:runtime [WARNING]log4j:log4j:jar:1.2.14:runtime [WARNING]org.springframework:spring-orm:jar:3.1.0.RELEASE:compile [WARNING]c3p0:c3p0:jar:0.9.1.2:provided [WARNING]postgresql:postgresql:jar:9.0-801.jdbc4:provided [WARNING]javassist:javassist:jar:3.4.GA:compile [WARNING]javax.servlet:servlet-api:jar:2.4:provided [WARNING]cglib:cglib:jar:2.2:compile [WARNING]org.company.security:security:pom:0.0.7-SNAPSHOT:compile [WARNING]org.company.audit:audit:pom:0.1.0-SNAPSHOT:compile [INFO] [INFO] [INFO] Building PROJECTX Web 1.1.0-SNAPSHOT [INFO] [INFO] [INFO] maven-dependency-plugin:2.1:analyze (default-cli) @ projectX-web [INFO] [INFO] --- buildnumber-maven-plugin:1.0:create (default) @ projectX-web --- [INFO] [INFO] --- maven-dependency-plugin:2.1:analyze (default-cli) @ projectX-web --- [WARNING] Used undeclared dependencies found: [WARNING] org.company.clinicalmanagement:clinicaltrial-api:jar:1.0.2-SNAPSHOT:compile [WARNING]org.company.security:security-api:jar:0.0.7-SNAPSHOT:compile [WARNING]org.hibernate:hibernate-core:jar:3.6.3.Final:compile [WARNING]org.apache.struts.xwork:xwork-core:jar:2.3.4:compile [WARNING]org.company.security:security-core:jar:0.0.7-SNAPSHOT:compile [WARNING]commons-logging:commons-logging-api:jar:1.1:compile [WARNING]org.company.audit:audit-struts:jar:0.1.0-SNAPSHOT:compile [WARNING]org.springframework:spring-tx:jar:3.1.0.RELEASE:compile [WARNING]org.company.audit:audit-core:jar:0.1.0-SNAPSHOT:compile [WARNING]org.company.security:security-mail:jar:0.0.7-SNAPSHOT:compile [WARNING]org.springframework:spring-web:jar:3.0.5.RELEASE:compile [WARNING] Unused declared dependencies found: [WARNING]org.apache.commons:commons-jci-fam:jar:1.0:compile [WARNING]postgresql:postgresql:jar:9.0-801.jdbc4:test [WARNING]org.apache.struts:struts2-sitemesh-plugin:jar:2.3.4:compile [WARNING] org.apache.struts:struts2-config-browser-plugin:jar:2.3.4:compile [WARNING]org.apache.struts:struts2-spring-plugin:jar:2.3.4:compile [WARNING]commons-fileupload:commons-fileupload:jar:1.1.1:compile [WARNING]org.company:projectX-model:jar:1.1.0-SNAPSHOT:compile [WARNING]org.company:projectX-persist:jar:1.1.0-SNAPSHOT:compile [WARNING]org.company.audit:audit:pom:0.1.0-SNAPSHOT:compile [WARNING]org.springframework:spring-core:jar:3.1.0.RELEASE:compile
Multiple Snapshot duplicates in WAR file
I have a multi-module project (one of the modules is a WAR). Some modules depend on projectX, and some of the dependencies depend on that projectX too. I've used maven properties and dependency management to ensure they all depend on the same version (0.0.7-SNAPSHOT). See the dependency-analyze in [1] I have performed a lot of changes in multiple projects today - a lot of snapshot deployments. On running my CI server's deployment job (runs deploy site:site and then site:deploy) I get a WAR file with *multiple timestamped versions of the projectX's SNAPSHOT (3, per module api,core,mail). * Running the goal package locally doesn't yield the same problem - only one snapshot is packaged in the war, as expected. I've tried to figure out why this could be happening, but I am lost. Does anyone have an idea of what could be wrong? Cheers, Miguel Almeida [1] [INFO] --- maven-dependency-plugin:2.1:analyze (default-cli) @ projectX-persist --- [WARNING] Used undeclared dependencies found: [WARNING] org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar:1.0.0.Final:compile [WARNING] org.company.clinicalmanagement:clinicaltrial-api:jar:1.0.2-SNAPSHOT:compile [WARNING]org.springframework:spring-tx:jar:3.1.0.RELEASE:compile [WARNING]org.company.security:security-api:jar:0.0.7-SNAPSHOT:compile [WARNING]commons-logging:commons-logging:jar:1.1.1:compile [WARNING]org.apache.struts.xwork:xwork-core:jar:2.3.4:compile [WARNING]org.company.audit:audit-core:jar:0.1.0-SNAPSHOT:compile [WARNING]org.company.security:security-core:jar:0.0.7-SNAPSHOT:compile [WARNING]org.company.security:security-mail:jar:0.0.7-SNAPSHOT:compile [WARNING]joda-time:joda-time:jar:2.0:compile [WARNING] Unused declared dependencies found: [WARNING]org.company:projectX-shared:pom:1.1.0-SNAPSHOT:compile [WARNING]org.company:projectX-model:jar:1.1.0-SNAPSHOT:compile [WARNING]org.company:projectX-configuration:jar:1.1.0-SNAPSHOT:test [WARNING]org.springframework:spring-core:jar:3.1.0.RELEASE:compile [WARNING]org.slf4j:jcl-over-slf4j:jar:1.5.8:runtime [WARNING]org.slf4j:slf4j-api:jar:1.5.8:runtime [WARNING]org.slf4j:slf4j-log4j12:jar:1.5.8:runtime [WARNING]log4j:log4j:jar:1.2.14:runtime [WARNING]org.springframework:spring-orm:jar:3.1.0.RELEASE:compile [WARNING]c3p0:c3p0:jar:0.9.1.2:provided [WARNING]postgresql:postgresql:jar:9.0-801.jdbc4:provided [WARNING]javassist:javassist:jar:3.4.GA:compile [WARNING]javax.servlet:servlet-api:jar:2.4:provided [WARNING]cglib:cglib:jar:2.2:compile [WARNING]org.company.security:security:pom:0.0.7-SNAPSHOT:compile [WARNING]org.company.audit:audit:pom:0.1.0-SNAPSHOT:compile [INFO] [INFO] [INFO] Building PROJECTX Web 1.1.0-SNAPSHOT [INFO] [INFO] [INFO] maven-dependency-plugin:2.1:analyze (default-cli) @ projectX-web [INFO] [INFO] --- buildnumber-maven-plugin:1.0:create (default) @ projectX-web --- [INFO] [INFO] --- maven-dependency-plugin:2.1:analyze (default-cli) @ projectX-web --- [WARNING] Used undeclared dependencies found: [WARNING] org.company.clinicalmanagement:clinicaltrial-api:jar:1.0.2-SNAPSHOT:compile [WARNING]org.company.security:security-api:jar:0.0.7-SNAPSHOT:compile [WARNING]org.hibernate:hibernate-core:jar:3.6.3.Final:compile [WARNING]org.apache.struts.xwork:xwork-core:jar:2.3.4:compile [WARNING]org.company.security:security-core:jar:0.0.7-SNAPSHOT:compile [WARNING]commons-logging:commons-logging-api:jar:1.1:compile [WARNING]org.company.audit:audit-struts:jar:0.1.0-SNAPSHOT:compile [WARNING]org.springframework:spring-tx:jar:3.1.0.RELEASE:compile [WARNING]org.company.audit:audit-core:jar:0.1.0-SNAPSHOT:compile [WARNING]org.company.security:security-mail:jar:0.0.7-SNAPSHOT:compile [WARNING]org.springframework:spring-web:jar:3.0.5.RELEASE:compile [WARNING] Unused declared dependencies found: [WARNING]org.apache.commons:commons-jci-fam:jar:1.0:compile [WARNING]postgresql:postgresql:jar:9.0-801.jdbc4:test [WARNING]org.apache.struts:struts2-sitemesh-plugin:jar:2.3.4:compile [WARNING] org.apache.struts:struts2-config-browser-plugin:jar:2.3.4:compile [WARNING]org.apache.struts:struts2-spring-plugin:jar:2.3.4:compile [WARNING]commons-fileupload:commons-fileupload:jar:1.1.1:compile [WARNING]org.company:projectX-model:jar:1.1.0-SNAPSHOT:compile [WARNING]org.company:projectX-persist:jar:1.1.0-SNAPSHOT:compile [WARNING]org.company.audit:audit:pom:0.1.0-SNAPSHOT:compile [WARNING]org.springframework:spring-core:jar:3.1.0.RELEASE:compile [WARNING] org.springframework:spring-context-support:jar:3.1.0.RELEASE:compile [WARNING]org.slf4j:jcl-over-slf4j:jar:1.5.8:runtime [WARNING]org.slf4j:slf4j-api:jar:1.5.8:runtime [WARNING]org.slf4j:slf4j-log4j12:jar:1.5.8:runtime [WARNING]log4j:log4j:jar
Surefire + failsafe plugins - how to generate reports?
Dear all, I was using surefire-report to test my multi-module Maven project, by running the goal clean surefire-report:report on the parent project. However, some Cucumber BDD tests were slowing the tests down (4+ minutes), which is not good if we want devs to run them frequently. Ideally, what I want is: - quick set of tests run locally - full set of tests run in CI (Jenkins) I decided to try the failsafe plugin, so I changed one test from Acceptance_Test to Acceptance_IT and added the following in the parent pom. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId version2.12/version executions execution idintegration-test/id goals goalintegration-test/goal goalverify/goal /goals /execution /executions /plugin Sure enough, mvn verify runs the IT test and surefire-report:report (or mvn site) runs the other ones. I added the following [1] to the reportPlugins section of the maven-site-plugin, but if I run mvn site I don't see my integration tests in the [each_module]/target/site/surefire-report.html document, nor in [each_module]/target/surefire-reports [1] - section of the maven-site-plugin configuration plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-report-plugin/artifactId version2.12/version reportSets reportSet idunit/id reports reportreport/report /reports /reportSet reportSet idintegration-tests/id reports reportfailsafe-report-only/report /reports /reportSet /reportSets /plugin My questions are: 1) *which goal(s) do I have to run to have an html report for both sets of tests?* 2) *Will it be one report with all tests, or two separate reports?* I also have a couple of questions regarding the different goals run in CI (I take it I should run all the goals in CI and only surefire:report on developer's machines) and how Cobertura is affected by this (I read that code coverage won't take into consideration the failsafe tests, even though it should in the CI server), but I'll tackle one problem at a time. I appreciate your help, Miguel Almeida
test-jar in multi-module: not working in some goals
I have a multi-module project where moduleA has a test-jar depedency to moduleB. I am running Maven 3 and was under the impression that maven would figure out the dependency in the same reactor (I am running through the parent project). However, some goals can't find the test-jar dependency: - site doesn't find the dependency* - surefire-report:report doesn't complain The problem is similar to what is explained in http://stackoverflow.com/questions/4786881/why-is-test-jar-dependency-required-for-mvn-compile Is this a known issue? Must I not use some goals when I have this kind of test-jar dependency? Even if I installed/deployed, maven would probably be out of sync, retrieving the previously installed test-jar and not the one in the current workspace. Thanks in advance for your clarification, Miguel Almeida *[ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site (default-site) on project clinicalmanagement: failed to get Reports: Failed to execute goal on project cm-web: Could not resolve dependencies for project com.itc.clinicalmanagement:cm-web:war:1.0.2-SNAPSHOT: Could not find artifact com.itc.clinicalmanagement:cm-persistence:jar:tests:1.0.2-SNAPSHOT in itc-internal (http://192.100.1.1:8082/archiva/repository/itc-internal/) - [Help 1]
Re: Can cobertura and surefire-report plugins be run without running the tests twice?
Thank you for pointing out to that discussion. Even though I don't agree completely - if running the coverage tool Cobertura changes the status of your tests, I'd say that in most likelihood the problem should be cobertura and not your code or your test - I might live with running the cobertura goal separately and even move it to the CI system: it delays quick feedback to the developer locally anyway. Miguel Almeida On Mon, Sep 26, 2011 at 4:08 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: http://maven.40175.n5.nabble.com/Cobertura-and-Surefire-td3338334.html On 26 September 2011 15:46, Miguel Almeida migueldealme...@gmail.com wrote: I am using the cobertura plugin to create test coverage reports, and surefire-report for test reports. See [1] for my maven 3 configuration on the top-tier of a multi-module project. The goals I am running are: Surefire: surefire-report:report Cobertura: cobertura:cobertura Is it possible to run the both reports in the same run *withou*t *running the tests twice*? I have tried two approaches: 1) mvn both goals 2) Site: site:site However, because site:site ran for too long (more than 2 minutes, vs a 30 second surefire-report), I inspected its output, and found out it was running each test twice (eg, I found two string matches of Running org.iwrs.web.IndexActionTest). To reduce total goal time, can *tests run once and produce surefire and cobertura reports*? Thank you, Miguel Almeida [1] plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-site-plugin/artifactId version3.0-beta-3/version configuration reportPlugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId version2.7/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-report-plugin/artifactId version2.6/version /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId configuration instrumentation excludes excludecom/work/**/*Fake*.class/exclude /excludes /instrumentation /configuration /plugin /reportPlugins /configuration /plugin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Can cobertura and surefire-report plugins be run without running the tests twice?
I am using the cobertura plugin to create test coverage reports, and surefire-report for test reports. See [1] for my maven 3 configuration on the top-tier of a multi-module project. The goals I am running are: Surefire: surefire-report:report Cobertura: cobertura:cobertura Is it possible to run the both reports in the same run *withou*t *running the tests twice*? I have tried two approaches: 1) mvn both goals 2) Site: site:site However, because site:site ran for too long (more than 2 minutes, vs a 30 second surefire-report), I inspected its output, and found out it was running each test twice (eg, I found two string matches of Running org.iwrs.web.IndexActionTest). To reduce total goal time, can *tests run once and produce surefire and cobertura reports*? Thank you, Miguel Almeida [1] plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-site-plugin/artifactId version3.0-beta-3/version configuration reportPlugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId version2.7/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-report-plugin/artifactId version2.6/version /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId configuration instrumentation excludes excludecom/work/**/*Fake*.class/exclude /excludes /instrumentation /configuration /plugin /reportPlugins /configuration /plugin
Re: One project per package or multiple packages in same project?
Anders, Is what you propose possible without repeating the War files? ie, I currently have *one* WAR project, where I have all the xml, jsp and java files for the web app. The only difference between the development and production environments is a few configs like: on line in the database.xml has jdbc:...db, the other has jdbcdb-test. Are you suggesting having one WAR with all the code, html and xmls, and then some void war projects that depend on it? I'm not even sure that would work in an IDE environment like Eclipse. On Tue, Jan 18, 2011 at 11:04 AM, Anders Hammar and...@hammar.net wrote: Have different projects for the different wars and then externalize any configuration stuff outside of your wars. We've been over this many times now. Here's one thread in the archive: http://www.mail-archive.com/users@maven.apache.org/msg115082.html /Anders On Tue, Jan 18, 2011 at 11:17, Miguel Almeida migueldealme...@gmail.com wrote: Hi, In http://maven.40175.n5.nabble.com/Maven-Problem-in-including-excluding-some-java-packages-in-the-src-while-creating-a-jar-td2641836.htmlAnders strongly discouraged having more than one package per project. However, I have a Maven conceptual doubt regarding this and thought you might be able to help. I have a webapp project in the format: -Parent --ModuleServices --ModulePersistence --ModuleWeb Packaging the Parent returns what I am really interested in, the .WAR file returned from the ModuleWeb. However, I do need more than one WAR: two for the client (one with a test profile, with some test configuration strings like test-db and that returns a myproject-test.war; and another myproject.war which will be the production environment). Both will be installed on the same machine. Now, in addition to this, you also might see that these .war will be specific to a particular client (it's his db, his credentials..). Until I saw this post, I had different maven profiles (these 2 plus a development one) and my only doubt was which profile will be active when I deploy the maven artifact?). Now it got me thinking: should I have one project per profile instead? Although I follow your logic, this approach seems cumbersome and I'm not even sure how I'd implement it. Can you share your thoughts on how the best Maven approach would be? Thank you for your help, Miguel Almeida
Re: One project per package or multiple packages in same project?
On Tue, Jan 25, 2011 at 11:18 AM, Antonio Petrelli antonio.petre...@gmail.com wrote: No, he means (correct me if I am wrong) that you should have a war for each web application you have. Since you have *one* web application, one war is ok. Configuration like IP addresses, ports, etc. should be externalized and not put in the WAR at all. Externalised where exaclty? Because that's precisely my configuration: I have one WAR and configuration is being externalised to profiles, like so: profile iddev/id properties isDevelopmentModetrue/isDevelopmentMode hibernate.connection.urljdbc:postgresql://locahost/develomentDB/hibernate.connection.url application.uploadPath/mnt/devel//application.uploadPath ... /properties /profile My original questions were, therefore: a) is this the best way to keep my project? b) when I package the WAR, what profile should I use? Or should I archive project-0.0.1-dev, project-0.0.1-clientTest, project-0.0.1-clientProduction ?
Re: One project per package or multiple packages in same project?
Anders,
I think I understand what you mean, but it doesn't seem to be very different
from the current approach.
On Tue, Jan 25, 2011 at 11:35 AM, Anders Hammar and...@hammar.net wrote:
Antonio is right.
This has been discussed several times. Search the archive for many examples
of doing this, including using JNDI or putting a properties file on the
classpath.
This leads to having, for example, a config-dev.xml, config-prod.xml,
config-clientTest.xml, etc in our code and, if necessary, use a filter to
build only with one of those. I haven't used JNDI much, but it seems more
complex and it might scatter the configuration if you need to put the
configuration outside the app (like in tomcat's configuration file). If one
can use JNDI with a similar approach as before (ie, one config.xml file),
then it's the same case I mentioned.
I understand this would require changes to your code base. Major changes
possibly. But it is the right way to go. Once you have donw this, adding
new
environments is a small task instead of requiring a new build (and breaking
close to everything Maven is about).
What I still am failing to realise is the major problem with putting this
in the profile: building a new environment now is as simple as adding a new
profile in the pom.xml. The only downfall I see is that I now effectively
have eg {log4j.loglevel} in my log4j.properties and the app will fail if I
don't define log4j.loglevel in the properties section of the active profile.
But that seems to also be the case with any other approach: if I don't
define the string in JNDI it will also not work.
Users in the archive suggest a variety of methods, from JNDI to profiles. Is
there any other pitfall I'm not seeing?
profile
iddev/id
properties
isDevelopmentModetrue/isDevelopmentMode
hibernate.connection.urljdbc:postgresql://locahost/develomentDB/hibernate.connection.url
application.uploadPath/mnt/devel//application.uploadPath
...
/properties
/profile
Re: One project per package or multiple packages in same project?
On Tue, Jan 25, 2011 at 12:50 PM, Anders Hammar and...@hammar.net wrote: Ok, I see where we misunderstand each other. What you want to do is to build just one war. This war should not include any environment configuration at all! Environment dependent configuration should be handled outside of the war. Yes, we seem to finally be on the same wavelength! :) One way to do this is to always load config file from the classpath. Every app server/web container (?) provides some conf folder where tou can put your configuration files so that they are added to the classpath. The config file should always be named the same name, regardless of the environment. (How you version control the config files is outside the scope of this discussion. It could be in a scm, in paper form, etc.)) Another way is to read config through JNDI. I agree with you. I'm still quite new to advanced Maven topics so it still seems counter-intuitive to store the config file outside the .war - it adds one extra step of deploy the .xml/config file in the installation, but like Mark pointed out it makes the WAR more independent and more agile to configuration changes. Miguel
One project per package or multiple packages in same project?
Hi, In http://maven.40175.n5.nabble.com/Maven-Problem-in-including-excluding-some-java-packages-in-the-src-while-creating-a-jar-td2641836.htmlAnders strongly discouraged having more than one package per project. However, I have a Maven conceptual doubt regarding this and thought you might be able to help. I have a webapp project in the format: -Parent --ModuleServices --ModulePersistence --ModuleWeb Packaging the Parent returns what I am really interested in, the .WAR file returned from the ModuleWeb. However, I do need more than one WAR: two for the client (one with a test profile, with some test configuration strings like test-db and that returns a myproject-test.war; and another myproject.war which will be the production environment). Both will be installed on the same machine. Now, in addition to this, you also might see that these .war will be specific to a particular client (it's his db, his credentials..). Until I saw this post, I had different maven profiles (these 2 plus a development one) and my only doubt was which profile will be active when I deploy the maven artifact?). Now it got me thinking: should I have one project per profile instead? Although I follow your logic, this approach seems cumbersome and I'm not even sure how I'd implement it. Can you share your thoughts on how the best Maven approach would be? Thank you for your help, Miguel Almeida
