REPOST: [M2] external config of artifact and dependencies

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

REPOST: [M2] external config of artifact and dependencies

Carlos.Fernandez
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: [hidden email]
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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                              -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REPOST: [M2] external config of artifact and dependencies

Tim Kettler
Hi,

you can define different profiles for the environments you deploy to in your pom. In these
profiles you can then define resource locations to pull the config files from.

-Tim

[hidden email] schrieb:

> 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: [hidden email]
> 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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
> 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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> --
>> I could give you my word as a Spaniard.
>> No good. I've known too many Spaniards.
>>                              -- The Princess Bride
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REPOST: [M2] external config of artifact and dependencies

Wayne Fay
In reply to this post by Carlos.Fernandez
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, [hidden email] <[hidden email]> 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: [hidden email]
> 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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
> 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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
> > 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                              -- The Princess Bride
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                             -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: REPOST: [M2] external config of artifact and dependencies

Carlos.Fernandez
In reply to this post by Carlos.Fernandez
Are you referring to using profiles to filter properties files or
otherwise tailor the build and resulting artifact to a particular
environment?

If that is your suggestion, I have some issues with that.

In filtering the configuration information, you generate an artifact,
such as a war or ear, that is tailored for an environment.  Doesn't that
compromise the utility of the artifact?

Don't you need to be careful about where you install that artifact?
Should artifacts generated with "local" only be installed in each
developer's 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?  It
seems that this can also significantly muddy dependency management.

This is why external configuration was suggested.  Which I can clearly
see working well for the application code I write.  My code can be
written to work just as well accessing properties via JNDI as it can be
written to access props files on the classpath.  However, what do I do
with dependencies that expect their configuration settings to be on the
classpath - such as log4j.

This seems to be less of an issue for the jars that my projects
generally produce.  These tend to either be common utilities or client
jars.  None of these are intended to be packaged with any configuration
information - it is the responsibility of the application using these
resources to configure them.  Just as you would with log4j.

I suspect I am just spinning myself out of control on this issue.


-----Original Message-----
From: Tim Kettler [mailto:[hidden email]]
Sent: Friday, June 02, 2006 10:45 AM
To: Maven Users List
Subject: Re: REPOST: [M2] external config of artifact and dependencies

Hi,

you can define different profiles for the environments you deploy to in
your pom. In these
profiles you can then define resource locations to pull the config files
from.

-Tim

[hidden email] schrieb:

> 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: [hidden email]
> 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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
> 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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> --
>> I could give you my word as a Spaniard.
>> No good. I've known too many Spaniards.
>>                              -- The Princess Bride
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: REPOST: [M2] external config of artifact and dependencies

Carlos.Fernandez
In reply to this post by Carlos.Fernandez
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:[hidden email]]
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, [hidden email] <[hidden email]>
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: [hidden email]
> 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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
> 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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
> > 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                              -- The Princess Bride
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> >
---------------------------------------------------------------------

> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                             -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REPOST: [M2] external config of artifact and dependencies

Kris Nuttycombe
Out of curiosity, why is programmatically configuring log4j (say in a
servlet context listener) not a great idea?

Kris

[hidden email] wrote:

>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:[hidden email]]
>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, [hidden email] <[hidden email]>
>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: [hidden email]
>>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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
>>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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
>>>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: [hidden email]
>>>>For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>        
>>>>
>>>--
>>>I could give you my word as a Spaniard.
>>>No good. I've known too many Spaniards.
>>>                             -- The Princess Bride
>>>
>>>
>>>      
>>>
>---------------------------------------------------------------------
>  
>
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>>      
>>>
>---------------------------------------------------------------------
>  
>
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>>      
>>>
>>--
>>I could give you my word as a Spaniard.
>>No good. I've known too many Spaniards.
>>                            -- The Princess Bride
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>>    
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: REPOST: [M2] external config of artifact and dependencies

Carlos.Fernandez
In reply to this post by Carlos.Fernandez
It is more work than writing a properties file.

Also, I am lazy.

Which is probably why I want to use maven on my projects.

Carlos

-----Original Message-----
From: Kris Nuttycombe [mailto:[hidden email]]
Sent: Friday, June 02, 2006 11:51 AM
To: Maven Users List
Subject: Re: REPOST: [M2] external config of artifact and dependencies

