Maven, Deploying Bundles and Transitive Dependency Management

[scotthamilton77]

Interested to know if anyone can point me to a hopefully automated solution to this problem.

Given any mavenized project that has dependencies, and assuming those dependencies are all OSGi-ready bundles, each with some of their own transitive dependencies, is there a way to get a PAR to pick up ALL of the dependencies at once and wrap them up such that I can deploy my whole app with its dependencies at once?

Put simply, I'm lazy, and don't want to have to copy bundles manually to the dm server repository folder, and especially don't want to force my development team to have to do this as well (tho I seem to recall we could configure dm server to point to a shared repo location). Whenever I update my POM to add a new dependency, I'd rather hot have ANOTHER step where I need to go grab that JAR and throw it somewhere else manually.

From what I can see, the Eclipse PAR management will only allow me to package projects I can point it to - and those projects' transitive dependencies are not pulled into the PAR.

If I use the maven PAR plugin, the same basic thing happens - per its documentation it will only include in the PAR those dependencies I explicitly refer to, it will not deal with transitive dependencies.

Am I missing something? Or do I need to bite the bullet and either do this manually (copying my dependencies somewhere or writing my own automation for this)?

[bjc]

Although not ideal in your scenario where "deployment" of the par isn't necessarily the same as the system building the par (ie. having all the depend resources in once nicely organised "release" folder). You could always just have your dm-server point to your internal *OSGI SAFE* maven repository(s)...

We currently have an internal osgi safe repo an our local build bundle repo which a local instance of the dm server references.

This works quite well for development (sans the fighting of the dm-server bundles vs the repo bundles (which is where I break down and cry))

But I too would like a nicer description of the ideal "release scenario" with respect to deploying on an "out of the box" dm server.

I also forgot to mention that the maven dependency plugin also has a transitive dependency inclustion feature which might help you...(merging all the dependencies used in a project hierarchy is something i'll leave to you)

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-dependency-plugin</artifactId>
  <executions>
    <execution>
      <id>copy-dependencies</id>
      <phase>package</phase>
      <goals>
        <goal>copy-dependencies</goal>
      </goals>
      <configuration>
        <outputDirectory>${project.build.directory}/dependencies</outputDirectory>
        <overWriteReleases>false</overWriteReleases>
        <overWriteSnapshots>false</overWriteSnapshots>
        <overWriteIfNewer>true</overWriteIfNewer>
      </configuration>
    </execution>
  </executions>
</plugin>

[scotthamilton77]

Thanks bjc, that's just what we ended up doing for now, but it's not quite what I'd *like* to do. Your comment about an OSGi-safe repo threw me for a little bit until we experimented by just pointing the server to our local repo (that contains both bundles and jars). No love there - Spring dm Server balks at the first non-bundle it finds and quits right there.

I put in an enhancement request for that - http://forum.springsource.org/showth...026#post264026. I'd be interested to know if you think that thread is promoting a good idea or something with hidden dangers/potholes. This osgi business is still quite new to me other than reading about it every year for the past few years.

[Andy Wilkinson]

If I use the maven PAR plugin, the same basic thing happens - per its documentation it will only include in the PAR those dependencies I explicitly refer to, it will not deal with transitive dependencies.

This is something that could be added to the maven PAR plugin. I say could as there would be some downsides to this approach that would limit its usefulness. If you packaged all of your dependencies in the PAR, they'd become scoped, and would only be available to the other bundles in the PAR, i.e. you'd lose one of the benefits of OSGi where you can share dependencies between applications.

Am I missing something? Or do I need to bite the bullet and either do this manually (copying my dependencies somewhere or writing my own automation for this)?

As you've mentioned, one solution for this sort of case is to configure your dm Server instances to access a hosted repository that contains all of the dependencies that you need. This means that you only have one repository that you need to keep up-to-date with your dependencies.

Another solution would be to collect together all of the dependencies using Maven, (as described in one of the posts above, and also covered in our GreenPages sample application) and then to also use Maven to copy these to the dm Server instance's repository. This would, however, require your build to know where the instance was.

I can see another solution here (that isn't supported at the moment) where dm Server would understand a deployment unit that was basically a collection of artifacts to be deployed, and a collection of artifacts to be added to its repository. There would be some problems to solve with this, e.g. how would dm Server know / be told to which repository it should add the artifacts but this approach may warrant some more thought. If this solution is of interest, please open a story describing your requirements so we can track it and think it through in detail to see if it makes sense.