[M2] questions about migrating to maven

[Ca...@usitc.gov]

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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [M2] questions about migrating to maven

[Konstantin Polyzois <po...@gmail.com>]

Is it not possible to alter the artifactId's finalName and the dependencies
with profiles also? Then you would not get tainted builds... Not sure how to
do this but I have read about it somewhere.

Konstantin

On 5/26/06, Carlos.Fernandez@usitc.gov <Ca...@usitc.gov> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: [M2] questions about migrating to maven

[Carlos Sanchez <ca...@apache.org>]

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, Carlos.Fernandez@usitc.gov <Ca...@usitc.gov> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org