Out of curiosity, why is programmatically configuring log4j (say in a
servlet context listener) not a great idea?

Kris

[hidden email] wrote:

>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:[hidden email]]
>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, [hidden email] <[hidden email]>
>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: [hidden email]
>>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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
>>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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
>>>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: [hidden email]
>>>>For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>        
>>>>
>>>--
>>>I could give you my word as a Spaniard.
>>>No good. I've known too many Spaniards.
>>>                             -- The Princess Bride
>>>
>>>
>>>      
>>>
>---------------------------------------------------------------------
>  
>
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>>      
>>>
>---------------------------------------------------------------------
>  
>
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>>      
>>>
>>--
>>I could give you my word as a Spaniard.
>>No good. I've known too many Spaniards.
>>                            -- The Princess Bride
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>>    
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REPOST: [M2] external config of artifact and dependencies

Kris Nuttycombe
I'm not talking about manually setting up the appenders, etc - I'm just
talking about configuring log4j from a properties file that can vary by
the deployment environment (i.e, be called something other than
log4j.properties.)

I have a somewhat similar issue to what you have, except that I use the
log4j xml dialect for configuration and consequently have to run
DOMConfigurator.configure(...) on application startup. It seems to me
that you could do something similar - you still get to configure by a
properties instance, but this instance is then selectable at runtime
(and potentially pulled from JNDI.)

Kris

[hidden email] wrote:

>It is more work than writing a properties file.
>
>Also, I am lazy.
>
>Which is probably why I want to use maven on my projects.
>
>Carlos
>
>-----Original Message-----
>From: Kris Nuttycombe [mailto:[hidden email]]
>Sent: Friday, June 02, 2006 11:51 AM
>To: Maven Users List
>Subject: Re: REPOST: [M2] external config of artifact and dependencies
>
>Out of curiosity, why is programmatically configuring log4j (say in a
>servlet context listener) not a great idea?
>
>Kris
>
>[hidden email] wrote:
>
>  
>
>>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:[hidden email]]
>>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, [hidden email] <[hidden email]>
>>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: [hidden email]
>>>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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
>>>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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
>>>>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: [hidden email]
>>>>>For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>>      
>>>>>
>>>>>          
>>>>>
>>>>--
>>>>I could give you my word as a Spaniard.
>>>>No good. I've known too many Spaniards.
>>>>                            -- The Princess Bride
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>---------------------------------------------------------------------
>>
>>
>>    
>>
>>>>To unsubscribe, e-mail: [hidden email]
>>>>For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>---------------------------------------------------------------------
>>
>>
>>    
>>
>>>>To unsubscribe, e-mail: [hidden email]
>>>>For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>--
>>>I could give you my word as a Spaniard.
>>>No good. I've known too many Spaniards.
>>>                           -- The Princess Bride
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>>  
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>>
>>    
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: REPOST: [M2] external config of artifact and dependencies

Carlos.Fernandez
In reply to this post by Carlos.Fernandez
Although I could do this for log4j - what about other 3rd party
frameworks that use classpath resources for configuration.  Log4j was
just kind of a stand-in for a more general condition.

Do you end up having to spool up and configure all of those resources
programmatically in order to externalize configuration?

-> I have a somewhat similar issue to what you have.

Can you elaborate?  This might help my small brain think outside of the
ant shaped box it is current encased in.

Carlos

-----Original Message-----
From: Kris Nuttycombe [mailto:[hidden email]]
Sent: Friday, June 02, 2006 12:35 PM
To: Maven Users List
Subject: Re: REPOST: [M2] external config of artifact and dependencies

I'm not talking about manually setting up the appenders, etc - I'm just
talking about configuring log4j from a properties file that can vary by
the deployment environment (i.e, be called something other than
log4j.properties.)

I have a somewhat similar issue to what you have, except that I use the
log4j xml dialect for configuration and consequently have to run
DOMConfigurator.configure(...) on application startup. It seems to me
that you could do something similar - you still get to configure by a
properties instance, but this instance is then selectable at runtime
(and potentially pulled from JNDI.)

Kris

[hidden email] wrote:

