Difference between revisions of "Talk:Creating gCube Maven components: How-To"
(Created page with '== Dependencies on External Repositories == gCube building and deployment environment are configured to use gCube Snapshots (only in /devsec scope), gCube Releases, gCube Extern…') |
|||
| Line 1: | Line 1: | ||
| − | == Dependencies on External Repositories == | + | === Dependencies on External Repositories === |
| − | gCube building and deployment | + | gCube building and deployment environments are configured to use gCube Snapshots (only in /devsec scope), gCube Releases, gCube Externals and Maven Central repositories for dependency resolution. In other words, any dependency declared in pom.xml that can be found in those repositories will be resolved at build time and deployment time without any further configuration. To emulate this behaviour also in development environment, it is strongly suggested to use the settings.xml file suggested here |
| − | Of course, range of usable software is not limited to the artifacts deployed on aforementioned repositories. Frequently it happens that gCube components needs software stored on external public Maven repositories. In this case, Maven provides an easy solution for declaring additional repositories for dependency resolution by adding a <repositories> section in the pom.xml of the project. | + | Of course, range of usable software is not limited to the artifacts deployed on aforementioned repositories. Frequently it happens that gCube components needs software stored on external public Maven repositories. In this case, Maven provides an easy solution for declaring additional repositories for dependency resolution by adding a <repositories> section in the pom.xml of the project. E.g.: |
| + | <source lang="xml" highlight="3,4"> | ||
| + | <repositories> | ||
| + | <repository> | ||
| + | <id>[repository-id]</id> | ||
| + | <url>[repository URL]</url> | ||
| + | </repository> | ||
| + | </repositories> | ||
| + | </source> | ||
| + | Though technically possible to add any Maven Exetrnal repository in this way, in order to guarantee the quality of gCube software it is required to check quality and trustwhortiness of its dependencies disallowing usage of external software that does not pass a quality check. To enforce such a control over external Maven repositories, Cube components are allowed to use external repository not directly but only through a proxy repository (a.k.a. shadow repository) created on CNR's Nexus Repository Portal. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Revision as of 17:15, 18 June 2012
Dependencies on External Repositories
gCube building and deployment environments are configured to use gCube Snapshots (only in /devsec scope), gCube Releases, gCube Externals and Maven Central repositories for dependency resolution. In other words, any dependency declared in pom.xml that can be found in those repositories will be resolved at build time and deployment time without any further configuration. To emulate this behaviour also in development environment, it is strongly suggested to use the settings.xml file suggested here
Of course, range of usable software is not limited to the artifacts deployed on aforementioned repositories. Frequently it happens that gCube components needs software stored on external public Maven repositories. In this case, Maven provides an easy solution for declaring additional repositories for dependency resolution by adding a <repositories> section in the pom.xml of the project. E.g.:
<repositories> <repository> <id>[repository-id]</id> <url>[repository URL]</url> </repository> </repositories>
Though technically possible to add any Maven Exetrnal repository in this way, in order to guarantee the quality of gCube software it is required to check quality and trustwhortiness of its dependencies disallowing usage of external software that does not pass a quality check. To enforce such a control over external Maven repositories, Cube components are allowed to use external repository not directly but only through a proxy repository (a.k.a. shadow repository) created on CNR's Nexus Repository Portal.
Addition of an third party repository proxy in Nexus
Any developer that needs to use an externa public Maven repository, should never use it directly, but asking for creation of a proxy of that repository on Nexus.
Procedure for asking addition of a proxy repository is: 1) open a ticket of type "Task" in iMarine TRAC (at .......URL.....) 2) ticket's description must report:
- URL of repository to add - organization which hosts the repository - license of software stored in the repository (if available) - reasons (e.g. which gCube component needs it)
3) assign the ticket to the Release Manager
Release Manager will process the ticket checking that software satisfy the quality level and no license issue migth rise from the usage of software stored in the repository. If request is accepted, a new proxy repository is created and the repository's id will be communicated publicly on gCube's developers mailinglist (a.k.a. TCOM mailinglist).
Furthermore, the repository will be added to gcube-public-deps grouping repository.
Troubleshooting It might happens that a new proxy repository will appear as empty in Nexus and any search (through Nexus Portal as well as from Eclipse) performed to find artifacts contained in the proxed repository will not find any artifact. This is a normal behaviour because Nexus download an artifact from the proxed repository only upon explicit request. After the first request, the artifact is added to Nexus indexes and will be, in such a way, discoverable browinsg and/or searching the indexes.
This issue does not take place when the proxed repository has index files (..... eg..... ) recognized and read by Nexus.
