views:

1084

answers:

2

Hi everyone,

Currently trying to package a small app in such a way that our ops team has a much easier time to deploy it. My requirements are that the projects gets compiled and zipped up.

I run the command "mvn -DmyProfile clean generate-sources package" from the command line and I have created a src.xml file that details where which file should go on top of declaring the use of zip format for the output.

As a result I get 2 files in my target folder, a jar and a zip file. The zip file is structured exactly how I need it, except my properties files didn't get injected with the right values from the POM. Instead all the {variables} are still there. The jar on the other hand seems to have all the right values injected, but the structure of the jar is not the one I need.

The kicker is this problem is occurring only since I've tried to add Java Service Wrapper to my project and needed to have the src.xml file to declare where all the new files should go in the project folder structure. Before that, the exact same command would work perfectly and even the jar structure was more consistent with the actual project structure in Eclipse.

Not blaming the Java Service Wrapper, just wondering if by trying to have everything working fot that piece, I didn't create a conflict with the MVN assembly.

Any help is much appreciated.

Thanks, Yann

A: 

So it turns out Maven creates a "snapshot" jar that gets included in the lib folder inside the Zip archive. That snapshot jar contains the config files injected with the right values. In other words if you load your config files using the class loader instead of a file system reference it should work.

At any rate I was told not to put the config files at the root of the Zip archive. So the config files that Maven was just pushing in the archive without injecting them shouldn't even be there in the first place in my case.

But here is the new content of my src.xml file that gets included within the pom.xml:

<assembly>
<id>bin</id>
<includeBaseDirectory>false</includeBaseDirectory>
<formats>
 <format>zip</format>
</formats>
<fileSets>
 <fileSet>
  <directory>src/main/bin</directory>
  <outputDirectory>/bin</outputDirectory>
  <includes>
   <include>**/*.sh</include>
  </includes>
  <fileMode>777</fileMode>
 </fileSet>
 <fileSet>
  <directory>lib</directory>
  <outputDirectory>/lib</outputDirectory>
  <includes>
   <include>**/*.jar</include>
  </includes>
 </fileSet>
 <!-- Wrapper files -->
 <fileSet>
  <directory>lib/wrapper</directory>
  <outputDirectory>/lib</outputDirectory>
  <includes>
   <include>**/*</include>
  </includes>
 </fileSet>
 <fileSet>
  <directory>src/main/bin/wrapper</directory>
  <outputDirectory>/bin/wrapper</outputDirectory>
  <includes>
   <include>**/*</include>
  </includes>
  <fileMode>777</fileMode>
 </fileSet>
 <fileSet>
  <directory>src/main/conf</directory>
  <outputDirectory>conf</outputDirectory>
  <includes>
   <include>**/*</include>
  </includes>
 </fileSet>
</fileSets>
<dependencySets>
 <dependencySet>
  <outputDirectory>/lib</outputDirectory>
  <includes>
   <include>*:jar:*</include>
  </includes>
  <excludes>
   <exclude>*:sources</exclude>
  </excludes>
 </dependencySet>
</dependencySets></assembly>

That still outputs a jar and a zip archive, but since the zip contains the snapshot jar everything should be fine now.

EXCEPT... (and that might be for another post so let me know if I go off topic for this question)

That the values injected in the config files aren't the one from the profile within my POM.xml. They are the ones from my settings.xml that lives in my .m2 folder. But turning off the activation in the settings.xml profile doesn't seem to solve this issue:

<activation>
<activeByDefault>false</activeByDefault>
</activation>

Again here is the command line I run:

mvn -Denv-prod clean generate-sources package

Where "env-prod" is the profile in the pom.xml containing the values to be injected.

Any idea?

Lancelot
A: 

Ok so I found the answer to my second problem. The maven command was wrong, what I executed successfully was:

mvn clean package -P env-prod

And that put the right values to the right places in my config files. Note the use of the switch -P instead of -D to select the profile.

Lancelot
-D defines a property, which can be optionally used to trigger a profile to activate. -P directly activates a profile no matter what is has for activation rules in the pom.xml
Matthew McCullough