On 11/8/06, easy life <[EMAIL PROTECTED]> wrote:
Hi Xavier.
Hi,
I want to share my opinion with you.
I see a lot of people are reacting to my mail, I wasn't used to get so much
feedback previously, is it already the apache effect ? :-)
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.
Yes, keeping a 1.x branch would be great, but for the moment the development
team is not big enough to spread the effort on both a 1.x effort and a
2.xone. I think we should first stay focused, either on
1.x or 2.x, but not both. Except to release bug fix or minor improvement (
1.4.x) versions while developing 2.0 for example. But I'm not sure trying to
add new (big) features to a 1.5 for example would really be compatible with
a 2.0 branch with major refactoring which would make porting from one branch
to the other difficult.
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.
I agree that we should work with use cases and find an easy solution for
each of them. But I believe a strength of Ivy is to be flexible, and I
really would like it to remain flexible, so accept most of users use cases
even when we don't think it's the best way to use a dependency manager.
(See Maven for example. It is a
big mess of many requirements. The result? Ivy! (of course :-))
I know you're just kidding, but I really think Maven is far from being a
big mess of many requirements. IMO, at least Maven 2 is a tool with a true
philosophy. The main problem I see is the lack of flexibility for some use
cases. But Maven does so much when Ivy does only dependency management that
it's difficult to compare.
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 agree, Ivy tries to follow the old unix tools principle: do one thing but
do it well. So what you are looking for is just a dependency manager I think
Ivy is a good tool.
- 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.
Interesting. I share your opinion on several points. Especially on the
necessity of using a wiki to share this kind of data.
On the other hand, I'm not sure this is how I would like to see Ivy
2.0design process go. Well, at least I think a project like Ivy need
to release
new stuff often. Especially now that it is just moving to a new website,
with a new brand, and new way to communicate. So maybe my ambition to go
with a 2.0 version is, well, too ambitious. Or maybe simply what I see in a
2.0 version of Ivy is just a 1.5, but with enough changes to name it 2.0.
Maybe the process to rethink everything should better occur later, for
a 3.0version. To avoid facing too many issues at a time (the move to
ASF and the
ambition of re thinking every thing).
What do you think?
Xavier
What do you think?
easyproglife.
