Re: configuration plugin
Hmmm. I did not mean to get a php solution. I am trying to find a solution for maven (if it exists). Hoping that in java or any other language anyone did have a similar problem. Or let me say a similar "vision". Ok, there are three solutions: assembly, shade, creating productional artifact (composing the library and application artifacts). I think we will write tutorials for those three solutions and the developers should be able to choose their favorite way. Thanks for your feedback. :-) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: configuration plugin
On 03/04/2012 7:49 AM, martin.eisengardt wrote: Profiles appear to be magic but it is black magic. Nice wording ;-) I already use profiles to manage our hudson build of the maven plugin. And yes: You are able to brake your projects if you do not know what to do. My lvl85 gnome mage is able to create a greater-flux-compensation-knife that will fix each maven profile. Most people are not that well equipped. You might come out unscathed or at least not fatally injured. Good luck Ron Your answer is: The most people mess up with profiles. ok, understood. Configuration does not belong with software developers. It belongs to system administrators. Yes and no. Developers always need to apply some local configuration to be able to develop (test it). You cannot always rely on a production test server to put your project and test against. And not all projects are that big that there is a system administrator or hudson/jenkins. In smaller projects the developer is the system administrator and he has only one computer for multiple roles. If possible, structure your Maven projects to produce a single artifact. Make a project that produces an artifact for development, another for your test environment. Have a look at the assembly plug-in or shade. These are safe and will not hurt you. They might be able to build the artifacts that you need. The assemblies are targeted for building packages that are used outside maven? Or did I understand it wrong? As a general policy, I defer to Wayne Fay's superior knowledge of Maven. We use the assembly plug-in to build executable jars that run as standalone batch jobs. The question is not so much about inside Maven or outside Maven since it is a "normal" Maven plug-in. It is more that the assembly plug-in is more flexible about inclusion of files and the type and structure of the resulting artifact than some other Maven plug-ins. For example, the war plug-in which only builds war files and thinks that it knows what a war file looks like and expects the required files to be properly structured in your project. The assembly plug-in requires more configuration but will build what you want and let you tell it where you have put the files that you want included. There is also the shade plug-in that might be used instead of assembly. We do not use it but it does come up here very often as a way to make custom archives. He is also very likely correct that you will find places with a better concentration of PHP/Maven users than here. Not that we are not inclined to help even when we do not know the whole story;-) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: configuration plugin
>> Have a look at the assembly plug-in or shade. These are safe and will not >> hurt you. > > The assemblies are targeted for building packages that are used > outside maven? Or did I understand it wrong? More or less. The plugin documentation has more info about its intended purpose and audience: http://maven.apache.org/plugins/maven-assembly-plugin/ Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: configuration plugin
> 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 If you don't get the level of discussion and answers you seek here, you may find a more receptive audience in a PHP-oriented forum (where the percentage of people using Maven is low but perhaps as high as 1-2%) vs here on this mailing list (where the percentage of people using Maven to build PHP applications is probably on the order of 0.1%). I'm afraid you're going to be blazing this trail more or less on your own. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: configuration plugin
> Profiles appear to be magic but it is black magic. Nice wording ;-) I already use profiles to manage our hudson build of the maven plugin. And yes: You are able to brake your projects if you do not know what to do. My lvl85 gnome mage is able to create a greater-flux-compensation-knife that will fix each maven profile. Your answer is: The most people mess up with profiles. ok, understood. > Configuration does not belong with software developers. It belongs to system > administrators. Yes and no. Developers always need to apply some local configuration to be able to develop (test it). You cannot always rely on a production test server to put your project and test against. And not all projects are that big that there is a system administrator or hudson/jenkins. In smaller projects the developer is the system administrator and he has only one computer for multiple roles. > > If possible, structure your Maven projects to produce a single artifact. > Make a project that produces an artifact for development, another for your > test environment. > > Have a look at the assembly plug-in or shade. These are safe and will not > hurt you. > They might be able to build the artifacts that you need. The assemblies are targeted for building packages that are used outside maven? Or did I understand it wrong? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
configuration plugin
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 sou 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 ini file with application configuration. 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. 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: configuration plugin
Profiles appear to be magic but it is black magic. They should only be used by senior sorcerers who possess advanced skills and have all of the required potions of healing and invulnerability. They are inherently evil and can make your life a living hell. There are a few Maven experts who can handle them with some level of safety but for the rest of us they are to be avoided. Configuration does not belong with software developers. It belongs to system administrators. If possible, structure your Maven projects to produce a single artifact. Make a project that produces an artifact for development, another for your test environment. Have a look at the assembly plug-in or shade. These are safe and will not hurt you. They might be able to build the artifacts that you need. Ron On 02/04/2012 2:55 PM, martin.eisengardt wrote: 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheele
configuration plugin
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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org