Ivy Informed Requirements & Design

[David M. Lloyd]

Whether or not the Jigsaw team is, we (Red Hat) definitely are.  Maybe 
we can set up a public IRC chat session on FreeNode for interested 
parties to join, and we can brainstorm requirements for dependency 
resolution systems.

Maybe next week sometime?

On 10/14/2011 10:26 AM, Brian Pontarelli wrote:
> 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
>


-- 
- DML