Ivy Informed Requirements & Design

[Brian Pontarelli]

Mark,

I agree that Ivy and others (particularly Savant - although it has collect a lot of dust lately) have really good dependency models and concepts that should be applied to Jigsaw. This was one of my reasons for bringing up the idea of creating a unified format for defining dependencies, resolution, handling, security, etc.

I'm not sure if the Jigsaw team is interested in community participation or standardizing some of these things, but I think it is a great idea and would help all of these projects (Jigsaw, Maven, Ivy, Savant, Gradle, etc) considerably.

-bp


On Oct 14, 2011, at 6:59 AM, Mark R Maxey wrote:

> 
> 
> Hello,
> 
> Like many, I've been following Jigsaw from afar - mainly through the last 2
> year's worth of JavaOne sessions.  Thank you for tackling this immense
> problem.  While I'm just a nobody, I'd like to offer up some concepts for
> your consideration.
> 
> Maven has a large footprint & you've rightly been letting it inform your
> direction.  However, I would suggest a better alternative is Ivy.  Ivy is a
> pure dependency analysis tool independent of Java.  It gives you the
> dependency information and repository management while letting you do with
> it what you want.
> 
> Here are a couple of Ivy features I think are relevant for Jigsaw:
> 
> 
> 
> CI & Build Promotion
> Here is a common use case: multiple teams are working on multiple modules
> concurrently.   Some teams want stability and rely on milestone releases.
> Some teams want to rely on integration / snapshot releases.  This could
> happen, for example, in the JDK where a few related modules are undergoing
> changes by different teams for different reasons simultaneously.
> 
> My concern is that the manual update of the version number in the
> module-info.java file is too cumbersome.  Maven snapshots aren't so bad
> since it is just a static suffix, i.e., "-SNAPSHOT", that would be
> infrequently updated.  However, I prefer Ivy's unique one-up numbers /
> timestamps because of the flexibility to rollback to previous builds.
> 
> Build promotion also needs to be considered.  Hudson/Jenkins is often used
> to promote an integration / snapshot build to a milestone release and a
> milestone to a GA release. Ivy & Maven can also do this.  All of these
> involve changing the version numbers on lots of modules.
> 
> It seems to me that Jigsaw needs some way of easily modifying a module's
> version without rebuilding it.  I'd like to hear your thoughts on how this
> lifecycle would play out under Jigsaw.
> 
> 
> 
> Repositories & Local Caches
> It is great that you are looking to integrate with Maven repositories.
> Here are a few related tidbits from Ivy applicable to Jigsaw:
> 
>   Ivy supports a variety of resolvers for different types of artifact
>   repositories, e.g., URL based, file based, SSH, etc.  It can also chain
>   these together in ways that allow you to specify search order.
>   You should check out the work Gradle is doing on dependency caches.  I'm
>   betting you're going to run into the same problems with Java modules.
>   Ivy also supports a sophisticated set of conflict resolution policies.
>   You can tell Ivy how to extract the GAVC out of the file path.  This
>   allows for a more customizable repository directory structure.
> 
> 
> 
> I understand these are advanced concepts that probably aren't targeted for
> your initial release.  Many may be tasks to leave to 3rd party tool
> vendors.   I simply suggest that you let them inform your roadmap forward.
> 
> 
> Thanks!
> Mark Maxey