Hi, I'm not sure that you expects feed-back from non membre of the project on this list, but I have read this mail and I have some ideas on he subject. So...
I think the two points of Xavier in favor of a 2.0 are good, but it miss a major element : the new features. Why to break the compatibility to not offer something else (except a better usability). I'm sure you also have plenty of ideas. Here is mine: Collaboration with maven : - Share the same cache. I'm using ivy from ant when it's required and for simple project I preffer to use maven. Why would I need two repository? - ivy should be able to reuse the maven settings file : location of the cache, definition of the proxies, maybe add definition of repositories, usage of profiles to define ivy variables. - Merging the concepts of profiles in maven with the concept of configurations in ivy (and there is also the concepts of dependency scope to reconciliate). - Ability to use pom.xml in the place of ivy.xml files for all ivy tasks. This would allow to build from maven when the maven plugin-is do what we want, but also to write some ant scripts using ivy when it didn't. A good example of that (actualy the major reasons for which I use ivy) is the management of the version numbers when releasing. Of curse, this should not break the possibilities that ivy users have currently : - define their own repositories - define their own dependencies transitivy rules - manage their version numbers - etc. Collaboration with ant : - Allow to use ivy to resolve dependencies for antlibs (or even to simple ant tasks) For ivy itselves: - Performances when dependency graph is deep (a factor 10 of enhancements would be a nice new features). - Review the usage of the cache to store some info. So, yes I would be pleased to view an ivy 2.0. But, has 2.0 would break the backward compatibility, a 1.4.2 would be required to fix the bugs, and to ensure a continuity for all the 1.x users. It was my 2 cents opinion. Cheers, Gilles -----Original Message----- From: Xavier Hanin [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 10:00 PM To: [email protected] Subject: future Ivy development Hi All, Ivy subversion repository should soon be migrated to ASF infrastructure, so I'd like to start discussing what will be the future developments of the project within the ASF incubator. The first thing I'm wondering about is what will be the next version of Ivy. Well, right now the next version will be 1.4.1, but it will be released tomorrow, and still with the old infrastructure and branding. What I'm wondering is what will be the first apache incubator version of Ivy? Will it be a bug fix focused version (1.4.2), a feature focused with backward compatiblity (1.5) or a major version, with some or a lot of backward incompatibilities (2.0)? The 1.x stream has began more than a year ago, and I see several reasons why we may consider a 2.0 version: * Ivy has been developed by a few people only so far, and so were the choices made for its development. The apache community is a great opportunity to discuss some choices that were made a long time ago and see if we can provide better solutions. There is in particular two things I would like to review which may break backward compatibility: * module identification For the moment module are identified by an organisation / module / revision uple (called ModuleRevisionId in Ivy code). The problem is that very often people have difficulties to find what to use as organisation and / or module. Hence I thought that we may like to review this choice, and maybe go with something similar to JSR 277 module identification system: a simple module / revision couple, in which the module name is a qualified name similar to a package name. The main advantage I see is that it would be very easy to guess the name for a jar. Even a tool could guess it in most cases, by finding the shortest non empty / non default package in a jar. Then converting dots in slashes for repository management as is done in maven 2 would make Ivy repositories closer to maven 2 ones. * terminology A choice I often regret on Ivy is the use of 'configuration' both to configure Ivy (with a configuration file) and for module configurations. First time users are often confused about that, so I'd like to change the terminology. This could be done without breaking backward compatibility (with deprecated old names), but it's an important change which would better be put in a 2.0 version * We will have to refactor existing code to move to org.apache package, this will break API backward compatibility (even if Ivy API hasn't really be meant to be a real API so far, I think it's time to stabilize it so that other tools could better use Ivy internally) * Ivy code is quite old now, with core classes developed only by one not so talented person (me :-)) very often with not much time. I'm fed up with the too flat package structure, with core classes being way too big (e.g. Ivy and IvyNode), so I can only imagine how someone taking a first look to the code can feel :-) So I think it's a good time for an important refactoring, to clean code and write some design documentation (not really my cup of tea, but we definitly need some) For all of these reasons I think we could target the next release to be a 2.0 version. However, the danger I see is that to deliver a 2.0 version it will take more time, and during this time Ivy may be considered with less interest (especially if we state that the next version will not be backward compatible). To avoid that I think we should try to keep the scope of this 2.0 version focused on the most important things, and keep the rest for later versions. We should also limit backward incompatibilty with deprecated features/attributes (except for the API, in which using deprecation would make the change too difficult), and provide tools for migration from 1.x to 2.x. So, what do you think? Xavier
