You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by xa...@apache.org on 2008/01/03 13:02:44 UTC

svn commit: r608459 - in /ant/ivy: core/trunk/doc/configuration/include.html site/features.html site/m2comparison.html

Author: xavier
Date: Thu Jan  3 04:02:38 2008
New Revision: 608459

URL: http://svn.apache.org/viewvc?rev=608459&view=rev
Log:
some documentation and site review

Modified:
    ant/ivy/core/trunk/doc/configuration/include.html
    ant/ivy/site/features.html
    ant/ivy/site/m2comparison.html

Modified: ant/ivy/core/trunk/doc/configuration/include.html
URL: http://svn.apache.org/viewvc/ant/ivy/core/trunk/doc/configuration/include.html?rev=608459&r1=608458&r2=608459&view=diff
==============================================================================
--- ant/ivy/core/trunk/doc/configuration/include.html (original)
+++ ant/ivy/core/trunk/doc/configuration/include.html Thu Jan  3 04:02:38 2008
@@ -45,7 +45,7 @@
 <code type="xml">
 <ivysettings>
   <property name="myrepository" value="path/to/my/real/rep"/>
-  <conf defaultResolver="default"/>
+  <settings defaultResolver="default"/>
   <include file="path/to/ivysettings-default.xml"/>
 </ivysettings>
 </code>
@@ -59,7 +59,7 @@
 </ivysettings>
 </code>
 
-The included ivysettings defines a resolver named default, which is an ivyrep resolver, with its root configured as being the value of myrepository variable. This variable is given the value path/to/rep in the included file, but because the attribute overwrite is set to false, it will not overide the value given in the main ivysettings including this one, so the value used for myrepository will be path/to/my/real/rep.
+The included ivysettings defines a resolver named default, which is an ivyrep resolver, with its root configured as being the value of myrepository variable. This variable is given the value path/to/rep in the included file, but because the attribute overwrite is set to false, it will not override the value given in the main ivysettings including this one, so the value used for myrepository will be path/to/my/real/rep.
 <hr/>
 <code type="xml">
 <ivysettings>

Modified: ant/ivy/site/features.html
URL: http://svn.apache.org/viewvc/ant/ivy/site/features.html?rev=608459&r1=608458&r2=608459&view=diff
==============================================================================
--- ant/ivy/site/features.html (original)
+++ ant/ivy/site/features.html Thu Jan  3 04:02:38 2008
@@ -28,8 +28,8 @@
 <p>Ivy is a very powerful dependency manager oriented toward Java dependency management, even though it could be used to manage dependencies of any kind.</p>
 <p>If you don't see why you should use a dependency manager at all, or have any question concerning Ivy in general, have a look at the <a href="faq.html">FAQ</a> and at the [[mailing-lists]].</p>
 <h1>Integrated with Ant</h1>
-<p>Of course, Ivy is integrated with the most popular build management system for Java projects. But the integration goes way beyond common Ant integration. Indeed Ivy has been designed with Ant integration and design principles in mind. If you have Ant skills, you already have Ivy skills! The plugin mechanism in Ivy follows the same design as Ant, you will find macrodef and files import in Ivy configuration, many things with which Ant users are already familiar with.<br/>
-And since Ivy is now an Apache project, we are getting even closer to Ant development.</p>
+<p>Of course, Ivy is integrated with the most popular build management system for Java projects. But the integration goes way beyond common Ant integration. Indeed Ivy has been designed with Ant integration and design principles in mind. If you have Ant skills, you already have Ivy skills! The plugin mechanism in Ivy follows the same design as Ant, you will find macrodef and files import in Ivy configuration, many things Ant users are already familiar with.<br/>
+And as Ivy is a sub project of Ant, we even share the same development community!</p>
 <h1>Simple to use</h1>
 <p>For simple cases, Ivy is easy to use. Declare your dependencies, and that's all. See the [[doc:tutorial/start quick start tutorial]] to check yourself, it should take less than 5 minutes!</p>
 <p>Ivy can therefore be used to bring the dependency management feature of maven to Ant build files, for those of you who already use Ant and who do not want to setup a maven project. But Ivy does not stop there, it provides many more great features!</p>
@@ -45,20 +45,19 @@
 <p>With Ivy, you usually do not have to adapt your project to Ivy structure, Ivy will conform to your environment.</p>
 <p>Even though Ivy comes with a lots of default values to work out of the box, you can change many things in Ivy. Of course, the dependencies repositories possibilities covers a lot of uses (file system, URL based, repository chaining, ...). But that's not all. You can change the way Ivy finds latest versions of your dependencies, you can change of conflict manager, you can choose if you want Ivy to copy dependencies in your project libs or use them directly from Ivy cache, ...</p>
 <h1>Easily extensible</h1>
