[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.technology.buckminster] Re: buckminster and maven repositories
Hi Edwin,
Our original intent was to write a mechanism that would do downloads and resolution from the Maven repositories. Our first implementation was for Maven 1. We later added support for Maven 2 but we didn't make it perfect for the simple reason that by then, discussions had commenced with people that were committers in the Maven project. They informed us about the maven embedder technology that would soon be released in Maven 2.1 and they created a patch for a Buckminster maven provider that would use this embedder. This was back in March 2007.

Unfortunately, Maven 2.1 has not yet been released and when it is, it has to go through a Eclipse Intellectual Property review. Since it has a dependency to 40 or so different jars, some with different licenses, that is likely to take some time.

Buckminster is planning a graduation review on January 30. In conjunction with that, we also plan to move from technology to tools. This means that we will no longer be in incubation and hence, no longer able to bundle things under what's called "parallel IP". This effectively rules out everything that hasn't been fully IP approved by the Eclipse EMO and hence, we are stuck with our own home-brewed maven provider.

So question is, what do we do now. Do we wait until we can get an approval? Or do we wait even longer until the proposed IAM project is approved so that they will provide the needed API's? From the looks of it, not much is happening on that front at present. Perhaps the wait is over and we must improve our current Maven support. After all, it wouldn't be that much work.

Would you be interested in having a go at it and perhaps submit a patch?

Regards,
Thomas Hallgren


Edwin Park wrote: 
Hi,

I noticed that when buckminster tries to read information from a maven repository, it assumes that the repository is a browseable apache directory, and parses the html in order to lookup artifact versions. This works for maven repositories that are implemented as browseable apache directories, such as the central http://repo1.maven.org/maven2 repository, but it does not work for many other proxy repositories (e.g. artifactory). It's good practice NOT to use the central repo, however, and to use a proxy instead in order to avoid slamming the central repo which is often slow, to insulate yourself from external connectivity issues, control version changes, etc. etc.

The right way to address this would be to change the Buckminster behavior to lookup artifact version information the same way the mvn command does: by looking up appropriate maven-metadata.xml files in the repository. These metadata files must be available and accessible in any maven repository. For instance, if I go to the central repo and want to find the available versions of org.springframework:spring artifacts, rather than going to http://repo1.maven.org/maven2/org/springframework/spring/ and parsing the directory listing, the correct thing to do would be to GET the http://repo1.maven.org/maven2/org/springframework/spring/maven-metadata.xml file and look through its contents. It is much easier to parse and has the same structure for every repository.

Using the maven-metadata.xml file will also help you support correct behavior when accessing snapshots. Maven snapshots are identified by versions with a trailing 'SNAPSHOT', e.g. commons-dbcp:commons-dbcp:1.3-SNAPSHOT. However, the artifacts actually stored in the repository will be named something like http://people.apache.org/repo/m2-snapshot-repository/commons-dbcp/commons-dbcp/1.3-SNAPSHOT/commons-dbcp-1.3-20071125.225953-2.jar - note that instead of SNAPSHOT, a timestamp is used. The maven-metadata.xml file to the rescue again: when a client asks for the 1.3-SNAPSHOT version, look at the maven-metadata.xml file: http://people.apache.org/repo/m2-snapshot-repository/commons-dbcp/commons-dbcp/maven-metadata.xml and you will see info about the timestamp and build number which you can use to construct the proper url for your artifact GET request.

I have all my maven artifacts in an Artifactory repo and can't get to them via Buckminster right now, so I'd love to see the proper behavior implemented. I'd be happy to help with the implementation, but I'm not that familiar w/the Buckminster internals so I'd need some guidance there; and given that this is pretty straightforward thing, it would probably be faster for someone more familiar w/the internals to do it instead. If you do decide you'd like my help though, please let me know.

Cheers,
Edwin