>It is more work than writing a properties file.
>
>Also, I am lazy.
>
>Which is probably why I want to use maven on my projects.
>
>Carlos
>
>-----Original Message-----
>From: Kris Nuttycombe [mailto:[hidden email]]
>Sent: Friday, June 02, 2006 11:51 AM
>To: Maven Users List
>Subject: Re: REPOST: [M2] external config of artifact and dependencies
>
>Out of curiosity, why is programmatically configuring log4j (say in a
>servlet context listener) not a great idea?
>
>Kris
>
>[hidden email] wrote:
>
>  
>
>>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:[hidden email]]
>>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, [hidden email] <[hidden email]>
>>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: [hidden email]
>>>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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
>>>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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
>>>>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: [hidden email]
>>>>>For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>>      
>>>>>
>>>>>          
>>>>>
>>>>--
>>>>I could give you my word as a Spaniard.
>>>>No good. I've known too many Spaniards.
>>>>                            -- The Princess Bride
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>---------------------------------------------------------------------
>>
>>
>>    
>>
>>>>To unsubscribe, e-mail: [hidden email]
>>>>For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>---------------------------------------------------------------------
>>
>>
>>    
>>
>>>>To unsubscribe, e-mail: [hidden email]
>>>>For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>--
>>>I could give you my word as a Spaniard.
>>>No good. I've known too many Spaniards.
>>>                           -- The Princess Bride
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>>  
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>>
>>    
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REPOST: [M2] external config of artifact and dependencies

Wayne Fay
How do you handle this in ant? Assuming of course that you're coming
from ant, and that you've previously solved this problem.

Wayne

On 6/2/06, [hidden email] <[hidden email]> wrote:

> Although I could do this for log4j - what about other 3rd party
> frameworks that use classpath resources for configuration.  Log4j was
> just kind of a stand-in for a more general condition.
>
> Do you end up having to spool up and configure all of those resources
> programmatically in order to externalize configuration?
>
> -> I have a somewhat similar issue to what you have.
>
> Can you elaborate?  This might help my small brain think outside of the
> ant shaped box it is current encased in.
>
> Carlos
>
> -----Original Message-----
> From: Kris Nuttycombe [mailto:[hidden email]]
> Sent: Friday, June 02, 2006 12:35 PM
> To: Maven Users List
> Subject: Re: REPOST: [M2] external config of artifact and dependencies
>
> I'm not talking about manually setting up the appenders, etc - I'm just
> talking about configuring log4j from a properties file that can vary by
> the deployment environment (i.e, be called something other than
> log4j.properties.)
>
> I have a somewhat similar issue to what you have, except that I use the
> log4j xml dialect for configuration and consequently have to run
> DOMConfigurator.configure(...) on application startup. It seems to me
> that you could do something similar - you still get to configure by a
> properties instance, but this instance is then selectable at runtime
> (and potentially pulled from JNDI.)
>
> Kris
>
> [hidden email] wrote:
>
> >It is more work than writing a properties file.
> >
> >Also, I am lazy.
> >
> >Which is probably why I want to use maven on my projects.
> >
> >Carlos
> >
> >-----Original Message-----
> >From: Kris Nuttycombe [mailto:[hidden email]]
> >Sent: Friday, June 02, 2006 11:51 AM
> >To: Maven Users List
> >Subject: Re: REPOST: [M2] external config of artifact and dependencies
> >
> >Out of curiosity, why is programmatically configuring log4j (say in a
> >servlet context listener) not a great idea?
> >
> >Kris
> >
> >[hidden email] wrote:
> >
> >
> >
> >>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:[hidden email]]
> >>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, [hidden email] <[hidden email]>
> >>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: [hidden email]
> >>>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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
> >>>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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
> >>>>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: [hidden email]
> >>>>>For additional commands, e-mail: [hidden email]
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>--
> >>>>I could give you my word as a Spaniard.
> >>>>No good. I've known too many Spaniards.
> >>>>                            -- The Princess Bride
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>---------------------------------------------------------------------
> >>
> >>
> >>
> >>
> >>>>To unsubscribe, e-mail: [hidden email]
> >>>>For additional commands, e-mail: [hidden email]
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>---------------------------------------------------------------------
> >>
> >>
> >>
> >>
> >>>>To unsubscribe, e-mail: [hidden email]
> >>>>For additional commands, e-mail: [hidden email]
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>--
> >>>I could give you my word as a Spaniard.
> >>>No good. I've known too many Spaniards.
> >>>                           -- The Princess Bride
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: [hidden email]
> >>>For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: [hidden email]
> >>>For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: [hidden email]
> >>>For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [hidden email]
> >>For additional commands, e-mail: [hidden email]
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [hidden email]
> >>For additional commands, e-mail: [hidden email]
> >>
> >>
> >>
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [hidden email]
> >For additional commands, e-mail: [hidden email]
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [hidden email]
> >For additional commands, e-mail: [hidden email]
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REPOST: [M2] external config of artifact and dependencies

