Detect user-provided replacements for addon jars

SBuild consists of a core and additional components like the Apache Ant support, Wrappers for Ant tasks and SBuild Addons. For concenience, SBuild add those JARs at the end of the classpath so that the user can use these components without any further action.

Sometimes, the user wants to provide different versions inplace of the provides JAR. Currently, this should work already, but it has its shortcommings: SBuild adds the JARs automatically at the end of the classpath. As long as the Java Runtime will load classes in the same order, as the JARs are added to the classpath, this will work. But this behavior can not be enforeced nor verified for all possible combination of platform and JVM.

Solution: Scan the JARs from the classpath. Each one that have a specific tag in its JAR manifest can be identified. This way, SBuild can detect, if it is necessary at all, to add a possible conflicting JAR.

Detection and collision detection should have the same semantics as the @Bundle-SymbolicName@ and @Bundle-Version@ manifest header entries in OSGi. But as we don't use OSGi (currently), different names should be choosen.

@SBuild-ComponentName@
@SBuild-ComponentVersion@

SBuild should automatically choose the highest compatible version available on the classpath.

Ticket imported form Redmine http://sbuild.tototec.de/sbuild

Original Redmine issue link: Redmine ID 33 Reporter: Tobias Roeser => @lefou Creating date: 2012-09-26T13:54:06+02:00

Assigned to: Start date: 2012-09-26 Due date:

SBuild-org / sbuild

Detect user-provided replacements for addon jars #33