Compatible version issues needs to be resolved

[starksm64]

In testing the thirdparty/licenses creation I saw that some component references in the 4.0 build-thirdparty.xml were using the wrong version. The primary example being the reference to the apache-logging version 1.0.3 which should be the 1.0.4jboss version. Changing this and rerunning the build produced:

C:\cvs\JBoss4.0\jboss-4.0\build\build-thirdparty.xml:185: A versioning problem exists:
Component: apache-logging is already defined as using version 1.0.4jboss
but it is also required to be at version 1.0.3

I created a bug report for this with some additional details:
http://jira.jboss.com/jira/browse/JBBUILD-126

Here we need to determine how we are going to deal with versioning. The immeadiate 2 problems are that the resolution process is not keeping track of what are the components involved at the point of the version conflict. It is not the apache-logging component that is referring to two versions. It is that some component has an import of apache-logging version 1.0.3 while the existing apache-logging component says its version 1.0.4jboss.

The second problem is that the Import.CompatibleVersions is not being used correctly. This was a vector of Compatible objects and only the first value was being used as the ComponentRef version. The Import.CompatibleVersions needs to be a sorted set with the entire set used to determine if the current project Component has a version that is compatible with the ComponentRef compatibles version set.

I'm working on getting this to a working state for the current 4.0 build so I can finish the installer for the 4.0.3RC2 release. This is something we have to get correct and working before the thirdparty mechanism can really be used.

[starksm64]

Changes:

- A ComponentRef has a SortedSet that are the set of compatible elements in an import statement:

 <import componentref="apache-logging">
 <compatible version="1.0.3"/>
 <compatible version="1.0.4jboss"/>
 </import>

when this set is populated, the version is set to the last Compatible.version. This means that the comparision/sorting of Compatibles has to make sense in terms of the dot decimal tupple a version represents. I doubt this is currently correct as its simply using the String.compareTo. Unfortunately the java.lang.Package class has not public constructor so that we could use this. We'll just need a proper Version class.

- An Import has a reference to the Component it belongs to. We should be able to use this to provide better feedback on where version conflicts occur. This is also passed to the ComponentRef created from the Import.

- The SynchronizeComponentsTask version check validates that ComponentRef.compatibles set against the component version being imported now rather than just doing a version to version comparison. We need the new Version class in order for this to be robust.