I don't think my team will react nicely if I tell them that in order to
have all the maven niceties we have to buy and run oracle app server or
have half a dozen instances of tomcat running on our servers.
Is this what people commonly do with maven built wars?
What I am trying to figure out is rote for a lot of people out there. I
just can't get my pea-sized brain to come up with a palatable solution.
-----Original Message-----
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent: Friday, June 02, 2006 10:49 AM
To: Maven Users List
Subject: Re: REPOST: [M2] external config of artifact and dependencies
One suggestion would be to use an app server that allows instancing of
webapps.
We run Oracle App Server, and each webapp is deployed to its own OC4J
instance. Each OC4J instance has its own full directory structure
which allows us to copy things like log4j.properties files and other
configuration files into specific webapp directories. So webapp1 has
its own webapp1/shared/classes type directory and webapp2 has
webapp2/shared/classes. They run in completely separated memory so
there is no issue of one app accessing the other's log4 configuration
file.
In Tomcat, you could do this too, but you'd be to run individual
Tomcat instances for each webapp.
This would allow you to maintain a single "build" of your code with
different configurations for each deployment.
Wayne
On 6/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
Sorry - about the repost, but my 10 month old daughter has taught me
that the crying wheel gets fed . . . or something like that.
Let's say I am working on a web application.
This application is a maven project configured as a war. During its
lifecycle this application will be deployed on:
- developer workstations
- testing environment
- production environment
This project has a dependency on log4j.
At runtime, my application code is configured to pull properties files
with configuration information from a well-known JNDI location. The
prop file will include environment specific settings. At deployment
time, the engineer responsible for generating the war will, if
necessary, also update the prop file (or individual properties) in the
JNDI tree.
log4j however, looks for its configuration file on the classpath at
application initialization. Although you can configure log4j
programmatically, that probably isn't a great idea. log4j is
configured
differently for each target environment. E.g. Developers will change
settings based on what they are currently working on, the testing
environment is set to DEBUG while production is set to WARN.
I don't want to filter the log4j configuration file when I package the
artifact. Doing so would place environment specific settings in the
archive, compromising its value. I can't use JNDI to configure log4j.
So that seems to leave "adding it to the classpath" as the only viable
option. Our app servers are tomcat 5.x. Although I have the option
to
drop the log4 files in <TomcatRoot>/shared/classes, that is the
nuclear
bomb of config. Doing so may impact other web applications, if they
don't have their own version of the resource locally. Moreover, it
can
only be done for a single application - I can't have two different
log4j.properties files in the shared/classes dir.
So now I have to alter the exploded web application directory after it
is installed and add the log4j.properties file.
That seems like a great deal of work and a kludge . . . what am I
missing here?
-----Original Message-----
From: Fernandez, Carlos
Sent: Thursday, June 01, 2006 10:49 AM
To: users@maven.apache.org
Subject: RE: [M2] questions about migrating to maven
Carlos,
EXTERNAL CONFIGURATION OF AN ARTIFACT AND DEPENDENCIES
Sorry for belaboring this point - but I tend to think better in
concrete
terms. Let me walk through a scenario just to make sure I understand
this.
Let's say I am working on a web application.
This application is a maven project configured as a war. During its
lifecycle this application will be deployed on:
- developer workstations
- testing environment
- production environment
This project has a dependency on log4j.
At runtime, my application code is configured to pull properties files
with configuration information from a well-known JNDI location. The
prop file will include environment specific settings. At deployment
time, the engineer responsible for generating the war will, if
necessary, also update the prop file (or individual properties) in the
JNDI tree.
log4j however, looks for its configuration file on the classpath at
application initialization. Although you can configure log4j
programmatically, that probably isn't a great idea. log4j is
configured
differently for each target environment. E.g. Developers will change
settings based on what they are currently working on, the testing
environment is set to DEBUG while production is set to WARN.
I don't want to filter the log4j configuration file when I package the
artifact. Doing so would place environment specific settings in the
archive, compromising its value. I can't use JNDI to configure log4j.
So that seems to leave "adding it to the classpath" as the only viable
option. Our app servers are tomcat 5.x. Although I have the option
to
drop the log4 files in <TomcatRoot>/shared/classes, that is the
nuclear
bomb of config. Doing so may impact other web applications, if they
don't have their own version of the resource locally. Moreover, it
can
only be done for a single application - I can't have two different
log4j.properties files in the shared/classes dir.
So now I have to alter the exploded web application directory after it
is installed and add the log4j.properties file.
That seems like a great deal of work and a kludge . . . what am I
missing here?
BTW - My father's family is from Galicia, with a lot of them living in
a
coruna. My parents have been a few times and have loved each and
every
trip. I hope to visit with my wife and daughter soon, and see a bit
of
the "old country" ;)
Carlos
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Carlos
Sanchez
Sent: Tuesday, May 30, 2006 12:50 PM
To: Maven Users List
Subject: Re: [M2] questions about migrating to maven
On 5/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
Carlos,
--> re FILTERING PROPERTIES FILES FOR ENVIRONMENTS
My suggestion is to externalie that configuration options in a way
that your artifact is always the same, and only configuration
changes.
You can do reading your config files from the classpath or better
using JNDI.
++++++++++++++++++++
Sorry to harp on this, but I think I am having trouble thinking
beyond
the way I have used ant the past few years.
100% of the differences between the developer workstation,
pre-production and production builds on my various projects are
isolated
into properties files. These are then pulled into Spring as
classpath
resources.
If I understand you correctly, you are suggesting that the project
artifacts, wars and jars alike, should not include these properties
files. These files should either:
- be accessed as classpath resource. Presumably some other
build/release process would deposit them on the classpath, or they
would
be added to the container's classpath at startup.
- accessed via JNDI. The JNDI entries would either be name/value
pairs,
the properties files themselves or a combo. When the war is
deployed,
part of the deployment process would be to configure the JNDI tree.
Is this correct?
Yes, that way you don't need different artifacts for each environment,
reducing the risks.
If you still want to do that you can use profiles to include/exclude
properties files in the jar, chnging the finalName so they are named
differently. I encourage the other option, but still you can do it
this way.
--> re INTER-PROJECT DEPENDENCIES
--> With maven the best way is not to rebuild all your dependencies
every
time, but to depend on the binaries generated by the other projects
as
SNAPSHOTs.
If I can get past the environment configuration step - then I
suspect
that this would no longer be an issue. Each artifact would be
generic
and just as relevant on a developers workstation as it will be in
production.
Carlos
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Carlos
Sanchez
Sent: Sunday, May 28, 2006 2:09 PM
To: Maven Users List
Subject: Re: [M2] questions about migrating to maven
Hi Carlos,
re FILTERING PROPERTIES FILES FOR ENVIRONMENTS
I usually don't like this approach for the inconvinients you
mention,
you need to rebuild your artifacts for each environments, which is
usually prone to errors, you test x-dev in your machine, and then
build x-prod for production, with no guarantees that it's the same
stuff you tested.
My suggestion is to externalie that configuration options in a way
that your artifact is always the same, and only configuration
changes.
You can do reading your config files from the classpath or better
using JNDI. You can also have dev config as default so your
developers
don't have to setup anything and you do it only in prod or preprod.
re INTER-PROJECT DEPENDENCIES
With maven the best way is not to rebuild all your dependencies
every
time, but to depend on the binaries generated by the other projects
as
SNAPSHOTs. You can ensure the repo has the latest snapshot by
setting
up continuum to deploy everytime somebody changes the project. That
way developers don't have to go through the extra time consuming
process of building the dependencies.
Regards
Carlos
On 5/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
I am pretty sure that I am over thinking this ;) However, I am
having
trouble thinking how best to migrate our ant based build process
to
maven. Principally:
- Filtering properties files for environments, and
- Inter-project dependencies
FILTERING PROPERTIES FILES FOR ENVIRONMENTS
As with most projects, our apps use properties files for
configuring
a
host of settings. Many of these (e.g. db settings, log4j
settings,
web
service host:port etc) are environment specific. Our projects
have
properties files for various target environments, such as
production,
pre-production, cruisecontrol. Each developer also has a local
props
file that they can tailor for their particular needs (e.g. for
debugging
you may want to log springframework as DEBUG and suppress all
others).
Ant uses these files to filter the application properties. The
result
is a build tailored for a particular environment. Since all
environment
specific properties, beside the local, are source controlled we
have
a
high degree of confidence in consistent and reproducible builds to
our
shared infrastructure.
In maven I have been able to reproduce this behavior with
profiles.
However, I am not sure what to do with the resulting artifacts.
Each
artifact is "tainted" with environment specific properties.
Should artifacts generated with "local" only be installed in each
developers local repository? What about the artifacts for the
testing
and production environments? Should the internal repository only
be
used to store "production" artifacts? Should there be multiple
shared
internal repositories, one for production and one for pre-prod?
INTER-PROJECT DEPENDENCIES
Currently we have a web based application broken out into four
projects:
1 - user-presentation-layer
2 - admin-presentation-layer
3 - web-service-layer
4 - common-utils
Each project generates a primary artifact, and the
web-service-layer
also generates a client jar.
Currently in order to generate a fresh build of say the
user-presentation-layer, you must have the web-service-layer and
common-utils checked out in your workspace. The ant build file
for
the
user-presentation-layer will end up calling the other two build
files.
These builds in turn, get an update from cvs and then generating
the
appropriate artifact. Granted it took some time to get this
process
up
and running, but it currently works and works pretty well.
From my readings, it seems that this process is frowned upon.
With
maven, the appropriate process would be to "mvn scm:update
install"
on
the web-service-layer and common-utils projects. Then run the
build
for
the user-presentation-layer.
Or better yet, have each user pull the dependencies
(web-service-layer
and common-utils) from an internal repository that is updated by
developers checking in changes or by some source control
repository.
However, as noted above, because of environmental impacts, I am
not
sure
a shared repository would work for artifacts used in development.
Currently, our environment profiles only effect configuration
settings.
They do not modify or impact the source code directly. While the
maven
dependencies are a result of class dependencies, which should not
be
impacted by using an artifact configured for "production" versus
one
configured for "preproduction".
What is the best way to handle this problem?
I am sure people much smarter than myself have already tackled
these
problems and come up with very simple solutions.
Any and all help sorting myself out would be really appreciated!
Carlos
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
