svn commit: r586872 - /incubator/ivy/core/trunk/doc/bestpractices.html

[xa...@apache.org]

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.