Hi Xavier.
I want to share my opinion with you.
First of all, Ivy 2.0 could be developed in parallel to 1.x branch.
Keeping 1.x branch is a must to support existing users, but it should not
interfere with designing and developing a new branch.
How do I see Ivy 2.0:
- First of all, we need to organize a list of requirements. They should
mainly come from real needs of the community.
- After having a list of requirements, we have to prioritize them and
discuss what will be included in ivy-2.0
- In addition, as I wrote in the past in the forum, I think managing a
use-case list would make it easier to concentrate on users' needs.
Currently, I have the feeling that any request from any user is getting
integrated. Of course at this stage of Ivy it is a good idea to help anyone
to adopt Ivy, but in the future, this approach could lead to an
architectural mess. I suggest organizing the needs and giving any use-case
the most simple and easy to use solution. (See Maven for example. It is a
big mess of many requirements. The result? Ivy! (of course :-)) Ivy is
concentrated on dependency-management and is trying to do its best, so this
is the reason it may be simpler and easier to use than Maven. Let's keep
this!)
- I currently can see the following requirements (just a few thought. Not
very ordered list):
1. Ivy, in general, manage artifacts. An artifact should be identified (open
discussion here) and may have additional attributes (status, publish date,
etc.)
2. Main part of managing artifacts is SEARCH. An artifact could be searched
by its ID and/or by its attributes. (e.g. ID=org.apache.log4j,
Attributes={status=release, publish-date=latest}. Just a possible example.)
3. Public repository is a great idea, but as we already can see, IBiblio and
ivyrep sites have a lot of traffic and some down times. A peer-to-peer
(eMule- and Kazaa-like) approach can help a lot in creating a widely
distributed reliable global repository.
4. In my vision, any open-source organization (like Apache, SourceForge,
etc.) would have its own repository (Ivy, Maven or other). Ivy would be able
to dynamically discover such global repositories and suggest the user using
them. The idea is: "think big!" If we would think big from now, we would be
able to easily scale Ivy to be the ad-hoc leader and standard in dependency
management world.
5. The concept of "module metadata" should be abstract. ivy.xml and
pom.xmlare only 2 possible implementations. Of course Ivy should be
backward and
forward compatible with Maven. I think it would just help much more users to
adopt Ivy.
6. Simplicity. Of course Ivy should be easy to use. A good architecture
should reconsider simplicity and usability at each and every release of ivy.
7. Fast repositories: sometimes creating a symbolic link (or even a hard
copy) of the latest artifact would make ivy much faster in getting the
latest release or integration version. A resolver for such a repository
would just bring the stuff from "latest.release" or "latest.integration"
directory instead of calculating the latest revision itself. (Looking at the
debug message I suspect that this behavior is already implemented?)
So in conclusion, I suggest creating the following collaboration tools:
1. Use cases (current and wish lists)
2. Requirements
Maybe Wiki will be a good tool to collaborate and share these lists.
What do you think?
easyproglife.
