OK, here is the problem set: For animal-sniffer, we need to have signatures of each of the java runtime libraries (i.e. the animal smells/scents)
That way animal-sniffer can detect whether you are compatible with a specific java runtime library. Initially I was going to have these signatures as primary artifacts, so you would have one pom.xml for each java version... Then jason and a few others felt that these were not really a packaging type, and it would be better to have them as secondary artifacts... Actually this is somewhat better... as we can differentiate by classifier and add value using the classifier... Of course we then hit the question, how should we divide things up? in the following bgid=org.codehaus.mojo.animal-sniffer Option 1: bgid:java:1.0:java11, bgid:java:1.0:java12, bgid:java:1.0:java13, bgid:java:1.0:java14, bgid:java:1.0:java15, bgid:java:1.0:java16 pros: * if we generate bad signatures, we can just rev the version number and people can just pick up the new rev anti: * version ranges cannot be used to pick a signature range * no room for differentiating vendor specific signatures * signature descriptions would have to be limited to broad sweeps, e.g. all of java 1.4... and thus we could miss some signature differences between 1.4.0, 1.4.1 and 1.4.2... unless we use java140, java141, java142 as the classifiers [just plain ugly] Option 2: bgid:java:1.1.0-1, bgid:java:1.2.2-1, bgid:java:1.3.2-20, bgid:java:1.4.2-19, bgid:java:1.5.0-19, bgid:java:1.6.0-15 pros: * version ranges now specify the version of java that you are after. * we still have classifier for vendor specific signatures anti: * what happens if we find that 1.4.2-19 is bad and we have already generated the signatures for 1.4.2-20... we cannot up the build number as the next one is taken, we cannot add a qualifier as qualifier < no qualifier, and we've used up all the segments that maven 2.x supports Option 3: bgid:java1:1.0.1, bgid:java1:2.2.1, bgid:java1:3.2.20, bgid:java1:4.2.19, bgid:java1:5.0.19, bgid:java1:6.0.15 pros: * we have the build number to fix bad signatures * for 5.0+ the version number matches the marketeers version number for java * we still have classifiers for vendor specific signatures anti: * not the version numbers that people are expecting Option 4: bgid:java11:1.0, bgid:j2se12:1.0, bgid:j2se13:1.0, bgid:j2se14:1.0, bgid:javase5:1.0, bgid:javase6:1.0 pros: * plenty of room on version numbers * still have classifiers anti: * now version ranges are no use for specifying the signatures to check. Thoughts anyone? other options? -Stephen
