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>
