On Jan 17, 2008 2:39 AM, John Gill <[EMAIL PROTECTED]> 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 xoocode.org, 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 though. 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... Xavier > > > On Jan 17, 2008 1:44 AM, Loehr, Ruel <[EMAIL PROTECTED]> 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: > > > http://www.nabble.com/IVY-DE-and-use-origin-flag-td13203097.html#a13203097 > > > > 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 http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
