Re: Maven Repository - Handling configuration Files
Cargo can't use the zip directly. But you should be able to get it to work by using the dependency-plugin and extract the content of the archive first. /Anders On Wed, Jan 12, 2011 at 10:33, Wayne Fay wrote: > > If I do this and create a new ".zip" or some other artifact for my > > configuration files, is it possible to deploy this by extracting the > config > > files to specific location using Cargo plugin? > > I haven't used Cargo in a while so I have no idea. It seems like > asking the Cargo folks directly would be the most efficient method to > get this answered. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Maven Repository - Handling configuration Files
> If I do this and create a new ".zip" or some other artifact for my > configuration files, is it possible to deploy this by extracting the config > files to specific location using Cargo plugin? I haven't used Cargo in a while so I have no idea. It seems like asking the Cargo folks directly would be the most efficient method to get this answered. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Maven Repository - Handling configuration Files
Thanks Wayne, If I do this and create a new ".zip" or some other artifact for my configuration files, is it possible to deploy this by extracting the config files to specific location using Cargo plugin? Regards, Tirumal Reddy M -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Wednesday, January 12, 2011 2:39 PM To: Maven Users List Subject: Re: Maven Repository - Handling configuration Files > I don't want to go for creation of maven assembly and packing things > together. Please suggest me if there are any other approaches There is nothing stopping you from making another Maven project that only contains your config files (in src/main/resources, perhaps) and then publishing that to the remote repo, then picking them up and unpacking (unjar/unzip) them to use in your app servers directly. This would not involve the assembly plugin or any non-standard approach. Why do you have a doubt about this? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Repository - Handling configuration Files
> I don't want to go for creation of maven assembly and packing things > together. Please suggest me if there are any other approaches There is nothing stopping you from making another Maven project that only contains your config files (in src/main/resources, perhaps) and then publishing that to the remote repo, then picking them up and unpacking (unjar/unzip) them to use in your app servers directly. This would not involve the assembly plugin or any non-standard approach. Why do you have a doubt about this? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven Repository - Handling configuration Files
Hi, I have a doubt regarding distributing configuration files which needs to be deployed in application server. But these files needs to be separated from the web achieve. I am publishing the web archive and other artifacts to remote repository, from where I am picking up and deploying them to application server. I don't want to go for creation of maven assembly and packing things together. Please suggest me if there are any other approaches Regards, Tirumal Reddy M
Re: Multiple packages with different configuration files
On Tue, Nov 23, 2010 at 9:49 AM, wrote: > Eric, > > Let me elaborate on the issue. I cannot use profiles as it will create > only one distribution for me. I need to have the same compiled cod > bundled with different config files for DEV/QA/PROD. Is there are any > easy way to create 3 TAR files from one jar or war and include different > sets of config files within each of them? How can I implement it with > Assembly mojo? Apply Dont Repeat Yourself princiiples plus separation of concerns. As someone already suggested the best way is to make your operations team take your one EAR and apply the specific environment configuration as part of the deployment process, how you do this is specific to you application server. The general practice appears to be having a directory included on the application server's classpath and you put your applications specific config files here. The operations team need to keep their copies of the configuration files up to date with any dev changes (like new configuration variables). Ideally you want to make this file as small as possible (i.e production passwords and ip, port, url values) Any values that are configurable, but dont generally change across environments, like timeout values should be in another file. These values are configurable so you can tweak them without recompiling but they would normally be the same across all environments. This configuration file may be bundled in your applications jar, or deployed into your application server config directory depending on how easily you want people to be able to tweak these values. Another approach (which I dont recommend) is to create a maven module for each environment. Then you can use the assembly plugin to bundle your EAR plus your per environment configuration file into your tar. The problem with this is you have just created X copies of your tar (and normally it will use a large amount of disk space) where the only difference is the configuration files. You've saved your ops team a little effort by creating a single bundle but you've just made your build/release process a lot slower. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Multiple packages with different configuration files
The Assembly plugin can have multiple assemblies defined. We produce one distribution with ALL configs in it though. Curt Yanko | Continuous Integration Services | UnitedHealth Group IT Making IT Happen, one build at a time, 600 times a day > -Original Message- > From: ilya.may...@ubs.com [mailto:ilya.may...@ubs.com] > Sent: Monday, November 22, 2010 6:19 PM > To: users@maven.apache.org > Subject: RE: Multiple packages with different configuration files > > Eric, > > Let me elaborate on the issue. I cannot use profiles as it > will create only one distribution for me. I need to have the > same compiled cod bundled with different config files for > DEV/QA/PROD. Is there are any easy way to create 3 TAR files > from one jar or war and include different sets of config > files within each of them? How can I implement it with Assembly mojo? > > > Thanks > > Ilya Mayzel > Distributed Change Management > UBS Financial Services Inc. > 1000 Harbor Boulevard, 4th Floor > Weehawken, NJ-07086 > Phone: 201-352-7976 > Email : ilya.may...@ubs.com > > -Original Message- > From: Haszlakiewicz, Eric [mailto:ehas...@transunion.com] > Sent: Monday, November 22, 2010 3:38 PM > To: Maven Users List > Subject: RE: Multiple packages with different configuration files > > > Well those are some rather useless answers. > JNDI will only "do the job" if you configure it that way. You need to > get that configuration *into* tomcat somehow in the first place, > regardless of whether you use JNDI or a properties file. > > To suggest some options for the original poster: > There are several different options to choose which > configuration gets > used or included in a application package. One way, which I > have used a > fair amount, is to include all configurations, and have an environment > variable that you set when you run that app that causes it to > choose the > right file. The exact method of doing this depends on > exactly how your > configuration is stored, but it might consist of things like having > property references in spring config files, tomcat setenv.sh scripts > that pass appropriate java options, or custom java code > within your app > that looks for the variable settings. > > On the other hand, if you want actual, separate application packages, > each that only contains a single set of configuration > options, well then > you're back in the realm of how to get maven to do that for you. What > I've done for this is use profiles with embedded ant tasks > that copy the > appropriate files into place. Then to build a dev > environment you might > do something like "mvn -P dev package". Of course, you can use any > other plugin config within a profile other than the ant > plugin, such as > having separate assembler plugin configs and include different > configuration files that way. > There's lots of way to do it; I'm not sure what the best one is. > > eric > > >-Original Message- > >From: Ron Wheeler [mailto:rwhee...@artifact-software.com] > >Sent: Monday, November 22, 2010 1:03 PM > >To: users@maven.apache.org > >Subject: Re: Multiple packages with different configuration files > > > > > >JNDI will do the job on Tomcat. > > > >Ron > > > > > >On 22/11/2010 1:47 PM, Antonio Petrelli wrote: > >> 2010/11/22: > >>> This app need to be packaged with different configuration files > >>> (server names/IP addresses) for Dev/QA/Prod environments. > >> This kind of info are better put in the server. For example, for > >> JBoss, you can create a .properties file and put it inside: > >> /server/ >> Everything in the conf directory is available in your classpath. > >> > >> Antonio > >> > >> > - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > > > > >- > >To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >For additional commands, e-mail: users-h...@maven.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > Please visit our website at > http://financialservicesinc.ubs.com/wealth/E-maildisclaimer.html > for importa
Re: Multiple packages with different configuration files
I believe you can specify multiple executions. See: http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Plugins I think you could use the EAR plugin for example with three separate executions, each with a configuration that excludes different files. Hope this helps. On 22 November 2010 23:19, wrote: > Eric, > > Let me elaborate on the issue. I cannot use profiles as it will create > only one distribution for me. I need to have the same compiled cod > bundled with different config files for DEV/QA/PROD. Is there are any > easy way to create 3 TAR files from one jar or war and include different > sets of config files within each of them? How can I implement it with > Assembly mojo? > > > Thanks > > Ilya Mayzel > Distributed Change Management > UBS Financial Services Inc. > 1000 Harbor Boulevard, 4th Floor > Weehawken, NJ-07086 > Phone: 201-352-7976 > Email : ilya.may...@ubs.com > > -Original Message- > From: Haszlakiewicz, Eric [mailto:ehas...@transunion.com] > Sent: Monday, November 22, 2010 3:38 PM > To: Maven Users List > Subject: RE: Multiple packages with different configuration files > > > Well those are some rather useless answers. > JNDI will only "do the job" if you configure it that way. You need to > get that configuration *into* tomcat somehow in the first place, > regardless of whether you use JNDI or a properties file. > > To suggest some options for the original poster: > There are several different options to choose which configuration gets > used or included in a application package. One way, which I have used a > fair amount, is to include all configurations, and have an environment > variable that you set when you run that app that causes it to choose the > right file. The exact method of doing this depends on exactly how your > configuration is stored, but it might consist of things like having > property references in spring config files, tomcat setenv.sh scripts > that pass appropriate java options, or custom java code within your app > that looks for the variable settings. > > On the other hand, if you want actual, separate application packages, > each that only contains a single set of configuration options, well then > you're back in the realm of how to get maven to do that for you. What > I've done for this is use profiles with embedded ant tasks that copy the > appropriate files into place. Then to build a dev environment you might > do something like "mvn -P dev package". Of course, you can use any > other plugin config within a profile other than the ant plugin, such as > having separate assembler plugin configs and include different > configuration files that way. > There's lots of way to do it; I'm not sure what the best one is. > > eric > > >-Original Message- > >From: Ron Wheeler [mailto:rwhee...@artifact-software.com] > >Sent: Monday, November 22, 2010 1:03 PM > >To: users@maven.apache.org > >Subject: Re: Multiple packages with different configuration files > > > > > >JNDI will do the job on Tomcat. > > > >Ron > > > > > >On 22/11/2010 1:47 PM, Antonio Petrelli wrote: > >> 2010/11/22: > >>> This app need to be packaged with different configuration files > >>> (server names/IP addresses) for Dev/QA/Prod environments. > >> This kind of info are better put in the server. For example, for > >> JBoss, you can create a .properties file and put it inside: > >> /server/ >> Everything in the conf directory is available in your classpath. > >> > >> Antonio > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > > > > >- > >To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >For additional commands, e-mail: users-h...@maven.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > Please visit our website at > http://financialservicesinc.ubs.com/wealth/E-maildisclaimer.html > for important disclosures and information about our e-mail > policies. For your protection, please do not transmit orders > or instructions by e-mail or include account numbers, Social > Security numbers, credit card numbers, passwords, or other > personal information. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
RE: Multiple packages with different configuration files
Eric, Let me elaborate on the issue. I cannot use profiles as it will create only one distribution for me. I need to have the same compiled cod bundled with different config files for DEV/QA/PROD. Is there are any easy way to create 3 TAR files from one jar or war and include different sets of config files within each of them? How can I implement it with Assembly mojo? Thanks Ilya Mayzel Distributed Change Management UBS Financial Services Inc. 1000 Harbor Boulevard, 4th Floor Weehawken, NJ-07086 Phone: 201-352-7976 Email : ilya.may...@ubs.com -Original Message- From: Haszlakiewicz, Eric [mailto:ehas...@transunion.com] Sent: Monday, November 22, 2010 3:38 PM To: Maven Users List Subject: RE: Multiple packages with different configuration files Well those are some rather useless answers. JNDI will only "do the job" if you configure it that way. You need to get that configuration *into* tomcat somehow in the first place, regardless of whether you use JNDI or a properties file. To suggest some options for the original poster: There are several different options to choose which configuration gets used or included in a application package. One way, which I have used a fair amount, is to include all configurations, and have an environment variable that you set when you run that app that causes it to choose the right file. The exact method of doing this depends on exactly how your configuration is stored, but it might consist of things like having property references in spring config files, tomcat setenv.sh scripts that pass appropriate java options, or custom java code within your app that looks for the variable settings. On the other hand, if you want actual, separate application packages, each that only contains a single set of configuration options, well then you're back in the realm of how to get maven to do that for you. What I've done for this is use profiles with embedded ant tasks that copy the appropriate files into place. Then to build a dev environment you might do something like "mvn -P dev package". Of course, you can use any other plugin config within a profile other than the ant plugin, such as having separate assembler plugin configs and include different configuration files that way. There's lots of way to do it; I'm not sure what the best one is. eric >-Original Message- >From: Ron Wheeler [mailto:rwhee...@artifact-software.com] >Sent: Monday, November 22, 2010 1:03 PM >To: users@maven.apache.org >Subject: Re: Multiple packages with different configuration files > > >JNDI will do the job on Tomcat. > >Ron > > >On 22/11/2010 1:47 PM, Antonio Petrelli wrote: >> 2010/11/22: >>> This app need to be packaged with different configuration files >>> (server names/IP addresses) for Dev/QA/Prod environments. >> This kind of info are better put in the server. For example, for >> JBoss, you can create a .properties file and put it inside: >> /server/> Everything in the conf directory is available in your classpath. >> >> Antonio >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > >- >To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Please visit our website at http://financialservicesinc.ubs.com/wealth/E-maildisclaimer.html for important disclosures and information about our e-mail policies. For your protection, please do not transmit orders or instructions by e-mail or include account numbers, Social Security numbers, credit card numbers, passwords, or other personal information. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multiple packages with different configuration files
On 22/11/2010 3:38 PM, Haszlakiewicz, Eric wrote: Well those are some rather useless answers. JNDI will only "do the job" if you configure it that way. You need to get that configuration *into* tomcat somehow in the first place, regardless of whether you use JNDI or a properties file. I was not suggesting that an unconfigured Tomcat would do JNDI on its own. The goal is to get the server specific configuration out of development teams hair and into the operations area. We started out with bits of server configuration in the applications and of course, it caused all kinds of silly errors when the wrong things got deployed to the right place and vice versa. We moved the server specific files into their own project which has 1 file per server with all the right JNDI for that server. If you want to make a new server configuration, you just make a new server configuration file that you deploy to the Tomcat configuration directory. Developers do not have to worry about building server specific WAR files with lots of dancing to get the right setup in the right WAR file or worrying about deploying the right combination of WAR files. Reduced our silly deployment errors. Ron To suggest some options for the original poster: There are several different options to choose which configuration gets used or included in a application package. One way, which I have used a fair amount, is to include all configurations, and have an environment variable that you set when you run that app that causes it to choose the right file. The exact method of doing this depends on exactly how your configuration is stored, but it might consist of things like having property references in spring config files, tomcat setenv.sh scripts that pass appropriate java options, or custom java code within your app that looks for the variable settings. On the other hand, if you want actual, separate application packages, each that only contains a single set of configuration options, well then you're back in the realm of how to get maven to do that for you. What I've done for this is use profiles with embedded ant tasks that copy the appropriate files into place. Then to build a dev environment you might do something like "mvn -P dev package". Of course, you can use any other plugin config within a profile other than the ant plugin, such as having separate assembler plugin configs and include different configuration files that way. There's lots of way to do it; I'm not sure what the best one is. eric -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, November 22, 2010 1:03 PM To: users@maven.apache.org Subject: Re: Multiple packages with different configuration files JNDI will do the job on Tomcat. Ron On 22/11/2010 1:47 PM, Antonio Petrelli wrote: 2010/11/22: This app need to be packaged with different configuration files (server names/IP addresses) for Dev/QA/Prod environments. This kind of info are better put in the server. For example, for JBoss, you can create a .properties file and put it inside: /server/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Multiple packages with different configuration files
Well those are some rather useless answers. JNDI will only "do the job" if you configure it that way. You need to get that configuration *into* tomcat somehow in the first place, regardless of whether you use JNDI or a properties file. To suggest some options for the original poster: There are several different options to choose which configuration gets used or included in a application package. One way, which I have used a fair amount, is to include all configurations, and have an environment variable that you set when you run that app that causes it to choose the right file. The exact method of doing this depends on exactly how your configuration is stored, but it might consist of things like having property references in spring config files, tomcat setenv.sh scripts that pass appropriate java options, or custom java code within your app that looks for the variable settings. On the other hand, if you want actual, separate application packages, each that only contains a single set of configuration options, well then you're back in the realm of how to get maven to do that for you. What I've done for this is use profiles with embedded ant tasks that copy the appropriate files into place. Then to build a dev environment you might do something like "mvn -P dev package". Of course, you can use any other plugin config within a profile other than the ant plugin, such as having separate assembler plugin configs and include different configuration files that way. There's lots of way to do it; I'm not sure what the best one is. eric >-Original Message- >From: Ron Wheeler [mailto:rwhee...@artifact-software.com] >Sent: Monday, November 22, 2010 1:03 PM >To: users@maven.apache.org >Subject: Re: Multiple packages with different configuration files > > >JNDI will do the job on Tomcat. > >Ron > > >On 22/11/2010 1:47 PM, Antonio Petrelli wrote: >> 2010/11/22: >>> This app need to be packaged with different configuration files (server >>> names/IP addresses) for Dev/QA/Prod environments. >> This kind of info are better put in the server. For example, for >> JBoss, you can create a .properties file and put it inside: >> /server/> Everything in the conf directory is available in your classpath. >> >> Antonio >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > >- >To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multiple packages with different configuration files
JNDI will do the job on Tomcat. Ron On 22/11/2010 1:47 PM, Antonio Petrelli wrote: 2010/11/22: This app need to be packaged with different configuration files (server names/IP addresses) for Dev/QA/Prod environments. This kind of info are better put in the server. For example, for JBoss, you can create a .properties file and put it inside: /server/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multiple packages with different configuration files
2010/11/22 : > This app need to be packaged with different configuration files (server > names/IP addresses) for Dev/QA/Prod environments. This kind of info are better put in the server. For example, for JBoss, you can create a .properties file and put it inside: /server/
Multiple packages with different configuration files
Hello, I am new to this list and may just missed this topic discussion. I have a web application that I need to compile and package into war/ear/tar. This app need to be packaged with different configuration files (server names/IP addresses) for Dev/QA/Prod environments. However I don't want to recompile the base code for each environment, but just package it with appropriate config files. Which mojo should I use and how to do this? I guess this is a trivial and standard requirement. I would appreciate your help. Thanks, Ilya Please visit our website at http://financialservicesinc.ubs.com/wealth/E-maildisclaimer.html for important disclosures and information about our e-mail policies. For your protection, please do not transmit orders or instructions by e-mail or include account numbers, Social Security numbers, credit card numbers, passwords, or other personal information. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
Ceki Gulcu a écrit : Olivier, Since projects A and B seem to be just artifacts, I am still wondering why projects A and B need a configuration file for logging. If it is for testing purposes, why not use logback-text.xml and place it under /src/test/resources/ directory? Indeed, it appears to me now that I was mixing two different purposes for my projects A and B: they aim to produce a usable library (reusable components for developers) AND they are providing some simple main class and launcher to enable direct, simple usage for a non-developer end-user. I guess I should separate these two concerns and develop 1) a project intended as a library, with the logging component and config files only in the "test" scope (and no need to include the launcher here) 2) a project intended for use by the end-user, dependant on the above library, and with the logging component provided at runtime. That might suffice to solve most of my problems of duplicate config files which were due to this mixing of concern in my mind. Anyway, my questions were more general than to be applied only on my current projects, so it was very useful to be able to think about other solutions. (Off-topic again, I must say I appreciate very much slf4j and logback-classic, and the "complain" of logback has not been annoying to me but rather useful as it allowed me to take note of an incorrect design in my projects.) Olivier - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
Olivier, Since projects A and B seem to be just artifacts, I am still wondering why projects A and B need a configuration file for logging. If it is for testing purposes, why not use logback-text.xml and place it under /src/test/resources/ directory? -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
2009/4/29 Ceki Gulcu > > > But what is annoying to me is that these redundant files > > are included when they should not, because from a logical point of > > view project C does not need the config files of project A or B. > => This means you should go into a D project (Stephen proposal) ... even if it is heavy for flyweight issues. To my mind the unpack/repack proposal is far less heavy/complicated than this point ... Particularly, it implies project C to "foresee" existence of certain files in your projects A & B (don't forget these projects could evolve without notifying C) : wouldn't it be dangerous ? > > > This is somewhat off topic, but since the question has been raised in > this forum, allow me to explain. > > First, it is not SLF4J which is complaining, it's logback-classic > which Olivier indicated he was using. During automatic > initialization, if and when logback-classic sees two or more > configuration files on the class path, it emits a warning: > "Hey, I see N different copies of logback.xml on your class path. The > copies are located at path1, path2, ..., pathN. I am picking the first > one." (It's just a warning...) > > Lobgack-classic is noticing an ambiguity and informing the user. > > HTH, > > -- > Ceki Gülcü > Logback: The reliable, generic, fast and flexible logging framework for > Java. > http://logback.qos.ch > > Cool ! I'm rassured ;-)
Re: Best practices for avoiding duplicate configuration files
> About slf4j complaining about multiple configuration files present in > the CP, I suppose it must be possible to overcome this > complaining. But what is annoying to me is that these redundant files > are included when they should not, because from a logical point of > view project C does not need the config files of project A or B. Even > if I get slf4j to ignore them, I would consider that a workaround > rather than a solution. This is somewhat off topic, but since the question has been raised in this forum, allow me to explain. First, it is not SLF4J which is complaining, it's logback-classic which Olivier indicated he was using. During automatic initialization, if and when logback-classic sees two or more configuration files on the class path, it emits a warning: "Hey, I see N different copies of logback.xml on your class path. The copies are located at path1, path2, ..., pathN. I am picking the first one." (It's just a warning...) Lobgack-classic is noticing an ambiguity and informing the user. HTH, -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
Once again, thank you to everyone who answered. I will investigate these proposals. About slf4j complaining about multiple configuration files present in the CP, I suppose it must be possible to overcome this complaining. But what is annoying to me is that these redundant files are included when they should not, because from a logical point of view project C does not need the config files of project A or B. Even if I get slf4j to ignore them, I would consider that a workaround rather than a solution. So I will investigate the other solutions proposed, namely with assembly & relevant advices... Olivier Nick Stolwijk a écrit : - it is not very elegant as any project depending on A or B would have to not forget to exclude the sub-module containing the log files (any dependent project would have the same problem as the project C has) ; This is not a very good point, as jar files should never be adjusted after releasing. To re-cap, I dream of a solution allowing me the following two possibilities, for any project I create: - a possibility to create and expose (for use by dependent projects) a .jar file NOT containing the log > configuration file ; - a possibility to create and deploy (for end-user usage) a .zip file containing the above .jar AND the > log configuration file, which is then easy for the end-user to modify ; and some start-up script (portable) or something equivalent to correctly configure the classpath to include the log configuration file and allow the end-user to easily start the application (this is the part I don't see how to do with the FAQ provided at This is a good solution and there exists a plugin for this, ie. the Application Assembler Maven Plugin[1]. Here is a good blog about adding your own files to the app assembly [2]. [1] http://mojo.codehaus.org/appassembler/appassembler-maven-plugin/ [2] http://www.joelpm.com/2009/01/23/maven-assembly-plugin-woes/ Hth, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Mon, Apr 27, 2009 at 7:41 PM, Olivier Cailloux wrote: Thanks to everybody who answered. I answer to everyone together: - Projects A and B are to be runnable independently and deployable without C. So putting the log config in test resources would not work. - Putting the log files in a dependent module is possible. But: - it would render the pom and project management more complex. Currently these projects are not multi-modules, they are very simple, and that solution would involve transforming them to multi-module projects with one module being a whole module for only one stupid configuration file! And then having the project C exclude the right sub-module. But I admit that it is not my main concern (I could accept a complex solution if it was very good in other aspects) ; - it is not very elegant as any project depending on A or B would have to not forget to exclude the sub-module containing the log files (any dependent project would have the same problem as the project C has) ; - it does not solve the question of the log configuration file not being integrated in the jar for easily modification by the end-user after deployment ; - the problem I face is a general problem, as I always use log configuration files in my projects, so I would like to find a good solution once and for all. - The use of Assembly and Dependency plugins is maybe part of a solution, but I don't see clearly how I can configure all this to do what I would like and avoiding ending up with pom files more complex than needed. To re-cap, I dream of a solution allowing me the following two possibilities, for any project I create: - a possibility to create and expose (for use by dependent projects) a .jar file NOT containing the log configuration file ; - a possibility to create and deploy (for end-user usage) a .zip file containing the above .jar AND the log configuration file, which is then easy for the end-user to modify ; and some start-up script (portable) or something equivalent to correctly configure the classpath to include the log configuration file and allow the end-user to easily start the application (this is the part I don't see how to do with the FAQ provided at http://www.sonatype.com/people/2008/04/how-to-share-resources-across-projects-in-maven/). Although the solutions proposed did not fully satisfy my needs, I have to thank those who responded because it gave me good hints and allowed me to re-think about my problem. Any more advices would be very appreciated because I am a beginner in Maven and I think there must be somehow a simple solution to my needs which I simply overlooked. I am wondering how the others do as this must be a very common problem (everybody use logging framework!). Also, sorry for my English... Olivier Brian Fox a écrit : See the 9th bullet point here: http://www.sonatype.com/people/2009/04/summary-of-maven-how-tos/ On 4/26/2009 3:17 P
Re: Best practices for avoiding duplicate configuration files
> - it is not very elegant as any project depending on A or B would have to > not forget to exclude the sub-module containing the log files (any dependent > project would have the same problem as the project C has) ; This is not a very good point, as jar files should never be adjusted after releasing. >To re-cap, I dream of a solution allowing me the following two possibilities, >for any project I create: >- a possibility to create and expose (for use by dependent projects) a .jar >file NOT containing the log > configuration file ; > - a possibility to create and deploy (for end-user usage) a .zip file > containing the above .jar AND the > log configuration file, which is then > easy for the end-user to modify ; and some start-up script > (portable) or something equivalent to correctly configure the classpath to > include the log > configuration file and allow the end-user to easily start the application > (this is the part I don't see > how to do with the FAQ provided at This is a good solution and there exists a plugin for this, ie. the Application Assembler Maven Plugin[1]. Here is a good blog about adding your own files to the app assembly [2]. [1] http://mojo.codehaus.org/appassembler/appassembler-maven-plugin/ [2] http://www.joelpm.com/2009/01/23/maven-assembly-plugin-woes/ Hth, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Mon, Apr 27, 2009 at 7:41 PM, Olivier Cailloux wrote: > Thanks to everybody who answered. I answer to everyone together: > - Projects A and B are to be runnable independently and deployable without > C. So putting the log config in test resources would not work. > - Putting the log files in a dependent module is possible. But: > - it would render the pom and project management more complex. Currently > these projects are not multi-modules, they are very simple, and that > solution would involve transforming them to multi-module projects with one > module being a whole module for only one stupid configuration file! And then > having the project C exclude the right sub-module. But I admit that it is > not my main concern (I could accept a complex solution if it was very good > in other aspects) ; > - it is not very elegant as any project depending on A or B would have to > not forget to exclude the sub-module containing the log files (any dependent > project would have the same problem as the project C has) ; > - it does not solve the question of the log configuration file not being > integrated in the jar for easily modification by the end-user after > deployment ; > - the problem I face is a general problem, as I always use log > configuration files in my projects, so I would like to find a good solution > once and for all. > > - The use of Assembly and Dependency plugins is maybe part of a solution, > but I don't see clearly how I can configure all this to do what I would like > and avoiding ending up with pom files more complex than needed. > > To re-cap, I dream of a solution allowing me the following two > possibilities, for any project I create: > - a possibility to create and expose (for use by dependent projects) a .jar > file NOT containing the log configuration file ; > - a possibility to create and deploy (for end-user usage) a .zip file > containing the above .jar AND the log configuration file, which is then easy > for the end-user to modify ; and some start-up script (portable) or > something equivalent to correctly configure the classpath to include the log > configuration file and allow the end-user to easily start the application > (this is the part I don't see how to do with the FAQ provided at > http://www.sonatype.com/people/2008/04/how-to-share-resources-across-projects-in-maven/). > > Although the solutions proposed did not fully satisfy my needs, I have to > thank those who responded because it gave me good hints and allowed me to > re-think about my problem. Any more advices would be very appreciated > because I am a beginner in Maven and I think there must be somehow a simple > solution to my needs which I simply overlooked. I am wondering how the > others do as this must be a very common problem (everybody use logging > framework!). > > Also, sorry for my English... > Olivier > > Brian Fox a écrit : >> >> See the 9th bullet point here: >> http://www.sonatype.com/people/2009/04/summary-of-maven-how-tos/ >> >> On 4/26/2009 3:17 PM, Olivier Cailloux wrote: >>> >>> Hello list, >>> >>> I am new to maven and couldn't find a simple and elegant solution to this >>> (probably) common problem. >>> >>> I have three projects : A and B are independent projects and C depends on >>>
Re: Best practices for avoiding duplicate configuration files
On 27 Apr 2009, at 21:32, Frédéric Camblor wrote: This is only a point of view but... Isn't the problem coming from the slf4f framework ? I don't really know this logging framework, but it astonishes me that it complains about multiple configuration in the classpath. Generally, framework takes (like commons-logging or log4j) the first config file found in the classpath so that responsibility is delegated to the order in which you put artefacts in your section. Have you searched in slf4j if it isn't possible to "disable" this "complaining" ? That's the whole point of the slf4j. You nail down the implementation you want by specifying it up-front. It seems to be a reaction against the commons-logging façade. http://www.slf4j.org/faq.html#yet_another_facade Don't ask me much more, as I just use log4j. :) -Dom - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
Hi Olivier, This is only a point of view but... Isn't the problem coming from the slf4f framework ? I don't really know this logging framework, but it astonishes me that it complains about multiple configuration in the classpath. Generally, framework takes (like commons-logging or log4j) the first config file found in the classpath so that responsibility is delegated to the order in which you put artefacts in your section. Have you searched in slf4j if it isn't possible to "disable" this "complaining" ? Cheers, Frederic 2009/4/27 Brian Fox > > > Olivier Cailloux wrote: > >> Thanks to everybody who answered. I answer to everyone together: >> - Projects A and B are to be runnable independently and deployable without >> C. So putting the log config in test resources would not work. >> - Putting the log files in a dependent module is possible. But: >> - it would render the pom and project management more complex. Currently >> these projects are not multi-modules, they are very simple, and that >> solution would involve transforming them to multi-module projects with one >> module being a whole module for only one stupid configuration file! And then >> having the project C exclude the right sub-module. But I admit that it is >> not my main concern (I could accept a complex solution if it was very good >> in other aspects) ; >> > > That's right but generally this config file would not be part of the same > tree that you build everytime. That is to say it has it's own lifecycle and > is released far less often than the projects that use it. > >> - it is not very elegant as any project depending on A or B would have to >> not forget to exclude the sub-module containing the log files (any dependent >> project would have the same problem a >> s the project C has) ; >> > Not true because you don't have to mark it as a dependency. You can use > dependency unpack (as opposed to unpack-dependencies) and this will not > affect the dependency tree. Or you could use scope=provided / optional=true > which means upstream dependencies would ignore it. > >> - it does not solve the question of the log configuration file not being >> integrated in the jar for easily modification by the end-user after >> deployment ; >> - the problem I face is a general problem, as I always use log >> configuration files in my projects, so I would like to find a good solution >> once and for all. >> >> You can unpack the zip file and leave them with just the log config file. > >> - The use of Assembly and Dependency plugins is maybe part of a solution, >> but I don't see clearly how I can configure all this to do what I would like >> and avoiding ending up with pom files more complex than needed. >> >> To re-cap, I dream of a solution allowing me the following two >> possibilities, for any project I create: >> - a possibility to create and expose (for use by dependent projects) a >> .jar file NOT containing the log configuration file ; >> - a possibility to create and deploy (for end-user usage) a .zip file >> containing the above .jar AND the log configuration file, which is then easy >> for the end-user to modify ; and some start-up script (portable) or >> something equivalent to correctly configure the classpath to include the log >> configuration file and allow the end-user to easily start the application >> (this is the part I don't see how to do with the FAQ provided at >> http://www.sonatype.com/people/2008/04/how-to-share-resources-across-projects-in-maven/). >> >> >> This is also possible, just don't put the log file in /target/classes and > it won't get jar'd up. You can then use the assembly plugin to zip up the > final jar along with the config file unpacked earlier. > > > Although the solutions proposed did not fully satisfy my needs, I have to >> thank those who responded because it gave me good hints and allowed me to >> re-think about my problem. Any more advices would be very appreciated >> because I am a beginner in Maven and I think there must be somehow a simple >> solution to my needs which I simply overlooked. I am wondering how the >> others do as this must be a very common problem (everybody use logging >> framework!). >> >> Also, sorry for my English... >> Olivier >> >> Brian Fox a écrit : >> >>> See the 9th bullet point here: >>> http://www.sonatype.com/people/2009/04/summary-of-maven-how-tos/ >>> >>> On 4/26/2009 3:17 PM, Olivier Cailloux wrote: >>> >>>> Hello list, >>>> >&
Re: Best practices for avoiding duplicate configuration files
Olivier Cailloux wrote: Thanks to everybody who answered. I answer to everyone together: - Projects A and B are to be runnable independently and deployable without C. So putting the log config in test resources would not work. - Putting the log files in a dependent module is possible. But: - it would render the pom and project management more complex. Currently these projects are not multi-modules, they are very simple, and that solution would involve transforming them to multi-module projects with one module being a whole module for only one stupid configuration file! And then having the project C exclude the right sub-module. But I admit that it is not my main concern (I could accept a complex solution if it was very good in other aspects) ; That's right but generally this config file would not be part of the same tree that you build everytime. That is to say it has it's own lifecycle and is released far less often than the projects that use it. - it is not very elegant as any project depending on A or B would have to not forget to exclude the sub-module containing the log files (any dependent project would have the same problem a s the project C has) ; Not true because you don't have to mark it as a dependency. You can use dependency unpack (as opposed to unpack-dependencies) and this will not affect the dependency tree. Or you could use scope=provided / optional=true which means upstream dependencies would ignore it. - it does not solve the question of the log configuration file not being integrated in the jar for easily modification by the end-user after deployment ; - the problem I face is a general problem, as I always use log configuration files in my projects, so I would like to find a good solution once and for all. You can unpack the zip file and leave them with just the log config file. - The use of Assembly and Dependency plugins is maybe part of a solution, but I don't see clearly how I can configure all this to do what I would like and avoiding ending up with pom files more complex than needed. To re-cap, I dream of a solution allowing me the following two possibilities, for any project I create: - a possibility to create and expose (for use by dependent projects) a .jar file NOT containing the log configuration file ; - a possibility to create and deploy (for end-user usage) a .zip file containing the above .jar AND the log configuration file, which is then easy for the end-user to modify ; and some start-up script (portable) or something equivalent to correctly configure the classpath to include the log configuration file and allow the end-user to easily start the application (this is the part I don't see how to do with the FAQ provided at http://www.sonatype.com/people/2008/04/how-to-share-resources-across-projects-in-maven/). This is also possible, just don't put the log file in /target/classes and it won't get jar'd up. You can then use the assembly plugin to zip up the final jar along with the config file unpacked earlier. Although the solutions proposed did not fully satisfy my needs, I have to thank those who responded because it gave me good hints and allowed me to re-think about my problem. Any more advices would be very appreciated because I am a beginner in Maven and I think there must be somehow a simple solution to my needs which I simply overlooked. I am wondering how the others do as this must be a very common problem (everybody use logging framework!). Also, sorry for my English... Olivier Brian Fox a écrit : See the 9th bullet point here: http://www.sonatype.com/people/2009/04/summary-of-maven-how-tos/ On 4/26/2009 3:17 PM, Olivier Cailloux wrote: Hello list, I am new to maven and couldn't find a simple and elegant solution to this (probably) common problem. I have three projects : A and B are independent projects and C depends on A and B. I use the same logging framework for the three projects (slf4j with logback). In A and B, I have a logback.xml configuration file in src/main/resources to configure logging behavior (A and B do not necessarily have the same configuration). C has also a specific logging configuration file. And, naturally, when I run the project C, logback complains that it found three logback.xml files in the classpath (the ones from A and B and C) when I would like it to find only the one from project C. I am thus wondering how to avoid this duplication of configuration files (or avoid exposure of the A and B configuration files /for dependent projects/). (Naturally completely "excluding" logback.xml in A and B wouldn't solve my problem as it would also exclude the configuration file when running A or B themselves.) More generally, is there some tutorial or best-practice about configuring logging for easy deployment and user-tweaking with maven? I would ideally like the end-user to be easily able t
Re: Best practices for avoiding duplicate configuration files
Thanks to everybody who answered. I answer to everyone together: - Projects A and B are to be runnable independently and deployable without C. So putting the log config in test resources would not work. - Putting the log files in a dependent module is possible. But: - it would render the pom and project management more complex. Currently these projects are not multi-modules, they are very simple, and that solution would involve transforming them to multi-module projects with one module being a whole module for only one stupid configuration file! And then having the project C exclude the right sub-module. But I admit that it is not my main concern (I could accept a complex solution if it was very good in other aspects) ; - it is not very elegant as any project depending on A or B would have to not forget to exclude the sub-module containing the log files (any dependent project would have the same problem as the project C has) ; - it does not solve the question of the log configuration file not being integrated in the jar for easily modification by the end-user after deployment ; - the problem I face is a general problem, as I always use log configuration files in my projects, so I would like to find a good solution once and for all. - The use of Assembly and Dependency plugins is maybe part of a solution, but I don't see clearly how I can configure all this to do what I would like and avoiding ending up with pom files more complex than needed. To re-cap, I dream of a solution allowing me the following two possibilities, for any project I create: - a possibility to create and expose (for use by dependent projects) a .jar file NOT containing the log configuration file ; - a possibility to create and deploy (for end-user usage) a .zip file containing the above .jar AND the log configuration file, which is then easy for the end-user to modify ; and some start-up script (portable) or something equivalent to correctly configure the classpath to include the log configuration file and allow the end-user to easily start the application (this is the part I don't see how to do with the FAQ provided at http://www.sonatype.com/people/2008/04/how-to-share-resources-across-projects-in-maven/). Although the solutions proposed did not fully satisfy my needs, I have to thank those who responded because it gave me good hints and allowed me to re-think about my problem. Any more advices would be very appreciated because I am a beginner in Maven and I think there must be somehow a simple solution to my needs which I simply overlooked. I am wondering how the others do as this must be a very common problem (everybody use logging framework!). Also, sorry for my English... Olivier Brian Fox a écrit : See the 9th bullet point here: http://www.sonatype.com/people/2009/04/summary-of-maven-how-tos/ On 4/26/2009 3:17 PM, Olivier Cailloux wrote: Hello list, I am new to maven and couldn't find a simple and elegant solution to this (probably) common problem. I have three projects : A and B are independent projects and C depends on A and B. I use the same logging framework for the three projects (slf4j with logback). In A and B, I have a logback.xml configuration file in src/main/resources to configure logging behavior (A and B do not necessarily have the same configuration). C has also a specific logging configuration file. And, naturally, when I run the project C, logback complains that it found three logback.xml files in the classpath (the ones from A and B and C) when I would like it to find only the one from project C. I am thus wondering how to avoid this duplication of configuration files (or avoid exposure of the A and B configuration files /for dependent projects/). (Naturally completely "excluding" logback.xml in A and B wouldn't solve my problem as it would also exclude the configuration file when running A or B themselves.) More generally, is there some tutorial or best-practice about configuring logging for easy deployment and user-tweaking with maven? I would ideally like the end-user to be easily able to modify the logging strategy, while providing him sensible defaults. Probably the logback.xml file should not be embedded in the .jar, but I don't know how to do that (and don't know if this is the best solution!) Thank you for any pointer. Olivier - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
See the 9th bullet point here: http://www.sonatype.com/people/2009/04/summary-of-maven-how-tos/ On 4/26/2009 3:17 PM, Olivier Cailloux wrote: Hello list, I am new to maven and couldn't find a simple and elegant solution to this (probably) common problem. I have three projects : A and B are independent projects and C depends on A and B. I use the same logging framework for the three projects (slf4j with logback). In A and B, I have a logback.xml configuration file in src/main/resources to configure logging behavior (A and B do not necessarily have the same configuration). C has also a specific logging configuration file. And, naturally, when I run the project C, logback complains that it found three logback.xml files in the classpath (the ones from A and B and C) when I would like it to find only the one from project C. I am thus wondering how to avoid this duplication of configuration files (or avoid exposure of the A and B configuration files /for dependent projects/). (Naturally completely "excluding" logback.xml in A and B wouldn't solve my problem as it would also exclude the configuration file when running A or B themselves.) More generally, is there some tutorial or best-practice about configuring logging for easy deployment and user-tweaking with maven? I would ideally like the end-user to be easily able to modify the logging strategy, while providing him sensible defaults. Probably the logback.xml file should not be embedded in the .jar, but I don't know how to do that (and don't know if this is the best solution!) Thank you for any pointer. Olivier - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
If A and B are only utility modules (not runnable), and you only use the log configuration files for unit testing, I would have moved them to src/test/resources in A and B. That way they are not made available to C. C will have the log configuration file in src/main/resources, at least if it is a war/ear module. Hope that helps. -ketil On Mon, Apr 27, 2009 at 1:23 PM, Stephen Connolly wrote: > Create a new module(s) which just has the log configuration... > > then A & B can both depend on this(ese) new module(s)... > > C can exclude the module(s) from it's dependencies on A & B > > 2009/4/26 Olivier Cailloux > >> Hello list, >> >> I am new to maven and couldn't find a simple and elegant solution to this >> (probably) common problem. >> >> I have three projects : A and B are independent projects and C depends on A >> and B. I use the same logging framework for the three projects (slf4j with >> logback). In A and B, I have a logback.xml configuration file in >> src/main/resources to configure logging behavior (A and B do not necessarily >> have the same configuration). C has also a specific logging configuration >> file. And, naturally, when I run the project C, logback complains that it >> found three logback.xml files in the classpath (the ones from A and B and C) >> when I would like it to find only the one from project C. >> >> I am thus wondering how to avoid this duplication of configuration files >> (or avoid exposure of the A and B configuration files /for dependent >> projects/). (Naturally completely "excluding" logback.xml in A and B >> wouldn't solve my problem as it would also exclude the configuration file >> when running A or B themselves.) >> >> >> More generally, is there some tutorial or best-practice about configuring >> logging for easy deployment and user-tweaking with maven? I would ideally >> like the end-user to be easily able to modify the logging strategy, while >> providing him sensible defaults. Probably the logback.xml file should not be >> embedded in the .jar, but I don't know how to do that (and don't know if >> this is the best solution!) >> >> Thank you for any pointer. >> Olivier >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practices for avoiding duplicate configuration files
Create a new module(s) which just has the log configuration... then A & B can both depend on this(ese) new module(s)... C can exclude the module(s) from it's dependencies on A & B 2009/4/26 Olivier Cailloux > Hello list, > > I am new to maven and couldn't find a simple and elegant solution to this > (probably) common problem. > > I have three projects : A and B are independent projects and C depends on A > and B. I use the same logging framework for the three projects (slf4j with > logback). In A and B, I have a logback.xml configuration file in > src/main/resources to configure logging behavior (A and B do not necessarily > have the same configuration). C has also a specific logging configuration > file. And, naturally, when I run the project C, logback complains that it > found three logback.xml files in the classpath (the ones from A and B and C) > when I would like it to find only the one from project C. > > I am thus wondering how to avoid this duplication of configuration files > (or avoid exposure of the A and B configuration files /for dependent > projects/). (Naturally completely "excluding" logback.xml in A and B > wouldn't solve my problem as it would also exclude the configuration file > when running A or B themselves.) > > > More generally, is there some tutorial or best-practice about configuring > logging for easy deployment and user-tweaking with maven? I would ideally > like the end-user to be easily able to modify the logging strategy, while > providing him sensible defaults. Probably the logback.xml file should not be > embedded in the .jar, but I don't know how to do that (and don't know if > this is the best solution!) > > Thank you for any pointer. > Olivier > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Best practices for avoiding duplicate configuration files
Hello list, I am new to maven and couldn't find a simple and elegant solution to this (probably) common problem. I have three projects : A and B are independent projects and C depends on A and B. I use the same logging framework for the three projects (slf4j with logback). In A and B, I have a logback.xml configuration file in src/main/resources to configure logging behavior (A and B do not necessarily have the same configuration). C has also a specific logging configuration file. And, naturally, when I run the project C, logback complains that it found three logback.xml files in the classpath (the ones from A and B and C) when I would like it to find only the one from project C. I am thus wondering how to avoid this duplication of configuration files (or avoid exposure of the A and B configuration files /for dependent projects/). (Naturally completely "excluding" logback.xml in A and B wouldn't solve my problem as it would also exclude the configuration file when running A or B themselves.) More generally, is there some tutorial or best-practice about configuring logging for easy deployment and user-tweaking with maven? I would ideally like the end-user to be easily able to modify the logging strategy, while providing him sensible defaults. Probably the logback.xml file should not be embedded in the .jar, but I don't know how to do that (and don't know if this is the best solution!) Thank you for any pointer. Olivier - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Centrally managing configuration files in a multi-module project
Thanks Brett!
It turns out that the jalopy plug-in does support multi-module projects ...
http://mojo.codehaus.org/jalopy-maven-plugin/examples/multimodule.html
Sorry for not looking at the docs a bit closer before firing off
questions on the mailing
list. But thanks anyway for drawing my attention to the dependency
plug-in. I think
I have some other problems that can be solved with it.
Best regards,
Jan van Mansum.
2008/8/28 Brett Porter <[EMAIL PROTECTED]>:
> The general approach used here can be seen in the checkstyle plugin - the
> configuration is able to be provided at either a file, URL, or within a
> repository artifact. The last option is the best since it makes advantage of
> Maven's resolution and local caching but also makes it referencable from any
> project regardless of the source hierachy.
> If jalopy doesn't support this, you can use the dependency plugin to grab
> the config, unpack it to the target directory, and then use it from there.
>
> - Brett
>
> 2008/8/27 Jan van Mansum <[EMAIL PROTECTED]>
>
>> Sorry, for the confusing message, I hit a gmail shortcut that sent the
>> mail out prematurely.
>>
>> So, again: I tried adding the following configuration to the main pom.xml:
>>
>>
>>org.codehaus.mojo
>>jalopy-maven-plugin
>>1.0-alpha-1
>>
>>${basedir}/docs/jalopy/jalopy.xml
>>
>>
>>
>>process-classes
>>
>>format
>>
>>
>>
>>
>>
>> and putting the jalopy.xml in the directory docs/jalopy relative to
>> the main project's pom.xml.
>> However, ${basedir} resolves to the base directory of the pom.xml that
>> is executed, so this
>> won't work. Is there a way to refer to the pom.xml that actually
>> declares the plugin element?
>>
>> Thanks and regards,
>>
>> Jan van Mansum.
>>
>>
>>
>>
>>
>> 2008/8/27 Jan van Mansum <[EMAIL PROTECTED]>:
>> > Hello group,
>> >
>> > I have a multi-module project and I want to use the same jalopy (code
>> > formatting)
>> > settings for all the modules. I tried to add the following to the main
>> pom.xml:
>> >
>> >
>> > ...
>> >
>> >org.codehaus.mojo
>> >jalopy-maven-plugin
>> >1.0-alpha-1
>> >
>> >
>> ${basedir}/docs/jalopy/jalopy.xml
>> >
>> >
>> >
>> >process-classes
>> >
>> >format
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> > Jan van Mansum
>> >
>>
>>
>>
>> --
>> Jan van Mansum
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
> Brett Porter
> Blog: http://blogs.exist.com/bporter/
>
--
Jan van Mansum
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Centrally managing configuration files in a multi-module project
The general approach used here can be seen in the checkstyle plugin - the
configuration is able to be provided at either a file, URL, or within a
repository artifact. The last option is the best since it makes advantage of
Maven's resolution and local caching but also makes it referencable from any
project regardless of the source hierachy.
If jalopy doesn't support this, you can use the dependency plugin to grab
the config, unpack it to the target directory, and then use it from there.
- Brett
2008/8/27 Jan van Mansum <[EMAIL PROTECTED]>
> Sorry, for the confusing message, I hit a gmail shortcut that sent the
> mail out prematurely.
>
> So, again: I tried adding the following configuration to the main pom.xml:
>
>
>org.codehaus.mojo
>jalopy-maven-plugin
>1.0-alpha-1
>
>${basedir}/docs/jalopy/jalopy.xml
>
>
>
>process-classes
>
>format
>
>
>
>
>
> and putting the jalopy.xml in the directory docs/jalopy relative to
> the main project's pom.xml.
> However, ${basedir} resolves to the base directory of the pom.xml that
> is executed, so this
> won't work. Is there a way to refer to the pom.xml that actually
> declares the plugin element?
>
> Thanks and regards,
>
> Jan van Mansum.
>
>
>
>
>
> 2008/8/27 Jan van Mansum <[EMAIL PROTECTED]>:
> > Hello group,
> >
> > I have a multi-module project and I want to use the same jalopy (code
> > formatting)
> > settings for all the modules. I tried to add the following to the main
> pom.xml:
> >
> >
> > ...
> >
> >org.codehaus.mojo
> >jalopy-maven-plugin
> >1.0-alpha-1
> >
> >
> ${basedir}/docs/jalopy/jalopy.xml
> >
> >
> >
> >process-classes
> >
> >format
> >
> >
> >
> >
> >
> >
> > --
> > Jan van Mansum
> >
>
>
>
> --
> Jan van Mansum
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Brett Porter
Blog: http://blogs.exist.com/bporter/
Re: Centrally managing configuration files in a multi-module project
Sorry, for the confusing message, I hit a gmail shortcut that sent the
mail out prematurely.
So, again: I tried adding the following configuration to the main pom.xml:
org.codehaus.mojo
jalopy-maven-plugin
1.0-alpha-1
${basedir}/docs/jalopy/jalopy.xml
process-classes
format
and putting the jalopy.xml in the directory docs/jalopy relative to
the main project's pom.xml.
However, ${basedir} resolves to the base directory of the pom.xml that
is executed, so this
won't work. Is there a way to refer to the pom.xml that actually
declares the plugin element?
Thanks and regards,
Jan van Mansum.
2008/8/27 Jan van Mansum <[EMAIL PROTECTED]>:
> Hello group,
>
> I have a multi-module project and I want to use the same jalopy (code
> formatting)
> settings for all the modules. I tried to add the following to the main
> pom.xml:
>
>
> ...
>
>org.codehaus.mojo
>jalopy-maven-plugin
>1.0-alpha-1
>
>${basedir}/docs/jalopy/jalopy.xml
>
>
>
>process-classes
>
>format
>
>
>
>
>
>
> --
> Jan van Mansum
>
--
Jan van Mansum
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Centrally managing configuration files in a multi-module project
Hello group,
I have a multi-module project and I want to use the same jalopy (code
formatting)
settings for all the modules. I tried to add the following to the main pom.xml:
...
org.codehaus.mojo
jalopy-maven-plugin
1.0-alpha-1
${basedir}/docs/jalopy/jalopy.xml
process-classes
format
--
Jan van Mansum
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Executable jar with extra directory for configuration files [ASGI]
Figured it out: you can specify manifest entry and configure class path at the same time. The result will be additive: org.apache.maven.plugins maven-jar-plugin config/ true lib/ com.barclaysglobal.asgintl.cmdlnfrmwrk.CommandProcessor Produces Class-Path: config/ lib/commons-lang-2.3.jar lib/log4j-1.2. Etc. which is exaclty what I need. > _ > From: Naftulin, Henry BGI SF > Sent: Friday, March 14, 2008 12:10 PM > To: 'users@maven.apache.org' > Subject: Executable jar with extra directory for configuration > files [ASGI] > > I have a rather simple, common problems, that probably was solved > before. I looked at both jar and assembly plug-in and did not find the > answer. > I have to produce an executable jar with dependencies and with > configuration files that I'd like to be stored outside of the jar, > like the following: > exec.jar > lib/dependecy.jar > config/configfile.prop > I was able to produce the structure, but I can't seem to figure out > how to add/modify manifest.mf file inside the exec.jar to have config > directory (which is external to all jars since we need to be able to > change the configuration) be added to the path. I have no problem > listing all the dependencies in lib directory, but is there a way to > prepend or append that extra config directory to manifest.mf? > Is there an option I can use in either jar plug-in or assembly > plug-in? Is there any other plug-in that I can use for this purpose? > Thank you, > Henry > -- This message and any attachments are confidential, proprietary, and may be privileged. If this message was misdirected, Barclays Global Investors (BGI) does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this e-mail message are the author's own and may not reflect the views and opinions of BGI, unless the author is authorized by BGI to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by BGI. Although BGI operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Executable jar with extra directory for configuration files [ASGI]
I have a rather simple, common problems, that probably was solved before. I looked at both jar and assembly plug-in and did not find the answer. I have to produce an executable jar with dependencies and with configuration files that I'd like to be stored outside of the jar, like the following: exec.jar lib/dependecy.jar config/configfile.prop I was able to produce the structure, but I can't seem to figure out how to add/modify manifest.mf file inside the exec.jar to have config directory (which is external to all jars since we need to be able to change the configuration) be added to the path. I have no problem listing all the dependencies in lib directory, but is there a way to prepend or append that extra config directory to manifest.mf? Is there an option I can use in either jar plug-in or assembly plug-in? Is there any other plug-in that I can use for this purpose? Thank you, Henry -- This message and any attachments are confidential, proprietary, and may be privileged. If this message was misdirected, Barclays Global Investors (BGI) does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this e-mail message are the author's own and may not reflect the views and opinions of BGI, unless the author is authorized by BGI to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by BGI. Although BGI operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why is there two configuration files for Maven, settings.xml and pom.xml
Hi, I am facing this problem after I put information about my Intranet repository in my settings.xml in .m2 folder. I had to do this, because m2eclipse which has the value for local settings file from \m2\settings.xml , wasn't able to download the SNAPSHOT versions from remote Intranet repository, if they were not present in the local repository(I had to configure the repository or snapshots). Everything seemed to work fine until I had to add other repository in my pom.xml(specific to the project), I added codehaus snapshots repository, but settings.xml seems to override everything now and throws an error telling could not download the required plug in from "internal-site". One way that I could thought of was to add this repository as well in the settings.xml but even after adding the error was same. Am I inferring the right reason for this or there is something else that I am not able to figure out? Could someone please guide on the same? Regards, Amit Kumar On Mon, Feb 25, 2008 at 10:17 AM, Allen, Daniel <[EMAIL PROTECTED]> wrote: > The idea is that some settings are not specific to a project > (settings.xml is just a file on your computer, not part of the build). > For example, one thing I have in settings.xml is settings for my local > web proxy. That doesn't make any sense to attach to your project, since > it's probably not applicable to everyone who wants to build said > project. And conversely, I don't have to add that to every single > project I ever try to build. > > There is some flexibility in putting certain things in either the POM or > settings.xml. You can create profiles in settings.xml, for example. This > is so that, again, you can deal with build aspects peculiar to your > particular machine. It's a fine line, but there's a pretty good page[1] > that details the concerns with putting profiles into settings.xml > without breaking portability. Or you can just see for yourself what can > go in the POM [2] and what can go in the settings [3]. > > ~Dan Allen > > > [1] > http://maven.apache.org/guides/introduction/introduction-to-profiles.htm > l > [2] http://maven.apache.org/ref/2.0.8/maven-model/maven.html - pom.xml > structre > [3] http://maven.apache.org/ref/2.0.8/maven-settings/settings.html - > settings.xml structure > -Original Message- > From: youhaodeyi [mailto:[EMAIL PROTECTED] > Sent: Sunday, February 24, 2008 2:54 AM > To: users@maven.apache.org > Subject: Why is there two configuration files for Maven, settings.xml > and pom.xml > > > Can I put the configurations in settings.xml to pom.xml? Why does maven > use > two configuration files? > > -- > This message may contain confidential, proprietary, or legally privileged > information. No confidentiality or privilege is waived by any transmission > to an unintended recipient. If you are not an intended recipient, please > notify the sender and delete this message immediately. Any views expressed > in this message are those of the sender, not those of any entity within the > KBC Financial Products group of companies (together referred to as "KBC > FP"). > > This message does not create any obligation, contractual or otherwise, on > the part of KBC FP. It is not an offer (or solicitation of an offer) of, or > a recommendation to buy or sell, any financial product. Any prices or other > values included in this message are indicative only, and do not necessarily > represent current market prices, prices at which KBC FP would enter into a > transaction, or prices at which similar transactions may be carried on KBC > FP's own books. The information contained in this message is provided "as > is", without representations or warranties, express or implied, of any kind. > Past performance is not indicative of future returns. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
RE: Why is there two configuration files for Maven, settings.xml and pom.xml
The idea is that some settings are not specific to a project (settings.xml is just a file on your computer, not part of the build). For example, one thing I have in settings.xml is settings for my local web proxy. That doesn't make any sense to attach to your project, since it's probably not applicable to everyone who wants to build said project. And conversely, I don't have to add that to every single project I ever try to build. There is some flexibility in putting certain things in either the POM or settings.xml. You can create profiles in settings.xml, for example. This is so that, again, you can deal with build aspects peculiar to your particular machine. It's a fine line, but there's a pretty good page[1] that details the concerns with putting profiles into settings.xml without breaking portability. Or you can just see for yourself what can go in the POM [2] and what can go in the settings [3]. ~Dan Allen [1] http://maven.apache.org/guides/introduction/introduction-to-profiles.htm l [2] http://maven.apache.org/ref/2.0.8/maven-model/maven.html - pom.xml structre [3] http://maven.apache.org/ref/2.0.8/maven-settings/settings.html - settings.xml structure -Original Message- From: youhaodeyi [mailto:[EMAIL PROTECTED] Sent: Sunday, February 24, 2008 2:54 AM To: users@maven.apache.org Subject: Why is there two configuration files for Maven, settings.xml and pom.xml Can I put the configurations in settings.xml to pom.xml? Why does maven use two configuration files? -- This message may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived by any transmission to an unintended recipient. If you are not an intended recipient, please notify the sender and delete this message immediately. Any views expressed in this message are those of the sender, not those of any entity within the KBC Financial Products group of companies (together referred to as "KBC FP"). This message does not create any obligation, contractual or otherwise, on the part of KBC FP. It is not an offer (or solicitation of an offer) of, or a recommendation to buy or sell, any financial product. Any prices or other values included in this message are indicative only, and do not necessarily represent current market prices, prices at which KBC FP would enter into a transaction, or prices at which similar transactions may be carried on KBC FP's own books. The information contained in this message is provided "as is", without representations or warranties, express or implied, of any kind. Past performance is not indicative of future returns. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why is there two configuration files for Maven, settings.xml and pom.xml
On Sat, 2008-02-23 at 23:53 -0800, youhaodeyi wrote: > Can I put the configurations in settings.xml to pom.xml? Why does maven use > two configuration files? The pom.xml is meant to be checked in to your version control system, and will be published to the maven repository. This should produce a "normal build" without any external settings. The settings.xml file can do per-person overrides of stuff in the pom.xml. Of course this is not normally checked in, and is never available in the maven repository. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why is there two configuration files for Maven, settings.xml and pom.xml
Can I put the configurations in settings.xml to pom.xml? Why does maven use two configuration files? -- View this message in context: http://www.nabble.com/Why-is-there-two-configuration-files-for-Maven%2C-settings.xml-and-pom.xml-tp15661726s177p15661726.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
答复: how to use maven project properties in other configuration files?
Kalle, Thanks a lot!
-邮件原件-
发件人: Kalle Korhonen [mailto:[EMAIL PROTECTED]
发送时间: 2008年1月7日 11:47
收件人: Maven Users List
主题: Re: how to use maven project properties in other configuration files?
On 1/6/08, Fred Zhang <[EMAIL PROTECTED]> wrote:
>
> My project is a multi-module project which contains an ear module and a
> war module. I need to access the property of the ear module (for the ear
> name and version) from the war module or from the project root pom.
> Is that possible to access properties of a module from another module or
> from the project root pom in maven?
>
No, but the properties declared in the parent pom (
http://maven.apache.org/pom.html#Properties) are available in the child
modules, so you'd need to organize your project so that the parent is
driving setting the properties and both ear and war are using them.
Kalle
-Original message---
> From: Kalle Korhonen [mailto:[EMAIL PROTECTED]
> Sent: Jan.04.2008 16:31
> To: Maven Users List
> Subject: Re: how to use maven project properties in other configuration
> files?
>
> Make your configuration file a filtered resource:
>
> http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html
>
> Kalle
>
> On 1/3/08, Fred Zhang <[EMAIL PROTECTED]> wrote:
> >
> > Hi there,
> > Sometimes I need to use maven project properties, e.g. ${project.version
> }
> > etc in some configuration files (not pom.xml or settings.xml). For
> > example, when I build an ear file with the name "EAR-${project.version
> }.ear",
> > I need to use this ear name in some configuration file for JNDI-lookup.
> >
> > But how can I use the maven property ${project.version} in configuration
> > files? Is there any plug-in that can make the job done?
> >
> > Thanks in advance!
> >
> > Fred Zhang
> >
> > -
> > 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]
>
>
Re: how to use maven project properties in other configuration files?
On 1/6/08, Fred Zhang <[EMAIL PROTECTED]> wrote:
>
> My project is a multi-module project which contains an ear module and a
> war module. I need to access the property of the ear module (for the ear
> name and version) from the war module or from the project root pom.
> Is that possible to access properties of a module from another module or
> from the project root pom in maven?
>
No, but the properties declared in the parent pom (
http://maven.apache.org/pom.html#Properties) are available in the child
modules, so you'd need to organize your project so that the parent is
driving setting the properties and both ear and war are using them.
Kalle
-Original message---
> From: Kalle Korhonen [mailto:[EMAIL PROTECTED]
> Sent: Jan.04.2008 16:31
> To: Maven Users List
> Subject: Re: how to use maven project properties in other configuration
> files?
>
> Make your configuration file a filtered resource:
>
> http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html
>
> Kalle
>
> On 1/3/08, Fred Zhang <[EMAIL PROTECTED]> wrote:
> >
> > Hi there,
> > Sometimes I need to use maven project properties, e.g. ${project.version
> }
> > etc in some configuration files (not pom.xml or settings.xml). For
> > example, when I build an ear file with the name "EAR-${project.version
> }.ear",
> > I need to use this ear name in some configuration file for JNDI-lookup.
> >
> > But how can I use the maven property ${project.version} in configuration
> > files? Is there any plug-in that can make the job done?
> >
> > Thanks in advance!
> >
> > Fred Zhang
> >
> > -
> > 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]
>
>
Re: how to use maven project properties in other configuration files?
Thanks Kalle!
My project is a multi-module project which contains an ear module and a war
module. I need to access the property of the ear module (for the ear name and
version) from the war module or from the project root pom.
Is that possible to access properties of a module from another module or from
the project root pom in maven?
Best Regards
Fred Zhang
-Original message---
From: Kalle Korhonen [mailto:[EMAIL PROTECTED]
Sent: Jan.04.2008 16:31
To: Maven Users List
Subject: Re: how to use maven project properties in other configuration files?
Make your configuration file a filtered resource:
http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html
Kalle
On 1/3/08, Fred Zhang <[EMAIL PROTECTED]> wrote:
>
> Hi there,
> Sometimes I need to use maven project properties, e.g. ${project.version}
> etc in some configuration files (not pom.xml or settings.xml). For
> example, when I build an ear file with the name "EAR-${project.version}.ear",
> I need to use this ear name in some configuration file for JNDI-lookup.
>
> But how can I use the maven property ${project.version} in configuration
> files? Is there any plug-in that can make the job done?
>
> Thanks in advance!
>
> Fred Zhang
>
> -
> 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]
Re: how to use maven project properties in other configuration files?
Make your configuration file a filtered resource:
http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html
Kalle
On 1/3/08, Fred Zhang <[EMAIL PROTECTED]> wrote:
>
> Hi there,
> Sometimes I need to use maven project properties, e.g. ${project.version}
> etc in some configuration files (not pom.xml or settings.xml). For
> example, when I build an ear file with the name "EAR-${project.version}.ear",
> I need to use this ear name in some configuration file for JNDI-lookup.
>
> But how can I use the maven property ${project.version} in configuration
> files? Is there any plug-in that can make the job done?
>
> Thanks in advance!
>
> Fred Zhang
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
how to use maven project properties in other configuration files?
Hi there,
Sometimes I need to use maven project properties, e.g. ${project.version} etc
in some configuration files (not pom.xml or settings.xml). For example, when I
build an ear file with the name "EAR-${project.version}.ear", I need to use
this ear name in some configuration file for JNDI-lookup.
But how can I use the maven property ${project.version} in configuration files?
Is there any plug-in that can make the job done?
Thanks in advance!
Fred Zhang
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to store configuration files?
Anywhere you want. The directory src/main/config/dev seems reasonable since you don't need these scripts in your final product (in which case, I'd say somewhere under src/main/resources). Wayne On 8/23/07, lightbulb432 <[EMAIL PROTECTED]> wrote: > > Where's the best place in the standard Maven layout to place configuration > files - I don't mean resources that end up bundled with the classes and > which are available on the final classpath, like property files. > > By configuration files, I mean things like development-time web server > scripts that are colocated with the project - but which aren't used for > production time. Where would be the best place to put this? > > Thanks. > -- > View this message in context: > http://www.nabble.com/Where-to-store-configuration-files--tf4320947s177.html#a12304815 > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > 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]
Where to store configuration files?
Where's the best place in the standard Maven layout to place configuration files - I don't mean resources that end up bundled with the classes and which are available on the final classpath, like property files. By configuration files, I mean things like development-time web server scripts that are colocated with the project - but which aren't used for production time. Where would be the best place to put this? Thanks. -- View this message in context: http://www.nabble.com/Where-to-store-configuration-files--tf4320947s177.html#a12304815 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: best practices: the location of configuration files vs resources
Hello, This question is quite common. In fact, in my opinion, the documentation is not enough clear for this point. Have a look to nabble : http://www.nabble.com/Default-location-of-config-files--%3E-Maven-Standard-Directroy-Layo-ut--tf3466078s177.html#a9672316 HTH, Rémy
Re: best practices: the location of configuration files vs resources
On 5/31/07, Tom Lambrechts <[EMAIL PROTECTED]> wrote: Hello, I found a wiki page "best practices: the location of configuration files vs resources" , but it is empty. Can somebody define this best practice and explain what the standard way is to use the src/main/config. This dir is a part of the standard directory structure of maven 2 but nowhere it is explained. Regards, Tom I don't have the answer, but src/main/config is not included by default during a jar build whereas src/main/resources is included. -- Robert Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
best practices: the location of configuration files vs resources
Hello, I found a wiki page "best practices: the location of configuration files vs resources" , but it is empty. Can somebody define this best practice and explain what the standard way is to use the src/main/config. This dir is a part of the standard directory structure of maven 2 but nowhere it is explained. Regards, Tom
Re: Newbie: running mvn test problem with configuration files and current directory
Good day, In addition to Sudheendra's message, you'd for your test resources ... ... src/test/java/resources Btw, the default resource directories for the main and for the test are src/main/resources and src/test/resources respectively. Cheers, Franz Cristian D. Romanescu wrote: > > Thanks, found the problem. I was loading the resource via: > > Thread.currentThread().getClass().getResource( "config.xml" ); > > replaced with > > getClass().getResource( "config.xml" ); > > and works fine now! > > Thank you, > Cristian. > > Singh, Sudheendra GNI CON wrote: >> Hi, >> You need to use >> >> . >>src/test/java >> target/test-classes >> >> >> Cheers, >> Sudheendra N Singh >> >> -Original Message- >> From: Cristian D. Romanescu [mailto:[EMAIL PROTECTED] >> Sent: 11 April 2007 17:25 >> To: [EMAIL PROTECTED] >> Subject: Newbie: running mvn test problem with configuration files and >> current directory >> >> Hello, >> >> I just downloaded maven and played a little bit with it. >> I have the following problem (maven 2.0.6): >> >> project structure >> >> . >> | >> src >> | main >> | | >> | java >> | test >> |java >> | |src >> | |resources >> | |myconfig.xml >> pom.xml >> >> When I run mvn test, everything works fine, sources are compiled, >> resources are copied into test-classes etc. >> When tests run, tests assumes that configuration file "config.xml" in >> current directory, which is "." and resource file went to >> ./test-classes/config.xml. >> >> I don't understand why current directory when running tests is not >> "./test-classes/". What should I do? How to tell maven which >> directory is current for runing tests? Or should I use another method to >> load configuration file? >> >> Thank you, >> Cristian. >> >> >> Here is my pom.xml >> >> >> http://maven.apache.org/POM/4.0.0"; >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 >> http://maven.apache.org/maven-v4_0_0.xsd";> >>4.0.0 >>ro.romanescu.eximius >>eximius >>jar >>1.0 >>eximius >>http://maven.apache.org >> >> >> >> org.apache.maven.plugins >> maven-compiler-plugin >> >>1.5 >>1.5 >> >> >> >> >> >> >> >>junit >>junit >>4.3.1 >>test >> >> >>log4j >>log4j >>1.2.12 >>runtime >> >> >>dom4j >>dom4j >>1.6.1 >>runtime >> >> >>jaxen >>jaxen >>1.1 >>runtime >> >> >> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> -- >> CONFIDENTIALITY NOTICE: If you have received this email in error, please >> immediately notify the sender by e-mail at the address shown. This email >> transmission may contain confidential information. This information is >> intended only for the use of the individual(s) or entity to whom it is >> intended even if addressed incorrectly. Please delete it from your files >> if you are not the intended recipient. Thank you for your compliance. >> Copyright 2007 CIGNA >> == >> >> >> - >> 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] > > > -- View this message in context: http://www.nabble.com/Newbie%3A-running-mvn-test-problem-with-configuration-files-and-current-directory-tf3560453s177.html#a9953515 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Newbie: running mvn test problem with configuration files and current directory
Thanks, found the problem. I was loading the resource via: Thread.currentThread().getClass().getResource( "config.xml" ); replaced with getClass().getResource( "config.xml" ); and works fine now! Thank you, Cristian. Singh, Sudheendra GNI CON wrote: Hi, You need to use . src/test/java target/test-classes Cheers, Sudheendra N Singh -Original Message- From: Cristian D. Romanescu [mailto:[EMAIL PROTECTED] Sent: 11 April 2007 17:25 To: users@maven.apache.org Subject: Newbie: running mvn test problem with configuration files and current directory Hello, I just downloaded maven and played a little bit with it. I have the following problem (maven 2.0.6): project structure . | src | main | | | java | test |java | |src | |resources | |myconfig.xml pom.xml When I run mvn test, everything works fine, sources are compiled, resources are copied into test-classes etc. When tests run, tests assumes that configuration file "config.xml" in current directory, which is "." and resource file went to ./test-classes/config.xml. I don't understand why current directory when running tests is not "./test-classes/". What should I do? How to tell maven which directory is current for runing tests? Or should I use another method to load configuration file? Thank you, Cristian. Here is my pom.xml http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 ro.romanescu.eximius eximius jar 1.0 eximius http://maven.apache.org org.apache.maven.plugins maven-compiler-plugin 1.5 1.5 junit junit 4.3.1 test log4j log4j 1.2.12 runtime dom4j dom4j 1.6.1 runtime jaxen jaxen 1.1 runtime - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- CONFIDENTIALITY NOTICE: If you have received this email in error, please immediately notify the sender by e-mail at the address shown. This email transmission may contain confidential information. This information is intended only for the use of the individual(s) or entity to whom it is intended even if addressed incorrectly. Please delete it from your files if you are not the intended recipient. Thank you for your compliance. Copyright 2007 CIGNA == - 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]
RE: Newbie: running mvn test problem with configuration files and current directory
Hi, You need to use . src/test/java target/test-classes Cheers, Sudheendra N Singh -Original Message- From: Cristian D. Romanescu [mailto:[EMAIL PROTECTED] Sent: 11 April 2007 17:25 To: users@maven.apache.org Subject: Newbie: running mvn test problem with configuration files and current directory Hello, I just downloaded maven and played a little bit with it. I have the following problem (maven 2.0.6): project structure . | src | main | | | java | test |java | |src | |resources | |myconfig.xml pom.xml When I run mvn test, everything works fine, sources are compiled, resources are copied into test-classes etc. When tests run, tests assumes that configuration file "config.xml" in current directory, which is "." and resource file went to ./test-classes/config.xml. I don't understand why current directory when running tests is not "./test-classes/". What should I do? How to tell maven which directory is current for runing tests? Or should I use another method to load configuration file? Thank you, Cristian. Here is my pom.xml http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 ro.romanescu.eximius eximius jar 1.0 eximius http://maven.apache.org org.apache.maven.plugins maven-compiler-plugin 1.5 1.5 junit junit 4.3.1 test log4j log4j 1.2.12 runtime dom4j dom4j 1.6.1 runtime jaxen jaxen 1.1 runtime - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- CONFIDENTIALITY NOTICE: If you have received this email in error, please immediately notify the sender by e-mail at the address shown. This email transmission may contain confidential information. This information is intended only for the use of the individual(s) or entity to whom it is intended even if addressed incorrectly. Please delete it from your files if you are not the intended recipient. Thank you for your compliance. Copyright 2007 CIGNA == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Newbie: running mvn test problem with configuration files and current directory
Hello, I just downloaded maven and played a little bit with it. I have the following problem (maven 2.0.6): project structure . | src | main | | | java | test |java | |src | |resources | |myconfig.xml pom.xml When I run mvn test, everything works fine, sources are compiled, resources are copied into test-classes etc. When tests run, tests assumes that configuration file "config.xml" in current directory, which is "." and resource file went to ./test-classes/config.xml. I don't understand why current directory when running tests is not "./test-classes/". What should I do? How to tell maven which directory is current for runing tests? Or should I use another method to load configuration file? Thank you, Cristian. Here is my pom.xml http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 ro.romanescu.eximius eximius jar 1.0 eximius http://maven.apache.org org.apache.maven.plugins maven-compiler-plugin 1.5 1.5 junit junit 4.3.1 test log4j log4j 1.2.12 runtime dom4j dom4j 1.6.1 runtime jaxen jaxen 1.1 runtime - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Surefire and Spring configuration files
Finally, I solved my problem with this config location: "classpath*:**/applicationContext-test*.xml" Regards Alexandre Alexandre Touret wrote: Hello, I programmed some testcases which run perfectly under M1.x . I moved them to M2 recently. Unfortunately, I have some troubles with the classloading of surefire. My test configuration files are stored under the directory src/test/resources. They are named as applicationContext-**-test.xml When I start mvn test, Spring doesn t load the right directory: [DEBUG] PathMatchingResourcePatternResolver - Looking for matching resources in directory tree [d:\java\src\javacommons\ccip-fk2\commons-lang\target\classes] [DEBUG] CollectionFactory - Creating [java.util.LinkedHashSet] [DEBUG] PathMatchingResourcePatternResolver - Searching directory [d:\java\src\j avacommons\ccip-fk2\commons-lang\target\classes] for files matching pattern [d:/ java/src/javacommons/ccip-fk2/commons-lang/target/classes/**/applicationContext- test*.xml] Normally, Spring should try to look for test configuration files under test-classes. I have already verified that all the files are present in this directory. I also tried to fork the process and to do the childDelegation. I have the same result What can I do ? Thanks for your help Regards, Alexandre Touret - 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]
[M2] Surefire and Spring configuration files
Hello, I programmed some testcases which run perfectly under M1.x . I moved them to M2 recently. Unfortunately, I have some troubles with the classloading of surefire. My test configuration files are stored under the directory src/test/resources. They are named as applicationContext-**-test.xml When I start mvn test, Spring doesn t load the right directory: [DEBUG] PathMatchingResourcePatternResolver - Looking for matching resources in directory tree [d:\java\src\javacommons\ccip-fk2\commons-lang\target\classes] [DEBUG] CollectionFactory - Creating [java.util.LinkedHashSet] [DEBUG] PathMatchingResourcePatternResolver - Searching directory [d:\java\src\j avacommons\ccip-fk2\commons-lang\target\classes] for files matching pattern [d:/ java/src/javacommons/ccip-fk2/commons-lang/target/classes/**/applicationContext- test*.xml] Normally, Spring should try to look for test configuration files under test-classes. I have already verified that all the files are present in this directory. I also tried to fork the process and to do the childDelegation. I have the same result What can I do ? Thanks for your help Regards, Alexandre Touret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuration files
Hey Eric, Many Many thanks for your response. I 'm trying to figure out if Maven is simply a repository of JAR only and that its more for dependency management. What ultimatly need is the ability to have a config directory with all sorts of config files from log4i to database settings, which when the app is deployed into production I can change the settings. So basically check in a directory structure to the repository. Thanks Naz -- View this message in context: http://www.nabble.com/Configuration-files-t1396714.html#a3766267 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuration files
When you say "distributed", do you mean deployed to a Maven repository? In that case, you have no choice but to package them inside of a jar (or zip, or whatever). If you mean distributed on its own, this sounds like a case of documenting to the user that they can put a file somewhere and make manual changes to it, or using some install scrip that will place a file somewhere in their system (like RPM, or MSI) and your code will find it. I guess I'm not understanding what you want Maven to do here. Eric On 4/4/06, Naz <[EMAIL PROTECTED]> wrote: > > > How to add runtime configurations to my projects - eg I want to have a > log4j > config distributed with my package and want the contents of the log4j file > modified to allow the users to change the log level. Filters are packaged > within jar so they're no good. Basically I want to have config directory > with all the config files that the users can change at will will. Thanks > -- > View this message in context: > http://www.nabble.com/Configuration-files-t1396714.html#a3756335 > Sent from the Maven - Users forum at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Configuration files
How to add runtime configurations to my projects - eg I want to have a log4j config distributed with my package and want the contents of the log4j file modified to allow the users to change the log level. Filters are packaged within jar so they're no good. Basically I want to have config directory with all the config files that the users can change at will will. Thanks -- View this message in context: http://www.nabble.com/Configuration-files-t1396714.html#a3756335 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
External configuration files
All, I decided to keep the context configuration for Tomcat 5.5 external (vs. in META-INF). That brought up the question, where to keep external configuration files in the Maven-suggested directory layout? Any ideas? Thx, Janek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where should configuration files go?
> -Original Message- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: lundi 24 octobre 2005 04:01 > To: Maven Users List > Subject: RE: Where should configuration files go? [snip] > We might want to align our notions: > > http://maven.apache.org/guides/introduction/introduction-to-the- > standard-directory-layout.html Ok, I hadn't noticed the introduction of src/main/config. > Are we going to make a distinction between resources like i18n files and > things like log4j.properties files or things like app server > configurations? I was planning on putting container configuration files in src/main/resources in order to reuse the resources tag and use the filtering mechanism in place. In the use case I'm working on, it'd be fine because I have a separate project for generate a container distribution. However I can see cases where you want to have both resources go in the artifact you're building and where you have config files that should remain outside of it. Thus I'd be all for having a separate config/ dir but we'd need to support it in the same way as we support resources in the pom (including filtering). > Just throwing this out for comment and clarification before we start > recommending things wholesale to users. Good point. [snip] -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where should configuration files go?
On Sat, 2005-10-22 at 14:05 +0200, Vincent Massol wrote: > Hi Robert, > > > -Original Message- > > From: Robert Taylor [mailto:[EMAIL PROTECTED] > > Sent: samedi 22 octobre 2005 14:03 > > To: users@maven.apache.org > > Subject: Where should configuration files go? > > > > Greetings, > > > > I'm a recent Ant-to-Maven 2.0 convert and am trying to "mavenize" some > > existing greenfield projects. > > > > In the past I have usually kept my Hibernate *.hbm.xml files in the same > > directory as their corresponding .java files because it facilitates > > referencing. Should I still keep them there, or move them to the > > /resources directory? Personally, I'ld like to keep them close to their > > corresponding .java file. > > You should move them in the resources directory but you can keep the same > package. The notion of "close" is subjective. They can be in a different > directory and still be close in your IDE view for example. > > > For testing, should I place files like log4j.properties, > > *-applicationContext.xml (Spring) files, and other configuration type > > files under the /test/resources directory? We might want to align our notions: http://maven.apache.org/guides/introduction/introduction-to-the- standard-directory-layout.html Are we going to make a distinction between resources like i18n files and things like log4j.properties files or things like app server configurations? Just throwing this out for comment and clarification before we start recommending things wholesale to users. > Exactly. Note that those files will need to be accessed using the classpath > as described on > http://maven.apache.org/guides/getting-started/index.html#How%20do%20add%20r > esources%20to%20my%20JAR? > > -Vincent > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where should configuration files go?
Vincent, thanks for advice. I'll put it to good use. /robert Vincent Massol wrote: Hi Robert, -Original Message- From: Robert Taylor [mailto:[EMAIL PROTECTED] Sent: samedi 22 octobre 2005 14:03 To: users@maven.apache.org Subject: Where should configuration files go? Greetings, I'm a recent Ant-to-Maven 2.0 convert and am trying to "mavenize" some existing greenfield projects. In the past I have usually kept my Hibernate *.hbm.xml files in the same directory as their corresponding .java files because it facilitates referencing. Should I still keep them there, or move them to the /resources directory? Personally, I'ld like to keep them close to their corresponding .java file. You should move them in the resources directory but you can keep the same package. The notion of "close" is subjective. They can be in a different directory and still be close in your IDE view for example. For testing, should I place files like log4j.properties, *-applicationContext.xml (Spring) files, and other configuration type files under the /test/resources directory? Exactly. Note that those files will need to be accessed using the classpath as described on http://maven.apache.org/guides/getting-started/index.html#How%20do%20add%20r esources%20to%20my%20JAR? -Vincent - 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]
RE: Where should configuration files go?
Hi Robert, > -Original Message- > From: Robert Taylor [mailto:[EMAIL PROTECTED] > Sent: samedi 22 octobre 2005 14:03 > To: users@maven.apache.org > Subject: Where should configuration files go? > > Greetings, > > I'm a recent Ant-to-Maven 2.0 convert and am trying to "mavenize" some > existing greenfield projects. > > In the past I have usually kept my Hibernate *.hbm.xml files in the same > directory as their corresponding .java files because it facilitates > referencing. Should I still keep them there, or move them to the > /resources directory? Personally, I'ld like to keep them close to their > corresponding .java file. You should move them in the resources directory but you can keep the same package. The notion of "close" is subjective. They can be in a different directory and still be close in your IDE view for example. > For testing, should I place files like log4j.properties, > *-applicationContext.xml (Spring) files, and other configuration type > files under the /test/resources directory? Exactly. Note that those files will need to be accessed using the classpath as described on http://maven.apache.org/guides/getting-started/index.html#How%20do%20add%20r esources%20to%20my%20JAR? -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Where should configuration files go?
Greetings, I'm a recent Ant-to-Maven 2.0 convert and am trying to "mavenize" some existing greenfield projects. In the past I have usually kept my Hibernate *.hbm.xml files in the same directory as their corresponding .java files because it facilitates referencing. Should I still keep them there, or move them to the /resources directory? Personally, I'ld like to keep them close to their corresponding .java file. For testing, should I place files like log4j.properties, *-applicationContext.xml (Spring) files, and other configuration type files under the /test/resources directory? thanks, /robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Distributing dependent resources (external configuration files)
We had a problem similar to this, but I don't think it's quite identical. We have a project that builds a jar that also has external configuration files that, when installed, may be updated by the installer to fit the user's situation (so the configuration can't be in the jar). For the project that builds the jar, I created a simple zip plugin that packages all of the configuration files into a zip file and deploys that artifact (so the project actually deploys two artifacts: the jar and the zip). The project that builds the install then uses both artifacts. It copies the jar, but extracts the zip (I have another custom plugin that does this part) so the install can copy the individual configuration files. The same sort of thing could work for your situation as well. In your case do you have another project that uses the jar and needs the configuration files in place in order to use it? It's not too hard to have a plugin extract the zip to the correct place, but having that take place as part of the dependency downloading is the tricky part (I actually don't know how you would do it--is there some goal you can attach to?). If the reason you can't have the configuration files in the jar is because it's likely the user will need to make changes to the configuration, then you wouldn't really want to overwrite those changes when extracting the zip anyway, so there would have to be some manual element to the process. What you could do is have a plugin extract the zip then automatically fix the configuration settings based on existing user settings (say from a build.properties or even project.properties). If that would work, then it would make sense to have a custom plugin for this particular jar that knows how to do this. ..David.. -Original Message- From: Chua, Hin [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 5:42 AM To: 'users@maven.apache.org' Subject: Distributing dependent resources (external configuration files) Hi, I've got a bit of a sticky problem and I was wondering if any of the Maven gurus in this list wuold be able to help. We have a common messaging package that we have set up as a Maven project in our local repository. This 'messaging project' consists of a single jar file and multiple user-editable text configuration files (which CANNOT be included inside the jar). This project utilised by several other projects in our organisation and is listed as a Maven dependency in each of the latter's project.xml files. As a result, it's very easy to update the messaging jar in the other projects as it change; we just run the Eclipse 'generate-classpath' goal to suck down the latest version of the messaging jar. However, we are unable to easily update the external configuration files; we have to manually copy these from the messaging project to any other project that utilises them. As the number of projects that utilise the messaging jar grows, this is becoming a major hassle. Is there a Maven-friendly approach to distribute these configuration files to other projects in a manner similar to distributing the messaging jar? As in, run some magical goal in a project and have all these dependent resources be updated. The only solution I can currently think of involves a lot of evil jelly/ant hackery in a custom plugin to pull the dependent resources from CVS... but surely there must be a cleaner solution? thanks in advance, Hin The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. 3167 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Distributing dependent resources (external configuration files)
Hi, I've got a bit of a sticky problem and I was wondering if any of the Maven gurus in this list wuold be able to help. We have a common messaging package that we have set up as a Maven project in our local repository. This 'messaging project' consists of a single jar file and multiple user-editable text configuration files (which CANNOT be included inside the jar). This project utilised by several other projects in our organisation and is listed as a Maven dependency in each of the latter's project.xml files. As a result, it's very easy to update the messaging jar in the other projects as it change; we just run the Eclipse 'generate-classpath' goal to suck down the latest version of the messaging jar. However, we are unable to easily update the external configuration files; we have to manually copy these from the messaging project to any other project that utilises them. As the number of projects that utilise the messaging jar grows, this is becoming a major hassle. Is there a Maven-friendly approach to distribute these configuration files to other projects in a manner similar to distributing the messaging jar? As in, run some magical goal in a project and have all these dependent resources be updated. The only solution I can currently think of involves a lot of evil jelly/ant hackery in a custom plugin to pull the dependent resources from CVS... but surely there must be a cleaner solution? thanks in advance, Hin The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. 3167
Re: Configuration Files
Hi Peter, > What is the maven.conf.dir property for? The user guide says, "The directory > that holds configuration files." Configuration files for what?? Are they > included as a 'source directory' of sorts?? What does Maven do with the > config files? Looks like maven itself doesn't use that property at all. Some plugins use it to find plugin-dependent configuration files. An example is the j2ee plugin, which uses it to locate deployment descriptors. http://maven.apache.org/reference/plugins/j2ee/properties.html > I would like Maven to slurp up my configuration files and put them on my > classpath for when I run JUnit tests with Maven. I keep all my config files > in a separate folder than the source package hierarchy. So how do I get > Maven to put them in with the classes? Is this what maven.conf.dir for?? Just add them as resources. http://maven.apache.org/reference/project-descriptor.html#unitTest_resources Best regards, -- Shinobu Kawai -- Shinobu Kawai([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Configuration Files
What is the maven.conf.dir property for? The user guide says, "The directory that holds configuration files." Configuration files for what?? Are they included as a 'source directory' of sorts?? What does Maven do with the config files? I would like Maven to slurp up my configuration files and put them on my classpath for when I run JUnit tests with Maven. I keep all my config files in a separate folder than the source package hierarchy. So how do I get Maven to put them in with the classes? Is this what maven.conf.dir for?? Thanks! Peter Melling
RE: Including dependencies and configuration files in JAR distributions
I seems that this plugin is used for executables, projects with a main. My project is deployed to a webapp that is developed by another company. And I don't want to mix our project with theirs (we don't have much control over their project). So my plan is: 1 install their project (a webapp) 2 build our project and create a zip containing the project's JAR, the dependencies, and configuration files 3 deploy our project to the webapp I'm stuck on 2. I have it done but the only problem is all my dependencies are in the binary distribution: Thanks Michael > -Message d'origine- > De : Carlos Sanchez [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 27 mai 2004 00:38 > À : 'Maven Users List'; [EMAIL PROTECTED] > Objet : RE: Including dependencies and configuration files in JAR > distributions > > > Have you tried uberjar plugin? > http://maven.apache.org/reference/plugins/uberjar/ > > Carlos Sanchez > A Coruña, Spain > > Oness Project > http://oness.sourceforge.net > > > > -Original Message- > > From: Michael Mattox [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, May 26, 2004 11:07 PM > > To: Maven Users List > > Subject: Including dependencies and configuration files in > > JAR distributions > > > > I'm using Maven to create distributions for several of our > > projects. I'm curious how people are including dependencies > > and configuration files in their distributions? So far I'm > > using a postGoal on the prepare-bin-filesystem goal with a > > copy dependencies (I forgot the tag). > > This copies ALL my JAR files. My project needs websphere's > > j2ee.jar to compile and run the unit tests, however I don't > > want to distribute this jar with my project. But I do want > > to distribute the other jars. I know the WAR plugin lets you > > set properties on the dependencies so they will be included > > or not, but I haven't found this feature for a JAR distribution. > > > > Also I have configuration files that I need to distribute. > > This is easier because I've separated them into different > > directories (src/conf.test and src/conf.dist). > > > > Any "best practices" here? Any Maven features that can help me out? > > > > Thanks, > > Michael > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- This E-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return E-mail. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Including dependencies and configuration files in JAR distributions
I'm using Maven to create distributions for several of our projects. I'm curious how people are including dependencies and configuration files in their distributions? So far I'm using a postGoal on the prepare-bin-filesystem goal with a copy dependencies (I forgot the tag). This copies ALL my JAR files. My project needs websphere's j2ee.jar to compile and run the unit tests, however I don't want to distribute this jar with my project. But I do want to distribute the other jars. I know the WAR plugin lets you set properties on the dependencies so they will be included or not, but I haven't found this feature for a JAR distribution. Also I have configuration files that I need to distribute. This is easier because I've separated them into different directories (src/conf.test and src/conf.dist). Any "best practices" here? Any Maven features that can help me out? Thanks, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