Carlos Sanchez-4
My suggestion is, include ALL the properties files and in your code
look for a system property to choose one. If it's not present you can
default to dev environment or fail, whatever you want.

Then you just have to run your server with that property -Denv=prod

That's it

On 6/2/06, Wayne Fay <[hidden email]> wrote:

> How do you handle this in ant? Assuming of course that you're coming
> from ant, and that you've previously solved this problem.
>
> Wayne
>
> On 6/2/06, [hidden email] <[hidden email]> wrote:
> > Although I could do this for log4j - what about other 3rd party
> > frameworks that use classpath resources for configuration.  Log4j was
> > just kind of a stand-in for a more general condition.
> >
> > Do you end up having to spool up and configure all of those resources
> > programmatically in order to externalize configuration?
> >
> > -> I have a somewhat similar issue to what you have.
> >
> > Can you elaborate?  This might help my small brain think outside of the
> > ant shaped box it is current encased in.
> >
> > Carlos
> >
> > -----Original Message-----
> > From: Kris Nuttycombe [mailto:[hidden email]]
> > Sent: Friday, June 02, 2006 12:35 PM
> > To: Maven Users List
> > Subject: Re: REPOST: [M2] external config of artifact and dependencies
> >
> > I'm not talking about manually setting up the appenders, etc - I'm just
> > talking about configuring log4j from a properties file that can vary by
> > the deployment environment (i.e, be called something other than
> > log4j.properties.)
> >
> > I have a somewhat similar issue to what you have, except that I use the
> > log4j xml dialect for configuration and consequently have to run
> > DOMConfigurator.configure(...) on application startup. It seems to me
> > that you could do something similar - you still get to configure by a
> > properties instance, but this instance is then selectable at runtime
> > (and potentially pulled from JNDI.)
> >
> > Kris
> >
> > [hidden email] wrote:
> >
> > >It is more work than writing a properties file.
> > >
> > >Also, I am lazy.
> > >
> > >Which is probably why I want to use maven on my projects.
> > >
> > >Carlos
> > >
> > >-----Original Message-----
> > >From: Kris Nuttycombe [mailto:[hidden email]]
> > >Sent: Friday, June 02, 2006 11:51 AM
> > >To: Maven Users List
> > >Subject: Re: REPOST: [M2] external config of artifact and dependencies
> > >
> > >Out of curiosity, why is programmatically configuring log4j (say in a
> > >servlet context listener) not a great idea?
> > >
> > >Kris
> > >
> > >[hidden email] wrote:
> > >
> > >
> > >
> > >>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:[hidden email]]
> > >>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, [hidden email] <[hidden email]>
> > >>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: [hidden email]
> > >>>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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
> > >>>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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
> > >>>>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: [hidden email]
> > >>>>>For additional commands, e-mail: [hidden email]
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>--
> > >>>>I could give you my word as a Spaniard.
> > >>>>No good. I've known too many Spaniards.
> > >>>>                            -- The Princess Bride
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>---------------------------------------------------------------------
> > >>
> > >>
> > >>
> > >>
> > >>>>To unsubscribe, e-mail: [hidden email]
> > >>>>For additional commands, e-mail: [hidden email]
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>---------------------------------------------------------------------
> > >>
> > >>
> > >>
> > >>
> > >>>>To unsubscribe, e-mail: [hidden email]
> > >>>>For additional commands, e-mail: [hidden email]
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>--
> > >>>I could give you my word as a Spaniard.
> > >>>No good. I've known too many Spaniards.
> > >>>                           -- The Princess Bride
> > >>>
> > >>>---------------------------------------------------------------------
> > >>>To unsubscribe, e-mail: [hidden email]
> > >>>For additional commands, e-mail: [hidden email]
> > >>>
> > >>>
> > >>>---------------------------------------------------------------------
> > >>>To unsubscribe, e-mail: [hidden email]
> > >>>For additional commands, e-mail: [hidden email]
> > >>>
> > >>>
> > >>>---------------------------------------------------------------------
> > >>>To unsubscribe, e-mail: [hidden email]
> > >>>For additional commands, e-mail: [hidden email]
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>---------------------------------------------------------------------
> > >>To unsubscribe, e-mail: [hidden email]
> > >>For additional commands, e-mail: [hidden email]
> > >>
> > >>
> > >>---------------------------------------------------------------------
> > >>To unsubscribe, e-mail: [hidden email]
> > >>For additional commands, e-mail: [hidden email]
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: [hidden email]
> > >For additional commands, e-mail: [hidden email]
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: [hidden email]
> > >For additional commands, e-mail: [hidden email]
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REPOST: [M2] external config of artifact and dependencies

