I'm facing the problem with setting up a development environment with Maven and OSGi dependencies in Intellij.
At the beginning, a few words about how it looks like.
Everything is built on top of the Maven build. The whole hierarchy is already set up and I don't have any problems with building the project. It consists of many small submodules:
<modules>
<module>com.modulea</module>
<module>com.moduleb</module>
<modules>
Those modules use OSGi internally so everything might be presented with the following tree:
PARENT (pom.xml)
|----- Module A (pom.xml)
|----- META-INF
|----- MANIFEST.MF
|----- Export-bundle: com.modulea
|----- Module B (pom.xml)
|----- META-INF
|----- MANIFEST.MF
|----- Require-bundle: com.modulea
|----- src
...
|----- ModuleAClass (uses classes from com.modulea bundle)
The problem is connected with importing the project into IntelliJ. I imported it as a Maven project with checkboxes selected:
Create IntelliJ IDEA modules for aggregator projects (with 'pom' packaging)
Create module groups for multi-module Maven projects
IntelliJ created project's submodules basing on maven configurations but...
dependencies of those modules are set to libraries (Maven p2.eclipse-plugin). Is there any way to force it to use project's submodules? Of course, it is possible to do it manually (Project Settings -> Dependencies -> + -> Module dependency) but there are too many dependencies and submodules to repeat it every now and then again.
Additionally, if I have dependencies configured (library dependencies), OSMORC plugin is not able to resolve OSGi dependencies/configuration. For each of classes from an external bundle I got a message:
The package 'com.modulea' is not imported in the manifest less... (Ctrl+F1)
Related
I have multiple maven multi-module projects and one parent project. Parent project pom.xml file is the parent of all other projects' root pom.xml.
-> ParentProject
pom.xml
->Project1
-> module1
src
pom.xml
-> module2
src
pom.xml
->pom.xml
->Project2
-> module1
src
pom.xml
-> module2
src
pom.xml
->pom.xml
In the parent pom.xml file, I have a couple of properties which are inherited and used by others. I need to update those properties quite frequently, and if I increase the version of parent pom after updating those properties, I need to update other poms and increase their versions as well. Is there any way to prevent it, or is there a better way to do it? Thanks!
You can use the versions plugin to help with the tedium: Update the ParentProject version (and install locally) and then run mvn versions:update-parent to update the parent version in Project1 and Project2.
There are other useful targets for updating properties and dependencies.
There are multiple modules in my application . All of them are maven projects .
So I am working on creating a parent pom for all these projects and was able to create one and ran maven build on this parent pom and works fine build
But when I opened the project in eclipse , the parent pom was not included in the projects displayed so it was picking it up for the build process to take place . My project structure is as follows
ProjectA
|
--------subProjects
ProjectB
|
--------subprojects
ProjectC
|
--------subProjects
ProjectD
|
-------subprojects
Pom.xml
So what do I need to make an eclipse recognise this parent pom ? I created another maven module and made it parent pom . But is there any way i could avoid creating another project and achieve the above scenario ?
One thing you can do is to import the global structure as a maven project on its own and then import the subprojects one by one as maven project in eclipse.
you can use mvn eclipse:eclipse in the command line for all the project one by one, and then you can select by importing(Maven Project Type) all the maven projects if you select the directory on the top of your maven projects.
In this case you make all settings in the pom and no additional configs in eclipse.
In svn repository I have a folder 'product' under which are all my Eclipse plugins and features, parallel to these there is parent POM. This setup works well when I build in Jenkins, I just check out 'product' and install pom.xml. However, I can't figure out how this setup works in Eclipse workspace? I can't check out pom.xml by itself into workspace, and if I do I need to check it out as single file under a project which brakes path to parent POM. How should I check out and build in such setup?
Also, do I need to define relativePath of parent POM in my plugins? I found that if I omit it, then I get error about path being missing.
Just to summarize, my svn repository structure is this:
repo/
trunk/
product <- maven project (folder with .project set as maven nature)
pluginA
pluginB
featureA
pom.xml
.project
I think you have two options:
Deploy your parent POM to a locally available repository, perhaps your company Nexus server, for example? This will then be available to all products and for all your colleagues.
Restructure your project to look more Maven-like, e.g.
|-- plugin1
|-- pom.xml
|-- ....
|-- plugin2...
|-- feature1...
|-- ...
pom.xml <-- parent POM
This second option may be better in the long term, otherwise your Jenkins server relies on you remembering to locally install the updated parent POM, rather than just plucking it from svn.
If you use m2eclipse (e.g. available from the Juno site), you can import any Maven project structure into Eclipse. In your case, the product folder would be imported as an Eclipse project, as well as the individual features and bundles.
<relativePath> defaults to .., so you need to specify it if the parent POM is not in the parent folder. You can set it to undefined (e.g. through an empty <relativePath/> tag) if the parent POM is not available locally. In this case, Maven will always resolve the parent POM from the local Maven repository or the configured remote (Maven) repositories.
I'm participating in an open source project (ps3mediaserver) which has been moved from google code (SVN) and ANT (for build tasks) to git (GitHub) and maven. I've got my own fork (called pms-mlx), where I'd like to maintain some plugins being part of the default packaging when releasing. I'm pretty new to maven and am not too sure how the project should be structured to respect the maven way.
I'll start by describing how the environment behaved previously and will then give the thoughts about the move to maven.
Links:
Old: SVN + ANT ps3mediaserver project on google code
Old: SVN + ANT pms-mlx project on SourceForge
New: Git + Maven ps3mediaserver project on GitHub
New: Git + Maven pms-mlx project on GitHub
Old behavior:
Project structure:
+--workspace
+--plugins
+--plugin1
build.xml
+--plugin2
build.xml
+--ps3mediaserver_mlx
+--plugins
build.xml
The main project is ps3mediaserver_mlx, all plugins live in sub-folders of the workspace/plugins folder.
ps3mediaserver_mlx/build.xml contains a target BuildWithoutLibs which will build the jar of the main project and copy it to workspace/pms_no_libs.jar which will then be referenced (at this location) by the plugins.
When executing the build target of any plugin, the plugin will be build and the resulting jar copied to ps3mediaserver_mlx/plugins/[plugin_name].jar.
And finally, when packaging the application using the the build target in ps3mediaserver_mlx/build.xml, the plugins containedin workspace/ps3mediaserver_mlx/plugins will be packaged (in a exe installer for windows, dmg for OSX or tar.gz for linux).
New behavior
The project structure has been changed to this:
+-- workspace/
+-- pom.xml (global-pom)
+-- ps3mediaserver/
| +-- pom.xml (pms-pom)
| +-- src/
| ...
+-- plugins/
| +-- pom.xml (plugins-pom)
| +-- Plugin1/
| pom.xml (plugin1-pom)
| src/
| +-- Plugin2/
| pom.xml (plugin2-pom)
| src/
+-- pms-package/
+-- pom.xml (package-pom)
+-- src/main/assembly/
+-- src/main/external-resources/
Responsabilities:
global-pom The root pom containing all dependencies used by pms. This lets use the same version without redeclaring them in any plugin (is this a good idea?). Builds everything and contains a modules section to perform the same maven commands on all projects
<modules>
<module>ps3mediaserver</module>
<module>plugins</module>
<module>pms-package</module>
</modules>
pms-pom: Inherits from global-pom andbuilds the pms jar
plugins-pom: Inherits from global-pom; contains a depency for pms (which will be required for all plugins); contains a list of all modules having to be built
pluginX-pom: Inherits from plugins-pom and contains a custom configuration for a plugin
package-pom: Is responsible to package pms according to the platform it is being built on.
Does this structure represent the way maven is ment to be used?
Everything is working up to the packaging. This means the main application jar as well as all the plugins have been built and need to be packaged. The package-pom is responsible to do that.
In the original application there is only one pom.xml and the packaging is being done by using different profiles for Windows, Linux and OS X. The one I'm currently working on is for OSX and uses osxappbundle-maven-plugin, but the source code is never being packaged in the app file. That's because the packaging project doesn't inherit from the actual project anymore.
How has the built jar to be referenced in order to be packaged correctly in the app file?
I've tried referencing the jar in additionalResources and as custom class path, but never with success.
You have defined a dependency for example in the plugins/pom.xml
<dependencies>
<dependency>
<groupId>net.pms</groupId>
<artifactId>pms-mlx</artifactId>
<version>1.52.1_mlx_v0.8-SNAPSHOT</version>
</dependency>
</dependencies>
which exactly represents your parent. In other words it's wrong to define a dependency which already been defined as your parent.
It's good practice to put the modelVersion tag directly after the project tag and before the parent tag. After the parent tag put the information the current module like artifactId.
After diving into the project i noticed that you defined in your of your plugins/WebservicePlugin:
<modelVersion>4.0.0</modelVersion>
<artifactId>WebservicePlugin</artifactId>
<version>3-SNAPSHOT</version>
<packaging>jar</packaging>
<parent>
<groupId>net.pms</groupId>
<artifactId>pms-plugins</artifactId>
<version>1.52.1_mlx_v0.8-SNAPSHOT</version>
</parent>
which is against the maven way for multi-module builds. You should not define a different version in this case. It should look like this:
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>net.pms</groupId>
<artifactId>pms-plugins</artifactId>
<version>1.52.1_mlx_v0.8-SNAPSHOT</version>
</parent>
<artifactId>WebservicePlugin</artifactId>
If you have problems based on the version of the WebservicePlugin module than you should think about separating the WebservicePlugin from the rest (may be the other plugins as well).
One other things which i have noticed that you defined in many of the plugins (if not all of them) the configuration and the usage of the maven-compiler-plugin...This should be done by using a pluginManagement part in your root pom...to simplyfy maintenance of your project.
The copying of the created plugins-jars via the maven-antrun plugin into a different location whould be done different.
Repeating the license entry in every plugin is not needed cause it's inherited by the parent.
I have a multi module maven project. It has 5 module and 2 of them are web projects.
I want to customize my plugins to be run at only war projects. I mean at parent pom level I would like to trigger my goals and only my war projects will be affected. Is there any way for it?
As a result of this, I will not have duplicated configurations at my war projects pom.
Thanks
You can build a war parent pom (where your war projects are inheriting from) and a general parent pom (where everyone else is inheriting from).
general parent
/ \ \
war parent \ \
/ \ \ \
war1 war2 other1 other2
For building you may have a seperate build pom, having all the above as modules.
HTH
I have faced the same problem numerous times and I have come to the conclusion that the best solution is as follows:
cool-master
|-+ parents
| |- cool-parent
| |- cool-parent-web
|
|- module1
|- module2
|- module3
|- module-web1
|- module-web2
In the above example there are three types of modules:
parent POM-s (cool-parent, cool-parent-web)
non-web aps (extending cool-parent)
webapps (extending cool-parent-web)
In the parents you can define settings which are specific for the different types of modules. For example in the cool-parent define non-webapp related stuff, wheres in the cool-parent-web you can have all the fancy stuff like maven-war-plugin, jetty-maven-plugin, etc. I generally have the cool-parent-web extend the cool-parent in order to avoid having to duplicate dependencies, plugins settings and etc.
In the cool-parent-web define a <pluginManagement/> section and set up all the stuff for your plugins and then just use them across your web modules.