ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: IVYDE - what are the alternatives?
Date Thu, 17 Jan 2008 07:24:52 GMT
On Jan 17, 2008 2:39 AM, John Gill <> wrote:

> I've said this before, but I'll say it again. ivyDE is what makes ivy a
> killer tool IMHO.

I don't share your opinion, but I understand. IMO Ivy shines by its
flexibility and predictability. Ivy+IvyDE is a very good combination, but
you have pretty similar eclipse plugin for maven and this doesn't make me
love maven.

> Yet ivyDE is treated as a second class citizen when it
> comes to releases, bug fixes, etc.

You're right.

> The fact that the projects are separate is part of the problem (and the
> size
> of the development team doesn't help I guess) in my view.

The projects aren't that much separated. When we moved to Apache we wondered
about moving IvyDE elsewhere, and we finally agreed to have it as a sub
project of Ivy, which makes it as close as it can be IMHO.
On the other hand, I'm not sure this relationship with Ivy is the problem,
or maybe not in the sense you see it. What is nice with IvyDE being an Ivy
subproject is that it gets more exposure. But it also means that we have to
follow ASF guidelines, and cutting a release at the ASF is more work than in
a sourceforge project for example. We do this job for Ivy, but this is not
the kind of work you do with pleasure: checking licenses, making sure your
packaging is allright, and so on. That's why I've started sharing some
unofficial IvyDE builds on, to help people use latest IvyDE
without going through the ASF release process. And that's really the best I
can do.

The real problem with IvyDE is that I guess nobody will object if I say that
I'm the only committer taking care of the project currently. But can we
blame other committers? Certainly not!!! They already involve much more time
in Ivy development than any other user. Because this what anybody should
remind when using Ivy / IvyDE: Ivy is developed by its users. Nobody gets
paid for dedicating time to the project. We all do this in our spare time.
Fortunately for IvyDE, I get help from the community, and I thank all the
contributors, and especially Nicolas Lalevée who has contributed many
patches recently, and several answers to questions too. But if developing a
tool like Ivy when you are only 3 committers is not easy, developing a
plugin like IvyDE mostly alone is even more difficult. And it's difficult to
attract people because you need to understand Ivy API which is so poorly
documented (and this is my fault) and to have eclipse plugin development
skills. How many people out there with this kind of skills? Not many. And
this is the core of problem IMHO.

> Personally, I have stuck with ivy 1.4.1 and ivyDE 1.2.0 because I can't
> put
> up with the problems with ivyDE that goes with ivy 2.x. I have attempted
> to
> migrate to ivy/ivyDE 2.0 several times now and it is just to problematic,
> so
> I figure "if it works, don't fix it" and stay with ivy 1.4.1 and ivyDE
> 1.2.0

I undertand, and I guess that's what I'd do too if I were you. But if you
later need to migrate to Ivy 2 for any reason (using a maintained release,
using some of the new features, ...) then you'll have to either drop or
upgrade IvyDE. And the best way to make sure the upgraded version of IvyDE
works well enough in your environment is to get involved!

> .
> Here is a dig at the maven users (and I expect to get flamed on this one
> big
> time, so bring it on... :-), but maybe if it wasn't for all these issue
> about maven repositories, and pom.xml problems, ivyDE could be given more
> time. The answer is simple... Build your own repository and stop using
> maven
> poms, repositories, etc and use ivy, OR use maven and don't use ivy. To me
> it seems like maven integration is given more time and energy than other
> issues, which for people who want to use plain old ivy is really
> disappointing. Frankly, I'd like to see a "ivy-maven" pseudo component in
> JIRA to track all the maven related issue separately.

I'm in favor of adding this component too, not sure I'll have time to

But I guess you'd be surprised if you compared the number of lines changed
for maven compatibility related issues compared to others. Have a look at
what has been done to get Ivy more maintainable and easier to understand to
help people get involved and ease its use as an API (which is exactly what
IvyDE does). This was done almost one year ago, and took at least 4 full
work days. Have a look at the changes done recently for cache management,
the most wanted feature in Ivy (IVY-399). For the whole work I estimate
approximately 10 days. Any idea on how long it took to implement the latest
compatible conflict manager? Approximately 2 days (but I got paid, so it's
slightly different). And this is only some examples of what I've done, other
committers have done great achievement too (improvement in configurations
like IVY-588, review of settings handling and relative paths, ...) And so
on, check yourself the list of changes, and you'll see that there is still
much more work done for Ivy core than for maven compatibility. And anyway,
if committers choose to work on maven compatibility, you can't blame us.
Maybe we do only what we need (which is already much better than nothing).
Maybe we do what peek our interest. Maybe we work for the sake of the user
community, to see the project helpful for more and more users. Whatever
reason, it's still time and sometimes feel more like work than fun
(reviewing documentation, preparing a release, I really have no fun at this
kind of things).

So don't get me wrong, I understand your frustration, but I have no other
solution than doing my best to get more people involved, and thank anybody
for any contribution (including you, because you contribute so much through
e-mails and issues). I'm really sorry, but I can't involve more time in OSS
without being paid, my ratio is already about one half of my working time,
and my wife starts to complain :-)

> I am now going to press the send button, and I just know I am going to
> regret writing the previous paragraph, but what the hell...

Have no regret, this is your opinion, and I really respect it.  Maybe I'll
regret pressing the send button too. But what the hell...


> On Jan 17, 2008 1:44 AM, Loehr, Ruel <> wrote:
> > First,   I'm a big fan of ivy.   When we use it through command line, it
> > is flawless.
> >
> > The eclipse integration is starting to become painful to the point that
> we
> > are investigating alternatives.
> >
> > The first issue I ran into was when dealing with snapshots:
> >
> >
> > This morning one the developers reported that
> >
> > "appears that in JBDevstudio 1.0.0 GA at least, setting source
> attachments
> > on jars in the ivy container doesn't work, so i can't debug into or
> navigate
> > third-party source like ibatis."
> >
> > I'll investigate this and open a jira if necessary, but it leads to me
> the
> > questions.....
> >
> > 1)       We're betting the farm so to speak on IVYDE.   Are other people
> > experiencing the same sort of difficulties?
> > 2)       If so, how are you handling it?   Developing in eclipse is here
> > to stay for  us ;)  I need to make this bulletproof for our devs.
> > 3)       I've already built an ant task to generate an eclipse classpath
> > based off the ivy.xml.   I realize that this is essentially how maven
> > handles their ide integration.  Maintaining what is essentially a fork
> from
> > the "best practices" isn't all that appealing to me though.
> >
> > I'm patiently awaiting the first official apache release and seeing  how
> > that goes, but if I'm still seeing issues I'm going to have to deviate
> from
> > IVYDE.
> >
> >
> >
> >
> >
> > Ruel Loehr
> > Configuration Management
> >
> > Pointserve, Inc.
> > 110 Wild Basin Road
> > Suite 300
> > Austin, Texas 78746
> > O: 512.617.5314
> > F: 512.617.0466
> >
> >
> --
> Regards,
> John Gill

Xavier Hanin - Independent Java Consultant

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message