-<p>When Ivy does not do what you want out of the box, you can often extend it to solve your problem. For instance, you can plug your own repository (like Scott Haug did for a svn repository now available in Ivy tools). But you can also define your own latest strategy and your own conflict manager. See [[doc:extend how to extend Ivy]] in the reference doc. </p>
-<p>Since Ivy 1.4 you can even define very easily your own metadata on your modules, with [[doc:concept extra attributes]].</p>
+<p>When Ivy does not do what you want out of the box, you can often extend it to solve your problem. For instance, you can plug your own repository. But you can also define your own latest strategy and your own conflict manager. See [[doc:extend how to extend Ivy]] in the reference doc. </p>
+<p>Moreover you can even define very easily your own metadata on your modules, with [[doc:concept extra attributes]].</p>
 <h1>High performances</h1>
-<p>In Ivy, performances have been taken in consideration from the beginning. It uses a cache to avoid downloading twice a dependency, its strong conflict management system has been thought to avoid downloading a dependency if not necessary, all configuration and Ivy file parsing are done using SAX for maximum performance, and so on...</p>
+<p>In Ivy, performances have been taken in consideration from the beginning. It uses a cache to avoid downloading twice a dependency, its strong conflict management system has been thought to avoid downloading a dependency if not necessary, all settings and Ivy files parsing are done using SAX for maximum performance, and so on...</p>
 <h1>Transitive dependencies</h1>
-<p>Imagine you have a component that you often reuse in your software development. Imagine that this component has dependencies as well. Then with classical dependency management, each time you use this component in your software you have to declare it as a dependency, but also all its dependencies.</p>
+<p>Imagine you have a component that you often reuse in your software development. Imagine that this component has dependencies as well. Then without a good dependency management tool, each time you use this component in your software you have to declare it as a dependency, but also all its dependencies.</p>
 <p>With Ivy it's different: you simply write a dependency file once for the component, declaring its own dependencies, then anytime you want to use this component you simply have to declare a dependency on it.</p>
 <p>And this is even more powerful if the component your software depends on changes of dependencies during its own development. Then, without Ivy, you have to maintain all your components dependencies declaration each time the dependencies of this component change. With Ivy, you update the Ivy file of the component and that's it !</p>
-<p><i>If you want to quickly start using this feature or simply see it in action with real world examples, check the official repository: <a href="http://ivyrep.jayasoft.org/">ivyrep</a></i></p>
 <h1>Strong conflict management</h1>
-<p>The problem with transitive dependencies is that it's sometimes difficult to know exactly which version of a dependency you get, because several modules are depending on it in different versions. Ivy provides a strong and flexible conflict management engine, which let you easily choose which version should be evicted or kept if its default behaviour does not fit your needs. </p>
+<p>The problem with transitive dependencies is that it's sometimes difficult to know exactly which version of a dependency you get, because several modules are depending on it in different versions. Ivy provides a strong and flexible conflict management engine, which let you easily choose which version should be evicted or kept if its default behavior does not fit your needs. </p>
 <p>It is also fully integrated with transitive dependencies management, which means that conflicts are solved for each dependency before being solved for your whole module. This  ensures that problematic conflicts will only need to solved in the dependency they are encountered.</p>
-<h1>Out of the box ibiblio repository support</h1>
-<p>Maven users all know this repository, where you can find a lot of Java projects artifacts. With Ivy, you benefit from this repository out of the box. But you even benefit from more, since Ivy also uses its <a href="http://ivyrep.jayasoft.org/">own repository</a> for dependencies metadata, leveraging the power of transitive dependencies.</p>
+<h1>Out of the box maven repository support</h1>
+<p>The public maven repository has many advantages: a lot of modules available, easy search with mvnrepository.com, ... With Ivy, you benefit from this repository out of the box thanks to maven 2 metadata compatibility. </p>
 <h1>Continuous Integration Ready</h1>
 <p>Are you working in a continuous integration environment? No? You should ;-)</p>
 <p>If you are working in a continuous integration environment, and if you have many projects that depend one on each other, then you are maybe experiencing the dependency management nightmare... Fortunately, Ivy is there to help !</p>
@@ -70,14 +69,14 @@
 <h1>Unique enterprise features</h1>
 <p>Ivy is the only dependency management tool to support powerful features such as repository namespace and building through the install task. A [[doc:tutorial/build-repository tutorial]] is dedicated to this feature, and show you how you can build your own repository importing data from public one, and converting heterogeneous repositories into a stable and homogeneous one.</p>
 <h1>Heavily tested</h1>