Carlos Sanchez-4
I didn't see the log4j part.

That looks more like a log4j question. IIRC there's a web.xml config
option that specify the path of the configuration. Maybe I saw that in
spring utilities.

SLF4J facade may also help you, http://www.slf4j.org/

On 6/2/06, Carlos Sanchez <[hidden email]> wrote:

> My suggestion is, include ALL the properties files and in your code
> look for a system property to choose one. If it's not present you can
> default to dev environment or fail, whatever you want.
>
> Then you just have to run your server with that property -Denv=prod
>
> That's it
>
> On 6/2/06, Wayne Fay <[hidden email]> wrote:
> > How do you handle this in ant? Assuming of course that you're coming
> > from ant, and that you've previously solved this problem.
> >
> > Wayne
> >
> > On 6/2/06, [hidden email] <[hidden email]> wrote:
> > > Although I could do this for log4j - what about other 3rd party
> > > frameworks that use classpath resources for configuration.  Log4j was
> > > just kind of a stand-in for a more general condition.
> > >
> > > Do you end up having to spool up and configure all of those resources
> > > programmatically in order to externalize configuration?
> > >
> > > -> I have a somewhat similar issue to what you have.
> > >
> > > Can you elaborate?  This might help my small brain think outside of the
> > > ant shaped box it is current encased in.
> > >
> > > Carlos
> > >
> > > -----Original Message-----
> > > From: Kris Nuttycombe [mailto:[hidden email]]
> > > Sent: Friday, June 02, 2006 12:35 PM
> > > To: Maven Users List
> > > Subject: Re: REPOST: [M2] external config of artifact and dependencies
> > >
> > > I'm not talking about manually setting up the appenders, etc - I'm just
> > > talking about configuring log4j from a properties file that can vary by
> > > the deployment environment (i.e, be called something other than
> > > log4j.properties.)
> > >
> > > I have a somewhat similar issue to what you have, except that I use the
> > > log4j xml dialect for configuration and consequently have to run
> > > DOMConfigurator.configure(...) on application startup. It seems to me
> > > that you could do something similar - you still get to configure by a
> > > properties instance, but this instance is then selectable at runtime
> > > (and potentially pulled from JNDI.)
> > >
> > > Kris
> > >
> > > [hidden email] wrote:
> > >
> > > >It is more work than writing a properties file.
> > > >
> > > >Also, I am lazy.
> > > >
> > > >Which is probably why I want to use maven on my projects.
> > > >
> > > >Carlos
> > > >
> > > >-----Original Message-----
> > > >From: Kris Nuttycombe [mailto:[hidden email]]
> > > >Sent: Friday, June 02, 2006 11:51 AM
> > > >To: Maven Users List
> > > >Subject: Re: REPOST: [M2] external config of artifact and dependencies
> > > >
> > > >Out of curiosity, why is programmatically configuring log4j (say in a
> > > >servlet context listener) not a great idea?
> > > >
> > > >Kris
> > > >
> > > >[hidden email] wrote:
> > > >
> > > >
> > > >
> > > >>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:[hidden email]]
> > > >>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, [hidden email] <[hidden email]>
> > > >>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: [hidden email]
> > > >>>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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
> > > >>>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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
> > > >>>>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: [hidden email]
> > > >>>>>For additional commands, e-mail: [hidden email]
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>--
> > > >>>>I could give you my word as a Spaniard.
> > > >>>>No good. I've known too many Spaniards.
> > > >>>>                            -- The Princess Bride
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>---------------------------------------------------------------------
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>>>To unsubscribe, e-mail: [hidden email]
> > > >>>>For additional commands, e-mail: [hidden email]
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>---------------------------------------------------------------------
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>>>To unsubscribe, e-mail: [hidden email]
> > > >>>>For additional commands, e-mail: [hidden email]
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>--
> > > >>>I could give you my word as a Spaniard.
> > > >>>No good. I've known too many Spaniards.
> > > >>>                           -- The Princess Bride
> > > >>>
> > > >>>---------------------------------------------------------------------
> > > >>>To unsubscribe, e-mail: [hidden email]
> > > >>>For additional commands, e-mail: [hidden email]
> > > >>>
> > > >>>
> > > >>>---------------------------------------------------------------------
> > > >>>To unsubscribe, e-mail: [hidden email]
> > > >>>For additional commands, e-mail: [hidden email]
> > > >>>
> > > >>>
> > > >>>---------------------------------------------------------------------
> > > >>>To unsubscribe, e-mail: [hidden email]
> > > >>>For additional commands, e-mail: [hidden email]
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>---------------------------------------------------------------------
> > > >>To unsubscribe, e-mail: [hidden email]
> > > >>For additional commands, e-mail: [hidden email]
> > > >>
> > > >>
> > > >>---------------------------------------------------------------------
> > > >>To unsubscribe, e-mail: [hidden email]
> > > >>For additional commands, e-mail: [hidden email]
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >---------------------------------------------------------------------
> > > >To unsubscribe, e-mail: [hidden email]
> > > >For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > > >---------------------------------------------------------------------
> > > >To unsubscribe, e-mail: [hidden email]
> > > >For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                              -- The Princess Bride
>


