我应该使用Eclipse插件（或OSGi捆绑软件）作为普通的依赖项管理工具吗？

Question

once again it has happened... I joined a new project, composed of several plain Eclipse Java Projects, with interdependencies, all managed through the Project build path. I find this all a bit of a chaos. And when it comes to run configurations - you just enter hell.

In the past I've sticked to create plug-in projects, instead of plain Java projects - even if I never intend to run these projects as osgi-bundles. I just find that dependencies are way easier to manage in plug-in projects. Are other people taking the same path? Anything against this approach?

Answer 1

If you read the restructure of org.aspectj document , that project did precisely that:

• All dependencies would be expressed in OSGi bundle manifest files, which specify a classpath (for library jars) and "required" bundles.
  Libraries expected or hoped for in the deployment environment (eg, XML or JRocket ) must be included for build and test purposes but excluded from the shipping product. These might be specified as "optional" required-bundles or as required-packages

• Initial binary assembly would work through the usual bundle assembly, with the bundle output including binaries from bundle fragments it requires (but not from optional bundles)

The benefits also include the version aspect of OSGi, which allows to specify the minimum and maximum expected version of a dependency.

Answer 2

I agree that in Eclipse it is easier to manage project dependencies using OSGi than the traditional way of adding project or library references.

However, if you promote the OSGi-way of dependency management at development time, developers will need to learn OSGi and there will be a cost as they get class visibility issues.

Are you using Require-Bundle or Import-Package for managing the dependencies? Even though Require-Bundle is not the recommended choice with OSGi, it might be a better fit from the point-of-view of development-time dependency management.

Unless you are using something like the Maven plug-in, Eclipse has the annoying split of completely different methods of compiling/running inside Eclipse and outside - with the pain of maintaining 2 parallel compile/run systems.

Answer 3

I think your methodology, to use OSGi for dependency management even if you will not be running inside an OSGi container, is very sound because ultimately it will lead to more modular code. Modular code is easier to refactor and easier to distribute among multiple developers. You don't even need to extend any OSGi classes, so you don't create any additional dependencies.

On the other hand, Ken Liu's suggestion of using an external dependency management has it's advantages too, since something like Maven will handle a lot of the dependency and management for you.

Combine the two, and you get the best of both worlds. OSGi can be made to work alongside Maven using additional libraries such as Bnd and m2eclipse .

Answer 4

It sounds like an interesting approach, but personally I think it is best to manage build dependencies using an external build tool like Ant or Maven rather than tying your build to an IDE. If you use maven and the m2eclipse plugin, it will automatically set up Eclipse project dependencies when loading the Maven POM if those other projects are also in your workspace.

Unfortunately, if your team is currently using ad-hoc dependency management, it is kind of unlikely they will want to make the effort to jump to Maven. Then again, maybe they just need a leader to spearhead the effort.

Answer 5

I wouldn't use plug-in projects personally, I would use build tools such as Ant, Maven and others.

If there's no build system integrated, it means that the company doesn't understand much about software development.

I wouldn't take all the responsibility to introduce a build system, possibly extra-hours. If they don't want to migrate, I suggest that you start looking for another job ASAP.

Answer 6

There's two separate issues here.

1. How do I set up multiple projects, and
2. Which build system allows me to build multiple projects

The two need not be related. So, for example, you might choose Maven to build the projects but use plugin projects to enable easier editing. Most things beat the Eclipse build-system hands down; once it gets working, it's fairly stable - but getting it from nothing to working involves (a) luck, and/or (b) black magic.

Ultimately, the question then comes down to which you feel easier managing; both types of dependency, or just a single one. If you want a single one, then you need to invest the time in either something like m2eclipse (which generates project dependencies from the maven POM) or using pax-construct (which can generate the manifest from the maven POM). Either that, or live with two dependency management systems.