-<p>Ivy benefits from a lot of unit tests checked at each code modification. It is also under heavy testing by the community itself, and bugs reported by the community are often fixed in only a few days.</p>
-<h1>Supported by several tools</h1>
-<p>A growing number of tools support Ivy, see the <a href="links.html">links</a> page for details.</p>
+<p>Ivy benefits from a lot of unit tests checked at each code modification. It is also under heavy testing by the community itself, and we pay a lot of attention to bug fixing and code stability.</p>
 <h1>Free and open source</h1>
-<p>Ivy is an incubating Apache project, which means that it's fully open sourced, with a business friendly Apache license.</p>
+<p>Ivy is an Apache project, which means that it's fully open sourced, with a business friendly Apache license.</p>
 <p>Being open source, you can even modify it for your own needs, and let the community benefit from your enhancements if you like.</p>
 <h1>Extensively documented</h1>
-<p>With Ivy, not only the tool is free and open source, but you also have access to a documentation of about 120 pages in its printer friendly version for free!</p></textarea>
+<p>With Ivy, not only the tool is free and open source, but you also have access to a very detailed documentation including tutorials and reference documentation, all for free!</p>
+<h1>Self contained</h1>
+<p>The core Ivy engine which allows to perform most of Ivy features is provided as a single jar with no dependency at all, except on JRE 1.4 or greater. This means that you can very easily use Ivy to bootstrap your build system, or embedded in your own tool. Ant support itself is provided only as a thin wrapper over Ivy engine so that you can do everything in embedded or standalone mode</p></textarea>
 <script type="text/javascript">xooki.postProcess();</script>
 </body>
 </html>

Modified: ant/ivy/site/m2comparison.html
URL: http://svn.apache.org/viewvc/ant/ivy/site/m2comparison.html?rev=608459&r1=608458&r2=608459&view=diff
==============================================================================
--- ant/ivy/site/m2comparison.html (original)
+++ ant/ivy/site/m2comparison.html Thu Jan  3 04:02:38 2008
@@ -29,23 +29,22 @@
 
 Obviously this comparison is biased (hey, you are on official Ivy site :-)), but we'll try to keep it as fair as possible. Do not hesitate to add comment if you feel something is missing or false on this page. You can also have a look at <a href="http://docs.codehaus.org/display/MAVEN/Feature+Comparisons">Maven2 feature comparison page on codehaus</a>, which itself offers another point of view.
 
-There have been also severa discussions on the subject, among which the one triggered by <a href="http://www.jayasoft.org/node/806.html">spring contemplating about switching to maven</a> is may be the more interesting.
+There have been also several discussions on the subject, among which the one triggered by <a href="http://xhab.blogspot.com/2006/09/interesting-discussions-about-maven-vs.html">spring contemplating about switching to maven</a> is may be the more interesting.
 
 But here is the points we think mainly differentiate maven2 and Ivy.
 
 <h1>Comparing plants and apples</h1>
-First, the most important difference between maven2 and ivy is that they aren't at all the same kind of tools. Maven2 is a software project management and comprehension tool, whereas Ivy is only a dependency management tool, highly integrated with ant, the popular build management tool. Maven2 offers dependency management facility, and that's why many ask how ivy compares to maven2. That's why we'll focus only on dependency management features of maven2 in this comparison.
-So if you look for an out of the box software project management tool, you may skip the rest of this comparison and check what maven2 has to offer.
+First, the most important difference between maven2 and ivy is that they aren't at all the same kind of tools. Maven2 is a software project management and comprehension tool, whereas Ivy is only a dependency management tool, highly integrated with Ant, the popular build management tool. So maybe a more interesting comparison would compare Ant+Ivy vs Maven 2. But this goes beyond the scope of this page which concentrates on dependency management only. 
 
 <h1>Different concepts</h1>
 Ivy heavily relies on a unique concept called configuration. In ivy, a module configuration is a way to use or to see the module. For instance, you can have a test and runtime configuration in your module. But you can also have a mysql and an oracle configuration. Or an hibernate and a jdbc configuration. In each configuration you can declare what artifacts (jar, war, ...) are required. And in each configuration, you can declare your dependencies on other modules, and describe which configuration of the dependency you need. This is called configuration mapping, and it is a very flexible way to answer to a lot of problems we face very often in software development.
 
-Maven2 on its side has something called the scope. You can declare a dependency as being part of the test scope, or the buildtime scope. Then depending on this scope you will get the dependency artifact (only one artifact per module in maven2) with its dependencies depending on their scope. Scopes are predefined in maven2 and you can't change that. No way to create an oracle scope. No way to indicate you need what as been declared to be needed in the runtime scope of your dependency in your compile one. Everything here is written in the marble.
+Maven2 on its side has something called the scope. You can declare a dependency as being part of the test scope, or the buildtime scope. Then depending on this scope you will get the dependency artifact (only one artifact per module in maven2) with its dependencies depending on their scope. Scopes are predefined in maven2 and you can't change that. No way to create an oracle scope. No way to indicate you need what has been declared to be needed in the runtime scope of your dependency in your compile one. Everything here is written in the marble.
 
 And this leads to some kind of troubles... as Matt Raible stated in his <a href="http://raibledesigns.com/page/rd?anchor=maven_2_s_transitive_dependencies">blog</a> talking about maven2 dependencies:
