On 11/8/06, Brett Porter <[EMAIL PROTECTED]> wrote:
Is there any scope to revisit collaborating on the metadata?
I think that moving to apache is a great opportunity to collaborate on the metadata, and if we choose to go with a 2.0 version, it will allow to give more flexibility to our point of view :-) So that's one more pro for a 2.0version :-) I know
you ruled it out back in 2005,
I regret you understood it like that, I should had been more cautious when speaking about that. The problem we identified at that time was that our users liked the flexibility of our module configurations and configuration mapping, and your point of view about that kind of flexibility was different. That's why I thought we both concluded we were not ready to collaborate on metadata. Anyway now I think both maven 2 and ivy are more mature, thus it should be easier to identify use cases that must be addressed and how we can address them. but you've identified that getting
contributed metadata in has been a problem for Ivy, something Maven is well familiar with and are (slowly) addressing and making good progress (especially with tooling in the area now). Seems like a good opportunity.
Yes, getting contributed metadata is difficult, and Maven has a lot more experience on the subject than Ivy community has. So I'd love to benefit from your experience, and so does the Ivy community I guess :-) Maven is getting into it's next big development cycle so additions/
changes to the POM and revisions to the way the dependencies are resolved are both up for grabs and high on my list of things to do.
This is great if we are both at a step where discussions can really lead to change in the tools and a more homogeneous way to deal with that difficult problem of managing dependencies. Is it worth discussing? Definitely! Xavier Incidentally, I think it solves your
configuration vs configuration naming issue too :)
Cheers,
Brett On 08/11/2006, at 8:00 AM, Xavier Hanin wrote: > 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
