FAQ
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

Search Discussions

  • Brett Porter at Sep 18, 2009 at 2:18 am
    Can you avoid cross posting? I went to reply to this on dev@mojo and
    it had the reply-to of this list as gmail merges the messages.

    If you aren't getting the answers you're seeking on dev@mojo you can
    post here to point people at it, but cross posting in general is kinda
    evil :)

    Thanks,
    Brett
    On 18/09/2009, at 6:41 AM, Stephen Connolly wrote:

    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

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
    For additional commands, e-mail: dev-help@maven.apache.org

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriesmaven
postedSep 17, '09 at 8:42p
activeSep 18, '09 at 2:18a
posts2
users2
websitemaven.apache.org
irc#maven

2 users in discussion

Stephen Connolly: 1 post Brett Porter: 1 post

People

Translate

site design / logo © 2019 Grokbase