Downloading and installing maven artifacts as modules

[Brian Pontarelli]

On Sep 27, 2011, at 10:14 AM, David M. Lloyd wrote:

> On 09/27/2011 10:06 AM, Brian Pontarelli wrote:
>> 
>> On Sep 27, 2011, at 6:47 AM, Alan Bateman wrote:
>> 
>>> Jesse Glick wrote:
>>>> 
>>>> If this were to be more than a demo, you would not want to recreate the logic for parsing Maven metadata, but rather call into the official embedding APIs.
>>>> 
>>>> I do not think you want to interpret<packaging>zip</packaging>; does such a packaging even exist? (Various named packagings produce *.zip artifacts which are usually software distributions, i.e. contain JARs and other files as entries.)
>>> This is just a demo for now, it's purpose being to tease out the issues that we would have if we were to extend the repository support to allow a module library be associated with a maven repository. Clearly we don't want to be parsing maven metadata but it's done this way for now to avoid the dependency.
>> 
>> I've been sporadically following Jigsaw but I saw this thread and have recently been discussing a similar topic with some folks. The topic we have been discussing is the meta-data needed for pure dependency management compared to the meta-data provided by Maven, Jigsaw, Ivy, Savant and others.
>> 
>> I wanted to bounce this idea off of this list as well as other Maven, Ivy and others. The idea would be to create an open standard format that defines the meta-data needed to do pure dependency management. This has a number of key benefits including:
>> 
>> 	- Standardize dependency repositories
>> 	- Clean dependency definitions
>> 	- Simple way for tool providers to work with dependencies separate from the build and runtime systems
>> 	- Easier migration between build tools (pick the right tool for the job not the repository or dependency management system)
>> 
>> There are probably other benefits as well. I wanted to get your thoughts this concept. It looks like Jigsaw intends to support POMs and potentially support some of OSGi, but at a baseline, there are a number of concepts that can be defined and shared across all these projects.
> 
> Not only this, but the Maven POM/repository format has many known inadequacies as the requirements for build dependencies are substantially different from the requirements for a runtime module environment.  Establishing a base set of requirements with community input is a key step to doing this right.

I agree. There are a number of concepts that some systems lack and others have, both around compile-time and runtime dependency management. A few ones that come to mind are:

	- Version compile-time compatibility
	- Version runtime compatibility
	- Version ranges
	- Code meta-data changes (group-id, package, ownership, etc)
	- Repository changes (re-location, etc)
	- Public and private code

Depending on the level of interest, I'd be willing to reach out to the Maven and Ivy developers and work on putting together an expert group for this.

-bp