Edge Cases

Edge Cases

31/10/09 18:51

I can inspect a POM and see if each artifact - as they shall be known - corresponds to a rule.
Consider:-

    <dependency>
        <groupId>net.sourceforge.nekohtml</groupId>
        <artifactId>nekohtml</artifactId>
        <version>1.9.12</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-full</artifactId>
        <version>1.1-rc1</version>
    </dependency>

Issues:-

1. 
   Is it possible to deduce the information in above from a jar file?
   
   
2. 
   Where it is possible to find - starting from the most right part of the jar file name after the .jar suffix - the version and the artifactId, is it possible to find the groupId?
   
   
3. 
   is a sub to 1. and the answer to 1. is no completely. The first jar will be nekohtml-1.9.12 and the second spring-full-1.1-rc1, but in neither case is it possible to know the groupId.
   
   

Look at these examples:-

The simple case --

<dependency>
  <groupId>httpunit</groupId>
  <artifactId>httpunit</artifactId>
  <version>1.6.2</version>
</dependency>

and two complex cases -

<dependency>
    <groupId>mockobjects</groupId>
    <artifactId>mockobjects-jdk1.4-j2ee1.3</artifactId>
    <version>0.09</version>
</dependency>


<dependency>
  <groupId>jtidy</groupId>
  <artifactId>jtidy</artifactId>
  <version>4aug2000r7-dev</version>
</dependency>

The simple case is just httpunit-1.6.2,jar, and that is easy.

The first complex case is -
mockobjects-jdk1.4-j2ee1.3-0.09.jar

  --- Notice there are several hyphens in the artifactId, as the next case shows, it is
     not possible to know which one denotes the boundary between version and artifactId. ---

The second complex case is -
jtidy-4aug2000r7-dev.jar

  --- Here it is possible to surmise from the meaning that 4aug2000r7-dev belongs to the version,
     it would be difficult to make a reliable rule for this, as the previous case shows. ---

I have also seen in private repositories an underscore used in place of a hyphen and artifacts anonymised when placed into the repository from their source, i.e. this information striped out of their name, only to be renamed differently where they are consumed.

 --- This may seem particularly strange, but when you consider that the artifact is playing a role in a
     different project with its own release versions and naming, it makes some sort of sense. ---

I don't think it is possible to order artifacts without consulting an online service such as jarvana.
This would have benefits in that other information can be gleaned at the same time, such as dependencies and, of course, the missing groupId.
However, it can be that a needed dependency is incorrectly refered to. How does this happen?

This was needed.

<groupId>org.apache</groupId>
<artifactId>poi-scratchpad</artifactId>
<version>2.5.1-final-20040804</version>

This is what was found.

<groupId>poi</groupId>
<artifactId>poi-scratchpad-2.5.1-final</artifactId>
<version>20040804</version>

I coped with this through renaming, and I assume that the dependency is to be found in some prior POM downloaded with another artifact? I should look into this, but either was something has to be re-edited.
Actually I think I made the wrong choice, the thing to do would have been to look into the offending POM dependency and correct it, this way the correct artifact could be downloaded to a correct position.

So, in the end, jarvana to the rescue and my ant/maven1 ---> maven2 tool has a bit of a way to go still.