-[quote]
+<blockquote>
 There are a *lot* of unnecessary dependencies downloaded for many libraries. For example, Hibernate downloads a bunch of JBoss JARs and the Display Tag downloads all the various web framework JARs. I found myself excluding almost as many dependencies as I added.
-[/quote]
+</blockquote>
 The problem is that hibernate can be used with several cache implementations, several connection pool implementation, ... And this can't be managed with scopes, wheres Ivy configurations offers an elegant solution to this kind of problem. For instance, in ivy, assuming hibernate as an ivy file like <a href="http://ivyrep.jayasoft.org/hibernate/hibernate/ivy-2.1.8.xml">this one</a>, then you can declare a dependency like that:
 <code type="xml">
 <dependency org="hibernate" name="hibernate" rev="2.1.8" conf="default->proxool,oscache"/>
@@ -57,7 +56,8 @@
 to get hibernate with dbcp and swarmcache.
 
 <h1>Documentation</h1>
-An important thing to be able to use a tool is its amount of documentation. With Ivy, even if they are written in broken english (would you have prefered well written french :-)), the printer friendly version of the documentation is now about 120 pages. 
+An important thing to be able to use a tool is its amount of documentation. With Ivy, even if they are written in broken english (would you have preferred well written french :-)), the reference documentation is extensive and covers all the features including many examples. We also provide some official tutorials which are maintained with the new versions of Ivy. And since we consider documentation so important, we also provide online versions of documentation per Ivy version since Ivy 2.0.0-alpha2.
+
 With maven2, it's a bit difficult to clearly know what can be considered as dependency management documentation, but we didn't managed to find much: some small introductory guides, short entries in the pom reference guide, and not really much more. Even in the maven book you can get for free on <a href="http://www.mergere.com/">mergere website</a>, the insight about dependency management is still light in our point of view. 
 
 <h1>Conflict management</h1>
@@ -66,12 +66,15 @@
 With maven2, conflict management is quite simple: the principle is to get the nearest definition. So if your module depends on foo 1.0, none of your dependencies will ever manage to get foo 1.1 without a change in your own dependency declaration. It may be ok in some cases, it may not in others...
 
 <h1>Flexibility</h1>
-In ivy many things can be [[doc:configuration configured]], and many others can be [[doc:extend plugged in]]: dependency resolvers, conflict manager, module descriptor parser, latest revision strategy, ... Maven2 also offers repository pluggability, but not much more as far as we know. Moreover, repository configuration seems to be less flexible than with ivy.
+In Ivy many things can be [[doc:configuration configured]], and many others can be [[doc:extend plugged in]]: dependency resolvers, conflict manager, module descriptor parser, latest revision strategy, ... 
+
+Maven2 also offers repository pluggability, but not much more as far as we know. Moreover, repository configuration is much less flexible than with Ivy: no repository chaining, no way to split metadata and artifacts in multiple repositories, ...
 
 <h1>Public Repositories</h1>
-Maven2 comes out of the box configured to use ibiblio maven2 repository, which contains <strong>a lot</strong> of modules (both artifacts and module descriptors). The only problem some may face is that module descriptors are not always checked, so some are not really well written.
-Ivy, on its side, is used out of the box with ivyrep, ivy official repository, which contains only a few modules, and is not updated frequently. But it is also compatible with maven1 ibiblio repository (for artifacts only, no module descriptors), can also be used with maven2 repository (with pom compatibility, but you will here face some naming problems - that can be addressed using the namespace feature-, you won't benefit from ivy configurations with the module descriptors found there, and, let's face it, the maven2 compatibility of Ivy is far from maven's one :-)), and also has an ivyrep sandbox in which much more module descriptors can be found (not checked, as with ibiblio repository).
-	</textarea>
+Maven2 comes out of the box configured to use maven2 repository, which contains <strong>a lot</strong> of modules (both artifacts and module descriptors). The only problem some may face is that module descriptors are not always checked, so some are not really well written.
+Ivy being compatible with maven 2 metadata, the default public repository used is also the maven 2 repository, which is fine for a good out of the box experience. 
+
+However, we [[doc:bestpractices don't recommend]] to use such a public repository for an enterprise build system, and as such Ivy provides features and documentation to build your own enterprise repository based (or not) on data available in the public repository. </textarea>
 <script type="text/javascript">xooki.postProcess();</script>
 </body>
 </html>