Sometimes in the project plain Maven dependencies has to be used. A simple strategy to use those in OSGi project handled by Maven is to have a separate module, containing all non-OSGi dependencies and converting those to OSGi bundles using Apache Felix Maven Bundle Plugin.
So one may have the following structure of the project:

project
    ...
    project.nonOsgiDependencies
        project.nonOsgiDependencies.base64
        project.nonOsgiDependencies.mysqlConnector
        project.nonOsgiDependencies.xercesImpl

This nonOsgiDependencies projects would contain just a pom.xml file, which would have a dependency on required maven dependency and would use maven-bundle-plugin to wrap it. Here is an example of such pom.xml for net.iharder:base64

<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>
    <artifactId>project.nonOsgiDependencies</artifactId>
    <groupId>dk.sorokin.maksim</groupId>
    <version>1.0.0-SNAPSHOT</version>
  </parent>

  <artifactId>ecosystem.nonOsgiDependencies.base64</artifactId>

  <name>net.iharder:base64 Maven Dependency</name>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-bundle-plugin</artifactId>
        <executions>
          <execution>
            <id>wrap-dependency</id>
            <goals>
              <goal>bundle</goal>
            </goals>
            <configuration>
              <instructions>
                <Embed-Dependency>*</Embed-Dependency>
                <Export-Package>net.iharder</Export-Package>
              </instructions>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

  <dependencies>
    <dependency>
      <groupId>net.iharder</groupId>
      <artifactId>base64</artifactId>
      <version>2.3.8</version>
    </dependency>
  </dependencies>
</project>

In Eclipse-OSGi world dependencies usually are defined with a range. For example:

Require-Bundle: org.eclipse.ui,
 dk.sorokin.maksim;bundle-version="[2.0.0,3.0.0)",

Numbers in build number x.y.z are meant to be

• x -- changes in API. Downstreamers should expect code breaking. Non-backwards compatible code.
• y -- changes, which might lead to code breaking.
• z -- bugfixes

Eclipse-OSGi world basically does not have understanding of "released" product. Built product is always "released" (if exposed to the public). Moreover, build number does not necessarily change. Thefore Eclipse-OSGi guys have problems, if they depend on online repositories. Because at any time new version of dependency with higher minor build number may appear and code may break.
What Eclipse-OSGi do then? Well, it is simple. They do not use online repositories! They used "frozen" version of those, for example by using standalone Eclipse installation as target platform. Usually this "frozen" target platform is being renewed at the beginning of each sprint.

Let's take a look on Eclipse-OSGi dependency management world from Maven perspective. Eclipse-OSGi world guys have SNAPSHOTs, but do not have releases. That is, you always grab the latest available version (of course, in possible range). Obviously, if we look from this perspective, it is very dangerous to depend on latest SNAPSHOT version.
In Maven world released products have to depend on released versions of dependencies. Moreover, when product is released, you are forced to change the build number. So there is no two releases with to numbers. Of course you can cheat and delete released product from maven repository and put another one, but at least you are guarded from doing that.

Ok, now why that matters. Lately more and more companies use Eclipse platform to build their products. And many development departments use maven heavily in the development process. Therefore they want to benefit from having maven to build Eclipse products. Tycho project allows to do that. However, beside many missing features in Tycho, there is a clashes between maven and Eclipse-OSGi world dependency ideology.

We already have some solutions and ideas to solve dependencies situation. However, let's wait with those until next posts..

Thanks to Tony Madsen for clarifications.

  <plugin>
	<artifactId>maven-dependency-plugin</artifactId>
	<executions>
	  <execution>
		<phase>package</phase>
		<goals>
		  <goal>copy-dependencies</goal>
		</goals>
		<configuration>
		  <outputDirectory>${dependencies.dir}</outputDirectory>
		</configuration>
	  </execution>
	</executions>
  </plugin>

where ${dependencies.dir} stands for folder where to dump the dependencies.

• a project projectA with submodules
  • projectA.module1 and
  • projectA.module2
• a project projectB

projectB dependes on projectA.module1.
projectA.module2 depends on projectA.module1 too and on projectB.

What is wrong here? Cyclic dependency! When projectA is built, its submodules projectA.module1 and projectA.module are built too. In your build server, for example, it may cause a infinity build loop when project is built whenever dependencies are built! So in this case it would be a great idea to move module projectA.module1 away from projectA.