
Apache Ivy – any future or is it also going to be retired? - winteriscoming
http://marc.info/?l=ant-dev&m=148092276604514
======
agentgt
I was a long time user many many years ago of Ivy. I will say Ivy is one of
the most sophisticated dependency management libraries/tools. It has things I
have yet to see other dependency managers do (and probably should not do
anyway).

The flexibility was sort of good for our enterprise code base that was still
using Ant but over all it was just way too complicated (this was in part
because it was not integrated with any particularly build system at the time ~
8 or so years ago).

I have come to the conclusion that with proper parent poms and enforcer
plugins (particularly dependency convergence) you can generally get Maven to
do a fairly good job.

The only thing I can't decide is if Maven (and Ivy for that matter) should
have lock files. I have some ambivalence to lock files (ie a file that gets
auto generated and that you check in). Bundler and cargo do it as well as a
netflix gradle plugin.

I deal with the lack of a lock file by using maven parent poms, sonatype,
enforcer plugins, and version plugins.

------
gsylvie
Next-In-Thread:

\---

    
    
      We see Ivy as a widely used component.
      We use archiving some components to
      recalibrate our focus. I don't think
      that we want to archive Ivy in the near
      future. Instead we try to push Ivy.
    
      If you want to help with Ivy, you're welcome.
    
      "It's already a challenge to stick with
      Ivy build system itself given the lack of
      fixes/releases/responses." What are the
      problems you think are resolved with new
      Ivy releases?
    
      Jan
    

\---

~~~
teraflop
That's a nice boilerplate comment that could be applied to any open source
project, but the reality is that Ivy is essentially abandonware.

At one point recently, I did a search and couldn't find any committer activity
of any kind (code, mailing list messages, JIRA updates) for the better part of
a year. And it's not like the project is "stable" or "complete" either --
users are constantly making posts about serious bugs that go unanswered,
because there's nobody active who has the knowledge to investigate or fix
them. (I've run into a couple of these myself.)

EDIT: Just took another look to see if anything had changed. The good news is
that a couple of very minor bugfixes were committed in November, amounting to
a grand total of 14 lines of code changed. There have been no other commits in
the past 12 months, and the last time one of the committers responded to a
question on the mailing list was March 2015.

------
Randgalt
Doesn't sbt still use Ivy under the covers? I know Gradle used to but maybe
not anymore. In any event, Ant is still an active project and Ivy is it's dep
system.

~~~
th3iedkid
sbt still uses ivy and so do many other projects that not just use sbt but ant
ones that directly use ivy.

SBT is quite a used one too.

~~~
johnwatson11218
I had to dig into gradle dependency resolution once I think I did see it
falling back to ivy if it couldn't find it in the maven repo, or if the
workstation had a config file for ivy but not maven. Kind of fuzzy on the
details at this point.

------
tfordon
A project I used to work on (opticks.org) used Ivy. At the time, Ivy was the
best solution we could find for C++ dependency management.

Are there any good cross-platform alternatives for C++ dependency management?

~~~
KindDragon
We also used Ivy for C++ dependency management, now we use Conan.io. But it is
very different with Ivy in many aspects

~~~
KindDragon
Someone suggest use Gradle with C++, but we did not try
[https://gradle.org/getting-started-native/](https://gradle.org/getting-
started-native/)

~~~
pjmlp
Given its state on Android, I wouldn't advise it.

Google gave up on their plugin for C++ and is now advising cmake as the future
for new NDK projects.

------
PaulHoule
Why use Ivy when there is Maven?

~~~
mbreese
I never liked the way Maven built projects - it just seemed like overkill for
simple things. I tended to use hand-written Ant builds backed by Ivy for
dependencies. Then again, I also build odd outputs, like self-executing jars.

~~~
djsumdog
The only thing that will survive from the Maven era is the directory
structure. It's the default structure in SBT and many other built tools. It's
a little verbose, but it does make sense and I've learned to embrace it.

Maven is terrible. Give SBT or Gradle and try and you'll see just how terrible
Maven is. SBT still has its issues (OMG why is everything a macro!), but I
still prefer it to trying to build anything in Maven.

~~~
neeleshs
I have exactly the opposite view. Until very recently modules in sbt required
a scala Build file. There is not one single file where you have a view of
everything - plugins, build properties, sbt file, and sbt scala file. I prefer
maven over SBT any time of the day. Have not tried Gradle, so cant comment

------
a3n
Irrelevant aside: my eyes! I was astounded to see plain text twisted up so
badly. It literally made my eyes water. Was that some artful/ironic attempt to
reproduce ink-bleeding typewritten pages? *View/Page Style/No Style" was the
only way I could tolerate this.

