On 11/8/06, Gilles Scokart <[EMAIL PROTECTED]> wrote:
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'm not yet accustomed with ASF rules, but as far as I understand the philosophy any feedback is welcome. 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).
Usability is a feature itself IMO. What I think is that a set of new features is good if it doesn't impact too much the delay of such a version. I think we should try to make a list of features (jira is a good way to do that), and discuss about their inclusion in a 2.0 version based on: - the interest we see in the feature - the time we estimate it will take to develop - the interest someone has to develop it in a well defined time (if a feature adheres to the philosophy and if someone contributes a patch for it with tests and documentation, I see no reason why it shouldn't be part of the next version) - the impact on backward compatibility and code change IMO, if a feature has no major impact on backward compatibility or code change, even if it's interesting we could postpone it to a 2.1 version. Once again, I think we should stay focused to avoid a major delay before 2.0. 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.
Good ideas, I'm sure brett will agree :-) This collaboration could be a major enhancement which could absolutely be part of a 2.0 version, which will require more discussion with maven team as engaged by brett in another mail. 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)
The concept of resource of ant 1.7 could also be good fit to improve the integration. But I think this is something that would not imply any major incompatibility or code change. For ivy itselves:
- Performances when dependency graph is deep (a factor 10 of enhancements would be a nice new features).
We (me and other users) have already worked on that subject in Ivy 1.4, going further is not an easy task, because performance is not something which has been forgotten, sometimes it's simply because a lot of things actually need to be done. This can still be improved, but I just say this is not a trivial task. But if others feel Ivy's too slow it would be good to investigate before a 2.0 version, because it may cause major code change to improve performance drastically. At least the code refactoring I suggest should be accompanied by regular performance measurement. - Review the usage of the cache to store some info. Agree, this is something already discusses on the forum and there's a jira issue for that. Moreover it's something which will imply a backward incompatibility, at least at API level and cache level. 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.
Yes, you're right. In this case we should even target first a 1.4.2 version, because it will probably be out before the 2.0. We will have to use a branch for that. But if we go with such a version, I have a question about ASF: is it possible to publish a 1.4.2 version of Ivy within the incubator using the fr.jayasoft.ivy package? Because if we have to change the package maybe we should at least name the version 1.5, even if it's only a bug fix version, to show that there is an API incompatible change. Any thoughts? Xavier 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.xto 2.x. So, what do you think? Xavier
