Author: xavier
Date: Sun Oct 21 01:40:35 2007
New Revision: 586872
URL: http://svn.apache.org/viewvc?rev=586872&view=rev
Log:
slight review of best practices: talk about security as argument for enterprise
repository + some minor updates
Modified:
incubator/ivy/core/trunk/doc/bestpractices.html
Modified: incubator/ivy/core/trunk/doc/bestpractices.html
URL:
http://svn.apache.org/viewvc/incubator/ivy/core/trunk/doc/bestpractices.html?rev=586872&r1=586871&r2=586872&view=diff
==============================================================================
--- incubator/ivy/core/trunk/doc/bestpractices.html (original)
+++ incubator/ivy/core/trunk/doc/bestpractices.html Sun Oct 21 01:40:35 2007
@@ -40,9 +40,10 @@
This is usually not a valid recommendation for open source projects, but for
the enterprise world we strongly suggest to avoid relying on a public
repository like maven ibiblio or ivyrep. Why? Well, there are a couple of
reasons:
<ul>
<li>control</li> The main problem with this kind of public repositories is
that you don't have control over the repository. This means that if a module
descriptor is broken you cannot easily fixed it. Sure you can use a chain
between a shared repository and the public one and put your fixed module
descriptor in the shared repository so that it hide the one on the public
repository, but this makes repository browsing and maintenance cumbersome.
-Even more problematic is the possible updates of the repository. We know that
versions published in such repositories should be stable and not be updated,
but we also frequently see that a module descriptor is buggy, or an artifact
corrupted. We even see sometimes a new version published with the same name as
the preceding one because the previous one was simply badly packaged. This can
occur even to the best, it occured to us with Ivy 1.2 :-) But then we decided
to publish the new version with a different name, 1.2a. But if the repository
manager allow such updates, this means that what worked before can break. It
can thus break your build reproducibility.
-<li>reliability</li> Ibiblio maven repository is not particularly well known
for its reliability (we often experience major slow down or even complete break
of the site), and ivyrep is only supported by a small company (yes we are only
a small company!). So slow down and site hang occurs also. And if the
repository you rely on is down, this can cause major slow down in your
development or release process.
-<li>accuracy</li> a public repository usually contains much more than what you
actually need (except maybe ivyrep which certainly features much less than what
you need :-)). Is it a problem? We think so. We think that in an enterprise
environment the libraries you use should step through some kind of validation
process before being used in every projects of your company. And what better
way to do so? Setup an enterprise repository with only the libraries you
actually want to use. This will not only ensure a better quality of your
application dependencies, but help to have the same versions everywhere, and
even help when declaring your module dependencies, if you use a tool like
IvyDE, the code completion will only show relevant information about your
repository, with only the libraries you actually want to see.
+Even more problematic is the possible updates of the repository. We know that
versions published in such repositories should be stable and not be updated,
but we also frequently see that a module descriptor is buggy, or an artifact
corrupted. We even see sometimes a new version published with the same name as
the preceding one because the previous one was simply badly packaged. This can
occur even to the best, it occurred to us with Ivy 1.2 :-) But then we decided
to publish the new version with a different name, 1.2a. But if the repository
manager allow such updates, this means that what worked before can break. It
can thus break your build reproducibility.
+<li>reliability</li> Maven repository is not particularly well known for its
reliability (we often experience major slow down or even complete break of the
site), and ivyrep is only supported by a small company (yes we are only a small
company!). So slow down and site hang occurs also. And if the repository you
rely on is down, this can cause major slow down in your development or release
process.
+<li>accuracy</li> a public repository usually contains much more than what you
actually need. Is it a problem? We think so. We think that in an enterprise
environment the libraries you use should step through some kind of validation
process before being used in every projects of your company. And what better
way to do so? Setup an enterprise repository with only the libraries you
actually want to use. This will not only ensure a better quality of your
application dependencies, but help to have the same versions everywhere, and
even help when declaring your module dependencies, if you use a tool like
IvyDE, the code completion will only show relevant information about your
repository, with only the libraries you actually want to see.
+<li>security</li> the artifacts you download from a module repository are
often executable, and are thus involved in security concerns. Imagine a hacker
replacing commons-lang by another version containing a virus? If you rely on a
public repository to build your software, you expose it to a security risk. You
can read more about that in this <a
href="http://www.fortifysoftware.com/servlet/downloads/public/fortify_attacking_the_build.pdf";>Forrester
article</a>.
</ul>
Note that it's not because you use an enterprise repository that you have to
build it entirely by hand. Ivy features an [[ant:install]] task which can be
used to install modules from a repository to another one, so it can be used to
selectively install modules from a public repository to your enterprise
repository, where you will then be able to ensure control, reliability and
accuracy.
@@ -50,7 +51,7 @@
Ivy is very flexible and can accomodate a lot of existing repositories, using
the concept of <a href="concept.html#pattern">patterns</a>. But if your
repository doesn't exist yet, we strongly recommend to always use the
organisation and the module name in your pattern, even for private repository
where you put only your own modules (which all the same organisation). Why?
Because Ivy listing feature rely on the token it can find in the pattern. If
you have no organisation token in your pattern, Ivy won't be able to list the
(only?) organisation in your repository. And this can be a problem for code
completion in IvyDE, for example, but also for repository wide tasks like
[[ant:install]] or [[ant:repreport]].
<h1>Public ivysettings.xml with public repositories</h1>
-If you create a public repository, provide an url to corresponding <a
href="configuration.html">ivysettings.xml</a>. It's pretty easy to do, and if
someone want to leverage your repository, he will just have to call
[[ant:configure]] with the url of your ivysettings.xml, or <a
href="configuration/include.html">include</a> it in its own configuration file,
which makes it really easy to combine several public repositories.
+If you create a public repository, provide an url to corresponding <a
href="configuration.html">ivysettings.xml</a>. It's pretty easy to do, and if
someone want to leverage your repository, he will just have to load it with
[[ant:settings]] with the url of your ivysettings.xml, or <a
href="configuration/include.html">include</a> it in its own configuration file,
which makes it really easy to combine several public repositories.
<h1>Dealing with integration versions</h1>
Very often especially when working in a team or with several modules, you will
need to rely on intermediate, non finalized versions of your modules. These
versions are what we call integration versions, because their main objective is
to be integrated with other modules to make and test an application or a
framework.
