You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by "Loehr, Ruel" <rl...@pointserve.com> on 2008/01/16 17:44:21 UTC
IVYDE - what are the alternatives?
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
RE: IVYDE - what are the alternatives?
Posted by "Loehr, Ruel" <rl...@pointserve.com>.
Thanks. I didn't mean to start a flame thread, though I figured it would probably happen.
The response I expected was, "it's open source, if you don't like it fix it", which is completely valid.
I've checked out the source of IVYDE and attempted a few modifications, but I'm admittedly not that great at eclipse plugin development.
On fixing the use origin issue.....thats good news. That's a really big one. Thank you.
You've answered all my questions though, I'll check out the official release and see how things go.
On Jan 16, 2008 5:44 PM, Loehr, Ruel <rl...@pointserve.com> 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
The good news is that next IvyDE version will fix this, thanks to the work
done on cache management in Ivy trunk. I mean it should be fixed with
current IvyDE trunk version...
>
> <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
You can open a jira, IvyDE doesn't support ad hoc source attachment. What
IvyDE supports is automatic source and javadoc attachment if you provide
such artifacts in your metadata. This works very well with maven 2 public
repository too with current IvyDE trunk version.
> , 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?
I can't speak for the whole community but I guess so. IvyDE is far from
being as polished as Ivy, and I understand people get into trouble.
>
> 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.
I fix problems when something is wrong in my environment. OK, you'll say
that I'm a committer, so it's easy for me. But I'll answer that this is open
source and anybody can fix what's wrong. The only difference is that you
have to get through a patch to get your fix applied to the official IvyDE
sources. But knowing how IvyDE works currently I suggest taking the
"provided on an "AS IS" BASIS WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND"
words in the license very carefully. And as such I strongly suggest using it
only if you can afford its maintenance yourself.
> 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.
You're not the only one to have written this, I even wonder if there isn't
something available in open source to do this kind of thing. And I wouldn't
say you deviate from "best practices". I think best practices is to use tool
you can rely on. Can you rely on IvyDE? It depends what kind of usage you
have, I suggest running acceptance tests in your environment to see if it
works well enough for you. But I suggest this for any tool, being open
source or commercial. The problem with IvyDE is that it doesn't pass the
acceptance test very often :-(
>
> 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.
I understand. I would love to be able to do enough to avoid that... more on
this in my reply to other e-mails in this thread...
Xavier
>
>
>
>
>
>
> Ruel Loehr
> Configuration Management
>
> Pointserve, Inc.
> 110 Wild Basin Road
> Suite 300
> Austin, Texas 78746
> O: 512.617.5314
> F: 512.617.0466
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: IVYDE - what are the alternatives?
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 16, 2008 5:44 PM, Loehr, Ruel <rl...@pointserve.com> 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
The good news is that next IvyDE version will fix this, thanks to the work
done on cache management in Ivy trunk. I mean it should be fixed with
current IvyDE trunk version...
>
> <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
You can open a jira, IvyDE doesn't support ad hoc source attachment. What
IvyDE supports is automatic source and javadoc attachment if you provide
such artifacts in your metadata. This works very well with maven 2 public
repository too with current IvyDE trunk version.
> , 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?
I can't speak for the whole community but I guess so. IvyDE is far from
being as polished as Ivy, and I understand people get into trouble.
>
> 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.
I fix problems when something is wrong in my environment. OK, you'll say
that I'm a committer, so it's easy for me. But I'll answer that this is open
source and anybody can fix what's wrong. The only difference is that you
have to get through a patch to get your fix applied to the official IvyDE
sources. But knowing how IvyDE works currently I suggest taking the
"provided on an "AS IS" BASIS WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND"
words in the license very carefully. And as such I strongly suggest using it
only if you can afford its maintenance yourself.
> 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.
You're not the only one to have written this, I even wonder if there isn't
something available in open source to do this kind of thing. And I wouldn't
say you deviate from "best practices". I think best practices is to use tool
you can rely on. Can you rely on IvyDE? It depends what kind of usage you
have, I suggest running acceptance tests in your environment to see if it
works well enough for you. But I suggest this for any tool, being open
source or commercial. The problem with IvyDE is that it doesn't pass the
acceptance test very often :-(
>
> 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.
I understand. I would love to be able to do enough to avoid that... more on
this in my reply to other e-mails in this thread...
Xavier
>
>
>
>
>
>
> Ruel Loehr
> Configuration Management
>
> Pointserve, Inc.
> 110 Wild Basin Road
> Suite 300
> Austin, Texas 78746
> O: 512.617.5314
> F: 512.617.0466
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: IVYDE - what are the alternatives?
Posted by Jim Mochel <jm...@comcast.net>.
I am afraid that I have to weigh in on John side of this.
I am currently using Ivy for an ant-based build system and it works
beautifully. Unfortunately, I have to spend a great deal of my time
doing hand maintenance of the eclipse projects and dependencies in order
to ensure that re-factoring within eclipse continues to work.
I loved the IvyDE concept and I have thought I have had it working a
couple of times. But each time I have had to give up in the face of
implementation issues. I currently use IVY 1.41 at work and IVY 2.0
at home.
If I had the time I would be putting the work in to bringing the plug-in
up-to-date. Since I don't, I will just hope and pray.
Thanks,
Jim Mochel
John Gill wrote:
> I've said this before, but I'll say it again. ivyDE is what makes ivy a
> killer tool IMHO. Yet ivyDE is treated as a second class citizen when it
> comes to releases, bug fixes, etc.
>
> 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.
>
> 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
> .
>
> 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 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...
>
>
> On Jan 17, 2008 1:44 AM, Loehr, Ruel <rl...@pointserve.com> 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
>>
>>
>>
>
>
>
Re: IVYDE - what are the alternatives?
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 17, 2008 9:49 PM, Nicolas Lalevée <ni...@anyware-tech.com>
wrote:
> I understand everybody frustration here, and that's why I take time to
> fix IvyDE.
>
> Maybe to tackle users frustrations we can provide a simple XSL that
> transform Ivy's resolve report into Eclipse classpath ?
> We loose the easy of use of IvyDE, the cool editor, but at least it
> will integrate Ivy into Eclipse early.
>
> Maven is actually doing this kind of .classpath generation with "maven
> eclipse:eclipse".
>
> Even more this XSL could be released with Ivy officially.
>
> WDYT ?
I think providing this (whatever the implementation is) would be nice, but
I'm not in favor of providing this with Ivy officially: first some wouldn't
understand why we provide this for eclipse only; second maintaining and
testing this may not be easy. So I'd prefer to see this somewhere else, and
add a pointer in the official Ivy link page.
Xavier
>
>
> Nicolas
>
> Le 17 janv. 08 à 16:01, John Gill a écrit :
>
> > The thing is though is that for those of us who do use eclipse,
> > ivyDE is
> > available, and therefore we naturally want to use it. I checked my
> > inbox for
> > emails on this ivy-user list, I have 517 conversations, with about 90
> > conversations about ivyDE (about 17%), so clearly there are a lot of
> > people
> > who are or want to use it.
> >
> >
> > On Jan 17, 2008 5:49 PM, Niklas Matthies <ml...@nmhq.net> wrote:
> >
> >> On Thu 2008-01-17 at 08:24h, Xavier Hanin wrote on ivy-user:
> >>> On Jan 17, 2008 2:39 AM, John Gill <ll...@gmail.com> 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.
> >>
> >> Also, not everyone is using Eclipse. There's NetBeans, IntelliJ and
> >> JDeveloper too, for example. One good thing about Ivy is that it's
> >> not
> >> IDE-bound. At our company, anyone can use their favorite IDE on the
> >> same shared project with no problems. I'd rather have the development
> >> effort concentrate on Ivy itself than on a plugin for a particular
> >> IDE.
> >>
> >> Just my two cents,
> >>
> >> -- Niklas Matthies
> >>
> >
> >
> >
> > --
> > Regards,
> > John Gill
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: IVYDE - what are the alternatives?
Posted by Gilles Scokart <gs...@gmail.com>.
I have ant script (yes, its a complete script) that do that for rad7.
It is unfortunatelly too loosly coupled with my project to share it.
The major reason to do this was to :
1. Support dependencies between project present in the eclipse workspace
2. Support dependencies in Ear and War projects.
I also already started to write ant task to do it [1]. But it was difficult
to make it generic and I fall out of time to finish it.
[1] http://ivytools.svn.sourceforge.net/viewvc/ivytools/
2008/1/17, Jing Xue <ji...@digizenstudio.com>:
>
>
> Quoting "Loehr, Ruel" <rl...@pointserve.com>:
>
> > +1.
> >
> > I like the idea of having an xsl to do this (I'm a little
> > embarrassed that I didn't think of it before). I'd be happy to
> > help you work on it or test it.
> >
> > I had written an ant task to do the same sort of thing, but XSL
> > would be a lot simpler.
>
> I wrote my own ant task to do that, too, which uses ant xml task to
> manipulate .classpath.
>
> My turn-off with IvyDE is it runs ivy.xml+ivysettings.xml without
> going through the same ant script used to make official builds. We
> have lots of property and environment settings done in ant before
> invoking ivy, so the "naked" ivy files just won't work.
>
> Cheers.
> --
> Jing Xue
>
>
--
Gilles Scokart
RE: IVYDE - what are the alternatives?
Posted by Jing Xue <ji...@digizenstudio.com>.
Quoting "Loehr, Ruel" <rl...@pointserve.com>:
> +1.
>
> I like the idea of having an xsl to do this (I'm a little
> embarrassed that I didn't think of it before). I'd be happy to
> help you work on it or test it.
>
> I had written an ant task to do the same sort of thing, but XSL
> would be a lot simpler.
I wrote my own ant task to do that, too, which uses ant xml task to
manipulate .classpath.
My turn-off with IvyDE is it runs ivy.xml+ivysettings.xml without
going through the same ant script used to make official builds. We
have lots of property and environment settings done in ant before
invoking ivy, so the "naked" ivy files just won't work.
Cheers.
--
Jing Xue
RE: IVYDE - what are the alternatives?
Posted by "Loehr, Ruel" <rl...@pointserve.com>.
+1.
I like the idea of having an xsl to do this (I'm a little embarrassed that I didn't think of it before). I'd be happy to help you work on it or test it.
I had written an ant task to do the same sort of thing, but XSL would be a lot simpler.
-----Original Message-----
From: Nicolas Lalevée [mailto:nicolas.lalevee@anyware-tech.com]
Sent: Thursday, January 17, 2008 2:50 PM
To: ivy-user@ant.apache.org
Subject: Re: IVYDE - what are the alternatives?
I understand everybody frustration here, and that's why I take time to
fix IvyDE.
Maybe to tackle users frustrations we can provide a simple XSL that
transform Ivy's resolve report into Eclipse classpath ?
We loose the easy of use of IvyDE, the cool editor, but at least it
will integrate Ivy into Eclipse early.
Maven is actually doing this kind of .classpath generation with "maven
eclipse:eclipse".
Even more this XSL could be released with Ivy officially.
WDYT ?
Nicolas
Le 17 janv. 08 à 16:01, John Gill a écrit :
> The thing is though is that for those of us who do use eclipse,
> ivyDE is
> available, and therefore we naturally want to use it. I checked my
> inbox for
> emails on this ivy-user list, I have 517 conversations, with about 90
> conversations about ivyDE (about 17%), so clearly there are a lot of
> people
> who are or want to use it.
>
>
> On Jan 17, 2008 5:49 PM, Niklas Matthies <ml...@nmhq.net> wrote:
>
>> On Thu 2008-01-17 at 08:24h, Xavier Hanin wrote on ivy-user:
>>> On Jan 17, 2008 2:39 AM, John Gill <ll...@gmail.com> 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.
>>
>> Also, not everyone is using Eclipse. There's NetBeans, IntelliJ and
>> JDeveloper too, for example. One good thing about Ivy is that it's
>> not
>> IDE-bound. At our company, anyone can use their favorite IDE on the
>> same shared project with no problems. I'd rather have the development
>> effort concentrate on Ivy itself than on a plugin for a particular
>> IDE.
>>
>> Just my two cents,
>>
>> -- Niklas Matthies
>>
>
>
>
> --
> Regards,
> John Gill
Re: IVYDE - what are the alternatives?
Posted by Nicolas Lalevée <ni...@anyware-tech.com>.
I understand everybody frustration here, and that's why I take time to
fix IvyDE.
Maybe to tackle users frustrations we can provide a simple XSL that
transform Ivy's resolve report into Eclipse classpath ?
We loose the easy of use of IvyDE, the cool editor, but at least it
will integrate Ivy into Eclipse early.
Maven is actually doing this kind of .classpath generation with "maven
eclipse:eclipse".
Even more this XSL could be released with Ivy officially.
WDYT ?
Nicolas
Le 17 janv. 08 à 16:01, John Gill a écrit :
> The thing is though is that for those of us who do use eclipse,
> ivyDE is
> available, and therefore we naturally want to use it. I checked my
> inbox for
> emails on this ivy-user list, I have 517 conversations, with about 90
> conversations about ivyDE (about 17%), so clearly there are a lot of
> people
> who are or want to use it.
>
>
> On Jan 17, 2008 5:49 PM, Niklas Matthies <ml...@nmhq.net> wrote:
>
>> On Thu 2008-01-17 at 08:24h, Xavier Hanin wrote on ivy-user:
>>> On Jan 17, 2008 2:39 AM, John Gill <ll...@gmail.com> 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.
>>
>> Also, not everyone is using Eclipse. There's NetBeans, IntelliJ and
>> JDeveloper too, for example. One good thing about Ivy is that it's
>> not
>> IDE-bound. At our company, anyone can use their favorite IDE on the
>> same shared project with no problems. I'd rather have the development
>> effort concentrate on Ivy itself than on a plugin for a particular
>> IDE.
>>
>> Just my two cents,
>>
>> -- Niklas Matthies
>>
>
>
>
> --
> Regards,
> John Gill
Re: IVYDE - what are the alternatives?
Posted by John Gill <ll...@gmail.com>.
The thing is though is that for those of us who do use eclipse, ivyDE is
available, and therefore we naturally want to use it. I checked my inbox for
emails on this ivy-user list, I have 517 conversations, with about 90
conversations about ivyDE (about 17%), so clearly there are a lot of people
who are or want to use it.
On Jan 17, 2008 5:49 PM, Niklas Matthies <ml...@nmhq.net> wrote:
> On Thu 2008-01-17 at 08:24h, Xavier Hanin wrote on ivy-user:
> > On Jan 17, 2008 2:39 AM, John Gill <ll...@gmail.com> 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.
>
> Also, not everyone is using Eclipse. There's NetBeans, IntelliJ and
> JDeveloper too, for example. One good thing about Ivy is that it's not
> IDE-bound. At our company, anyone can use their favorite IDE on the
> same shared project with no problems. I'd rather have the development
> effort concentrate on Ivy itself than on a plugin for a particular IDE.
>
> Just my two cents,
>
> -- Niklas Matthies
>
--
Regards,
John Gill
Re: IVYDE - what are the alternatives?
Posted by Niklas Matthies <ml...@nmhq.net>.
On Thu 2008-01-17 at 08:24h, Xavier Hanin wrote on ivy-user:
> On Jan 17, 2008 2:39 AM, John Gill <ll...@gmail.com> 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.
Also, not everyone is using Eclipse. There's NetBeans, IntelliJ and
JDeveloper too, for example. One good thing about Ivy is that it's not
IDE-bound. At our company, anyone can use their favorite IDE on the
same shared project with no problems. I'd rather have the development
effort concentrate on Ivy itself than on a plugin for a particular IDE.
Just my two cents,
-- Niklas Matthies
Re: IVYDE - what are the alternatives?
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 17, 2008 2:39 AM, John Gill <ll...@gmail.com> 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 <rl...@pointserve.com> 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/
Re: IVYDE - what are the alternatives?
Posted by John Gill <ll...@gmail.com>.
I've said this before, but I'll say it again. ivyDE is what makes ivy a
killer tool IMHO. Yet ivyDE is treated as a second class citizen when it
comes to releases, bug fixes, etc.
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.
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
.
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 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...
On Jan 17, 2008 1:44 AM, Loehr, Ruel <rl...@pointserve.com> 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