Maven Dependency Resolution

Maven Dependency Resolution

05/11/09 17:42

What have I been doing recently?
Building a variety of projects.
These include some - relatively - old projects. All of the CoffeeShop sample code in JUnit Recipes: Practical Methods for Programmer Testing -
Here are the details --
By: J. B. Rainsberger
Publisher: Manning Publications
Pub. Date: July 15, 2004
Print ISBN-10: 1-932394-23-0
Print ISBN-13: 978-1-932394-23-8
Pages in Print Edition: 752

Look up safaribooksonline

This is from around 2005.
I have also done same with zoe, also from around 2005.
Interesting.
CoffeeShop, with multiple projects, needed a lot of work reconciling dependencies.
In come my friends jarvana and so.
zoe [1.,2.,3.,4.] is different, and, in a way, more complex.
zoe is configured for maven1 with a project.xml file.
It is instructive making the conversion by hand. Certainly the mvn one:convert tool cannot cope.
There are guesses that can be made that must be regular mappings. So why not look at the xsd for each version, along with any notes, and make a map from this, say using generateDS?

There are some other things.
The way I see it is that we have.

1. 
   ant builds - these entail finding canonical versions of referenced artifacts across a system - as far as is
   possible.
   
   
   1.1. when artifacts have been resolved the .properties file needs to be referenced in the created pom
   
   
   1.2. the build.xml file needs to be parsed, from what I can see just for directory locations
   
   
   1.3. the build file remains intact, other tasks, such as code generation, will be invoked via ant
   
   
   1.3.1. some tasks are ant like and it is not reasonable to use maven for them. However some tasks imply something
   about structure that really needs to be resolved in the pom module dependency hierarchy.
   It is unclear how to make this distinction automatically, but a mechanism to create a module against
   which a specific complex ant task is run would go some way.
   
   
2. 
   maven1 builds - this would entail a mapping between the two as mentioned.
   
   
3. 
   creating canonical versions and canonical version management.
   
   
   3.1. creating canonical - there are different issues here. Finally it seems that there is no way of engineering
   an unknown version apart from doing a look up
   
   
   3.2. look ups have their own difficulties and interest. Sometimes a project cannot be found -
   
   
   3.2.1. the jar is not available on public repositories, e.g. Sun version jars
   
   
   3.2.2. the particular version is not available
   
   
   3.3. above seems to be an issue that could be solved with some very sophisticated search - more later
   
   
   3.4. canonical version management - augeas with the magic lens seems to be the way to control this and seems
   preferable to an XML db. It would only be build.xml that would be appropriate to an xml db anyway.
   
   
4. 
   issues to explore are semantic annotation, which would seem appropriate to build.xml etc. This maybe made
   automatic if it is possible to digest the nature of the ant tasks.
   
   

---

---

1. http://alt.textdrive.com/dynam/
2. http://alt.textdrive.com/nanoki/
3. http://it1.evectors.it/itSites/zoe/
4. http://www.zoeprofessional.com/taketour.html

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.