I've got a maven project that will consume a number of webservices. The application will be packaged as a WAR. So far the clients' code has been generated with cxf-codegen-plugin, in the generate-sources phase. By default, generated sources are placed into target/generated-sources/cxf, and after compile, they are compiled and mixed up with the application classes in target/classes. Both the generated and application classes can share the first level packages.
I'd like each of the clients to be packaged in its own JAR inside WEB-INF/lib in the WAR file. I found out about -clientjar, but it only generates the .jar files and places them into target/generated-sources/cxf, and the JARs also end up in target/classes along with the compiled classes, which is pointless.
I suppose the compile plugin at some point is compiling the generated sources into target/classes, and possibly another phase is also moving the JARs there. Would it be possible to have Maven avoid compiling those generated sources (or even have cxf-codegen-plugin generate no sources at all, only the JARs), and compile the application classes against the JARs generated by CXF?
I know it would be possible to achieve this by defining a multimodule project with a jar packaging module for each webservice, but I'd like to avoid this option. There can be a large number of webservices and it would not be suitable to maintain an independent module for each one. With -clientjar I'm already forced to define a <wsdlOption> for each WSDL in order to provide the JAR name for each WSDL (it's not possible to let cxf-codegen-plugin just scan src/main/resources/wsdl or <wsdlRoot>).
Of course the client JARs could be generated outside Maven and installed to a local repository, and be defined as dependencies in the project, but I'd like to know if it's possible to do this in a single Maven build.
With assemblies I'd probably sort out how to place the JAR files generated by -clientjar into WEB-INF/lib but there would still be an issue with the generated classes inside the WAR.
I don't have a deep knowledge of the Maven build lifecycle and its possibilities, any suggestions or pointers are very much welcome.
This is the approach I took. It isn't exactly what I wanted, there's still lots of manual work to do with every WSDL file and is far from the solution I had in mind (having Maven automatically create individual JAR artifacts for every wsdl in the project and using them as dependency).
Specifically, for each WSDL, this approach needs :
Creating a directory containing the WSDL file and a pom.xml containing a distinct artifact name
Adding that directory to the top-level aggregator POM.
Adding a dependency to the WS client JAR artifact in the webapp's POM.
I ended up creating an aggregator (multimodule) Maven project, having one module for each WebService Client, that will produce a JAR artifact with the generated WS client classes (following Maven's convention of one artifact per POM).
For convenience, the plugin that will take care of the WebService client classes generation is defined only once in the main pom.xml, and this POM is the parent of the WS client generation POMs. It is important to note the difference between aggregator and parent POMs. Both concepts are used together in this approach.
There's also a module for the main webapp. Its pom.xml specifies dependencies for each of the WS client JAR artifacts.
This is the outline of the project's directory tree:
| pom.xml
+-- WSClient1
| | WebService1.wsdl
| | pom.xml
+-- WSClientN
| | WebServiceN.wsdl
| | pom.xml
\---MyWebapp
| src
| pom.xml
The aggregator POM:
<?xml version="1.0" encoding="UTF-8"?>
<project xsi...>
<modelVersion>4.0.0</modelVersion>
<groupId>com.example.myproject</groupId>
<artifactId>parent</artifactId>
<version>1.0.0</version>
<packaging>pom</packaging>
<name>Aggregator POM</name>
<properties>
<!-- CXF version used for cxf-codegen-plugin -->
<cxf.version>2.7.10</cxf.version>
</properties>
<modules>
<!-- WS Client Modules -->
<module>WSClient1</module>
<module>WSClientN</module>
<!-- WAR Module -->
<module>MyWebapp</module>
</modules>
<!-- Project configuration every child POM will inherit -->
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>${cxf.version}</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<!-- WSDL files will be at each project's root level -->
<wsdlRoot>.</wsdlRoot>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Each one of the WS client POMs is extremely simple, just an artifact name and specify the parent:
<?xml version="1.0" encoding="UTF-8"?>
<project xsi...>
<modelVersion>4.0.0</modelVersion>
<groupId>com.example.myproject</groupId>
<artifactId>wsclient1</artifactId>
<packaging>jar</packaging>
<version>1.0.0</version>
<name>WebService1 client</name>
<parent>
<groupId>com.example.myproject</groupId>
<artifactId>parent</artifactId>
<version>1.0.0</version>
</parent>
</project>
The webapp's POM doesn't need to be a child of the parent POM because it won't be using the cxf-codegen-plugin, and includes <dependency>s for each one of the WS client artifacts:
<dependency>
<groupId>com.example.myproject</groupId>
<artifactId>wsclient1</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>com.example.myproject</groupId>
<artifactId>wsclientN</artifactId>
<version>1.0.0</version>
</dependency>
Related
We have a couple of legacy Java projects, which we converted to Maven projects / modules. Previously, all projects were NetBeans projects and had no real dependency management. External dependencies existed on the companies network drive and were directly included as JARs in the NetBeans projects of each module. For the internal dependencies, simple project references were used. It was a pain to build everything because the programmer had to build everything in the right order.
Now, we are in the position that we can open all the Maven modules in IntelliJ IDEA and NetBeans. However, I am having trouble figuring out the best way to combine the different modules and external dependencies in a specific way, which conforms to in-house plugin-like structure. Especially with NetBeans (developing with both IDEs must be possible).
Here is how the git repositories / project structure roughly looks like. The folder structure of the modules is the default Maven structure for each module. The list feature of this site was too clumsy, so I included it as screenshot...
We have an internal maven repository for the stuff and building with maven etc. is working. For Intellij IDEA i can run and debug the end product for customer1 via a custom run configuration, which copies the needed files in the needed structure:
With IntelliJ IDEA, I can debug the software, but I think that the approach (custom IntelliJ run config I created, pointing to all needed JARs and files directly) is rather ugly, and for NetBeans I could not find a similar "run configuration" mechanism.
So I tried to achieve this build process by creating a new "Customer1Runnable" Maven project as a sort of build description, which points to all needed Maven modules. Based on this, I believed I could achieve and automatism to create the needed software structure. Ergo copy all modules into a plugin folder and all dependencies of the modules into a lib folder inside the Customer1Runnable project, using the maven-assembly-plugin.
First off, is my assumption correct that this is a possible use case for the maven-assembly-plugin?
The project itself does not have any source files, it is only a pom.xml and the assembly-config.xml descriptor. I attached the assembly-plugin to the package phase. When running the mvn package command all connected modules are built, but for the execution of the assembly-plugin I get the following output:
For starters, I only tried to include one module in the assembly descriptor. This is the XML (opicom-assembly.xml) for it:
<assembly xmlns="http://maven.apache.org/ASSEMBLY/2.1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.1.0 http://maven.apache.org/xsd/assembly-2.1.0.xsd">
<id>opicom-assembly</id>
<formats>
<format>dir</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<moduleSets>
<moduleSet>
<useAllReactorProjects>true</useAllReactorProjects>
<includes>
<include>my.company.reporting:module1</include>
</includes>
</moduleSet>
</moduleSets>
</assembly>
pom.xml of Customer1Runnable project
<?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>
<version>1.6</version>
<groupId>my.company.customer1</groupId>
<artifactId>OpicomRunnable</artifactId>
<packaging>pom</packaging>
<name>OpicomRunnable</name>
<repositories>
<repository>
<id>Company-Maven-Repo</id>
<url>file:\\\\MyCompany\TFSDrop\MavenRepo</url>
</repository>
</repositories>
<modules>
<module>../my.company.customer1.module1</module>
<module>../my.company.customer1.module2</module>
.
.
.
<module>../../MyCompany_Common/Report/my.company.reporting.module1</module>
</modules>
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>3.3.0</version>
<inherited>true</inherited>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
<configuration>
<descriptors>
<descriptor>opicom-assembly.xml</descriptor>
</descriptors>
</configuration>
</plugin>
</plugins>
</build>
</project>
The pom of a module 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>
<parent>
<groupId>my.company</groupId>
<artifactId>reporting</artifactId>
<version>1.3</version>
<relativePath>../pom.xml</relativePath>
</parent>
<artifactId>module1</artifactId>
<version>1.3</version>
<packaging>jar</packaging>
<dependencies>
<!-- external dependencies -->
<dependency>
<groupId>commons-pool</groupId>
<artifactId>commons-pool</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>com.oracle.database.jdbc</groupId>
<artifactId>ojdbc8</artifactId>
<version>21.1.0.0</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>3.3.0</version>
<configuration>
<finalName>my-company-${project.artifactId}</finalName>
<appendAssemblyId>false</appendAssemblyId>
<outputDirectory>../build</outputDirectory>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
</plugin>
</plugins>
</build>
</project>
Thanks for any input on what I am doing wrong here / how to achieve this with Maven.
EDIT:
As requested, here an example project as ZIP-File.
https://drive.google.com/drive/folders/1ilJeTrOPgYgUTdOP0J4BQcBnPT5fls0k?usp=sharing
The parent directories ModuleGroupCustomer and ModuleGroupCommon do represent git repositories in the real scenario. The relative module path is caused, because the maven project which should be my "run config" points to maven projects in both repositories.
Maybe I am misunderstanding Maven in general? I thought of it in terms of use cases for dependency management similar to .Net nuget packages, but also as "project configuration" like ordinary NetBeans/Intellij projects.
Is it better to simply stick to the existing NetBeans projects for day to day development?
After a long and tedious process of trial and error, I have found a solution which is working for me. So I decided to share the solution online, in case someone else runs into a similar problem. Here is a link to the final zip archive containing working example projects => File CustomerRunnable_RunningAssemblyPluginStackoverflowExample.zip https://drive.google.com/drive/u/0/folders/1ilJeTrOPgYgUTdOP0J4BQcBnPT5fls0k
My error was that I misunderstood how the assembly-plugin works. The approach that I executed the plugin inside my aggregator pom (CustommerRunnable) is wrong, as this maven project only exists as parent pom.
The CustommerRunnable pom.xml references all customer plugins as modules. Those modules have not the CustommerRunnable as parent, but a different pom. Then I created a separate maven project "distribution". The pom.xml of the distribution defines all the plugins (needed customer maven modules) as dependencies. It also has the CustommerRunnable pom.xml as parent. Hence when I run the project in NetBeans, all connected modules are also build(if necessary).
It also configures the assembly plugin. The assembly plugin is attached to the maven package-phase and thus executed with it. It also uses a custom assembly descriptor, which copies all the previously defined plugins into the right folders. This is done by using dependencySets with include and exclude patterns.
See https://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html for details on this.
So one dependencySet copies all jar files of all plugins to a /plugin folder by using an include pattern. Then this approach is inversed to copy the jar files of all external dependencies to a /lib folder.
The descriptor also defines some extra files to copy to a particular location. exec-maven-plugin, so I can comfortably start the customer software out of NetBeans. I didn't yet manage to configure the execute plugin correctly regarding the needed classpath arguments.
Endresult looks like this:
It is also worth noting that the configurations of the "Build project", "Run project" and "Debug project" inside NetBeans need a tiny bit of modification. (Right Click Module "distribution" -> "Properties" -> point "Actions"
I have a project with 2 folders:
1) src - contains the Java code files & folders (entity, code, rest,
timer)
2) WebContent - contains folders (META-INF, WEB-INF)
I have not experienced with server-side Java and I would like to ask how I can create a valid .war file using CLI that can be deployed using the Wildfly web admin interface and achieve that project is available and running on URL defined in web.xml file (located in WEB-INF folder).
I tried to deploy war which been created using the following command in root folder (i tried WebContent folder too) but after uploading the .war file the application is not reachable on the given URL (404).
Thanks for any advice.
Edit:
Added actual project structure
I'd encourage you to move to a build tool of some sort. There are various options - I'll go over Maven as it is the one I'm most familiar with.
First thing is code organization. You'll need to organize your code like:
src/
main/
java/
com/
packagename/
SomeJavaCode.java
webapp/
WEB-INF/
web.xml
So all of your Java code will be somewhere under src/main/java in whatever packages you want. In src/main/webapp are files related to your web application. You should have a minimum of WEB-INF/web.xml for a .war file but if you have a .jsp or .html it would go in the webapp directory too.
At the root of the directory you will need a pom.xml file. This is your build file that tells Maven what to do. A super basic one for a .war file would be:
<?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/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>tld.companyname</groupId>
<artifactId>your-artifact</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>war</packaging>
<properties>
<maven.compiler.source>11</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
</properties>
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>8.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>4.0.1</version>
<scope>provided</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<source>${maven.compiler.source}</source>
<target>${maven.compiler.target}</target>
<showDeprecation>true</showDeprecation>
<showWarnings>true</showWarnings>
<compilerArgument>-Xlint:all</compilerArgument>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.3</version>
<configuration>
<failOnMissingWebXml>false</failOnMissingWebXml>
</configuration>
</plugin>
</plugins>
</build>
</project>
This file only has dependencies on the JEE stack with the Servlet libraries. These are both marked as "provided" as you don't need to include these in your .war file as Wildfly already provides them.
Note that you are very likely to have additional dependencies for your code. They need to be added as a dependency stanza in the pom.xml like the other ones. If you're not sure what this value should be go to mvnrepository.com to search for the correct code to insert.
The output of this will be a .war file in the target directory. This .war file can be deployed to Wildfly.
An extra piece - to help Wildfly determine the root URL path of your .war file, include the file jboss-web.xml in your WEB-INF directory:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web version="10.0"
xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd">
<context-root>/myapp</context-root>
</jboss-web>
When you deploy this .war the jboss-web.xml file will tell Wildfly to put it under the path /myapp in this example. To me this removes some of the confusion around automatic web app names that can occur. Note that it is perfectly legitimate to have the context-root be / so that your .war is at the root of the URL hierarchy.
Once you have all that, you'll need to install Maven and have it on your PATH. Take a look at the Maven Install page for details for your O/S. After this is installed just run:
mvn clean package
on the command line to generate the .war in your target directory.
EDIT
One thing that is different is that you do not need to add the dependencies inside of your code - Maven takes care of that. So, for example, in your image for the AWS libraries I would just add:
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk</artifactId>
<version>1.11.119</version>
</dependency>
inside of the dependencies block. Maven will automatically pull this library from the Maven central repository and use it. You don't need to have it in your WEB-INF/lib directory as, when Maven builds, it will automatically include the libries you have in your dependencies (and anything they depend on). Again, just search in https://mvnrepository.com/ for the library you need.
I have a project divided into modules/sub-projects.
Root
- module jar (used to contain ejb)
- module war (used to contain web app)
- module ear (used to pack the two aforementioned modules into one deployable unit)
Without using maven we should:
Build the jar and war projects separately and then
pack them in a ear.
I'm new to Maven but in my understanding Maven is used to manage this process
on behalf of the developer.
My project in term of maven is structured in the following way:
ROOT
parent-pom.xml
- jar-pom.xml
- war-pom.xml
- ear-pom.xml
My question is how do we tell maven to pack the jar and war module into a .ear
project, wich pom.xml should host this information ?
Edit:
The following is my project structure
Find the sample pom.xml under ear project to build ear
Add
<packaging>ear</packaging>
Add Dependencies
<dependencies>
<dependency>
<groupId><Your api Jar Group Id></groupId>
<artifactId><Your API artifact Id></artifactId>
<version>${project.parent.version}</version>
<type>ejb</type>
</dependency>
Add build plugin
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId
<configuration>
<version>6</version>
<defaultLibBundleDir>lib</defaultLibBundleDir>
<modules>
<ejbModule>
<groupId><Your EJB Module Group Id></groupId>
<artifactId><Your EJB Module Artifact Id></artifactId>
</ejbModule>
</modules>
</configuration>
</plugin>
</plugins>
</build>
I have a question regarding maven and its tomcat7 plugin :)
I have the following maven projects:
plugin1: plain java project packaged as jar
plugin2: plain java project packaged as jar
webapp: standalone webapp project packaged as jar
those three project are properly build in maven and the outcome works fine:
I can use the jars from plugin1/plugin2
I can deploy the webapp war file to a web container
I can run tomcat7:run to start the webapp
Now, I need to provide different packaging of the webapp containing specific plugin setup.
i.e. I want to generate a war file with webapp + plugin1 and another one with webapp + pugin2
To achieve this, I have created 2 additionnal maven projects that declare dependancies on the webapp project + the appropriate plugin projects and are packaged as wars.
The generated war files have the expected content, and can be deployed to a tomcat, but when I try to use the maven tomcat plugin (tomcat7:run again), it simply doesnt start anything.
Though this is not blocking for me (my main point was to generate the war files), I have the feeling that I missed something.
the pom.xml for those aggregate projects looks like this (note that there is absolutly no code in those projects, these were just created for packaging with specific dependancies convenience).
<groupId>my.project</groupId>
<artifactId>live1</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>war</packaging>
<name>MyWebapp</name>
<properties>
<failOnMissingWebXml>false</failOnMissingWebXml>
</properties>
<dependencies>
<dependency>
<groupId>my.project</groupId>
<artifactId>plugin1</artifactId>
<version>${project.version}</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>my.project</groupId>
<artifactId>webapp</artifactId>
<version>${project.version}</version>
<type>war</type>
<scope>runtime</scope>
</dependency>
</dependencies>
<build>
<finalName>MyWebapp</finalName>
<plugins>
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.0</version>
<configuration>
<url>http://localhost:8080/manager</url>
<server>localhost</server>
<path>/${project.build.finalName}</path>
</configuration>
</plugin>
</plugins>
</build>
Thanks !
note: long time lurker, first time asker here, if some information is missing tell me :)
Depending on the structure of your project it may not be suficient to just add a dependency of type war. You may need also to configure <overlays> as described here maven-war-plugin.
It looks like your final war does not provide the full web configuration that you expect. With overlays you can configure how the resources from the dependency will be packed into your final web app.
There must be some difference in the way that your external tomcat starts the app compared to the tomcat7 plugin. May be you can try -X option :
mvn -X tomcat7:run
This should log out some details, of what the embedded tomcat is configuring..
I'm having one of those nights...
I'm developing an Eclipse plugin using Tycho (the Maven extension), and at some point I wanted simply to use the class StringUtils from org.apache.commons. After some research, the only way that I could find is the following code in my pom.xml parent file:
<dependencies>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.3.2</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-maven-plugin</artifactId>
<version>${tycho.version}</version>
<extensions>true</extensions>
</plugin>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>${tycho.version}</version>
<configuration>
<pomDependencies>consider</pomDependencies>
<environments>
<environment>
...
This didn't work, and any other solution that I tried didn't work either.
I'm using Maven for the first time, so maybe I'm missing something (or a lot of things)...
Does anyone have an idea? I'd be very thankful :o)
Your configuration looks correct. So if it doesn't work, you are probably missing the dependency declaration in the MANIFEST.MF. To do this, e.g. add Require-Bundle: org.apache.commons.lang3 in that file.
Background: A dependency in the POM doesn't automatically mean for Tycho that your bundle also automatically has this dependency. It only means that the artifact will be added to the target platform (given that pomDependencies=consider is configured and the artifact is an OSGi bundle - both is true in your case). Once it is in the target platform, it can be used to resolve the dependencies declared in your bundle's MANIFEST.MF.
It sounds like you need to "upgrade" to using a target platform to define your target.
How are you achieving this dependency in your development environment? If you are not using a target platform, you are inheriting whatever plug-ins are installed in your development (that is the default target platform).
Create Target Platform
First create a target platform. I recommend using the Target Platform Definition DSL and Generator to create and edit the target platform.
The tpd file will look something like this for orbit
target "name"
with source requirements
location "http://download.eclipse.org/tools/orbit/downloads/drops/R20150519210750/repository/" mars-orbit {
org.apache.commons.lang3
}
location "http://download.eclipse.org/releases/mars" mars-release {
org.eclipse.platform.feature.group
org.eclipse.equinox.executable.feature.group
org.eclipse.e4.rcp.feature.group
org.eclipse.ui.trace
org.eclipse.pde.feature.group
}
This example uses the already created OSGi bundles for third-parties. You can choose which release of orbit and browse all the available packages on the Orbit Site. You can also use auto-completion in the tpd editor.
Tycho Using Target Platform
Place the target file in a new plug-in. Name the target file the same as the plug-in. (e.g. com.example.releng.targetplatform.target is the name of the target file in this example.)
In this project, a pom that looks like this:
<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>
<artifactId>com.example.releng.targetplatform</artifactId>
<packaging>eclipse-target-definition</packaging>
<parent>
<groupId>com.example</groupId>
<artifactId>com.example.releng</artifactId>
<version>1.0.0-SNAPSHOT</version>
<relativePath>../com.example.releng</relativePath>
</parent>
</project>
You can configure (in your releng pom.xml) the target configuration like this:
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>${tycho-version}</version>
<configuration>
<target>
<artifact>
<groupId>eGui</groupId>
<artifactId>com.example.releng.targetplatform</artifactId>
<version>1.0.0-SNAPSHOT</version>
</artifact>
</target>
</configuration>
</plugin>
Tutorial
Have a look at Code & Me's excellent tutorial on Tycho, it goes into more detail and over many steps goes from new project to a complete Tycho.