I'm creating a project which is on two modules: service and web
in service i'am injecting beans with properties defined in web module. properties depends on profiles defined in web module.
at jetty start a spring errors have been displayed informing me that he can't read properties so he can't instanciate beans.
So how to declare properties in web module and use them in service module?
in service module I'am injecting a bean which uses properties declared in another module
<bean id="universignService"
class="fr.lfm.dna.service.file.document.impl.UniversignServiceImpl"
autowire="byName" init-method="initWebService" lazy-init="true">
<property name="url" value="${ws.universign.url}">
</property>
<property name="username" value="${dna.ws.universign.username}">
</property>
<property name="password" value="${dna.ws.universign.password}">
</property>
</bean>
Well, as I understand, you have 2(ServiceProject and WebProject) maven projects. In ServiceProject you want to use propeties from WebProject/pom.xml. The thing is Spring doesn't know anything about this file.
There are few options, if you want to share these properties for multiple projects.
1) The first that comes to my mind is to create a parent maven-project. It's going to be a project with just one pom.xml, where you can define your properties in properties section.
<project xmlns="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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.test</groupId>
<artifactId>parent</artifactId>
<version>1.0.SNAPSHOT</version>
<properties>
<dna.ws.universign.username>ABC</dna.ws.universign.username>
<dna.ws.universign.password>XYZ</dna.ws.universign.password>
</properties>
</project>
After you do this, you can refer to this project in other projects.
<project xmlns="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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.test</groupId>
<artifactId>web</artifactId>
<parent>
<groupId>com.test</groupId>
<artifactId>parent</artifactId>
<version>1.0.SNAPSHOT</version>
</parent
</project>
As a result, properties from you parent project are included in your actual project (com.tests.web in my example).
2) Speaking of storing an username and a password, it might be more convenient and more natural to store them in an external *.properties file. In this case you don't need to create a parent project. Try to take a look at maven-properies-plugin.
Whether way you chose, after your properties are defined on maven-level, you should pass it to spring config. In case you use xml-configuration (like in your post), you should ask maven to process files with such ${...} placeholders. Just put this xml in your pom.xml:
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
<includes>
<include>spring-config.xml</include>
</includes>
</resource>
</resources>
</build>
Where spring-config.xml is a file, where you store your configuration. After this, properties can be injected by Spring.
Related
The application landscape consists of several domains with dozens of projects (Maven modules) which can be turned on or off via simple mouse clicks in IntelliJ IDEA.
This is how these modules are defined via profiles in Maven:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>at.wrwks.pipe</groupId>
<artifactId>pipe.reactor.blue</artifactId>
<version>0.0.0-SNAPSHOT</version>
<packaging>pom</packaging>
<profiles>
<profile>
<id>modules-blueops</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<modules>
<module>../../blueops/blueops.reactor</module>
</modules>
</profile>
...
How can this be achieved with Gradle also in IDEA? I haven't found a profile-equivalent in Gradle yet, using if/else in the build script is cumbersome and there is no UI support for such custom steps.
I am hosting a Local Repository with 80+ Jar files which are related to our internal Project
Something like this
I want to add a tag in my Maven pom.xml where in I retrieve all the jar files in one shot when I create a new project in Eclipse.
These jars are static and will not change.
Can anyone please help in setting up this?
In Artifactory - "Set me Up", I can see this TAG, but its for pushing a final jar
You have at least two options:
1. Use a parent pom
Add all the 80 dependencies to a POM which looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>your.company</groupId>
<artifactId>ourDependencies</artifactId>
<version>1.0.0</version>
<packaging>pom</packaging> <!-- IMPORTANT -->
<dependencies>
<!-- place here 80 dependencies -->
<dependency>
...
</dependency>
</dependencies>
<build> <!-- optional -->
<plugins>
<plugin>
...
</plugin>
</plugins>
</build>
<distributionManagement>
... <!-- optional -->
</distributionManagement>
</project>
In the project that needs the dependencies, add a <parent> element to the pom.xml:
<project>
<groupId>your.company</groupId>
<artifactId>newApplication</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging> <!-- or war or ... -->
....
<parent>
<groupId>your.company</groupId>
<artifactId>ourDependencies</artifactId>
<version>1.0.0</version>
</parent>
...
</project>
Keep in mind that every project can have only one parent.
2. Create an archetype
This way is more complex. You can create a simple project similar to "HelloWorld" which contains all the dependencies. Based on this project, you can create an archetype which serves as a template when you create a new Maven project.
More Informations:
Introduction to archetypes
archetype tutorial
I'm trying to filter an application.xml file generated by the maven-ear-plugin using file filters. My project structure is the standard for Maven.
Here is my POM file:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>test</groupId>
<artifactId>test-filter</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>ear</packaging>
<properties>
<prop1>xyz</prop1>
</properties>
<build>
<plugins>
<plugin>
<artifactId>maven-ear-plugin</artifactId>
<version>2.10.1</version>
<configuration>
<version>6</version>
<env-entries>
<env-entry>
<env-entry-name>env1</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>${prop1}</env-entry-value>
</env-entry>
</env-entries>
</configuration>
</plugin>
</plugins>
</build>
</project>
Up to here everything works fine. The plugin generates an application.xml file containing the env1 entry with the interpolated value xyz.
The problem is when I move the Maven property prop1 to a properties file and configure a filter:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>test</groupId>
<artifactId>test-filter</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>ear</packaging>
<build>
<filters>
<filter>src/main/filters/filter.properties</filter>
</filters>
<plugins>
<plugin>
<artifactId>maven-ear-plugin</artifactId>
<version>2.10.1</version>
<configuration>
<version>6</version>
<env-entries>
<env-entry>
<env-entry-name>env1</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>${prop1}</env-entry-value>
</env-entry>
</env-entries>
</configuration>
</plugin>
</plugins>
</build>
</project>
For my understanding of the filters feature, it is equivalent as the properties but using a separate file. Nonetheless, the generated application.xml contains the entry env1 without interpolating ${prop1}.
Of course the file src/main/filters/filter.properties exists and contains:
prop1=abc
Is there something I am missing?
My guess is that the order in which the plugins run does not work in your favor.
The ear plugin creates the application.xml quite early on: http://maven.apache.org/plugins/maven-ear-plugin/generate-application-xml-mojo.html in process during "generate-resources".
The resources plugin that does the filtering runs in the next phase: http://maven.apache.org/ref/3.3.9/maven-core/default-bindings.html#Plugin_bindings_for_ear_packaging
So the properties are probably not read at the time the application.xml is generated.
An option would be to use the properties plugin: http://www.mojohaus.org/properties-maven-plugin/usage.html and bind it to an early phase to have them available for filtering in the ear plugin.
I am starting to work on a poorly documented Maven project. I have set up my profile for the project but I may or may not be missing property definitions that used during resource filtering. By default, if a property is not defined in a filtered file, the variable name is left in the copied resource and Maven continues silently.
Is there a way to force Maven to fast-fail in this case?
As a minimal example, take this pom,
<project xmlns="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">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>my-app</name>
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
<profiles>
<profile>
<id>production</id>
<properties>
<foo>Craig</foo>
</properties>
</profile>
</profiles>
</project>
And have a resource to filter:
echo 'Hello, my name is ${foo}!' > src/main/resources/test
Then running mvn clean install -Pproduction produces a file that says Hello, my name is Craig! while running mvn clean install produces a file that says Hello, my name is ${foo}!.
So my question is; how do I force Maven to fail in the second case?
JIRA issues exist for this feature in The Codehause database:
MRESOURCES-163 Filtering: check if there are any placeholders that were not substituted
MRESOURCES-162 Fail build if resource not fully filtered
You can log in and vote for them. Unfortunately the demand for this important safety net feature seems to be low ... strange.
Of course, the Apache Maven Enforcer Plugin is your friend, especially the RequireProperty Rule
I have an enterprise application which I am in the process of converting from an Ant build to Maven. It's almost completely converted; this is the very last thing I need to fix. The application is packaged as an EAR file which contains two WARs and has a JAR module which provides all of the core functionality of the application.
I'm using the Freemarker templating library to generate, among other things, message bodies for automatic emails sent by the application. Freemarker needs its *.ftl template files to be on the classpath, and since this is core application functionality not specific to one WAR or the other, it needs to be in the JAR.
The Maven module which defines the JAR has the following POM:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<relativePath>../../pom.xml</relativePath>
<groupId>com.company.project</groupId>
<artifactId>projectName</artifactId>
<version>1.8.0</version>
</parent>
<artifactId>core</artifactId>
<packaging>jar</packaging>
<name>Core Application</name>
<profiles>
<!-- snip -->
</profiles>
<dependencies>
<!-- snip -->
</dependencies>
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
<includes>
<include>**/*.ftl</include>
<include>**/*.properties</include>
<include>**/*.xml</include>
</includes>
</resource>
</resources>
<plugins>
<!-- snip -->
</plugins>
</build>
</project>
The *.ftl files are located at src/main/resources/template/, with some in a subdirectory within template/. There are other files within src/main/resources -- some .properties and some .xml, some at the root and some under a directory structure.
When I run the package phase on this module (or on the parent), the target/classes directory created as part of the build process contains the template directory, which in turn contains all of the *.ftl, *.xml, and *.properties files with an appropriate directory structure. If I JAR this directory up manually, everything works perfectly.
Here's where this gets weird and I get lost: when maven-jar-plugin creates the JAR, it includes the XML and properties files, but the template directory is completely absent from the JAR and its contents are nowhere to be found.
As you can see above, I tried explicitly including **/*.ftl. It doesn't make a difference; I can exclude the entire "includes" tag and I get the exact same behavior.
I'm using Maven 3.0.5 and maven-jar-plugin 2.4.
I figured out the answer RIGHT after submitting this question.
In a parent POM, I had the following:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<includes>
<include>**/*.class</include>
<include>**/*.jdo</include>
<include>**/*.properties</include>
<include>**/*.xml</include>
</includes>
</configuration>
</plugin>
I added **/*.ftl to the list of includes and now it's working.
EDIT: Better yet, I removed the configuration tag entirely, and it's still working. I think it was a remnant from before I figured out that the .properties files and other things I needed on the classpath needed to be in src/main/resources and not src/main/java.