Hi Alexi,
Thanks for clarifying. So what you could do is keep the
applicationContext.xml packaged in your jar and update your war's POM to
use the "dependency:unpack" mojo to copy it to the right location to be
included in your war.
The dependency plugin page has an example of unpacking specific artifacts:
http://maven.apache.org/plugins/maven-dependency-plugin/examples/unpacking-artifacts.html
The end result is that the war classpath will have two
applicationContext.xml files, but the one packaged in the war *should*
resolve before the one in the jar allowing you to make tweaks to it to
change the behavior. This assumes that you are loading the Spring
context from the classpath (eg. "classpath:/applicationContext.xml").
I've not tried this before so can't give you specific examples, but
hopefully this points you to a solution that works.
Joe Hindsley
apolenur wrote:
Hi Joe,
Thanks for spending your time and share your experience.
I don't think that solution you are proposing will work in our context.
I see 2 issues with approach you are proposing
1. I have to maintain 2 copies of applicationContext.xml one in WAR and one
in JAR (for testing).
2. My JAR is really an independent module which can be used in WAR as well
as in other environment.The content of applicationContext.xml from JAR just
used by Java code in my jar, it is never directly loaded or used by java
code in my WAR. The combination of jar and applicationContext.xml really
forms an independent module - jar has classes and applicationContext.xml has
configuration for them. Thus I really like to maintain
applicationContext.xml withing my jar module src tree and then deploy it
together with jar into what ever environment which need to use services from
my jar.
Joe Hindsley wrote:
Hi Alexi,
The way we've done this is to package the applicationContext.xml in the
war - not in the jar. You can do this by adding it to the war's
src/main/resources directory. In order to run unit tests in the jar
module, we have added an applicationContext.xml in the jar's
src/test/resources directory.
Keeping the applicationContext.xml out of the jar will help keep weird
class path issues from cropping up if you try to 'override' it. Plus, we
feel like it's the top most package's responsibility to configure the
spring environment. There's probably a better way to do it, so hope that
others will chime in with their ideas as well.
One other suggestion is to use JNDI to supply your DataSource instead of
having a jndi.properties file. This way you don't have to unpack the war
to make configuration changes - they'll be part of the container's
configuration. The more you can delegate to the container the less you
have to fiddle with at deployment time.
Hope this helps,
Joe Hindsley
Alexi Polenur wrote:
Hi all,
I am trying to setup a multi-module project. One module produce a JAR
(jar-module) and another one a WAR which uses jar produced by
"jar-module".
jar-modules has some configuration files - Spring xml and .property
files.
Rather then package them as part of the jar I wanted to deploy them into
WEB-INF/classes directory of the war, to allow end user easy
customization.
I am new to Maven and wondering what is the best way to do it.
First thing which comes to my mind is following.
1. Make jar module produce additional artifacts, let say jdbc.properties
and
applicationContext.xml
2. Make WAR module depend not only on jar but also on additional
artifacts
above.
3. Somehow configure WAR module build process to get this artifacts from
repository and install them into WEB-INF/classes of the war file.
Is it right approach or there is better, simpler approach.
If it is right approach can somebody point me in direction of how to
achieve
it. Such as how I install additional artifacts in 1. above and then how I
do
3.
Thanks, Alexi
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
