Ian Bull [http://community.jboss.org/people/irbull] commented on "Coping with versions in large multi-module osgi projects" To view all comments on this blog post, visit: http://community.jboss.org/community/tools/blog/2011/09/17/coping-with-ve... -------------------------------------------------- I'll let the OSGi purists battle the OSGi parts, but from a p2 perspective I see some things that could really get you in trouble. In particular, it's all related to the version 1.2.3.GA.  (or even worse 1.0.0).  p2 uses and ID/Version as a unique identifier.  So, if you have a bundle called Foo version 1.2.3.GA and you realize that you messed up the build, so you built again. Now you have two different sets of bytes with the same Unique ID (Foo/1.2.3.GA). If p2 has cached the original one somewhere  (or someone has it installed), then it's anybodies guess wich version will get fetched.  This is why nobody should ever reuse the same version for the same bundle. PDE/Build takes 1.0.0.qualifier and replaces it with a timestamp, so at least part of the version changes. Another (related) problem.  If *nothing* changes in a bundle then the version should not change. Let's say JBoss version 1.2.3 is released.  Tomorrow you release 1.2.4 and only 1 line of code in one bundle has changed.  If all your bundles get their versoin bumped, then users will download all 628 artifacts, instead of the single artifact that changed.  BTW, the Eclipse project has over 400 bundles and they manage their versions without bumping each bundle for each build.  There are techniques for doing this successfully including map files, API Tools and the Jar Comparator. Cheers, Ian --------------------------------------------------