--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REPOST: [M2] external config of artifact and dependencies

Wayne Fay
In reply to this post by Carlos Sanchez-4
This is a great suggestion. I'm going to take this approach when JNDI
is not feasible.

Thanks Carlos.

Wayne

On 6/2/06, Carlos Sanchez <[hidden email]> wrote:

> My suggestion is, include ALL the properties files and in your code
> look for a system property to choose one. If it's not present you can
> default to dev environment or fail, whatever you want.
>
> Then you just have to run your server with that property -Denv=prod
>
> That's it
>
> On 6/2/06, Wayne Fay <[hidden email]> wrote:
> > How do you handle this in ant? Assuming of course that you're coming
> > from ant, and that you've previously solved this problem.
> >
> > Wayne
> >
> > On 6/2/06, [hidden email] <[hidden email]> wrote:
> > > Although I could do this for log4j - what about other 3rd party
> > > frameworks that use classpath resources for configuration.  Log4j was
> > > just kind of a stand-in for a more general condition.
> > >
> > > Do you end up having to spool up and configure all of those resources
> > > programmatically in order to externalize configuration?
> > >
> > > -> I have a somewhat similar issue to what you have.
> > >
> > > Can you elaborate?  This might help my small brain think outside of the
> > > ant shaped box it is current encased in.
> > >
> > > Carlos
> > >
> > > -----Original Message-----
> > > From: Kris Nuttycombe [mailto:[hidden email]]
> > > Sent: Friday, June 02, 2006 12:35 PM
> > > To: Maven Users List
> > > Subject: Re: REPOST: [M2] external config of artifact and dependencies
> > >
> > > I'm not talking about manually setting up the appenders, etc - I'm just
> > > talking about configuring log4j from a properties file that can vary by
> > > the deployment environment (i.e, be called something other than
> > > log4j.properties.)
> > >
> > > I have a somewhat similar issue to what you have, except that I use the
> > > log4j xml dialect for configuration and consequently have to run
> > > DOMConfigurator.configure(...) on application startup. It seems to me
> > > that you could do something similar - you still get to configure by a
> > > properties instance, but this instance is then selectable at runtime
> > > (and potentially pulled from JNDI.)
> > >
> > > Kris
> > >
> > > [hidden email] wrote:
> > >
> > > >It is more work than writing a properties file.
> > > >
> > > >Also, I am lazy.
> > > >
> > > >Which is probably why I want to use maven on my projects.
> > > >
> > > >Carlos
> > > >
> > > >-----Original Message-----
> > > >From: Kris Nuttycombe [mailto:[hidden email]]
> > > >Sent: Friday, June 02, 2006 11:51 AM
> > > >To: Maven Users List
> > > >Subject: Re: REPOST: [M2] external config of artifact and dependencies
> > > >
> > > >Out of curiosity, why is programmatically configuring log4j (say in a
> > > >servlet context listener) not a great idea?
> > > >
> > > >Kris
> > > >
> > > >[hidden email] wrote:
> > > >
> > > >
> > > >
> > > >>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:[hidden email]]
> > > >>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, [hidden email] <[hidden email]>
> > > >>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: [hidden email]
> > > >>>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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
> > > >>>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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
> > > >>>>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: [hidden email]
> > > >>>>>For additional commands, e-mail: [hidden email]
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>--
> > > >>>>I could give you my word as a Spaniard.
> > > >>>>No good. I've known too many Spaniards.
> > > >>>>                            -- The Princess Bride
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>---------------------------------------------------------------------
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>>>To unsubscribe, e-mail: [hidden email]
> > > >>>>For additional commands, e-mail: [hidden email]
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>---------------------------------------------------------------------
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>>>To unsubscribe, e-mail: [hidden email]
> > > >>>>For additional commands, e-mail: [hidden email]
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>--
> > > >>>I could give you my word as a Spaniard.
> > > >>>No good. I've known too many Spaniards.
> > > >>>                           -- The Princess Bride
> > > >>>
> > > >>>---------------------------------------------------------------------
> > > >>>To unsubscribe, e-mail: [hidden email]
> > > >>>For additional commands, e-mail: [hidden email]
> > > >>>
> > > >>>
> > > >>>---------------------------------------------------------------------
> > > >>>To unsubscribe, e-mail: [hidden email]
> > > >>>For additional commands, e-mail: [hidden email]
> > > >>>
> > > >>>
> > > >>>---------------------------------------------------------------------
> > > >>>To unsubscribe, e-mail: [hidden email]
> > > >>>For additional commands, e-mail: [hidden email]
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>---------------------------------------------------------------------
> > > >>To unsubscribe, e-mail: [hidden email]
> > > >>For additional commands, e-mail: [hidden email]
> > > >>
> > > >>
> > > >>---------------------------------------------------------------------
> > > >>To unsubscribe, e-mail: [hidden email]
> > > >>For additional commands, e-mail: [hidden email]
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >---------------------------------------------------------------------
> > > >To unsubscribe, e-mail: [hidden email]
> > > >For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > > >---------------------------------------------------------------------
> > > >To unsubscribe, e-mail: [hidden email]
> > > >For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                             -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: REPOST: [M2] external config of artifact and dependencies

