Re: Maven environment configurations
Hi Mark, It sounds like you're right on the money. What you're looking to create is a distribution artifact using the maven assembly plugin. This will create a tar or zip which you can layout however you need to. I typically use this to create a zip file that has a bin directory for startup scripts, a conf directory for configuration files, and a lib directory for all of the jars. Hope this helps, Joe Hindsley On 07/14/2011 09:58 AM, mark.angrish wrote: I sent this to Anders Hammar but i thought i would cross post this to the community as well: In the past i have used profiles for environment configuration (uat, prod etc.) but as most people know this becomes quite problematic (different profile causes rebuild and redploy with env specific settings etc. and what's more maven forces the recompilation.. i can think of a million more reasons too!) What i currently have is just plan java projects (no j2ee, or frameworks etc.) that are client/server based. I typically end up with a client, a server and a 'common' jar that is shared by both other artifacts. I also have a parent pom to control dependencies across all artifacts (but they are not modules as the gui can increment independantly of the server). -project-name - pom.xml -project-name-gui - src/main/java - src/main/resources - pom.xml -project-name-common - src/main/java - src/main/resources - pom.xml -project-name-server - src/main/java - src/main/resources - pom.xml All the resources directories here contain nothing but 'static' resources (images, dictionary files, static templates for 3rd parties i.e. these don't change and if they did, it would be for development reasons). It's at this point i get frustrated! What i need to achieve is: - being able to run a configured version of the server for my desktop (local) environment that can be run inside my IDE (eclipse or IDEA). This is of a very high importance to my team. - being able to deploy a configured version of the server to a particular environment (DEV, UAT, PROD etc.). - I don't have a database or a ubiquitious jndi server available (machines are across firewalls) to store configuration. It also seems like overkill for what we need. My current idea is as follows: Create a project calledproject-name-build (or -package) which is a jar project that only contains resource and deployment type directories. This should allow me to develop locally and release to different environments but it does place an environment specific version of my 'resources' jar into the repository (due to running the assembly). This dependency can be implemented if i make the server's pom depend on this artifact. This project would also have the assembly descriptor to create my environment specific tarballs as well. I don't like this idea at all but i cannot think about how better to seperate the jar build from the act of development and deployment! -project-name-build - src/main/filters - src/main/config - src/main/assembly - src/main/sql - src/main/scripts - pom.xml Any help you could give me here would be greatly appreciated! -- View this message in context: http://maven.40175.n5.nabble.com/Maven-environment-configurations-tp4586719p4586719.html Sent from the Maven - Users mailing list archive at Nabble.com. - 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: Maven 2: How can I avoid hard-coding the version multiple times?
Hi Dave, If you want to inherit the parent's groupId and version values, you simply remove them from the child's pom definition. In your case, the child pom would look like: parent groupIdMyco.galc.capitol.tours/groupId artifactIdMyco-galc-capitol-tours/artifactId version1.0-SNAPSHOT/version /parent nameMyco GA Capitol Tours Webapp/name descriptionMyco GA Capitol Tours Webapp/description artifactIdMyco-galc-capitol-tours-webapp/artifactId packagingwar/packaging We also do this for our multi-module projects since it makes dependency management a little easier. Hope this helps, Joe Hindsley laredotornado wrote: Hi, I'm using Maven 2.2. In my maven project, I have this fragment in my pom.xml at the project root ... nameMyco GA Capitol Tours/name descriptionMyco GA Capitol Tours/description inceptionYear2009/inceptionYear groupIdMyco.galc.capitol.tours/groupId artifactIdMyco-galc-capitol-tours/artifactId version1.0-SNAPSHOT/version packagingpom/packaging Then I have a webapp sub-folder and I have this in the webapp/pom.xml ... parent groupIdMyco.galc.capitol.tours/groupId artifactIdMyco-galc-capitol-tours/artifactId version1.0-SNAPSHOT/version /parent nameMyco GA Capitol Tours Webapp/name descriptionMyco GA Capitol Tours Webapp/description artifactIdMyco-galc-capitol-tours-webapp/artifactId version1.0-SNAPSHOT/version packagingwar/packaging You'll notice I have 1.0-SNAPSHOT hard-coded a couple of times in my webapp/pom.xml. Is there any way I can replace that with something that will be automatically inherited from the parent? Thanks, - Dave - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2: How can I avoid hard-coding the version multiple times?
Dave, Yes. Child poms should always explicitly name their parents. The reason for this is that you might have a parent pom that exists in the repository and not in your directory structure. In order for maven to be able to find that pom, it will need the repository 'coordinates'. An example of where this type of pom would be useful is for companies that have multiple projects going which need to keep their dependency and plugin versions in sync. Cheers, Joe Hindsley laredotornado wrote: Thanks, Joe. So we do keep the version element within the parent element? Thus, the version appears in both the pom.xml in the root and also in the webapp/pom.xml ? - Dave Joe Hindsley wrote: Hi Dave, If you want to inherit the parent's groupId and version values, you simply remove them from the child's pom definition. In your case, the child pom would look like: parent groupIdMyco.galc.capitol.tours/groupId artifactIdMyco-galc-capitol-tours/artifactId version1.0-SNAPSHOT/version /parent nameMyco GA Capitol Tours Webapp/name descriptionMyco GA Capitol Tours Webapp/description artifactIdMyco-galc-capitol-tours-webapp/artifactId packagingwar/packaging We also do this for our multi-module projects since it makes dependency management a little easier. Hope this helps, Joe Hindsley laredotornado wrote: Hi, I'm using Maven 2.2. In my maven project, I have this fragment in my pom.xml at the project root ... nameMyco GA Capitol Tours/name descriptionMyco GA Capitol Tours/description inceptionYear2009/inceptionYear groupIdMyco.galc.capitol.tours/groupId artifactIdMyco-galc-capitol-tours/artifactId version1.0-SNAPSHOT/version packagingpom/packaging Then I have a webapp sub-folder and I have this in the webapp/pom.xml ... parent groupIdMyco.galc.capitol.tours/groupId artifactIdMyco-galc-capitol-tours/artifactId version1.0-SNAPSHOT/version /parent nameMyco GA Capitol Tours Webapp/name descriptionMyco GA Capitol Tours Webapp/description artifactIdMyco-galc-capitol-tours-webapp/artifactId version1.0-SNAPSHOT/version packagingwar/packaging You'll notice I have 1.0-SNAPSHOT hard-coded a couple of times in my webapp/pom.xml. Is there any way I can replace that with something that will be automatically inherited from the parent? Thanks, - Dave - 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 practice on releasing a webapp (war-file)
Hi Ludwig, The cargo plugin is what you're looking for: http://cargo.codehaus.org/Maven2+plugin Cheers, Joe Hindsley Ludwig Magnusson wrote: Hi! We are developing a webapp which is packaged in a war-file. I wonder how we can use maven for releasing new versions to our actual server and our staging server. I have tested the deploy function and read about the release function but these seem to serve a different purpose than the one I'm after. They seem to be developed for the purpose of releasing jar-libraries into a repository where other users can download them (no big surprise really ;) ). But can they be modified for releasing my war-file directly into my web servers webapp folder? I'm also open for other best practices on releasing webapps. /Ludwig - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [WAR-plugin] Can I put my resources in their original folder?
Hi Ludwig, I would recommend putting those directories and files in the src/main/webapp directory. The maven war plugin puts everything under src/main/webapp into the base of the war. In your case: src/main/webapp/external-resource.jpg src/main/webapp/image2/external-resource2.jpg would give you the war layout: ./external-resource.jpg ./image2/external-resource2.jpg Hope this helps, Joe Hindsley Ludwig Magnusson wrote: The first example on this page http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering- webresources.html http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-w ebresources.html says that resources outside the src folder will be placed in the root of the war Ex, with this filestructure: |-- pom.xml |-- resource2 | |-- external-resource.jpg | `-- image2 | `-- external-resource2.jpg //more structure And this configuration of the war-plugin configuration webResources resource !-- this is relative to the pom.xml directory -- directoryresource2/directory /resource /webResources /configuration The war file will be structured like this: //more structure |-- external-resource.jpg |-- image2 | `-- external-resource2.jpg Is it possible to structure the war-file like the original filestructure? I.e having all the extra resources in the resource2-folder, and that folder in the root of the war-file? /Ludwig - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [WAR-plugin] Can I put my resources in their original folder?
Ludwig, I think I misunderstood what you were asking in the original email. Let me try again... If I understand correctly, you want to keep the 'external' resource directory name in the root of the war instead of copying it's contents to the root of the war. This can be accomplished by adding a targetPath element to the resource definition. My example below assumes you are renaming the resource2 directory to myTarget in the war. In your case, with a webResource definition like: configuration webResources resource directoryresource2/directory targetPathmyTarget/targetPath /resource /webResources /configuration Applied to a project layout like: pom.xml resource2/external-resource.jpg resource2/image2/external-resource2.jpg src/main/webapp/WEB-INF/web.xml ... Would produce a war layout like: myTarget/external-resource.jpg myTarget/image2/external-resource2.jpg WEB-INF/web.xml Hopefully this is the answer you're looking for. Joe Hindsley Ludwig Magnusson wrote: But the problem is that I configure my webapp with property files. Some properties point to other files. Won't those links be wrong in any case since the files will be in a new directory? I suppose I could use separate configurations for development and live but it seems like a lot of work. I don't really understand why the structure needs to be different. /Ludwig -Original Message- From: Joe Hindsley [mailto:jhinds...@gmail.com] Sent: den 20 november 2009 17:02 To: Maven Users List Subject: Re: [WAR-plugin] Can I put my resources in their original folder? Hi Ludwig, I would recommend putting those directories and files in the src/main/webapp directory. The maven war plugin puts everything under src/main/webapp into the base of the war. In your case: src/main/webapp/external-resource.jpg src/main/webapp/image2/external-resource2.jpg would give you the war layout: ./external-resource.jpg ./image2/external-resource2.jpg Hope this helps, Joe Hindsley Ludwig Magnusson wrote: The first example on this page http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering- webresources.html http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-w ebresources.html says that resources outside the src folder will be placed in the root of the war Ex, with this filestructure: |-- pom.xml |-- resource2 | |-- external-resource.jpg | `-- image2 | `-- external-resource2.jpg //more structure And this configuration of the war-plugin configuration webResources resource !-- this is relative to the pom.xml directory -- directoryresource2/directory /resource /webResources /configuration The war file will be structured like this: //more structure |-- external-resource.jpg |-- image2 | `-- external-resource2.jpg Is it possible to structure the war-file like the original filestructure? I.e having all the extra resources in the resource2-folder, and that folder in the root of the war-file? /Ludwig - 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: Assembly plugin: specifying an alternative extension name for the assembly
Hi Graham, The extension for the assembly is configured with the format element of the assembly descriptor. There are only a couple of supported formats. My guess is that you'd have to write a custom Archiver to get a different extension, but haven't looked under the hood of the assembly plugin to know for sure. More information is here: http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_assembly Joe Hindsley Graham Charters wrote: Hi, I'm trying to create a zip file using the assembly plugin, but I'd like it to have a different extension (not .zip). I've tried using finalName/, but that still insists on giving the file the .zip extension. Is this possible using the assembly plugin, or should I be using something else? Many thanks for any help. Regards, Graham. - 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 proxies problem
You might try adding an id element to each of the settings to make them distinct. From http://maven.apache.org/settings.html#Proxies: id - The unique identifier for this proxy. This is used to differentiate between proxy elements. Joe Hindsley Koerner, Ron wrote: Hi list, I use several repositories which are both http and https. So I added this to settings.xml: proxies proxy activetrue/active protocolhttps/protocol hostproxy/host port81/port /proxy proxy activetrue/active protocolhttp/protocol hostproxy/host port81/port /proxy /proxies where proxy is our internal proxy. No it seems that maven only ever uses the first entry, so in the current configuration I can download from https-repositories while http-repositories are contacted directly (which fails due to firewalls). If I swap the entries I can download from http-repositories but not from https... I think (but cannot prove it) that this behaviour is new with maven 2.2.0, while everything was ok with 2.0.8. Is this a bug or am I doing something wrong? Thanks, Ron - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Jar packaging. Produce more artifacts, in addition to jar
Hi Alexi, The way we've done this is to package the applicationContext.xml in the war - not in the jar. You can do this by adding it to the war's src/main/resources directory. In order to run unit tests in the jar module, we have added an applicationContext.xml in the jar's src/test/resources directory. Keeping the applicationContext.xml out of the jar will help keep weird class path issues from cropping up if you try to 'override' it. Plus, we feel like it's the top most package's responsibility to configure the spring environment. There's probably a better way to do it, so hope that others will chime in with their ideas as well. One other suggestion is to use JNDI to supply your DataSource instead of having a jndi.properties file. This way you don't have to unpack the war to make configuration changes - they'll be part of the container's configuration. The more you can delegate to the container the less you have to fiddle with at deployment time. Hope this helps, Joe Hindsley Alexi Polenur wrote: Hi all, I am trying to setup a multi-module project. One module produce a JAR (jar-module) and another one a WAR which uses jar produced by jar-module. jar-modules has some configuration files - Spring xml and .property files. Rather then package them as part of the jar I wanted to deploy them into WEB-INF/classes directory of the war, to allow end user easy customization. I am new to Maven and wondering what is the best way to do it. First thing which comes to my mind is following. 1. Make jar module produce additional artifacts, let say jdbc.properties and applicationContext.xml 2. Make WAR module depend not only on jar but also on additional artifacts above. 3. Somehow configure WAR module build process to get this artifacts from repository and install them into WEB-INF/classes of the war file. Is it right approach or there is better, simpler approach. If it is right approach can somebody point me in direction of how to achieve it. Such as how I install additional artifacts in 1. above and then how I do 3. Thanks, Alexi - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Jar packaging. Produce more artifacts, in addition to jar
Hi Alexi, Thanks for clarifying. So what you could do is keep the applicationContext.xml packaged in your jar and update your war's POM to use the dependency:unpack mojo to copy it to the right location to be included in your war. The dependency plugin page has an example of unpacking specific artifacts: http://maven.apache.org/plugins/maven-dependency-plugin/examples/unpacking-artifacts.html The end result is that the war classpath will have two applicationContext.xml files, but the one packaged in the war *should* resolve before the one in the jar allowing you to make tweaks to it to change the behavior. This assumes that you are loading the Spring context from the classpath (eg. classpath:/applicationContext.xml). I've not tried this before so can't give you specific examples, but hopefully this points you to a solution that works. Joe Hindsley apolenur wrote: Hi Joe, Thanks for spending your time and share your experience. I don't think that solution you are proposing will work in our context. I see 2 issues with approach you are proposing 1. I have to maintain 2 copies of applicationContext.xml one in WAR and one in JAR (for testing). 2. My JAR is really an independent module which can be used in WAR as well as in other environment.The content of applicationContext.xml from JAR just used by Java code in my jar, it is never directly loaded or used by java code in my WAR. The combination of jar and applicationContext.xml really forms an independent module - jar has classes and applicationContext.xml has configuration for them. Thus I really like to maintain applicationContext.xml withing my jar module src tree and then deploy it together with jar into what ever environment which need to use services from my jar. Joe Hindsley wrote: Hi Alexi, The way we've done this is to package the applicationContext.xml in the war - not in the jar. You can do this by adding it to the war's src/main/resources directory. In order to run unit tests in the jar module, we have added an applicationContext.xml in the jar's src/test/resources directory. Keeping the applicationContext.xml out of the jar will help keep weird class path issues from cropping up if you try to 'override' it. Plus, we feel like it's the top most package's responsibility to configure the spring environment. There's probably a better way to do it, so hope that others will chime in with their ideas as well. One other suggestion is to use JNDI to supply your DataSource instead of having a jndi.properties file. This way you don't have to unpack the war to make configuration changes - they'll be part of the container's configuration. The more you can delegate to the container the less you have to fiddle with at deployment time. Hope this helps, Joe Hindsley Alexi Polenur wrote: Hi all, I am trying to setup a multi-module project. One module produce a JAR (jar-module) and another one a WAR which uses jar produced by jar-module. jar-modules has some configuration files - Spring xml and .property files. Rather then package them as part of the jar I wanted to deploy them into WEB-INF/classes directory of the war, to allow end user easy customization. I am new to Maven and wondering what is the best way to do it. First thing which comes to my mind is following. 1. Make jar module produce additional artifacts, let say jdbc.properties and applicationContext.xml 2. Make WAR module depend not only on jar but also on additional artifacts above. 3. Somehow configure WAR module build process to get this artifacts from repository and install them into WEB-INF/classes of the war file. Is it right approach or there is better, simpler approach. If it is right approach can somebody point me in direction of how to achieve it. Such as how I install additional artifacts in 1. above and then how I do 3. Thanks, Alexi - 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: How to use maven to gather all (or some) dependent jar files
The way I've done this in the past is to use the assembly plugin to generate a distribution zip/tar. The unpacked structure looks like: /bin /lib /conf /log In the bin directory, you would add a shell script that sets up the runtime environment and invokes the mule runtime. The lib directory would be the destination of all of the dependency jars. The conf directory would hold your mule, log4j, db, etc configuration files. The log directory would be the destination for any log files created when running mule. The advantage to this method is that you shouldn't have to touch your base installation of mule to run your application. Hope this helps, Joe Hindsley Steve Lihn wrote: Hi, When maven builds a project, it figures out all the dependent jar files, adds them to the classpath, produces the project's jar file under target/. My question is -- is there a way to ask maven also puts all (or some) those dependent jar files under target/ too. The origin of the issue is that we have a project that builds a jar for Mule. However, when deploying this jar file to Mule, we still have to collect all the dependent jar files that Mule does not have and place them under Mule's lib/user/ folder. So every time we upgrade a dependency, for instance, json-lib from 2.2.2 to 2.2.3, we not only have to modify the pom.xml, but also look for json-lib 2.2.3 jar and make sure we upgrade it in lib/user/. Wouldn't it be easier if maven can figure these all out for us since it is all in pom.xml ? Thanks, Steve - 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
