You could include all property-files in build but use some environment variable for making your code chose the correct one like -Denvironment=prod
/Kostantin On 5/30/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
On 5/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Carlos, > > --> re FILTERING PROPERTIES FILES FOR ENVIRONMENTS > My suggestion is to externalie that configuration options in a way > that your artifact is always the same, and only configuration changes. > You can do reading your config files from the classpath or better > using JNDI. > > ++++++++++++++++++++ > > Sorry to harp on this, but I think I am having trouble thinking beyond > the way I have used ant the past few years. > > 100% of the differences between the developer workstation, > pre-production and production builds on my various projects are isolated > into properties files. These are then pulled into Spring as classpath > resources. > > If I understand you correctly, you are suggesting that the project > artifacts, wars and jars alike, should not include these properties > files. These files should either: > > - be accessed as classpath resource. Presumably some other > build/release process would deposit them on the classpath, or they would > be added to the container's classpath at startup. > - accessed via JNDI. The JNDI entries would either be name/value pairs, > the properties files themselves or a combo. When the war is deployed, > part of the deployment process would be to configure the JNDI tree. > > Is this correct? Yes, that way you don't need different artifacts for each environment, reducing the risks. If you still want to do that you can use profiles to include/exclude properties files in the jar, chnging the finalName so they are named differently. I encourage the other option, but still you can do it this way. > > --> re INTER-PROJECT DEPENDENCIES > > --> With maven the best way is not to rebuild all your dependencies > every > time, but to depend on the binaries generated by the other projects as > SNAPSHOTs. > > If I can get past the environment configuration step - then I suspect > that this would no longer be an issue. Each artifact would be generic > and just as relevant on a developers workstation as it will be in > production. > > Carlos > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos > Sanchez > Sent: Sunday, May 28, 2006 2:09 PM > To: Maven Users List > Subject: Re: [M2] questions about migrating to maven > > Hi Carlos, > > re FILTERING PROPERTIES FILES FOR ENVIRONMENTS > > I usually don't like this approach for the inconvinients you mention, > you need to rebuild your artifacts for each environments, which is > usually prone to errors, you test x-dev in your machine, and then > build x-prod for production, with no guarantees that it's the same > stuff you tested. > > My suggestion is to externalie that configuration options in a way > that your artifact is always the same, and only configuration changes. > You can do reading your config files from the classpath or better > using JNDI. You can also have dev config as default so your developers > don't have to setup anything and you do it only in prod or preprod. > > > re INTER-PROJECT DEPENDENCIES > > With maven the best way is not to rebuild all your dependencies every > time, but to depend on the binaries generated by the other projects as > SNAPSHOTs. You can ensure the repo has the latest snapshot by setting > up continuum to deploy everytime somebody changes the project. That > way developers don't have to go through the extra time consuming > process of building the dependencies. > > Regards > > Carlos > > > On 5/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > wrote: > > I am pretty sure that I am over thinking this ;) However, I am having > > trouble thinking how best to migrate our ant based build process to > > maven. Principally: > > > > - Filtering properties files for environments, and > > - Inter-project dependencies > > > > FILTERING PROPERTIES FILES FOR ENVIRONMENTS > > As with most projects, our apps use properties files for configuring a > > host of settings. Many of these (e.g. db settings, log4j settings, > web > > service host:port etc) are environment specific. Our projects have > > properties files for various target environments, such as production, > > pre-production, cruisecontrol. Each developer also has a local props > > file that they can tailor for their particular needs (e.g. for > debugging > > you may want to log springframework as DEBUG and suppress all others). > > Ant uses these files to filter the application properties. The result > > is a build tailored for a particular environment. Since all > environment > > specific properties, beside the local, are source controlled we have a > > high degree of confidence in consistent and reproducible builds to our > > shared infrastructure. > > > > In maven I have been able to reproduce this behavior with profiles. > > However, I am not sure what to do with the resulting artifacts. Each > > artifact is "tainted" with environment specific properties. > > > > Should artifacts generated with "local" only be installed in each > > developers local repository? What about the artifacts for the testing > > and production environments? Should the internal repository only be > > used to store "production" artifacts? Should there be multiple shared > > internal repositories, one for production and one for pre-prod? > > > > INTER-PROJECT DEPENDENCIES > > Currently we have a web based application broken out into four > projects: > > > > 1 - user-presentation-layer > > 2 - admin-presentation-layer > > 3 - web-service-layer > > 4 - common-utils > > > > Each project generates a primary artifact, and the web-service-layer > > also generates a client jar. > > > > Currently in order to generate a fresh build of say the > > user-presentation-layer, you must have the web-service-layer and > > common-utils checked out in your workspace. The ant build file for > the > > user-presentation-layer will end up calling the other two build files. > > These builds in turn, get an update from cvs and then generating the > > appropriate artifact. Granted it took some time to get this process > up > > and running, but it currently works and works pretty well. > > > > From my readings, it seems that this process is frowned upon. With > > maven, the appropriate process would be to "mvn scm:update install" on > > the web-service-layer and common-utils projects. Then run the build > for > > the user-presentation-layer. > > > > Or better yet, have each user pull the dependencies (web-service-layer > > and common-utils) from an internal repository that is updated by > > developers checking in changes or by some source control repository. > > > > However, as noted above, because of environmental impacts, I am not > sure > > a shared repository would work for artifacts used in development. > > Currently, our environment profiles only effect configuration > settings. > > They do not modify or impact the source code directly. While the > maven > > dependencies are a result of class dependencies, which should not be > > impacted by using an artifact configured for "production" versus one > > configured for "preproduction". > > > > What is the best way to handle this problem? > > > > I am sure people much smarter than myself have already tackled these > > problems and come up with very simple solutions. > > > > Any and all help sorting myself out would be really appreciated! > > > > Carlos > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > I could give you my word as a Spaniard. > No good. I've known too many Spaniards. > -- The Princess Bride > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
