Ivy Chinese Reference Document (6)-best Practices (top)

Here are some suggestions and best practices that we have gathered from our experience and some of our clients ' consultancy work.

1 Add module descriptors for all modules

In the world of Ivy, the module descriptor is a kind of ivy file, basically a simple XML file that describes what the module produces as a product and its dependencies.

It is a good habit to write or download module descriptors for all the modules involved in your development, even if they do not provide their own module descriptors.

At first it will look like an extra job and take time. But when you have multiple modules and use the same third-party libraries, you just need to add a line to your Ivy file to get the class library and the dependencies it has on what you really need (if you have the correct module descriptor in your warehouse, especially with the module configuration). It can be very helpful when you want to update a dependency. A simple modification in the Ivy file of your module will get the updated version and its updated (or not) dependencies.

So we recommend adding Ivy files to all the modules in your warehouse, and you can even enforce the rule by setting the ALLOWNOMD property on your parser to false. You do not need to use a dependency on the inclusion/exclusion/specification These ivy features that can only be used in very special situations.

2 Use your own enterprise warehouse

This is often not the right advice for open source projects, but for the corporate world we strongly recommend that we avoid relying on a common warehouse like Mave ibiblio or Ivyrep. Why? Well, here's a bunch of reasons:

1. Control

The main problem with public warehouses is that you have no control over the warehouse. This means that if a module descriptor is corrupted, you can't easily fix it. Of course, you can use a chain of shared warehouses and public warehouses, and place your repaired module descriptors in a shared warehouse so that it can hide the public warehouses, but this can lead to problems with warehouse browsing and maintenance.

More problems are possible updates to the warehouse. We know that the release in the warehouse should be stable and not updated, but we also frequently see that the module descriptor has many bugs, or the product is corrupted. Even some times we see a new version using the same name as the previous version, because the previous version was simply packaged incorrectly.　This setting happens in the best of things, like our ivy1.2:-). Later we decided to release a new version using a different name, 1.2a. But if the warehouse manager allows similar updates, this means that previous work can be broken. This will destroy the reproducibility of your build.

2. Reliability

The reliability of the Mave warehouse is not very good (we often experience very slow, even inaccessible), while Ivyrep is only supported by a small company (yes, we are just a small company). Because of the slow speed and the site hangs of the situation will also occur. And if the warehouse you rely on falls down, this will cause your development or release process to slow down severely.

3. Accuracy

A public warehouse usually contains much more than you actually need. Is this a problem? That's what we think. We believe that the class library you use in an enterprise environment requires some validation before it is used by every project in your company. And what is the way to do it well? Create an enterprise warehouse that contains only the class libraries you actually need to use. This will not only ensure that your application relies on better quality, but also helps you use the same version everywhere, even when you can affirm your module dependencies. If you use a tool like Ivyde, the automatic completion of the code will closely display the appropriate information for your warehouse and the class library you actually need to use.

4. Security

From the module warehouse blind artifacts are usually executable, which involves security issues. Imagine a hacker replacing Commons-lang with a virus-containing version? If you rely on a public warehouse to build your software, it will have a security risk. You see here you can see more relevant information from Forrester article.

Note that it is not to say that the use of the Enterprise warehouse will have to be built thoroughly by hand. Ivy has an installation task that can be used to install modules from one warehouse to another, so it can be used to selectively install modules from the public warehouse to your corporate warehouse, where you will have the ability to ensure control, reliability and accuracy.

3 usage patterns at least on the organization and module

Ivy is very flexible and can adapt to many existing warehouses by using the concept of patterns. But if your warehouse does not exist now, we strongly recommend that you always use the organization and module names in your schema, or even that you simply place your own module's private repository (where all organizations are the same). Why? Because Ivy listing feature (List feature?) Depends on the tags found in the pattern. If there is no organization tag in your model, Ivy will not be able to list the organization in your warehouse. For example, this would be a problem for automating the code in Ivyde, as well as for warehouse-wide tasks such as installation and warehouse reporting.

4 release ivysettings.xml for public warehouses

If you create a public warehouse, please provide a ivysettings.xml URL address. It's easy to do, and if someone wants to leverage your warehouse, he just needs to set up this URL of your ivysettings.xml to load it, or include it in its own configuration file, which makes it easy to combine multiple public warehouses.