Loading...

users@maven.apache.org

[Prev] Thread [Next]  |  [Prev] Date [Next]

configuration plugin martin.eisengardt Mon Apr 02 12:01:20 2012

Hi.

I am looking for a configuration plugin or (if it does not exist) some
brainstorming related to the maven-way of configuration. First let me
say that the configuration task is relevant for our php-maven projects
where we do not have clear conventions you may know from java/jar or
java/war files. Please do not answer with something saying "But a java
servlet should be able to load configuration via server.xml and
server.xml is never part of the generated war". Let us assume the
config.ini is part of the file structure of our application and thus
may be part of the package we are building.

Let us look at a simple scenario of a php web application:
src/main/php/lib --> contains some useful classes
src/main/php/htdocs --> contains the index.php (and maybe other scripts)
src/main/resources/htdocs --> contains .htacces, css files etc.
src/main/resources/config/config.ini --> contains the config.

The maven way would be to activate filtering and declaring something
like this in the config.ini:
[foo]
bar = ${baz}

Typically you would add the properties to your settings.xml and
everything will be fine.

1)
But what happens now? Maven will filter the config.ini and place the
filtered content at the target/classes. Typically a developer (maybe
by using the IDE) wants to place his personal local database
information in the settings.xml. Everything he needs to test his small
web application inside a local tomcat/jetty/apache-httpd. Maybe he
wants to use a different database for unit testing. This is because he
do not want to influence the data he created by manual testing the
app.
As soon as we want to deploy he runs into trouble because normally the
maven way says: Take the target/classes and create a package. Then
deploy this package to the repository. For java projects this creates
jars/wars, for php-maven it creates phars. But all of them contain the
developers config and maybe the database credentials. This is not that
clever. You may exclude the config from build or use assemblies. But
then the configuration is gone.

As far As I understood the maven way we are now forced to use
profiles. For example one could name profiles "development",
"testing", "deploy", "production". That is ok for me because I do not
want to reinvent the wheel and profiles are somehow magic :-). But I
did not see a way to declare something like "For goal package do use
profile deploy; for goal test do use profile testing". Must the
developers remember what profiles to activate before deploying their
module? They may use a jenkins for deploying but keep in mind that
there are enough small projects around that do not have ci servers.

2)
What about the installation phase? I do not know how to name it, I
think of installation to a productional server and not installation in
the meaning of copying it to local repository. So let me call it
"install-app". I saw some small examples to store war projects into
tomcats. Is there any convention around how the lifecycle is named for
the different application types? What I mean is something like this:
"mvn -DgroupId=org.mygroup -DartifactId=my-app -Dversion=1.5.0 install-app"

If there are no plugins around that solve this tasks what about
writing a generic one? A plugin that is able to "hack" the config.ini
by activating the correct profile depending on the use case of the
developer. All we need to know is what files represent mutable
configuration files. And as soon as we want to execute "install-app"
it means to load it from repository (containing non-filter
configuration files), to ask for the configuration parameters "baz" at
command line and to provide a filtered config.ini.

Similar to the way the archetype:generate asks for additional parameters.

What do you think about it?

Greetings

Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]