Using Ivy in AppFuse
I'll admit, the thought of not checking in JARs to AppFuse's CVS is intriguing. With Ivy, I think I could pull off the current setup, plus a dynamic-downloading system. By current setup, I mean that the JARs are distributed in your "lib" directory and you can build your app w/o downloading any dependencies. I like this because I can develop AppFuse and not worry about my internet connection.
Dion doesn't get my love for checking in JARs. The main reason I do it is because it takes me a less time to download a new release and check it into CVS than it takes me to find that same release in Maven's Repo. Case in point: Hibernate 3.
I love the idea of Ivy, and mockhaug makes it sounds great, but I don't want to have to create a bunch of metadata whenever I want to use something like Hibernate 3. Then again, if Ivy is ever going to catch on, someone has to do it.
In conclusion, I'm still not convinced I should integrate Ivy into AppFuse - sounds like maintaining and uploading dependencies would be a lot more work than just checking in JARs. If there was a person responsible for creating Ivy metadata every time a new release came out, I might think different.
Posted by Trygve Laugstøl on April 13, 2005 at 09:32 PM MDT #
this is also a compelling reason to check in ant and all of it's libraries as well. it's also beneficial if you add 3rd party tasks you don't need to go around to every developer to tell them to install the jar, they automatically pull it on an update. i used this method at my last place of employment and it worked out very well (current place uses maven - yuck!) i will be carrying this concept over to my next job as well.
Posted by jae on April 13, 2005 at 09:43 PM MDT #
Another alternative is to use Maven with Ant. Maven2 was built from components, and we have from the beginning intended to make those components available where it makes sense, and the artifact handling is definitely one of those cases. We intend to release Ant tasks (there were some in CVS a year ago, but were delayed until the first releases came out) that would allow you to use Maven's transitive dependencies support in Ant.
It's also worth noting Ant 1.7 has library support (without some of the advanced dependency features) using the Maven2 repository, out of the box.
In response to jae's comment - Maven is no worse in this instance, you still get back what you tagged because the versions haven't changed, unless you are following a practice of dropping new JARs into the repository with the same version. SNAPSHOTs are different, though you can still resolve them if you want to tag a release and get something buildable in the future. We need to improve in the areas you've mentioned - making sure the Maven and plugins versions can also be tagged - and don't stop there, remember the JDK (care to check that in to source control? :)
Posted by Brett Porter on April 13, 2005 at 10:45 PM MDT #
In Brett's post, Xavier Hanin, (an?) author of Ivy, makes a valid argument for why POMs are currently insufficient for describing the information needed for by Ivy, that being multiple configurations. This is a very compelling feature, and our build now makes extensive use of it. Our webapp build has configurations that represent compiling, test, deployment, and more. In maven1, one could attach properties to dependencies that certain plugins would recognize for their own benefit, but this mechanism is very ad-hoc, and not used by plugins that could benefit from this type of grouping.
That said, having to create my own ivy descriptors for our 3rdparty dependencies has been annoying, and hopefully maven and ivy can work together to find a common format. But as it stands now, the current Maven POM format doesn't provide enough information to take full advantage of Ivy's capabilities.
PS Matt, your link to Dion's site is instead pointing to Ivy's.
Posted by Scott Haug on April 14, 2005 at 12:10 AM MDT #
Posted by Matt Raible on April 14, 2005 at 04:29 AM MDT #
As an author of ivy (we're 4 in the company, and even if I am the main developer, others often contribute), I would like to precise that we haven't made ivy to beat against maven. The fact that ivy is integrated with ant and not with maven is only because we personnaly use ant, because it fulfills our needs. And as we don't charge for ivy, we still first focus on our needs.
But we would really be glad to share metadata with maven2. But as Scott pointed out, it's not possible for the moment, because we need the feature called configuration and it is not supported in maven2 for the moment. But if we can work together with maven team to go in this direction, we'll be really happy to do this.
And concerning the fact to put jars in version control as jae suggest, I am personnaly not a big fan of this approach. Problems I encountered with source control was particularly slowness. In my previous job, we used a homemade dependency manager using cvs to check for dependencies. And it often took minutes to get your dependencies, even if few of them were to be updated.
Now that we use ivy and a repository in a shared directory, it usually takes a few seconds. The repository being backed up as our source control base is, no problem with that. And to go back to a previous version, no problem with ivy, even if you use continuous integration: ivy is able to generate an ivy file with all "latest" versions fixed. Putting this generated file into source control ensures that we can revert back to a previous state. And we also do not have to inform others that a dependency version has changed, cause dependency resolution is part of our builds. And with transitive dependencies it's even better cause others using your project in their dependencies also have your dependency update without having to change anything in their project.
Posted by Xavier Hanin on April 14, 2005 at 02:55 PM MDT #