Is there any scope to revisit collaborating on the metadata? I know
you ruled it out back in 2005, 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.
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.
Is it worth discussing? 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
