Ivy Informed Requirements & Design

[Brian Pontarelli]

I'll send an email to the ivy dev and maven dev lists. Anywhere else we should send emails to?

On Oct 14, 2011, at 11:57 AM, David M. Lloyd wrote:

> Okay, 10am PDT October 21 it is.  Let's use ##java-modularity on irc.freenode.net.  Time to spread the word.
> 
> On 10/14/2011 12:40 PM, Brian Pontarelli wrote:
>> Sounds great. Later in the week might be better and then someone can send out an email to the Maven and Ivy teams to see if they want to join in. Friday around 10am PDT might work.
>> 
>> -bp
>> 
>> 
>> On Oct 14, 2011, at 10:44 AM, David M. Lloyd wrote:
>> 
>>> 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
>> 
> 
> 
> -- 
> - DML