Lee Meador-3
In reply to this post by Carlos Sanchez-4
In one situation, I put some log4j settings in a file in the jar or war and
allow putting an override properties file on the classpath. I use the
settings inside the jar to configure log4j and then override the log levels
from the classpath file (if it is there). [You could override whatever suits
your application.]

In this way, when I build for a particular environment, I set the "default"
value of the settings in the file that is in the jar/war. There are many
ways to do this with or without maven.

Only when debugging and such is there a need to override and in that
environment it is easy to add the override values with a properties file on
the classpath.

The disadvantage of this is that there is a short time during startup that
third party libraries may log something before I get everything set up and
overridden. I haven't found it to be a big issue for me.

On 6/2/06, Carlos Sanchez <[hidden email]> wrote:

>
> My suggestion is, include ALL the properties files and in your code
> look for a system property to choose one. If it's not present you can
> default to dev environment or fail, whatever you want.
>
> Then you just have to run your server with that property -Denv=prod
>
> That's it
>
> On 6/2/06, Wayne Fay <[hidden email]> wrote:
> > How do you handle this in ant? Assuming of course that you're coming
> > from ant, and that you've previously solved this problem.
> >
> > Wayne
> >
> > On 6/2/06, [hidden email] <[hidden email]>
> wrote:
> > > Although I could do this for log4j - what about other 3rd party
> > > frameworks that use classpath resources for configuration.  Log4j was
> > > just kind of a stand-in for a more general condition.
> > >
> > > Do you end up having to spool up and configure all of those resources
> > > programmatically in order to externalize configuration?
> > >
> > > -> I have a somewhat similar issue to what you have.
> > >
> > > Can you elaborate?  This might help my small brain think outside of
> the
> > > ant shaped box it is current encased in.
> > >
> > > Carlos
> > >
> > > -----Original Message-----
> > > From: Kris Nuttycombe [mailto:[hidden email]]
> > > Sent: Friday, June 02, 2006 12:35 PM
> > > To: Maven Users List
> > > Subject: Re: REPOST: [M2] external config of artifact and dependencies
> > >
> > > I'm not talking about manually setting up the appenders, etc - I'm
> just
> > > talking about configuring log4j from a properties file that can vary
> by
> > > the deployment environment (i.e, be called something other than
> > > log4j.properties.)
> > >
> > > I have a somewhat similar issue to what you have, except that I use
> the
> > > log4j xml dialect for configuration and consequently have to run
> > > DOMConfigurator.configure(...) on application startup. It seems to me
> > > that you could do something similar - you still get to configure by a
> > > properties instance, but this instance is then selectable at runtime
> > > (and potentially pulled from JNDI.)
> > >
> > > Kris
> > >
> > > [hidden email] wrote:
> > >
> > > >It is more work than writing a properties file.
> > > >
> > > >Also, I am lazy.
> > > >
> > > >Which is probably why I want to use maven on my projects.
> > > >
> > > >Carlos
> > > >
> > > >-----Original Message-----
> > > >From: Kris Nuttycombe [mailto:[hidden email]]
> > > >Sent: Friday, June 02, 2006 11:51 AM
> > > >To: Maven Users List
> > > >Subject: Re: REPOST: [M2] external config of artifact and
> dependencies
> > > >
> > > >Out of curiosity, why is programmatically configuring log4j (say in a
> > > >servlet context listener) not a great idea?
> > > >
> > > >Kris
> > > >
> > > >[hidden email] wrote:
> > > >
> > > >
> > > >
> > > >>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:[hidden email]]
> > > >>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, [hidden email] <[hidden email]>
> > > >>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: [hidden email]
> > > >>>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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]>
> > > >>>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: [hidden email] [mailto:[hidden email]] 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, [hidden email] <[hidden email]
> >
> > > >>>>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: [hidden email]
> > > >>>>>For additional commands, e-mail: [hidden email]
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>--
> > > >>>>I could give you my word as a Spaniard.
> > > >>>>No good. I've known too many Spaniards.
> > > >>>>                            -- The Princess Bride
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > >
> >>---------------------------------------------------------------------
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>>>To unsubscribe, e-mail: [hidden email]
> > > >>>>For additional commands, e-mail: [hidden email]
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > >
> >>---------------------------------------------------------------------
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>>>To unsubscribe, e-mail: [hidden email]
> > > >>>>For additional commands, e-mail: [hidden email]
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>--
> > > >>>I could give you my word as a Spaniard.
> > > >>>No good. I've known too many Spaniards.
> > > >>>                           -- The Princess Bride
> > > >>>
> > >
> >>>---------------------------------------------------------------------
> > > >>>To unsubscribe, e-mail: [hidden email]
> > > >>>For additional commands, e-mail: [hidden email]
> > > >>>
> > > >>>
> > >
> >>>---------------------------------------------------------------------
> > > >>>To unsubscribe, e-mail: [hidden email]
> > > >>>For additional commands, e-mail: [hidden email]
> > > >>>
> > > >>>
> > >
> >>>---------------------------------------------------------------------
> > > >>>To unsubscribe, e-mail: [hidden email]
> > > >>>For additional commands, e-mail: [hidden email]
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > >
> >>---------------------------------------------------------------------
> > > >>To unsubscribe, e-mail: [hidden email]
> > > >>For additional commands, e-mail: [hidden email]
> > > >>
> > > >>
> > >
> >>---------------------------------------------------------------------
> > > >>To unsubscribe, e-mail: [hidden email]
> > > >>For additional commands, e-mail: [hidden email]
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >---------------------------------------------------------------------
> > > >To unsubscribe, e-mail: [hidden email]
> > > >For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > > >---------------------------------------------------------------------
> > > >To unsubscribe, e-mail: [hidden email]
> > > >For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                              -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
-- Lee Meador
Sent from gmail. My real email address is [hidden email]